좋은진호의 여유만만

지난주 '아파치 웹서버를 한방에 다운시키는 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(수) 점심)

.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 )