시스템이야기2014. 4. 9. 15:19

OpenSSL 1.0.1 Heartbleed 취약점

OpenSSL 1.0.1버전에 TLS heartbeat 취약점(일명 Heartbleed Bug라고 부름. CVE-2014-0160, openssl: information disclosure in handling of TLS heartbeat extension packets)이 있습니다. 

공격자가 https서버의 메모리 64KB 데이터를 볼 수 있습니다. 메모리에는 https서버와 유저간에 주고 받은 데이터들(ID/PW, ... 등의 정보)이 있는데, 공격자는 plain text형태로 볼 수 있습니다. 그리고,SSL 개인키를 얻을 수 있습니다. 반드시 업데이트하세요.


http://a4.aurynj.net/post/82075898166/heartbleed (Heartbleed 이슈에 관해 정리)

http://yisangwook.tumblr.com/post/82056087918/openssl-heartbeat-heartbleed (OpenSSL 취약점 발견. Heartbleed)

http://heartbleed.com/


1. 취약한 버전


OpenSSL 1.0.0과 0.9.8 버전은 취약하지 않으며,

1.0.1은 1.0.1f까지 취약합니다. 1.0.1g에서 패치되었구요.


http://www.openssl.org/news/secadv_20140407.txt



2. RHEL, CentOS


# yum update openssl*

... 생략 ...

=====================================================================

 Package              Arch      Version               Repository        Size

=====================================================================

Updating:

 openssl              x86_64    1.0.1e-16.el6_5.7     updates          1.5 M

 openssl-devel        x86_64    1.0.1e-16.el6_5.7     updates          1.2 M



3. FreeBSD


# freebsd-update fetch

# freebsd-update install

# ls -la /usr/lib*/libssl*

-r--r--r--  1 root  wheel  685846 Apr  9 12:28 /usr/lib/libssl.a

lrwxr-xr-x  1 root  wheel      11 Feb 25 09:24 /usr/lib/libssl.so -> libssl.so.7

-r--r--r--  1 root  wheel  430352 Apr  9 12:28 /usr/lib/libssl.so.7

-r--r--r--  1 root  wheel  713782 Apr  9 12:28 /usr/lib/libssl_p.a

-r--r--r--  1 root  wheel  470850 Apr  9 12:28 /usr/lib32/libssl.a

lrwxr-xr-x  1 root  wheel      11 Feb 25 09:26 /usr/lib32/libssl.so -> libssl.so.7

-r--r--r--  1 root  wheel  363552 Apr  9 12:28 /usr/lib32/libssl.so.7

-r--r--r--  1 root  wheel  480306 Apr  9 12:28 /usr/lib32/libssl_p.a

# 


업데이트 후 openssl사용하는 데몬은 재실행해주세요.



'시스템이야기' 카테고리의 다른 글

zabbix 셋팅값만 백업 후 DB 새로 구축하기  (0) 2015.06.19
텔레그램(Telegram)으로 서버 모니터링하기  (16) 2014.10.15
root권한 획득하는 리눅스 커널 취약점  (2) 2013.05.20
FreeBSD에서 Dell R620서버 NIC문제 해결  (0) 2013.02.05
Brocade SAN 스위치 펌웨어 업그레이드  (0) 2012.09.12
Posted by 좋은진호
IT이야기2013. 9. 17. 13:07

KT의 스미싱 접속 차단 서비스

'[국정원]내란음모로 인한 소환서 발부되었습니다 내용확인 rort.??/???'이라는 '스미싱 문자 기사'를 봤다.



apk파일을 받아보려고 'PC 브라우저'에서 접속해봤다. 그런데, '[olleh]스미싱 감염 예방 안내'라는 페이지( http://175.196.95.228/smishing.htm )로 바로 이동해버린다. KT가 스미싱 차단 서비스를 얼마전에 시작했는데, 이게 이통망만 적용한게 아니었다.


[olleh]스미싱 감염 예방 안내

1. 문자에 포함된 인터넷주소가 확실하지 않은 것이면 누르지 마십시오. 다양한 방법으로 유해어플이 설치되어 문자 수신이 안될 수 있습니다.

2. 올레마켓에서 알약(http://olleh.kr/alyac) 또는 올레스미싱차단 앱 등 백신을 다운받아 검사하시면 감염확인 및 치료를 할수 있습니다.

* 휴대폰을 최상의 상태로 유지하기 위하여는 하루에 한번 정도 전원을 껐다 켜 주세요.

다른망을 통해 PC에서 접속해봤는데, 악성 apk 배포 서버가 내려갔는지 접속은 안된다.


아무튼 안드로이드 사용자는 문자에 URL이 포함될 때 주의해야 한다.

1. 스마트폰에서 SMS문자의 URL을 누르지 않는다.
2. 실수로 URL을 눌렀을 때, 어플 설치하라는 메시지가 나오면 절대 설치하지 않는다.
3. URL을 '반드시' 확인해보고 싶다면(실제 지인이 보낸 문자일 가능성이 있을 때) 폰이 아닌 백신이 설치된 PC에서 크롬, 파폭 브라우저로 확인한다.

'IT이야기' 카테고리의 다른 글

구글 문화를 들여다보자, 책 ‘실리콘밸리 견문록’  (2) 2015.05.25
갤럭시 기어(Galaxy Gear) 사용 후기  (4) 2013.10.04
스마트폰을 라즈베리 파이 xbmc용 리모콘으로  (10) 2012.10.08
콘텐츠 룰 :: 글은 '미니스커트의 길이'만큼 짧게  (0) 2012.04.16
구글은 90만대 서버로 운영된다. 해외 다른 업체는?  (4) 2012.03.14
Posted by 좋은진호
시스템이야기2013. 5. 20. 18:56

root권한 획득하는 리눅스 커널 취약점

로컬에서 root ID를 얻을 수 있는 커널 취약점이 발견되었다. 해당 커널 버전은 2.6.37~3.8.9 이다.
그러나 CentOS 6.x(또는 RHEL)의 커널 2.6.32버전은 2.6.27에서 백포팅된 것이 있는데 해당 취약점까지 백포팅된 것으로 알려졌다.



CentOS 6.x버전을 사용중이면 커널 업데이트(지난주에 커널패치가 나옴)를 반드시 해야한다.

* CentOS 6.x에서 취약점없는 버전 : 2.6.32-358.6.2.el6.x86_64 <-- 패치 번호 -358.6.2가 문제 없음.

* Linux PERF_EVENTS Local Root

http://packetstormsecurity.com/files/121616/semtex.c
http://downloads.securityfocus.com/vulnerabilities/exploits/59846.c

커널 취약점 테스트 결과다. gcc 컴파일할 때 반드시 -O2 optimize 옵션을 넣고 테스트해야 한다.

[ 커널 패치 전 ]

$ gcc semtex.c
$ ./a.out
2.6.37-3.x x86_64
sd _at_ fucksheep.org 2010
a.out: semtex.c:81: main: Assertion `p = memmem(code, 1024, &needle, 8 )' failed.
중지됨
$ gcc -O2 semtex.c  <-- -O2 옵션 넣고 컴파일
$ ./a.out
2.6.37-3.x x86_64
sd _at_ fucksheep.org 2010
-sh-4.1# id
uid=0(root) gid=0(root) groups=0(root),501(true)  <-- root권한 획득
-sh-4.1# exit
logout


[ 커널 패치 후 ( yum update kernel* 명령 후 ) ]

$ uname -r
2.6.32-358.6.2.el6.x86_64
$ ./a.out
a.out: a.c:51: sheep: Assertion `!close(fd)' failed.
중지됨
$

※ expolit 소스를 링크하고 싶지 않았다. 하지만 이미 공개가 많이 되었고, SE가 직접 취약성을 테스트하도록 링크를 걸었다.

'시스템이야기' 카테고리의 다른 글

텔레그램(Telegram)으로 서버 모니터링하기  (16) 2014.10.15
OpenSSL 1.0.1 Heartbleed 취약점  (2) 2014.04.09
FreeBSD에서 Dell R620서버 NIC문제 해결  (0) 2013.02.05
Brocade SAN 스위치 펌웨어 업그레이드  (0) 2012.09.12
MySQL보다 빠른 MemSQL, 앞으로 기대된다.  (0) 2012.06.26
Posted by 좋은진호
시스템이야기2012. 1. 11. 18:37

PHP 5.3.9 Released(HashDoS 문제 해결 버전)

Hash table 충돌을 이용한 DoS 공격(일명 HashDoS)을 해결한 PHP 5.3.9버전이 나왔습니다.
  • php 5.3.8 포함하여 이전 버전 사용중 : 필히 업그레이드 할 것
  • php 5.3.9 RC 또는 5.4.0 RC4~RC5 사용중 : 임시 업그레이드하셨던 분은 필요하면 정식 버전을 적용해도 되겠네요.

php


참고로 php.ini의 max_input_vars default값은 1000입니다.

http://www.php.net/index.php#id2012-01-11-1

The PHP development team would like to announce the immediate availability of PHP 5.3.9. This release focuses on improving the stability of the PHP 5.3.x branch with over 90 bug fixes, some of which are security related.

Security Enhancements and Fixes in PHP 5.3.9:

* Added max_input_vars directive to prevent attacks based on hash collisions. (CVE-2011-4885)
* Fixed bug #60150 (Integer overflow during the parsing of invalid exif header). (CVE-2011-4566)


※ 2012.2.2에 php 5.3.10버전이 나왔습니다. HashDoS를 패치한 5.3.9버전에 원격에서 코드를 실행할 수 있는 취약점이 있습니다. 자세한 것은 'php 5.3.10으로 업그레이드하세요."를 읽어보세요.

* HashDoS 관련 글

- 2012/01/04 - [시스템이야기] - php에서 hash table DoS(HashDoS) 공격 방어
- 2012/01/02 - [시스템이야기] - 웹서버 hash table DoS(HashDoS) 공격 (중요. PHP, ASP 등 해당)


'시스템이야기' 카테고리의 다른 글

bash에서 순차적 숫자를 사용하는 쉬운 방법  (2) 2012.05.29
SSD기반 Scale-out NAS 스토리지  (8) 2012.05.08
php에서 hash table DoS(HashDoS) 공격 방어  (2) 2012.01.04
웹서버 hash table DoS(HashDoS) 공격 (중요. PHP, ASP 등 해당)  (7) 2012.01.02
아파치 웹서버, DoS 취약점 해결한 버전 발표  (2) 2011.08.31
Posted by 좋은진호
시스템이야기2012. 1. 4. 09:36

php에서 hash table DoS(HashDoS) 공격 방어

HashDoS 공격에 대해서는 '웹서버 hash table DoS(HashDoS) 공격 (중요. PHP, ASP 등 해당)'  을 읽어보기 바란다.

웹서버에서는 Request POST, GET 변수를 hash 구조로 관리한다. 그런데 POST 요청 파라미터수가 상당히 많을 경우(GET 요청은 길이 제한이 있으므로 문제가 되지 않음)에 hash 충돌이 많이 발생하게 되어 CPU load가 상당히 올라가게 된다. 이런 문제는 PHP5, Asp.Net, Java, V8 자바스크립트 엔진 등에서 발생한다.

취약점을 해결하거나 공격을 약화시키는 방법이다.

1. php 5.4.0 RC버전과 앞으로 나올 PHP 5.3.9 버전 (취약점 해결)

max_input_vars 설정으로 파라미터 개수를 제한한다.

2. 기존 php버전에서 (완벽한 해결이 아닌 공격을 약화시키는 방법)

php.ini 설정값 (default)
max_input_time = 60     ; Maximum amount of time each script may spend parsing request data
post_max_size = 8M

max_input_time은 요청 데이터를 파싱하는데 걸리는 최대 시간이다.
max_input_time으로 파싱 시간 제한, post_max_size으로 POST 사이즈를 제한함으로써 파라미터수를 어느정도(?) 제한하는 효과를 갖는다. 완벽한 해결이 아닌 공격을 약화시키는 방법이다.

기존에 쌓아둔 웹로그를 분석해서
  1. 스크립트의 실행 시간이 얼마나 걸리는지 (max_input_time 설정위해. 웹로그 시간은 정확히는 전송시간 + max_input_time + max_execution_time과 관련)
  2. POST 요청의 사이즈를 분석한다. (post_max_size 설정위해)
수치를 적절히 파악한 후 서비스에 지장없는 정도로 조절한다.
(예 : max_input_time = 10, post_max_size = 100K)
단, 파일이 업로드되는 서비스는 POST사이즈가 크므로 post_max_size는 적용하기 어렵고, max_input_time만 설정해볼 수 있다.

3. 수호신(suhosin) php 보안 모듈 사용 (취약점 해결)

suhosin.post.max_value_length = 1000000
suhosin.post.max_vars = 500
suhosin.request.max_vars = 500

수호신 모듈을 사용하면 위 설정만으로도 문제가 해결된다. 최대 파라미터 개수를 500개로 제한한 경우이다. default는 1000이다. 다음과 같이 차단되었음을 확인할 수 있다.

suhosin[95705]: ALERT - configured POST variable limit exceeded - dropped variable '..생략..' (attacker 'xxx.xxx.xxx.xxx', file '/..생략../index.html')

4. apache와 nginx에서 POST사이즈 제한 (100K로 제한하는 예)

POST사이즈 제한을 php설정 외에 웹서버 자체 설정도 적용하고 싶다면 다음과 같이 한다. 위 2번에서 설명한대로 기존 웹로그를 분석해서 적절한 POST사이즈를 파악해서 적용한다.

1) apache
   LimitRequestBody 100000

2) nginx (defaul는 1MB)
   client_max_body_size 100k;


※ 다음은 php.ini의 max_input_time 설정을 착각하는 분들이 있어 정리했다. (1.4(수) 19시)

위에서 말한대로, php.ini 설정 중 max_input_time은 HTTP '요청 데이터(POST, GET)를 파싱하는데 걸리는 시간'이다. 'input' 이라는 단어가 들어가기 때문에, 전송되는 시간으로 착각하는 경우가 있다. 하지만 모든데이터를 다 받은 순간부터 실행 시작하기까지의 시간이다. 아래에서 3번에 해당하는 구간이다.

1) POST 요청 -> 2) POST 데이터 전송 -> 3) 전송후 파싱 -> 4) 실행

정상적인 요청이라면 파싱하는데 걸리는 시간은 짧다. 그래서 이 수치를 줄임으로써 어느정도의 효과가 있다.


'시스템이야기' 카테고리의 다른 글

SSD기반 Scale-out NAS 스토리지  (8) 2012.05.08
PHP 5.3.9 Released(HashDoS 문제 해결 버전)  (0) 2012.01.11
웹서버 hash table DoS(HashDoS) 공격 (중요. PHP, ASP 등 해당)  (7) 2012.01.02
아파치 웹서버, DoS 취약점 해결한 버전 발표  (2) 2011.08.31
아파치 웹서버를 한방에 다운시키는 Range요청 취약점  (2) 2011.08.30
Posted by 좋은진호
시스템이야기2012. 1. 2. 19:20

웹서버 hash table DoS(HashDoS) 공격 (중요. PHP, ASP 등 해당)

먼저 공격 동영상 한편을 보자.

Denial of Service using Hash tables collisions in PHP


hash table collisions버그를 이용해서 PHP로 DoS공격을 하는 예이다. 동영상에서는 약 190초 동안이나 CPU load가 15%정도 올라갔다. H/W사양이나 요청하는 POST값은 다양하니 수치의 의미보다는 load 상승의 심각성을 중요포인트로 생각해야 한다. 이런 비정상 요청 몇개만으로 서비스는 제대로 이뤄지지 않을 수 있다. '단 몇개만'으로.

웹서버에서는 Request POST, GET 변수를 hash 구조로 관리한다. 그런데 POST 요청 파라미터수가 상당히 많을 경우(GET 요청은 길이 제한이 있으므로 문제가 되지 않음)에 hash 충돌이 많이 발생하게 되어 CPU load가 상당히 올라가게 된다. 이런 문제는 PHP5, Asp.Net, Java, V8 자바스크립트 엔진 등에서 발생한다.

PHP의 경우 5.4.0 RC버전과 앞으로 나올 PHP 5.3.9 버전에서 max_input_vars 설정으로 파라미터 개수를 제한할 수 있다.

현재 @hashDoS 트위터( http://twitter.com/hashDoS )에서 이번 취약점에 대한 논의가 있으니 참고하기 바란다.

* php에서 hash table DoS(HashDoS) 공격 방어 (정리해서 올렸습니다. 1.4(수) 오전)
* hashDoS 취약점 관련 글


'시스템이야기' 카테고리의 다른 글

PHP 5.3.9 Released(HashDoS 문제 해결 버전)  (0) 2012.01.11
php에서 hash table DoS(HashDoS) 공격 방어  (2) 2012.01.04
아파치 웹서버, DoS 취약점 해결한 버전 발표  (2) 2011.08.31
아파치 웹서버를 한방에 다운시키는 Range요청 취약점  (2) 2011.08.30
로그 분석 및 실시간 검색의 강자, Splunk 맛보기  (5) 2011.04.08
Posted by 좋은진호
시스템이야기2011. 8. 31. 17:15

아파치 웹서버, DoS 취약점 해결한 버전 발표

지난주 '아파치 웹서버를 한방에 다운시키는 Range요청 취약점'이 발표되었다.

apache 웹서버


국내에서는 이 DoS 취약점에 대해 너무나 조용하지만, 한방에 서버를 다운시킬 수 있는 심각한 문제이다. 아파치 웹서버(Apache)에 정상적이지 않은 형태로 Range 헤더를 요청하면, 웹서버의 load는 단 몇초만에 급상승하여 서버는 응답을 처리할 수가 없다.

아파치 1.3, 2.0, 2.2버전대 모두 DoS 취약점이 존재한다. 오늘 DoS 취약점을 패치한 2.2.20 버전을 발표했다.

SECURITY: CVE-2011-3192 (cve.mitre.org) core: Fix handling of byte-range requests to use less memory, to avoid denial of service. If the sum of all ranges in a request is larger than the original file, ignore the ranges and send the complete file. PR 51714.

예전 1.3.x버전 운영중인 분들은 더 이상 지원하지 않는 버전대를 버리고 2.2.x대로 갈아타시기 권장한다. 2.0.x버전대는 조만간 발표될 것이다.
2.2.20 테스트 결과, 해당 취약점이 패치된 것을 확인했다.


'시스템이야기' 카테고리의 다른 글

php에서 hash table DoS(HashDoS) 공격 방어  (2) 2012.01.04
웹서버 hash table DoS(HashDoS) 공격 (중요. PHP, ASP 등 해당)  (7) 2012.01.02
아파치 웹서버를 한방에 다운시키는 Range요청 취약점  (2) 2011.08.30
로그 분석 및 실시간 검색의 강자, Splunk 맛보기  (5) 2011.04.08
rsync에서 특정 퍼미션으로 고정하기  (3) 2011.03.17
Posted by 좋은진호
시스템이야기2011. 8. 30. 13:22

아파치 웹서버를 한방에 다운시키는 Range요청 취약점



apache


jjun님이 글을 쓰셨으니 간단하게만 몇가지 언급하겠다.

'아파치 웹서버 무력화시킬 심각한 DoS 결함 발견' 기사에는 mod_deflate또는 mod_gzip 모듈과 관련이 있는 것으로 쓰여있지만, 이 모듈과는 무관하게 취약점이 존재한다. 해당 모듈을 주석처리해도 악의적인 Range 헤더 요청에 대해 똑같은 문제가 있으며, 아파치 메일링 리스트에서도 이 모듈을 언급한 것은 잘못된 판단이었다고 한다.

* Bug 51714 - Byte Range Filter might consume huge amounts of memory combined with compressed streams
As discussed on the Apache Dev Mailing list it looks like this issue has nothing to do with mod_deflate or mod_gzip, wrong assumption by me.

웹페이지 size에 따라서, Range 헤더의 문제가 발생할 수도 있고 없을 수도 없다.

1) mod_php5모듈이 없다면 웹페이지 size에 상관없이 문제가 있다.
2) mod_php5모듈과 함께 아파치를 동작중이라면 8000bytes 이하의 웹페이지를 요청할 때만 문제가 발생한다. mod_php5 모듈이 있더라도 php로 인식하지 않는 확장자(예를 들어 .css, js, .txt 등)는 사이즈에 상관없이 문제가 있다.

따라서 index페이지만 체크하고 '우리는 문제가 없네'라고 판단해서는 안된다. php로 된 index가 8000bytes를 넘는다면, 취약점이 없는 것으로 보일 수 있기 때문이다.

Request 헤더에 Range: bytes=0-,1-2,2-3,4-5 같은 형태로 요청했다고 가정하자.

0-은 해당 웹페이지의 시작부터 끝까지를, 1-2는 웹페이지의 2번째~3번째 문자(0부터 시작하니깐 1-2는 2~3번째)를, 나머지도 같은 의미이다. 일반적으로 콤마(,)로 구분해서 여러 필드를 요청하는 경우는 없다라고 생각하면 된다.

[ 아파치 설정에서 Range헤더에 콤마를 제한하는 예 ]
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range

따라서 위처럼 5개 필드 이상(콤마가 5개 이상)인 경우만 제한해도 좋고, 간단하게 콤마(,)가 포함된 경우를 차단해도 무방할 것으로 보인다.
곧 패치버전이 나올 것이다. 하지만 그 때까지는 L7장비 또는 웹서버에서 Range 헤더 조건 강화하는 방법으로 차단해야 할 것이다.


* 관련글 :
  - Mitigation of Apache Range Header DoS Attack
  - DoS with mod_deflate & range requests

* 내용 추가 (2011.8.31(수) 점심)

이 DoS 취약점을 패치한 2.2.20 버전이 발표되었다.

- Release 정보 : http://www.apache.org/dist/httpd/Announcement2.2.html
- 다운받기 : http://ftp.daum.net/apache/httpd/




'시스템이야기' 카테고리의 다른 글

웹서버 hash table DoS(HashDoS) 공격 (중요. PHP, ASP 등 해당)  (7) 2012.01.02
아파치 웹서버, DoS 취약점 해결한 버전 발표  (2) 2011.08.31
로그 분석 및 실시간 검색의 강자, Splunk 맛보기  (5) 2011.04.08
rsync에서 특정 퍼미션으로 고정하기  (3) 2011.03.17
DNS 요청에 대한 TimeOut시간의 진실은.  (0) 2010.11.11
Posted by 좋은진호
시스템이야기2011. 3. 17. 18:57

rsync에서 특정 퍼미션으로 고정하기


rsync


rsync는 크게 2가지 용도를 생각해볼 수 있다.

1) 파일 백업 (퍼미션 유지 필요. 백업본으로 복구할 경우 퍼미션도 중요하다.)
2) 파일 배포 (반드시 퍼미션을 유지하지 안해도 될 상황이 있다.)

rsync를 이용해서 다수의 서버를 동기화한다고 하자. 그리고, 대상 서버는 웹서버들이다. (즉, '파일 배포' 용도) 이 웹페이지 파일은 웹에서 읽을 수 있는 권한만 갖으면 된다. 쓰기 권한을 갖을 필요가 없다. (업로드가 이뤄지는 디렉토리는 쓰기 권한이 필요하겠지만)

rsync는 원본 파일(또는 디렉토리) 퍼미션과 상관없이, 싱크할 때 특정한 퍼미션으로 고정시키는 옵션이 있다. 디렉토리는 555(dr-xr-xr-x) 또는 515(dr-x--xr-x)으로, 파일은 444(-r--r--r--)로 고정해볼 수 있을 것이다. 서비스 서버(대상 서버)의 파일은 보안에 조금 더 안전하게 존재하게 된다.

(예)
-------------    ---------------
 원본 서버          대상 서버
192.168.1.123    192.168.1.110~120
-------------    ---------------
drwxr-xr-x    ->   dr-xr-xr-x
drwxrwxr-x    ->   dr-xr-xr-x
-rw-r--r--    ->   -r--r--r--
-rw-rw-rw-    ->   -r--r--r--
-------------    ---------------

대상 서버의 rsyncd.conf 예이다.

# server : 192.168.1.110
#
uid             = root
gid             = root
user chroot     = yes
max connections    = 10
hosts allow    = 192.168.1.123

[coffeenix]
path        = /home/coffeenix/public_html
read only    = no
incoming chmod  = Du=rx,Dgo=rx,Fugo=r

'incoming chmod =' 파라미터는 들어오는 파일을 특정 퍼미션으로 고정한다.
파라미터의 값은 각각 다음과 같은 의미를 갖는다.

- D : 디렉토리
- F : 파일
- ugo : 각각 user(u), group(g), other(o)에 해당한다.

[ 기본적인 파일 보호 장치인 chmod (열쇠찾아서 그리는데 쉽지 않았다. ^^) ]


위의 Du=rx,Dgo=rx,Fugo=r 는 Dugo=rx,Fugo=r처럼 통합해서 표시해도 좋다.
Du=rx는 디렉토리 소유자는 r-x(읽기, 쓰기)로 설정한다는 의미이다.
Fugo=r은 누구나(user, group, other) 파일을 읽을 수 있도록(r--)로 설정한다.
위 설정대로하면 디렉토리는 r-xr-xr-x 가 되고, 파일은 r--r--r--가 된다.

# rsync -avz --delete public_html/ 192.168.1.110::coffeenix/

보다 자세한 글은 커피닉스에 써뒀으니 살펴보시길.

'시스템이야기' 카테고리의 다른 글

아파치 웹서버를 한방에 다운시키는 Range요청 취약점  (2) 2011.08.30
로그 분석 및 실시간 검색의 강자, Splunk 맛보기  (5) 2011.04.08
DNS 요청에 대한 TimeOut시간의 진실은.  (0) 2010.11.11
MySQL에서 보안위해 load_file() 경로 제한하기  (0) 2010.05.31
MySQL관련 기술적 동영상 제공하는 percona.tv  (4) 2009.06.24
Posted by 좋은진호
IT이야기2011. 1. 20. 22:48

좀비PC 양산체제와 DDoS 공격

DDoS공격은 꾸준했지만, 최근 12월과 1월에 DDoS 공격량이 증가하고, 공격도 심해졌다는 얘기를 한다.

최근 몇몇 업체가 DDos공격을 받았다. 이들 업체도 DDoS 공격 피해자인데, 고객들에게 그것도 못 막냐~라는 얘기를 듣게 되고, 고객에게 미안한 마음까지 생긴다. 하지만 이들 업체가 노력하지 않아서 못 막는게 아니다. 차단위한 인프라 구축에도 한계가 있다. 만약 50G, 아니 100G가 들어온다면 일반적인 국내 환경에서 이 트래픽을 감당할 인프라를 갖춘 곳이 얼마나 되겠는가.

1. 폭우가 쏟아져 상류댐에서 대량의 물을 방류하게 되면 하류에서는 대비를 하더라도 피해를 입을 수밖에 없다.

이런 경우 해결할 방법은 상류댐(IDC나 연동망 등)에서 물길을 막아주는 것 밖에 없다.(이를 IP null routing이라고 한다. 공격받는 IP로 들어오는 트래픽을 상단에서 버리는 것이다.) 그러나 이 댐은 특이해서 물을 한방울도 흘러보내지 않거나 대량의 물을 그대로 방류하거나 둘중 하나만 선택할 수 있다. 어쩔 수 없이 물을 한방울도 흘러보내지 않는 것을 선택하게 된다. 대량의 물은 막았지만 식수난을 겪게 된다. (IP null routing을 하게 되면 공격 트래픽은 막아지지만 해당 IP로는 서비스를 할 수 없다. 인프라는 보호했지만 서비스는 못하는 현실)

DDoS

[ 이미지 출처 : 구글 이미지 검색 -> make.to ]


※ DDoS공격 유형은 여러가지가 있는데, 위는 UDP유형으로 대역폭을 초과하는 공격을 예로 든 것이다.
※ DDoS공격은 유형에 따라 차단할 수 있다. 그리고, 인프라를 초과하더라도 상단과의 협조와 내부 DDos방어장비를 이용해 단계별 처리로 피해를 줄일 수 있다. 먼저 DDoS방어장비 구축과 인프라 개선은 해야하는 것은 당연하다.


2. 최근 공격량이 증가했다는 것은 좀비 PC가 늘었다는 이야기가 된다. '선' 좀비 PC 구축 -> '후' DDoS공격의 형태이기 때문이다.

'하우리의 맞춤전용백신 목록'에서도 Trojan/DDoSAgent 전용백신이 작년 11월부터 증가했다. 좀비 PC도 늘어 났다는 것이다.
인터넷침해대응센터(KRCERT)의 보안공지( http://www.krcert.or.kr/ )를 보면 12월말부터 국내 주요 오픈소스 게시판의 취약점이 줄줄이 발표되었다. (당시 대량의 서버에 설치된 제로보드를 자동 패치하느라 고생한 커피닉스 분이 생각난다. ^^) 이들 3개 게시판이면 국내 공개 게시판의 대부분을 커버한다고 보면 된다.
취약점을 이용해 악성코드만 심으면, 공장에서 찍어내듯 좀비 PC를 만들 수 있는 대량 양산 체제를 구축한 것이다. 밤낮이 필요없는 24시간 양산 체제. 게시판 사용하는 사이트는 널려있으니, 악의적인 사람 입장에서는 원감절감(노력절감) 체제. 우리 나라 좀비 PC들은 네트웍도 빵빵하고, 성능은 날아다닌다. 그만큼 막강한 공격력을 자랑(?)하게 된다.

[ 인터넷침해대응센터(KRCERT)의 보안공지 ]


* 국내 공개 웹 게시판(제로보드) 취약점 주의 (2010/12/21)

  o 국내 PHP 기반의 공개 웹 게시판 제로보드에서 XSS, CSRF 및 RFI 취약점이 발견됨[1, 2]
  o 해당 취약점을 이용한 홈페이지 변조 및 원격 실행 위협이 발생함에 따라, 취약한 버전 사용자의 주의 및 조속한 패치가 요구됨

* 국내 공개 웹 게시판(테크노트) 취약점 주의 (2011/01/06)

  o 국내 PHP기반의 공개 웹 게시판인 테크노트에서 SQL인젝션 취약점이 발견됨 [1]
  o 취약한 버전을 사용하고 있을 경우, 홈페이지 해킹에 의한 내부정보(개인정보 등)유출 등의 피해를 입을 수 있으므로 웹 관리자의 적극적인 조치 필요

* 국내 공개 웹 게시판(그누보드) 취약점 주의 (2011/01/07)

  o 국내 PHP기반의 공개 웹 게시판인 그누보드에서 XSS, CSRF 취약점이 발견됨[1]
  o 취약한 버전을 사용하고 있을 경우, 홈페이지 해킹에 의한 관리자 계정 탈취 및 악성코드 유포지로 악용되는 등의 피해를 입을 수 있으므로 웹 관리자의 적극적인 조치 필요

게시판 취약점 이용한 악성코드 심기, 유명사이트 해킹으로 악성코드 심기, 웹브라우저의 zeroday취약점 등으로 좀비 PC 양산체제 구축은 꾸준할 것이다. DDoS공격 증가와 좀비 PC 양산체제 여건 마련은 무관하지 않다.

PC점검 철저히 하시라. 그리고 IE에만 의존하지 말고, 파이어폭스나 크롬 등도 이용하시라.
내가 이용자이면서 그들에게 공격자일 수도 있다. 누구를 욕할 처지가 아닐 수 있다.

'IT이야기' 카테고리의 다른 글

KISA, 개인정보 노출 검사위해 웹페이지 여전히 긁어간다  (6) 2011.03.24
이집트 정부의 인터넷 차단  (4) 2011.02.01
아마존의 EC2 클러스터, 세계 슈퍼컴 중 231위  (8) 2010.12.16
파이어폭스에서 구글 캘린더 날짜 오류  (4) 2010.12.07
전세계와 국내 스마트폰 OS별 웹이용률  (6) 2010.12.01
Posted by 좋은진호

티스토리툴바