시스템이야기2012. 1. 4. 09:36
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) 실행

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


Posted by 좋은진호
시스템이야기2011. 8. 31. 17:15
지난주 '아파치 웹서버를 한방에 다운시키는 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 테스트 결과, 해당 취약점이 패치된 것을 확인했다.


Posted by 좋은진호
시스템이야기2011. 8. 30. 13:22


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/




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

apache


다행인 것은 공격자는 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 인증키를 만들어 놓곤 한다. 그러나 이 키들이 노출됐을 때 얼마나 위험한 것인지 잘 아셔야 한다. 그리고, 왜 이런 오픈소스 진영의 서버들을 해킹하려고 시도하는지, 안타깝다. 그런 노력(?)을 하려거든, 오픈소스 진영에 기부나 할 것이지...

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

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

ServerName www.coffeenix.net

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

다음은 On으로 설정한 경우이며, ServerName에 설정된 호스트명이 출력된다.
사용자 삽입 이미지

Off으로 설정한 경우이며, 브라우저에서 요청한 호스트명이 출력된다.
phpinfo _SERVER변수

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

[ 아파치 1.3.x의 httpd.conf ]
# UseCanonicalName:  (new for 1.3)  With this setting turned on, whenever
# Apache needs to construct a self-referencing URL (a URL that refers back
# to the server the response is coming from) it will use ServerName and
# Port to form a "canonical" name.  With this setting off, Apache will
# use the hostname:port that the client supplied, when possible.  This
# also affects SERVER_NAME and SERVER_PORT in CGI scripts.
#
UseCanonicalName On

[ 아파치 2.2.x의 httpd-default.conf ]
# UseCanonicalName: Determines how Apache constructs self-referencing
# URLs and the SERVER_NAME and SERVER_PORT variables.
# When set "Off", Apache will use the Hostname and Port supplied
# by the client.  When set "On", Apache will use the value of the
# ServerName directive.
#
UseCanonicalName Off

Posted by 좋은진호
시스템이야기2008. 4. 23. 23:19
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 변수값을 로그에 남기면 된다.

사용자 삽입 이미지

<IfModule geoip_module>
        GeoIPEnable On
        GeoIPDBFile /usr/local/GeoIP/share/GeoIP/GeoIP.dat
</IfModule>

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{Host}i %{GEOIP_COUNTRY_CODE}e" cnxlog

CustomLog logs/access_log cnxlog

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

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

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

125.129.xxx.xxx - - [01/Apr/2008:01:07:15 +0900] "GET /bbs/ HTTP/1.1" 200 29388 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13" foobar.com KR
61.243.xxx.xxx - - [01/Apr/2008:01:17:20 +0900] "GET /data/linux_base/editors.html HTTP/1.1" 403 520 "-" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; DigExt)" foobar.com CN

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

Posted by 좋은진호
시스템이야기2007. 9. 19. 21:58
SSL인증서를 사용할 때, https는 왜 도메인기반 virtual host가 안되는가에 대해서 http://linuxchannel.net/board/read.php?table=qna&no=6427 에 2006년 1월에 답변한 내용을 정리한 것이다. 단일도메인 인증서(인증서 1개에 하나의 도메인만 갖고 있음)를 기준으로 답변한 내용이다. 와일드카드 인증서(*.foo.com 형태의 인증서)와 멀티인증서(foo.com, bar.com 등 여러 도메인을 하나에 넣은 인증서. 즉, Common Name(CN)을 여러개 갖고 있음)는 1개의 인증서로 같은 IP, 같은 포트(443)로 여러 도메인의 SSL 서비스가 가능하다.

한편 Channy's Blog( http://channy.creation.net/blog/?p=444 )에 따르면 TLS 프로토콜(RFC 2246)의 확장 규약(RFC 3546)에서 웹 서버와 브라우저 사이의 통신을 할 때 서버명을 미리 보내는 SNI(Server Name Indication)을 추가하였다고 한다. 따라서, 브라우저와 서버가 지원하게 되면 쉽게 virtual 설정이 가능할 날이 올 것으로 보인다.

----------------------------------------------------------------------------------------------------
글쓴이 : 좋은진호
글쓴날 : 2006년 01월 10일

     [이현철]님이 남기신 글:

> 상용화용 CA와 서버에서 만든 CA(테스트용 CA)를 사용할 경우
> 다른점은 단지 웹브라우저 접속시 서버에서 만든 CA를 사용해서 서명한 사이트 경우에는 경고창이 뜬다는것으로 알고 있습니다.
> (신뢰성이 없는 사이트라는 형태의 메세지)
>
> 상용화 CA라는것을 사용하는 이유는 신뢰성을 믿고 사이트를 이용해도 된다는 판단이라고 생각합니다.
>
> 그 이외 기능은 같다고 생각합니다.(암호화 처리)
    
예. 그렇습니다.

사설인증서를 사용하더라도 테스트는 동일하게 하실 수 있으며,
내부용으로 사용하는 것이나 단지 암호화를 위한거라면 사설인증서를 사용해도 됩니다.

> ----------------   ------------------ --------------------
> 현재 1대서버에 2개의 도메인이 존재하고 두개의 도메인 전부(http)웹서비스 그리고
> 하나의 도메인에 관해서만(https) 이용하고있습니다.(상용화키를 이용하지 않음-테스트용ca를 가지고 https형태로 이용중)
>
> httpd.conf에는
> ---------------------------------------------------
> <VirtualHost xxx.xxx.xxx.xxx:80>
>    ServerAdmin xxxxxxxxx
>    DocumentRoot /home/xxxxxxx
>    ServerName zec.gigaprize.co.jp
>    ErrorLog logs/error.log
>    CustomLog logs/access.log common
> </VirtualHost>
> <VirtualHost xxx.xxx.xxx.xxx:80>
>    ServerAdmin xxxxxxxxx
>    DocumentRoot /home/xxxxxxx
>    ServerName gourmet-star.gigaprize.co.jp
>    ErrorLog logs/error_1.log
>    CustomLog logs/access_1.log common
> </VirtualHost>
> ---------------------------------------------
>
> http://zec.gigaprize.co.jp/index.html (현재 index.html와 존재하지 않치만 도메인까지 접속은 가능함)
> http://gourmet-star.gigaprize.co.jp/index.html (현재 test용 index.html)이 존재함
>
> ----------------------------------
> ssl.conf에는
> ----------------------------------
> <VirtualHost _default_:443>
> #   General setup for the virtual host
> DocumentRoot /home/xxxxxxx
> ServerName gourmet-star.gigaprize.co.jp:443
> ErrorLog logs/ssl-error_log
> TransferLog logs/ssl-access_log
> -----------------------------------------------
> gourmet-star.gigaprize.co.jp 만 https(ssl)형태로 설정이 되어 있음.
>
> ----
> 실제 접속을 해보시면 알시겠지만 https://gourmet-star.gigaprize.co.jp/index.html
> 제대로 접속이 되고 있습니다.
>
> 그런데
> https://zec.gigaprize.co.jp/index.html
> 로 접속해보면 이 도메인도 https로 접속되어 버립니다.(index.html은 실제 존재하지 않는데, 내용을 보면 gourmet-gigaprize.co.jp 형태로 접속해버립니다.(웹브라우저 URL은 zec.gigaprize.co.jp 인데 index.html은
> gourmet-star.gigaprize.co.jp 내용이 보이고 있습니다)
>
> -------질문 1입니다..-----------------
> 위의 결과를 보면 1대의 서버에 443의 포트로 요청이(https가 설치되어있지않은 도메인도 ) ssl.conf에 설정된 도메인으로 결과를 보여주고 있는데 이것이 정상인지요?
> 개인적으로 https 설정되지 않은 도메인 경우에는 80은 보여주지만
> 443관해서는 에러가 나는 것이 정상이라고 생각하는데, 아니면 제 설정이 잘못되었습니까?
>------------------------------------

정상적인 현상입니다.
이유는 아래 질문에서 답변.

> --------질문2입니다-------------------
> 그리고 위의 두개 도메인을 전부 https형태로 시험해봤지만.
> (ssl.conf에 버츄얼로 두개의 도메일 등록-물론 ca와 각각 도메인별로 만들었음-테스트용 ca를 사용)
>
> 두개의 도메인을 등록 후 아파치설정 syntax테스트
> #sh apache2/bin/apachectl configtest
> Syntax OK
> 그리고 restart 한후 error.log를 보면 기존의 443포트가 이용하고 있기때문에 apachessl를 기동할수없다고 나옵니다.
> 결국 한대의 서버에 443포트는 하나의 도메인만 움직일수 있다는 결론인데요.(80포트는 몇개의 도메인을  띄울수있는데 말이죠)
>
> 결국 한대의 서버에 하나의 도메인만 https형태로 작동하는지요.
> --------------------------------------------------------------
> (상용화 CA사이트에 보면 700달러 정도주면 서브도메인(aaa.domail.com ,
> bbb.domail.com) 까지 전부 대응하는 CA도 팔고 있는데요..
> --------------------------------------------------------------

우선 처음 질문올릴 때 말씀하신, 여러 도메인을 SSL로 서비스를 한다면

1) 한 서버에 여러 IP를 할당하고, 웹서버는 각각의 IP에 바인딩해서 올리셔야 합니다.
   또는 https 포트를 443외에 각 도메인별로 다르게 하여 바인딩하거나.

2) 완전히 다른 서버에 한대당 하나의 도메인을 사용해야 합니다.

http(80포트)에서 virtual host 설정하는 것처럼 https를 도메인기반 virtual 설정으로는 안됩니다.

이유는 프로토콜의 계층만 이해하면 간단합니다.
HTTPS로 표시되는 SSL프로토콜층은 HTTP보다 하위에 있습니다.
그런데 웹서버의 virtual host설정에 의한 도메인정보는 HTTP의 헤더에 붙어있습니다.
즉, SSL프로토콜은 HTTP보다 하위이니 HTTP의 헤더를 이해를 못하는 것이겠죠.
따라서 도메인기반 virtual host설정과는 다르게 어떤 도메인으로 들어오든 첫 설정에 따라 결정이 되는겁니다.

layer는 http://coffeenix.net/doc/network/ssl_fig3.gif 에서 볼 수 있고,

사용자 삽입 이미지

이유는 http://www.modssl.org/docs/2.8/ssl_faq.html 에서 볼 수 있습니다.
    
Why can't I use SSL with name-based/non-IP-based virtual hosts?

The reason is very technical. Actually it's some sort of a chicken and egg problem: The SSL protocol layer stays below the HTTP protocol layer and encapsulates HTTP. When an SSL connection (HTTPS) is established Apache/mod_ssl has to negotiate the SSL protocol parameters with the client. For this mod_ssl has to consult the configuration of the virtual server (for instance it has to look for the cipher suite, the server certificate, etc.). But in order to dispatch to the correct virtual server Apache has to know the Host HTTP header field. For this the HTTP request header has to be read. This cannot be done before the SSL handshake is finished. But the information is already needed at the SSL handshake phase. Bingo!
Posted by 좋은진호
시스템이야기2007. 6. 11. 22:18
ModSecurity 는 아파치(apache)에서 사용하는 대표적인 웹방화벽 모듈이다. 아파치에 모듈을 설치하고, 룰(Rule) 설정을 통해 설정한 조건에 맞는 경우 차단을 할 수 있다. modsecurity 2.x 을 기준으로한 간단한 예이다.

- 웹서버명을 숨기거나 속인다.

SecServerSignature "lighttpd"

- 특정 메소드의 사용만 허용한다. (POST, GET, OPTIONS, HEAD 메소드만 허용)

SecRule REQUEST_METHOD "!^((?:(?:POS|GE)T|OPTIONS|HEAD))$" \
    "phase:1,log,auditlog,status:501,msg:'Method is not allowed by policy', severity:'2',,id:'960032',"

- 요청한 HTTP 프로토콜 버전이 1.0, 1.1이 아닐 경우 차단한다.

SecRule REQUEST_PROTOCOL "!^HTTP/(1\.[01])$" \
    "t:none, deny,log,auditlog,status:505,msg:'HTTP protocol version is not allowed by policy', severity:'2',,id:'960034',"

- GET, HEAD 메소드는 Content-Length가 0이 아닌 경우는 차단하고, POST는 Content-Length header가 없으면 차단한다.

SecRule REQUEST_METHOD "^(GET|HEAD)$" "chain,deny,log,auditlog,status:400,msg:'GET or HEAD requests with bodies', severity:'2',,id:'960011',"
SecRule REQUEST_HEADERS:Content-Length "!^0?$"

SecRule REQUEST_METHOD "^POST$" "chain,deny,log,auditlog,status:400,msg:'POST request must have a Content-Length header',,id:'960012',severity:'4'"
SecRule &REQUEST_HEADERS:Content-Length "@eq 0"

오픈소스 IDS인 snort에 기본 룰을 제공하는 것처럼 ModSecurity 에서도 modsecurity-core-rules 이름으로 룰 파일을 제공하고 있으니 참고하기 바란다. 룰에 대해서는 이만하고 원래 꺼내려한 얘기거리로 들어가자.

이런 룰 설정을 웹페이지를 통해서 할 수 있는 REMO(Rule Editor for ModSecurity) beta버전을 6월에 발표했고, Howtoforge에 Introducing Remo - An Easy Way to Secure an Insecure Online Application with ModSecurity 제목으로 REMO 다루는 방법에 대한 글이 올라왔다. 자세한 글은 Howtoforge에 글을 보시고, 간단하게 설명하면 이렇다.

REMO를 사용하기 위해서는 ruby 1.8.2이상, irb, sqlite3-ruby 환경이 필요하다. 또한 ModSecurity 모듈이 설치되지 않은 테스트나 개발 서버, 개인 PC 등에 설치해도 무관하다. 다음과 같이 실행한 후 http://서버:3000/main/index 로 접속하면 설정화면을 볼 수 있다.

wget http://remo.netnea.com/files/remo-0.2.0.tar.gz
tar xvzf remo-0.2.0.tar.gz
cd remo-0.2.0
ruby script/server

사용자 삽입 이미지
[ 이미지 출처 : 위 howtoforge URL ]

REMO화면에서 메소드와 URI등을 새로 입력한 다음, 원하는 조건을 정의한다. 그 후 'generate' 버튼을 누르면 파일로 룰셋 파일을 다운로드 받을 수 있다. 받은 룰셋을 다음과 같이 apache 설정에서 include해주면 된다.

<IfModule mod_security2.c>
    Include /파일경로/rulefile.conf
</IfModule>

REMO툴은 ModSecurity 룰 생성의 모든 것을 제공해주지는 않는다. modsecurity-core-rules 룰 파일을 보면 룰 설정이 쉽지않다는 것을 알 수 있다. 이 툴은 이런 복잡한 룰을 보고 고개를 설레설레 젓지 않도록 보조적인 역할을 하는 툴로 여기면 된다.
Posted by 좋은진호