좋은진호의 여유만만

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


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

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

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

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

php.ini 설정값 (default)

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 보안 모듈 사용 (취약점 해결)


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


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번에 해당하는 구간이다.


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

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

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 취약점 관련 글

• [SECURITY] Apache Tomcat and the hashtable collision DoS vulnerability
• Denial of Service through hash table multi-collisions http://www.nruns.com/_downloads/advisory28122011.pdf
• Hash collisions vulnerability in web servers
• PHP Hash Table Collision Bug Lets Remote Users Deny Service

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

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

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


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

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



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

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

* Bug 51714 - Byte Range Filter might consume huge amounts of memory combined with compressed streams

웹페이지 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헤더에 콤마를 제한하는 예 ]

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


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

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

지난 금요일(8.28일)에 Apache Software Foundation의 웹사이트가 해킹을 당해 서비스를 일시 중지한 적이 있다. F-Secure의 'Apache.org hack'을 읽은 금요일 밤에 접속했을 때는 웹서비스는 정상적으로 복구된 상태였다.



다행인 것은 공격자는 Apache 웹서버 자체의 S/W적인 취약점이나 SSH의 취약점이 아닌 SSH key 인증을 이용해서 접근했다. minotaur.apache.org(people.apache.org로 알려진 서버) 서버에 파일을 업로드 한 것이다. 이 minotaur 서버는 Apache 커미터들에게 쉘 계정을 제공하는 서버이다.

ASF측에서는 예방차원에서 서버를 모두 shutdown했다. 그리고 초기 조사 이후에 apache.org 서비스를 eris.apache.org(이 서버는 공격 당하지 않은 안전한 서버)로 DNS를 변경했고, 이 서버를 통해 공지페이지를 제공했다. 그 이후 유럽의 장애 대처 및 백업 서버인 aurora.apache.org 서버(이 서버 또한 안전한 서버)로 서비스를 변경했다. 현재 aurora.apache.org IP와 www.apache.org IP가 같은 것을 보면 아직 유럽의 임시 서버를 통해서 서비스가 되고 있는 것으로 보인다.

공격자는 www.apache.org 내의 CGI 스크립트를 포함하여 몇몇 파일을 생성까지 했다. 그런데, ASF의 서버들은 rsync의 자동화처리(cron에 등록되어 있을 것 같음)를 통해서 파일을 각 서버로 자동 배포하는 구조로 되어 있다. 공격자가 생성한 몇몇 파일들이 자동적으로 sync가 되었는데, 복구는 ZFS 스냅샷으로 이전 상태로 복원했다고 한다. ZFS 파일시스템의 우수성을 다시 한번 느끼게 한다.

참고로 ZFS파일시스템은 주기적으로 snapshot을 실행(zfs snapshot -r ... 형식) 한다면, 적은 공간으로 파일시스템을 원하는 시점으로 되돌릴 수 있다(zfs rollback). ZFS에 대해서는 'FreeBSD 7에서 ZFS 사용 (유연성은 좋으나, 성능은 불만족)' (2009.2월)을 읽어보기 바란다.

apache.org 얘기로 돌아가서, 공격자가 서버 접속해서 상위 권한을 획득하지는 않았다. 하지만 다운로드 받는 분들은 디지털 signature 체크(MD5 등)를 하길 바란다. 자세한 글은 아파치 인프라팀의 'apache.org downtime - initial report' 글에 있다.

서버 운영자들 중 PW없이 접속하도록 SSH 인증키를 만들어 놓곤 한다. 그러나 이 키들이 노출됐을 때 얼마나 위험한 것인지 잘 아셔야 한다. 그리고, 왜 이런 오픈소스 진영의 서버들을 해킹하려고 시도하는지, 안타깝다. 그런 노력(?)을 하려거든, 오픈소스 진영에 기부나 할 것이지...

아파치 웹서버에는 UseCanonicalName 이라는 옵션이 있다. 이 옵션은 CGI나 php등에 SERVER_NAME과 SERVER_PORT변수값을 넘길 때, 어떤값을 넘길 것인지 결정한다. On으로 설정되어 있을 경우는 아파치의 ServerName으로 지정한 값이 넘겨지고, Off로 설정되어 있을 경우는 클라이언트가 요청한 호스트명과 포트명이 넘겨진다.

이런 경우를 가정해보자. www.coffeenix.net 로 서비스되는 서버가 5대라고 하고, 각 5대의 서버는 w101~w105.coffeenix.net 이름을 갖고 있다.


위처럼 설정되어 있을 때 On과 Off의 차이를 확인홰보자. 유저가 브라우저에서 w101.coff...를 요청했을 때이다.

다음은 On으로 설정한 경우이며, ServerName에 설정된 호스트명이 출력된다.
Off으로 설정한 경우이며, 브라우저에서 요청한 호스트명이 출력된다.

UseCanonicalName 옵션은 아피치 1.3에선 기본값이 On으로, 2.x대(2.0, 2.2)는 Off로 되어 있다. 기본값의 차이가 있으니 반드시 ServerName에서 지정한 호스트명이 나와야할 경우 주의가 필요하다. 다음은 아파치 웹서버의 httpd.conf 일부다.

[ 아파치 1.3.x의 httpd.conf ]

[ 아파치 2.2.x의 httpd-default.conf ]

.html이나 .js 등의 파일들을 전송할 때 압축해서 보낸다면, 웹페이지 접속시에 약간의 전송속도 향상을 가져올 수 있을 것이다. 요즘 워낙 회선속도가 좋아 그 영향이 미비할 수도 있지만. 주요 포털들과 랭킹 상위 사이트 몇개를 대상으로 gzip 압축 전송을 지원하는지를 체크해봤다. 메인페이지를 기준으로 확인해봤으며, 메인페이지 접속시에 함께 요청되는 페이지도 체크에 포함했다.

gzip 압축 전송 지원여부 체크는 초기에는 직접 Request 헤더에 'Accept-Encoding: gzip, deflate'를 포함해서 만들어 보내고, Response 헤더에 'Content-Encoding: gzip'가 포함되어 있는지를 파악했다. 그러나 정확도가 떨어진데다가 한 페이지에 .css, .js등 여러 request가 있는 경우까지 체크하기 위해서 Fiddler툴을 이용해서 결과를 정리했다.


gzip을 지원하는 사이트들이다.

1. 다음( www.daum.net )
   .html 파일의 gzip 압축 전송을 지원했으며, top-sc.daum.net 의 .js 파일과 top-sc.daum-img.net 의 .xml 파일도 지원한다.

2. 네이버( www.naver.com )
   20bytes의 작은 사이즈도 gzip 압축했으며, .js, .css 파일은 사이즈에 무관하게 압축을 하지 않았다.
   auto.naver.com의 .html 파일, .js 파일, .css 파일의 gzip 압축 전송 지원

3. 네이트( www.nate.com )
   .html 파일, .js 파일, .ico 파일의 gzip 압축 전송을 지원한다. 특이하게 .ico까지 한다. 아니, 일반적인 이미지파일을 제외하고는 확장자에 무관하게 gzip을 지원하는 것일 수도 있다. 300bytes대의 사이즈도 gzip 압축을 했다. 메인페이지의 최소사이즈 파일이 300bytes였으며, 이보다 작은 사이즈의 파일이 있었으면 압축을 지원했을 수 있다. 적용범위를 폭넓게 생각하면, 파일확장자와 사이즈에 무관하게 압축할 가능성이 있다.
   .css파일은 존재하지 않아 gzip 압축 전송 여부 확인할 수 없었다.
   
4. 야후! 코리아( kr.yahoo.com )
   .html 파일의 gzip 압축을 지원한다. .js와 .css는 img.yahoo.co.kr 이미지 웹서버에 존재하는데 .js, .css 파일의 압축을 지원한다.
   adz.kr.yahoo.com 요청 중에 .js 파일의 압축을 지원한다.

5. 싸이월드( www.cyworld.com )
   .asp(.html), .js 파일의 gzip 압축을 지원한다. 31bytes의 작은 사이즈도 압축했으므로, 사이즈 상관없이 압축한다는 의미일 것이다.
   .css는 압축 지원을 하지 않았다.

6. 구글( www.google.co.kr )
   .html, .js, .css 파일의 gzip 압축 전송을 지원한다.

7. Live Search( www.live.com )
   .html 파일의 gzip 압축 전송을 지원한다.

8. MSN Korea( kr.msn.com )
   .html 파일의 gzip 압축 전송을 지원한다.
   stckr.msn.com의 .css 파일, stjkr.msn.com 의 .js 파일의 gzip 압축을 지원하며,
   특이하게도 ads1.msn.com의 js 파일과 stj.msn.com의 .js 파일은 deflate 압축을 지원한다. 아마도 'Footprint 4.2/FPMCP' 캐싱 서버 때문일 것 같다.

위 사이트를 확장자별로 지원 여부를 표시했다.


다음은 지원하지 않는 사이트이다.

엠파스( www.empas.com ), 파란닷컴( www.paran.com ), 드림위즈( www.dreamwiz.com )

MaxMind의 GeoIP 데이터와 GeoIP apache 모듈을 사용하여, 아파치의 웹로그에 국가코드를 남겨보자.

1. GeoIP C API 설치한다.
2. 그리고, Apache mod_geoip2 모듈을 설치한다. (apache 2.x 기준임)

apache 모듈이 설치된 상태에서 phpinfo() 를 살펴보면, Apache Environment 부분에서 GEOIP_CONTINENT_CODE, GEOIP_COUNTRY_CODE, GEOIP_COUNTRY_NAME환경 변수를 볼 수 있다.
이중에서 GEOIP_COUNTRY_CODE 변수값을 로그에 남기면 된다.



위에서 %{변수명}i 형식은 Header중 해당 변수값을 말한다. %{변수명}e 는 환경변수를 의미한다.

%{Host}i : 요청한 호스트명을 로그에 남긴다. 이를테면 하나의 서버에 2개 이상의 도메인을 갖고 있을 때 유용하다.  www.foobar.com, www.foobar.net, foobar.com 등의 도메인이 있을 때 어떤 도메인으로 요청했는지를 남길 수 있게 된다.
%{GEOIP_COUNTRY_CODE}e : GEOIP_COUNTRY_CODE 환경변수, 즉 국가코드를 남긴다.

로그는 다음과 같이 남는다.


자세한 것은 커피닉스의 'GeoIP 활용(아파치 웹로그에 국가코드 남기기 외)' 에 정리해뒀다.

Netcraft의 5월 웹서버 통계에 따르면 apache 웹서버는 지난달 약 6689만대에서 6608만대로 줄었고, 점유율에서도 58.86%에서 56.00% 로 무려 2.86%나 감소했다.
이같은 감소의 원인은 Netcraft가 GFE(Google Front End) 로 불리는 구글웹서버의 트래킹을 시작했기 때문으로 apache로 분류했던 웹서버를 이제 GFE로 판단하기 때문이다. 이로 인해 GFE 서버는 호스트명 기준으로 지난달 51,665개에서 2,753,041개로 급증했다. 이 숫자가 서버대수를 의미하는 것은 아니다.구글의 서버대수는 정확하게 들은 것 없고, 45만대라는 글을 읽은 적이 있다.

May 2007 Web Server Survey
http://news.netcraft.com/archives/2007/05/01/may_2007_web_server_survey.html



www.google.com 의 HEAD를 살펴보니 다음과 같이 나온다.


그외의 서비스에 대해서도 살펴봤다. 웹서버명에 GWS, NFE, mfe, bsfe, OFE, codesite, GWS-GRFE, TWS, DFE  등을 볼 수 있는데, 이는 서비스 환경에 맞게 웹서버를 커스터마이징하고 있음을 의미할 것이다.

search.google.com          Server: GWS/2.1
mail.google.com            Server: GFE/1.3
news.google.com            Server: NFE/1.0
earth.google.com           Server: GWS/2.1
video.google.com           Server: GFE/1.3
images.google.com          Server: GWS/2.1
maps.google.com            Server: mfe
moon.google.com            Server: mfe
local.google.com           Server: mfe
blogsearch.google.com      Server: bsfe
books.google.com           Server: OFE/0.1
catalogs.google.com        Server: OFE/0.1
desktop.google.com         Server: GFE/1.3
finance.google.com         Server: SFE/0.8
toolbar.google.com         Server: GFE/1.3
code.google.com            Server: codesite/4511653
labs.google.com            Server: Apache
groups.google.com          Server: GWS-GRFE/0.50
picasa.google.com          Server: GWS/2.1
sketchup.google.com        Server: GWS/2.1
mobile.google.com          Server: GWS/2.1
webaccelerator.google.com  Server: GFE/1.3
translate.google.com       Server: TWS/0.9
directory.google.com       Server: DFE/1.0

www.googlestore.com        Server: Microsoft-IIS/6.0
www.blogspot.com           Server: GFE/1.3
www.youtube.com            Server: Apache
www.orkut.com              Server: GFE/1.3