[080630_정식] ModSecurity 안내서_090427_name_fixed.hwp

Transcription

1 ModSecurity 를활용한아파치웹서버보안강화안내서 KISA는본문서에서언급한 ModSecurity 및해당도구개발사인 Breach 社와어떠한관계도없으며, 국내웹해킹피해예방을위해공개웹방화벽인 ModSecurity를보안참고용으로소개합니다 본보고서의전부나일부를인용시반드시 [ 자료 : 한국정보보호진흥원 (KISA)] 를명시하여주시기바랍니다

2 1. 개요 ModSecurity 는 Apache 웹서버에서동작하는오픈소스웹방화벽이며, 소스의재사용및재생산된프로그램의공개조건인 GNU GPL 을따르는공개버전과 ModSecurity 의개발사인 Breach Security 社의상업용버전이있는데, 본안내서에서는공개버전을이용한설치및운영방법을알아본다. 본문서는 2006 년 3 월에발간된 ModSecurity 를이용한아파치웹서버보안 ( ) 에기초하여그동안업데이트된내용에대해보강하고 2.x 버전의내용을추가하였다. ModSecurity 는 O Reilly 社에서출간한 "Apache Security" 라는책을쓴 Ivan Ristic 가개발한툴로써, 설치및차단 Rule 설정인터페이스가 CLI 기반이어서다소불편하다는단점은있지만그만큼유연한정책설정이가능하고입력값검증기능이또한매우우수하다. Apache 웹서버는전세계적으로널리사용되는공개웹서버이며, 많은수의중소기업에서도사용하고있다. 그러므로고가의상용웹방화벽도입에어려움을겪는중소기업에서는 ModSecurity 를활용하여웹사이트에대한보안수준강화에큰도움을얻을수있다. 하지만, 다수의대형웹서버를운영하는기업이나복잡한웹환경을운용하는경우, 관리자인터페이스및기술지원측면을고려한다면상용웹방화벽도입이바람직하다. 본안내서에서는공개용 ModSecurity 를이용한아파치웹서버의보안강화방안을살펴보고, 특히국내에서홈페이지변조사고에이용되고있는 PHP Injection 공격에대응하기위하여 ModSecurity 에서어떻게설정해야하는지에대해사례를중심으로살펴보고, 웹서버의가장일반적인공격인 SQL Injection, XSS 등의대표적인웹공격에대한방어방법도함께기술하였다. ModSecurity 는웹공격에대한침입탐지및침입방지기능을추가해주는아파치웹서버의하나의모듈로동작하며, 웹클라이언트와아파치웹서버사이에 ModSecurity 가존재하여클라이언트로부터악의적인접속요청이발견되면공격차단, 로깅등사전에정의된행위를수행한다. 다른아파치모듈과마찬가지로 ModSecurity 를아파치의한부분으로설치할수있으며, 정상적으로설치되었을경우 ModSecurity 의추가적인처리로부터발생되는부하는거의없다고할수있다. ModSecurity 의주요특징은다음과같다. o 요청 (request) 필터링 - 클라이언트로부터웹요청이들어올때, 웹서버또는다른모듈들이처리하기전에 ModSecurity 가요청내용을분석하여필터링한다. o 우회방지기술 - 경로와파라미터를분석하기전에정규화시켜우회공격을차단한다. - 즉, //, \/,., %00 등우회공격용스트링을제거하고, 인코딩된 URL 을디코딩한다. o HTTP 프로토콜이해 - 엔진이 HTTP 프로토콜을이해하기때문에전문적이고정밀한필터링을수행할수있다. o POST 페이로드 (payload) 분석 - GET 방식뿐만아니라 POST 메소드를사용해서전송되는컨텐츠도분석가능하다

3 o 감사로깅 - POST를포함하여모든요청의모든상세한부분들까지추후분석을위해서로깅될수있다. - ModSecurity에서차단기능을비활성화시킨후, 강력한로깅기능만으로침입탐지시스템역할을수행할수있도록한다. o HTTPS 필터링 - 엔진은웹서버에임베디드되어있기때문에복호화한후에요청데이터에접근하여 HTTPS 를통한공격도필터링할수있다. 공개웹방화벽사용자커뮤니티 기술문서오탈자정보 기술정보및최적화등정보공유 기술문서및차단정책 ( 룰 ) 배포 사용자들간의질의답변 > 열린지식 > 공개웹방화벽커뮤니티 2. ModSecurity 1.x 설치및운영 ModSecurity는 1.x 버전과 2.x 버전이있다. 먼저알아볼것은 ModSecurity 1.x 버전이며본안내서에서는아래의환경에서 ModSecurity를설치하여테스트하였다. o 커널 : Linux smp o 웹서버 : Apache o ModSecurity 소스코드디렉토리 : /usr/local/modsecurity-apache_1.9.5 o 아파치소스설치디렉토리 : /usr/local/apache2 o 아파치웹서버홈디렉토리 : /usr/local/apache2/htdocs Breach Security에서는 ModSecurity 버전을마지막으로 1.x 버전에대한지원은더이상없다는뜻을홈페이지를통해공지하였다 ModSecurity 1.x 다운로드및설치 설치방법은 Linux 에서의과정을위주로살펴보겠다. 크게 2 가지설치방법이있는데소스를통해 설치하는방법과바이너리파일을통해설치하는방법이있다. 바이너리파일을통한설치는윈도 - 3 -

4 우즈버전의아파치를사용하거나컴파일러가없을경우에사용하면좋다. 본안내서에서는소스를통한설치방법을알아보도록한다. 설치하고자하는 ModSecurity 버전을다음사이트에서다운로드받을수있다. 또는, KrCERT/CC 홈페이지공개웹방화벽페이지에서다운로드받을수있다. /firewall2/index3.jsp 접속후 modsecurity-apache_1.9.5.tar.gz 다운 다운로드받은후다음의명령으로압축및패키징을해제한다. # tar xvzf modsecurity-apache tar.gz # cd modsecurity-apache-1.9.5; ls -al linux-web:/usr/local# cd modsecurity-apache-1.9.2; ls -al 합계 88 drwxrwx 월 drwxr-xr-x 21 root root 월 11 00:24.. -rw-rw 월 CHANGES -rw-rw 월 INSTALL -rw-rw 월 LICENSE -rw-rw 월 README drwxrwx 월 apache1 drwxrwx 월 apache2 drwxrwx 월 doc -rw-rw 월 httpd.conf.example-minimal drwxrwx 월 util 소스를통한설치방법에도웹서버초기설치시웹서버자체에모듈을설치하는방식과운영되고있는웹서버에 mod_security.c 만을컴파일하여포함시키는동적공유객체 (DSO, Dynamic shared object) 방식등두가지가있다. 일반적으로 DSO 방식으로설치하는것을권장하며 Static 방식으로설치할경우아파치를재설치해야하기때문에권장하는방법은아니다. DSO 방식설치 DSO 방식은아파치웹서버의재설치과정없이기존에운영되고있는아파치웹서버에모듈을동적으로추가하는방식이므로기존에아파치웹서버를이미운영중이면서 DSO 설치방식을지원하는기관의경우이방법을택하길권장한다. 그리고설치하기에앞서유념해야할사항이있는데, 필요한경우재차거듭하겠지만, ModSecurity 의설치는 Apache 의버전에의존적이다. Apache 1.x 의경우 ModSecurity 1.x 버전만설치가가능하며 Apache 2.x 의경우 ModSecurity 1.x 와 2.x 모두를설치할수있다. 하지만 ModSecurity 2.x 는 Apache2 에만설치가가능하다. 1 apxs 를이용하여 ModSecurity 모듈을컴파일하고, 설치하고, 설정을자동으로변경한다. # /usr/local/apache2/bin/apxs -cia /usr/local/modsecurity-apache_1.9.5/apache2/mod_security.c - 4 -

5 위의명령은 mod_security.c 를컴파일하고 (-c 옵션 ), 공유객체를웹서버 modules 디렉토리에설치하고 (-i 옵션 ), 아파치 httpd.conf 설정파일에적절한 LoadModule 줄을추가 (-a 옵션 ) 한다. 참고로 apxs 는아파치웹서버의확장모듈을컴파일하고설치하는도구로써, 여러소스와오브젝트파일을 LoadModule 지시어로실행중인아파치서버로읽어들일수있는동적공유객체 (DSO) 를만든다. 위의결과로 modules 디렉토리에 mod_security.so 가생성되고 httpd.conf 파일에 LoadModule security_module modules/mod_security.so 행이추가된다. 2 설치가완료되면다음과같은메시지가출력이될것이다. Libraries have been installed in: /usr/local/apache2/modules If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,--rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages chmod 755 /usr/local/apache2/modules/mod_security.so [activating module `security' in /usr/local/apache2/conf/httpd.conf] 3 아파치웹서버를재구동한다. # /usr/local/apache2/bin/apachectl stop # /usr/local/apache2/bin/apachectl start 여기까지 ModSecurity 의 DSO 방식을이용한모듈설치가끝났다. 실제설치방법이매우간단하고빠른방법이다. 소스컴파일을통한설치 DSO 방식이아닌정적으로소스컴파일될경우에는 ModSecurity 모듈이웹서버의 body 에포함되게된다. 이방법은 DSO 방식에비해다소실행속도가빠르지만, 아파치웹서버를재컴파일해야하는번거로움이있다. 또한, 아파치버전에따라설치를위한사전설정을달리해주어야한다. < 아파치 1.x 의경우 > # cd <apache1-source> # cp <modsecurity-source-path>/apache1/mod_security.c./src/modules/extra - 5 -

6 #./configure --activate-module=src/modules/extra/mod_security - enable-module=security < 아파치 2.x 의경우 > # cd <apache2-source> # cp <modsecurity-source>/apache2/mod_security.c./modules/proxy #./configure -enable-security --with-module=proxy:mod_security.c 아파치 1.x 또는아파치 2.x 에서위의과정을거친후에, 일반적인아파치컴파일과설치과정을거치면된다. # make && make install # /usr/local/apache2/bin/apachectl start DSO 방식과는달리소스컴파일을통한설치시에는 httpd.conf 파일에아무런내용이추가되지않는다. DSO 방식과마찬가지로 ModSecurity 를활성화시키기위해서는, 다음장의 ModSecurity 활성화및 Rule 정의를위한환경설정이필요하다 ModSecurity 1.x 활성화및 Rule 설정 ModSecurity 를설치하였다고해서바로웹방화벽기능이적용되는것은아니다. 이를적용시키기위해서는아파치웹서버환경설정파일 (httpd.conf) 의 <IfModule> 태그안에설정지시자 (directive) 를정의해주어야한다. <IfModule mod_security.c> # mod_security configuration directives # 이하생략... </IfModule> 또는 ModSecurity 를위한별도의환경설정파일을만들고이를 httpd.conf 에포함시킬수있다. 만약 "<apache_home>/conf/mod_security.conf" 라는이름으로 ModSecurity 웹방화벽을위한환경설정파일을별도로만들었을경우 httpd.conf 파일에다음과같이이파일을포함시켜줄수있다. Include conf/mod_security.conf ModSecurity 를위한 Rule 이다양하고, 내 외부웹환경에따라 Rule 변경및업데이트가지속적으로필요하기때문에별도의파일을이용하는것이좀더편리할것이다. ModSecurity 는다양한기능의설정을위해서상당히많은지시자들이존재하는데, 이를일일이직접작성하여적용하기는쉽지않을것이다. 따라서아래 ModSecurity 홈페이지에서제공하는 Rule template 을자신의웹환경에맞게수정하는것이용이할것이다. 위페이지에서 "Download ModSecurity and Core Rules from Breach Security Network" 를클릭하여들어가면로그인화면이나온다. 사용자계정이없을경우간단한등록절차후로그인하면 Core Rule 뿐만아니라 ModSecurity 의버전별소스까지다운받을수있다. Core Rule 에는기본설정및각유형별구체적인 Rule template 이있으므로이들을참고해보자

7 또는, KrCERT 홈페이지에서도 Sample Rule 을다운받을수있다. /firewall2/index3.jsp 페이지하단의업체및버전별 Sample Rule 다운 여기에서는 <IfModule> 태그안에들어갈지시자들중기본적인지시자들을알아보도록한다. 상당히다양한지시자가있으므로자세한것은아래를참고해보기바란다. /firewall2/index2.jsp 에 modsecurity1.9.4-manual.pdf 다운 기본환경설정 SecFilterEngine On ModSecurity 기능을활성화 (enable) 시킨다. o On : ModSecurity 기능활성화 o Off : ModSecurity 기능비활성화 SecFilterScanPOST On POST 메소드의 payload 를점검한다. ModSecurity 는다음과같은 2 가지타입으로인코딩된 Request body 를지원한다. o application/x-www-form-urlencoded (Form 데이터전송시사용 ) o multipart/form-data ( 파일전송시사용 ) 다른인코딩타입은대부분의웹어플리케이션에서사용되지는않는다. SetEnvIfNoCase Content-Type \ "^multipart/form-data;" "MODSEC_NOPOSTBUFFERING=Do not buffer file uploads" 각요청별로 POST payload 점검을비활성화할수있다. 환경변수 MODSEC_NOPOSTBUFFERING 이정의되어있으면 POST payload 버퍼링을하지않는다. SecFilterDefaultAction "deny,log,status:404" 룰이요청에일치하면하나또는그이상의행위 (action) 가발생된다. 각각의필터별로행위를정의할수있지만모든필터들을위한기본행위집합을정의하면편리하다. 모든필터에적용될수있는디폴트행위는 SecFilterDefaultAction 지시자로정의할수있다. 이설정은각룰에일치할경우접속요청을차단하고, 로그를남기긴후 HTTP 상태코드 404를보내는예이다. 일반적으로 SecFilter 로정의한옵션에적용이되며다른지시자와옵션을부가하여짜여진 Rule 은 SecFilterSignatureAction 으로행위를정의한다. 앞서 SecFilterDefaultAction 지시자로필터링규칙에일치할경우기본적으로어떤행위 (Action) 를하게할것인지에대해간단히알아보았다. 그러면필터링규칙에일치할경우일어날수있는행위의종류에대해알아보자. 먼저, 행위는다음과같은 3가지종류로나눌수있다

8 구분 Primary action Secondary actions Flow actions 설명 요청을계속진행할것인지차단할것인지를결정하는것으로, deny, pass, redirect 중하나를선택한다. Primary action 에의한결정과는독립적으로수행되는것으로 exec 와같은몇개의 secondary action 들이있다. 필터룰의흐름을변경할수있는것으로다른룰로점프하게하거나몇개의룰을건너띄게할수있다. Flow action 에는 chain 과 skipnext 가있다. 앞서 SecFilterDefaultAction 지시자에의한기본적용 action의예에서는콤마 (,) 로구분된 3개의 action을정의하고있다. 취할수있는대표적인행위는다음표와같다. 행위 pass allow deny status redirect proxy exec 설명 필터에일치할경우요청을그냥허용한다. 이 action 은아무런행위를하지않고그냥로그만남겨침입을모니터링하거나초기환경설정시유용할수있다. 예 ) SecFilter KEYWORD "log,pass" pass 에비해좀더강력한행위로이 action 이수행된후다른필터는적용시키지않고곧바로요청을허용하게된다. 예 ) SecFilterSelective REMOTE_ADDR "^192\.168\.2\.99$" allow 위의예는관리자컴퓨터 ( ) 에서의접속은항상허용하도록하고있다. 요청처리를차단한다. 상태 action(status) 이명시적으로함께사용되지않으면 ModSecurity 는 HTTP 500 error code" 를반환한다. 요청이거부되었을경우 HTTP 상태를제공한다. 예 ) SecFilter KEYWORD "deny,status:404" 필터가일치하면사용자를주어진 URL 로이동시킨다. 예 ) SecFilter KEYWORD "redirect:/warn.html" 필터가일치하면요청을내부리버스프록시로다시쓴다. 예 ) SecFilter KEYWORD proxy: 이동작은 mod_proxy 가반드시설치되있어야한다. 필터가일치하면특정바이너리를실행시킨다. 실행될파일은전체경로를지정해주어야한다. 예 ) SecFilter KEYWORD "exec:/home/ivanr/report-attack.pl" log 아파치에러로그 (error_log) 에기록한다. nolog 필터가일치해도기록하지않으며, audit logging" 도일어나지않도록한다. skipnext 필터가일치하면하나이상의룰을건너뛸수있다. 예 ) SecFilterSelective ARG_p value1 skipnext:2 SecFilterSelective ARG_p value2 SecFilterSelective ARG_p value3 ( 이후부터룰이적용된다.) - 8 -

9 행위 chain pause 설명 두개의룰을연관지어허용하고싶을때사용할수있다. 예 ) SecFilterSelective ARG_username admin chain SecFilterSelective REMOTE_ADDR "!^YOUR_IP_ADDRESS_HERE$" 요청에대한응답을하기전에정의된수 milliseconds 동안중지시킨다. 이는웹스캐너를느리게하거나완전히교란시킴으로써스캔공격을억제시킬수도있다. 어떤스캐너는중지시간이너무길면스캐닝을포기한다. auditlog 트랜젝션정보를 audit log(secauditlog 지시자에의해파일명지정 ) 에기록한다. noauditlog 트랜젝션정보를 audit log 에기록하지않는다. logparts 룰에따라로깅되는정보를추가, 삭제혹은다른것으로바꿀수있다. 예 ) SecFilter 111 pass, logparts:abcdefz SecFilter 222 pass, logparts:+c SecFilter 333 pass, logparts:-f SecFilterSignatureAction "deny, log, status:403" 룰설정을유지하기쉽게만들어주는이지시자는 1.9RC1 버전부터사용할수있다. 이지시자는단독설정내에서몇번이고쓰일수있고, 쓰인위치의다음에나오는룰에바로적용이된다. 각룰마다의동작을설정할수있게해주는기능을한다. 기본값은 deny,log,status:403" 으로 SecFilterSelective 등의옵션을사용할시 SecFilterSiganatureAction 값을설정해주지않으면기본값으로동작하게된다. 기본적인설정방법은 SecFilterDefaultAction 과동일하다. SecFilterCheckURLEncoding On 특수문자들은 URL 에전송되기전에인코딩될필요가있다. %XY(XY 는 16 진수 ) 형태의문자들은일반텍스트문자로변환된다 사용자 Rule 정의필터링엔진이활성화되면유입되는모든요청이웹서버에의해처리되어지기전에가로채어지고분석된다. 앞서환경설정지시자들에의해웹요청형태가유효한지등이점검된후, 두번째단계로웹요청은일련의사용자정의필터를거치게된다. 사용자에의해정의될수있는대표적인필터들은다음과같다

10 SecFilter KEYWORD [ACTIONS] 가장단순한형태의필터링으로특정키워드에의한필터를정의할수있다. SecFilter 지시자는웹요청의첫번째라인에서특정키워드가일치하는지점검하고, SecFilterScanPOST On 설정이되어있을경우에는 body 까지점검한다. 이때키워드는대소문자를구분하지않는다. 만일 SecFilter /bin/sh 와같이디렉토리를포함한키워드필터링을설정해놓았을경우공격자는 /bin/./sh 와같이필터를우회하여공격할수있다. 따라서, ModSecurity 에서는다음과같이공격자가우회할수있는특정문자열을자동으로변환하여키워드필터링을우회할수없도록하고있다. 변환 전 변환 후 비고 \ / 윈도우 시스템에서 적용 /./ / // / URL 인코딩된 문자열 URL 디코딩된 문자열 키워드는단순한 text 가아닌정규표현식으로다양한필터규칙을만들어적용시킬수있다. 키워드에서! 문자를맨앞에넣어서표현식을반대로적용할수도있다. 가령, SecFilter!php 같이하여 php" 문자를포함하지않는모든요청은거절할수도있다. SecFilterSelective LOCATION KEYWORD [ACTIONS] 앞서 SecFilter 지시자를이용한필터링은적용이너무광범위한단점이있다. 이러한단점을보완하여실제유용하게사용될수있는지시자가 SecFilterSelective 이다. 이지시자는 SecFilter 지시자에서 LOCATION 부분이추가되었는데해당키워드를어느위치에서찾을것인지지정해서보다정확한필터링을할수있도록한다. LOCATION 변수는다음과같이파이프 ( ) 로구분된일련의위치확인자로구성된다. SecFilterSelective "REMOTE_ADDR REMOTE_HOST" KEYWORD 위의예는클라이언트의 IP 주소와호스트이름에만키워드가적용된다. 위치확인자에들어갈수있는것은다음과같다. REMOTE_ADDR REMOTE_HOST REMOTE_USER REMOTE_IDENT REQUEST_METHOD SCRIPT_FILENAME PATH_INFO QUERY_STRING AUTH_TYPE DOCUMENT_ROOT SERVER_ADMIN SERVER_NAME SERVER_ADDR SERVER_PORT SERVER_PROTOCOL SERVER_SOFTWARE TIME_YEAR TIME_MON TIME_DAY TIME_HOUR TIME_MIN TIME_SEC TIME_WDAY TIME API_VERSION THE_REQUEST REQUEST_URI REQUEST_FILENAME REQUEST_BASENAME IS_SUBREQ 이외에도보다전문적이고부가적인위치확인자들도존재하는데이는 ModSecurity 의매뉴얼을참조하기바란다

11 SecFilterScanOutput On 아파치 2 에서 ModSecurity 는출력필터를지원한다. 기본설정상, 이기능은비활성화되어있으므로위와같이활성화시켜주어야한다. 기존의입력필터는웹요청이아파치에의해처리되기이전에실행되지만출력필터는아파치에의해웹요청이처리완료된이후에실행된다. 위와같이출력필터를설정한후에 OUTPUT" 파라메터를사용하여특정키워드를가진출력에대해필터링을할수있다. SecFilterSelective OUTPUT "Fatal error:" deny,status:500 ErrorDocument 500 /php-fatal-error.html 이와같이공격자가공격정보로이용될수있는정보나특정명령어실행결과등 Critical 한결과가실행되어공격자에게결과가전달되는것을차단할수있다. 출력필터는일반평문 text 와 HTML 출력에대해서만유용하며, 이미지와같은바이너리컨텐츠에대해정규식을적용한다면서버가느려질수있다. 디폴트로 ModSecurity 는컨텐츠타입을가지고있지않거나 text/plan" 또는 text/html" 을컨텐츠타입으로가진출력에대해서만스캔한다. 스캔하고자하는컨텐츠타입을바꾸고자할경우에는 SecFilterOutputMimeTypes 지시자를이용한다. SecFilterOutputMimeTypes "(null) text/html text/plain" 위의설정은 ModSecurity 가평문 text 파일, HTML 파일그리고 MIME 타입이정의되지않은파일들에대해출력필터를적용하게한다. 출력필터는유용한기능이라고할수있지만완벽하지는못하다. 공격자가모니터링하고있지않는컨텐츠타입으로바꾸거나출력을인코딩하는방법으로필터를우회할가능성이존재한다 기타지시자 SecUploadDir /tmp ModSecurity는 POST 요청과 multipart/form-data 인코딩을통하거나 PUT 요청을통한파일업로드를가로채어점검할수있는기능이있다. ModSecurity는항상임시디렉토리에파일들을업로드하게하는데, 이때 SecUploadDir 지시자를사용하여임시디렉토리를선택할수있다. SecServerSignature "Microsoft-IIS/5.0" 웹서버는기본적으로 HTTP 응답에서버의정보를실어서보낸다. 이정보는공격자들이공격하기위한기본정보가될수있다. 따라서, 이정보를 SecServerSignature 지시자를이용하여바꿈으로써공격자를혼란스럽게할수있다

12 SecFilterDebugLog logs/modsec_debug_log SecFilterDebugLog 지시자는디버깅결과를어디에기록할것인지를정의한다. 위치를지정해주는파라메터가슬래쉬 (/) 로시작하지않으면아파치홈디렉토리로부터의상대경로를의미한다. SecFilterDebugLevel 1 SecFilterDebugLevel 지시자를사용하여디버깅수준을얼마나상세하게수행할것인지를결정할수있다. 과도한디버깅수준은불필요한로그를생산할수있으므로문제발생시나서비스분석이필요한경우등에상세디버깅을하는것이바람직하다. 레벨 설명 0 없음 1 중요 이벤트 (error_l og 에 기록됨 ) 2 간략한 정보 메시지 3 상세한 정보 메시지 SecAuditEngine On SecAuditLog logs/audit_log 표준아파치로깅은특정사용자나공격자를추적하기위해서부족한면이있다. ModSecurity 는 SecAuditEngine 지시자를통해아파치의기본로그파일 (access_log, error_log) 보다좀더상세한공격관련정보를제공해줄수있다. SecAuditEngine 이사용할수있는파라메터는다음과같다. o On : 모든요청에대해로그를남김 o Off : 어떠한요청에대해서도로그를남기지않음 o RelevantOnly : 필터에일치하는요청에대해서만로그를남김 3. ModSecurity 2.x 설치및운영 우리는앞서 ModSecurity 1.x 버전의설치및운영방법을간략히살펴보았다. 이번절에서는 ModSecurity 2.x 버전의설치및운영방안에대해알아본다. o 커널 : Linux smp o 웹서버 : Apache o ModSecurity 소스코드디렉토리 : /usr/local/modsecurity-apache_2.1.4 o 아파치소스설치디렉토리 : /usr/local/apache2 o 아파치웹서버홈디렉토리 : /usr/local/apache2/htdocs

13 ModSecurity가 ' 부로 2.5가릴리즈되면서이안내서가최초개정당시 (1월) 안정화버전인 버전에비해많은발전이이루어졌다. 이에따라 ModSecurity의안정화버전은 2008년 6월기준으로 2.1.7( Realesed), 2.5.5('08.6.6) 이며 1.x 버전은 1.9.5가마지막안정화버전이다. 본안내서에서는 2.5.x 버전에대한내용은포함되어있지않다. ModSecurity 설치에앞서 1.x 버전과 2.x 버전의차이점을간단히알아보자. 구분 ModSecurity 1.x ModSecurity 2.x Apache 버전 Apache 1.x, 2.x 지원 Apache 2.x Only 설치법 apxs 이용한 DSO 방식, 소스컴파일 Makefile 처리단계 설정방법 Inbound(Request body) / Outbound(Response body) apache 1.x 의경우 <IfModule mod_security.c> apache 2.x 의경우 <IfModule security_module> phase:1 (Request header) phase:2 (Request body) phase:3 (Response header) phase:4 (Response body) phase:5 (logging) <IfModule security2_module> 룰활성화 SecFilterEngine SecRuleEngine 기본동작 SecFilterDefaultAction SecDefaultAction 지시자 SecFilter, SecFilterSelective SecRule Request body 접근 SecFilterScanPost SecRequestBodyAccess(phase:2) Response body 접근 SecFilterScanOutput SecResponseBodyAccess(phase:4) ModSecurity 2.5.x 버전에대한사항은별도안내서제작예정 ModSecurity 2.x 부터는 Apache 1.x를지원하지않는다. 그렇기때문에설치전시스템의 Apache 버전을확인후설치해야한다. 그리고각버전의룰이호환되지않기때문에개별적으로룰이생성된다. 3.1 ModSecurity 2.x 다운로드및설치 ModSecurity 2.x 부터는 Apache 1.x을지원하지않을뿐아니라설치시 apxs를지원하지않기때문에자체 Makefile을이용한설치만가능하다. 설치하기앞서자신의 Apache의버전을꼭확인하고 Apache2가아니라면최신 Apache를먼저다운로드후에설치해야한다. Apache는아래링크에서다운로드받을수있다. 이후, ModSecurity 버전을아래링크에서다운로드받는다

14 - ModSecurity 공식홈페이지 또는, - KrCERT/CC 공개웹방화벽페이지 /firewall2/index3.jsp 접속후 modsecurity-apache_2.1.4.tar.gz 다운 ModSecurity 2.x 버전을설치하면서아래사항을확인한뒤다음과정을진행하도록하자. 세부사항 PCRE libxml2 ModSecurity 2.x 가정상작동을위해필수설치되있어야함. => 다운로드 ModSecurity 2.x 가정상작동을위해필수설치되있어야함. => 다운로드 unique_id ModSecurity 2.x 가필터링기능을수행하기위해필수 Enable 되있어야함. =>./configure --enable-unique-id --enable-so Apache 컴파일시 enable 해야하며, RPM 설치버전은모듈로드확인 위언급한세가지사항을체크한뒤 ModSecurity의설치를진행하는것이수월하다. 다운로드받은파일을압축해제하면다음과같은파일과폴더가생성된다. # tar xzvf modsecurity-apache_2.1.4.tar.gz # cd modsecurity-apache_2.1.4; ls -al 합계 52 drwxrwx 월 28 06:05. drwxr-xr-x 22 root root 월 16 16:08.. -rw-rw 월 28 03:37 CHANGES -rw-rw 월 LICENSE -rw-rw 월 27 21:45 README.TXT drwxrwx 월 28 06:05 apache2 drwxrwx 월 28 06:06 doc -rw-rw 월 8 01:24 modsecurity.conf-minimal drwxrwx 월 28 06:05 rules [root@www modsecurity-apache_2.1.4]# ModSecurity 2.x는 Makefile을이용한설치방법만존재하기때문에 Apache가설치된종류에따라구분하여설명한다. RPM 으로설치된 Apache

15 Apache가 RPM 패키지로설치되어있다면레드햇계열의경우 httpd-devel, 데비안계열에서는 apache2-prefork-dev나 apache2-threaded-dev 패키지가설치되있어야한다. 1 최초압축을해제한폴더에서 apache2 폴더로이동하면 Makefile 파일이존재한다. 이파일을열어다음과같이수정한다. 35 번째라인의 top_dir 값수정 top_dir = /apps/apache22 top_dir = /etc/httpd top_dir = /usr/share/apache22 top_dir = /var/apache2 // 데비안계열 // 솔라리스계열 45번째라인의 libxml2 옵션확인, 기본적으로아래경로에설치되기때문에특이한경우가아니라면수정하지않아도된다. INCLUDES = -I /usr/include/libxml2 2 컴파일하여설치한다. # make && make install 3 설치가완료되면 /usr/lib/httpd/modules/mod_security2.so 파일이생성되었는지확인한다. 확인되었다면 httpd.conf 를열어아래문장을추가해준다. LoadFile /usr/lib/libxml2.so //mod_security 보다먼저 Load되어야한다. LoadModule security2_module modules/mod_security2.so LoadModule unique_id_module modules/mod_unique_id.so // RPM설치이므로추가 4 아파치웹서버를재구동한다. # /etc/init.d/httpd restart DSO 방식으로설치된 Apache 1 DSO 방식으로설치된 Apache 역시 Makefile 에서아래사항을수정해줘야한다. 35 번째라인의 top_dir 값수정 top_dir = /apps/apache22 top_dir = /usr/local/apache2 45번째라인의 libxml2 옵션확인, Default로아래경로설치 INCLUDES = -I /usr/include/libxml2 2 컴파일하여설치한다. # make && make install 3 설치가완료되면 /usr/local/apache2/modules/mod_security2.so 파일이생성되었는지확인한

16 후 httpd.conf에아래문장을추가해준다. LoadFile /usr/lib/libxml2.so // mod_security 보다먼저 Load되어야한다. LoadModule security2_module modules/mod_security2.so 재차강조하지만소스컴파일된 Apache 의경우는 unique_id 모듈이 Enable 되어있어야한다. 4 아파치웹서버를재구동한다. # /usr/local/apache2/bin/apachectl stop # /usr/local/apache2/bin/apachectl start 3.2 ModSecurity 2.x 활성화및 Rule 설정 ModSecurity 2.x를설치하였으니 1.x버전과마찬가지로웹방화벽기능적용을위해 httpd.conf 파일내에설정지시자를정의해주자. 2.x버전의대부분의지시자는 Virtual Host, Location, Location Match, Directory 등의 Apache 지시자내에서도사용할수있다. 그외에메인파일의구성중에서는오직한번만사용할수있는것들이있는데, 지금부터자세히알아보겠다. 마찬가지로관리의편의상별도의룰파일을생성하여 httpd.conf에 Include시키자. Include conf/mod_security2.conf ModSecurity 2.x의룰은 1.x버전과호환이되지않기때문에별도로구분해줘야한다. 여러부가기능과옵션들이추가되었으니이제그업데이트된기능을알아보자. ModSecurity 2.x는공식홈페이지에서 Core-Rule을제작하여배포하고있다. 2.x에서는다양한기능이추가되었디때문에이러한 Core-Rule을통해미리룰의사용법을숙지해두어야한다. 또한압축해제하여생성된 rules 폴더내에 Core-Rule을기본포함되어있으니별도로다운받을필요가없다. 이외에 KrCERT 홈페이지에서도 Sample Rule 을다운로드받을수있다. /firewall2/index3.jsp 하단에업체및버전별 Sample Rule 다운 이제실제로 <IfModule> 태그안에들어갈지시자들중기본적인지시자들을알아보도록한다. 상당히다양한지시자가있으므로자세한것은아래를참고해보기바란다. /firewall2/index2.jsp 에 modsecurity2.1.4-manual.pdf 다운

17 3.2.1 기본환경설정및로깅관련지시자 SecRuleEngine On Off DetectionOnly ModSecurity 기능을활성화 (enable) 시킨다. o On : ModSecurity 기능활성화 o Off : ModSecurity 기능비활성화 o DetectionOnly : 활성화는하지만차단하지않고탐지만한다. SecAuditEngine On Off RelevantOnly 감사로깅에대한설정을구성한다. o On : 모든트랜젝션로깅 o Off : 모든트랜젝션로깅하지않음 o RelevantOnly : Error 또는, Warning 의트랜젝션, 그리고 SecAuditLogRelevantStatus에정의된상태코드와일치하는트랜젝션만로깅 SecAuditLog logs/modsec_audit.log 감사로그파일의경로를정의한다. 예 ) SecAuditLog /usr/local/apache2/logs/modsec_audit.log 이파일은 Root로접근했을때만확인할수있어야하며 Root가아닌사용자의접근은불가해야한다. 이로그파일에는 Serial 방식의로깅형태에사용된다. 만약 Concurrent 방식의로깅형태라면이파일은로그의 Index로쓰여지게되며모든감사로그에대한파일이생성되면서그기록을포함하게된다. 만약 Concurrent 로깅방식을사용하고감사로그를원격콘솔로보내려면 modsec-auditlog-collector.pl 스크립트를아래와같이사용하면된다. 예 ) SecAuditLog \ " /path/modsec-auditlog-collector.pl /path/secauditlogdatadir /path/secauditlog" SecAuditLogParts 로그파일에기록할항목을정의한다. 예 ) SecAuditLogParts ABCFHZ Parts 세부내용 A audit log header ( 필수 ) B C request header request body (request body 가존재하고 modsecurity 가 request body 를검사하도록설정되어있는경우에만 ) D 보류중, response header 의중개 ( 현재지원안됨 ) E response body 중간단계 ( 현재 modsecurity 가 response body 를검사하며감사로깅엔진이이를저장하게끔설정되어있는경우에만 )

18 Parts 세부내용 F 최종 response header( 마지막컨텐츠전달과정에서아파치에의해매번추가되는날짜와서버헤더를제외한 ) G 실제 response body( 현재지원안됨 ) H I J 감사로그트레일러 이옵션은 C를대체하는옵션이다. multipart/form-data 인코딩이사용되었을때를제외한모든경우엔 C와같은데이터를기록한다. 보류중, 이옵션은 multipart/form-data 인코딩을사용하는파일업로드에대한정보를포함할때효과가있다. Z 로그의끝을의미한다. ( 필수 ) SecAuditLogRelevantStatus REGEX 감사로깅의목적과관련된 response 상태코드의값을설정한다. o 매개변수에는정규표현식이들어간다. 예 ) SecAuditLogRelevantStatus ^[45] SecAuditLogType Serial Concurrent 감사로깅구조의타입을설정한다. o Serial - 모든로그는메인로그파일에저장된다. 일시적으로편리할순있지만하나의파일에만기록되기때문에느려질수있다. o Concurrent - 로그가각트랜잭션별로나누어저장된다. 이방식은로그파일을원격 ModSecurity Console host로보낼때사용하는방식이다. SecDefaultAction "log, auditlog, deny, status:403, phase:2, t:lowercase" 룰이매칭되면기본적으로취할행동을정의한다. 1.9.x 버전의 SecFilterDefaultAction을떠올리면이해가쉬운데 2.1.x 버전에서는옵션들이더욱다양해졌다. 룰이특정액션들에대한개별룰을적용하거나다른 SecDefaultAction이정의되어있지않다면최초지정된 SecDefaultAction의설정을따른다. 위의예는룰이매칭되었을때차단하며로그를남기고, 403 상태코드페이지를보여주며필터링단계는 2 이다. 기본적으로대문자는모두소문자로바뀌어필터링된다. SecDefaultAction 지시자의추가적인 Action에대해알아보자. 먼저, 다음과같은 5가지종류로분류할수있다

19 구분설명 Disruptive actions Non-Disruptive actions ModSecurity 가데이터를중간에서가로챌때일어나는행위이다. 하나의체인에첫번째룰에만나타낼수있다. allow, deny, drop 등이있다. 어디에나나타낼수있다. capture, ctl, exec, initcol 등이있다. Flow actions 하나의체인에첫번째룰에만나타낼수있다. chain 이있다. Meta-data actions 하나의체인에첫번째룰에만나타낼수있다. id, rev, severity, msg 가있다. Data actions 전면적으로수동적이고다른행위에서사용된데이터를운반하는역할뿐이다. 앞서 SecDefaultAction 지시자에의한기본적용 action의예에서는콤마 (,) 로구분된 6개의 action을정의하고있다. 취할수있는대표적인행위는다음표와같다. 행위설명 allow auditlog capture chain 룰에매칭되면처리를멈추고트랜젝션을허가한다. 예 ) SecRule REMOTE_ADDR "^192\.168\.1\.100$" "nolog, phase:1, allow" allow 액션은오직현재처리단계에서만적용된다. 감사로그에트랜젝션을기록한다. 예 ) SecRule REMOTE_ADDR "^192\.168\.1\.100$" "auditlog, phase:1, allow" 정규표현식과함께사용되었을때 capture 액션은정규표현식의사본을만들고트랜잭션의가변적인콜렉션에모은다. 최대 10 개가수집되면각각 0~9 까지한자리숫자의이름이매겨진다. 예 ) SecRule REQUEST_BODY "^username=(\w{25,})" "phase:2,capture,t:none,chain" SecRule TX:1 "(?:(?:a(dmin nonymous)))" 두개의룰을연관지어허용하고싶을때사용할수있다. 예 ) SecRule REQUEST_METHOD ^POST$ "chain" SecRule REQUEST_HEADER:Content-Length ^$ ctl 액션은트랜잭션을최신화하기위한설정옵션이다. 예 ) SecRule REQUEST_CONTENT_TYPE ^text/xml "nolog,pass,ctl:auditengine=on" ctl 다음과같은옵션들이들어갈수있다. auditengine auditlogparts debugloglevel requestbodyaccess requestbodylimit requestbodyprocessor responsebodyaccess responsebodylimit ruleengine

20 행위설명 deny 룰이일치할경우요청처리를차단한다. status action 이명시되어있지않으면 ModSecurity 는 HTTP 403 error code" 를반환한다. 예 ) SecRule REQUEST_HEADERS:User-Agent \ "nikto log,deny,msg:'nikto Scanners Identified'" drop FIN 패킷을보내 TCP 연결을끊어서연결을종료시킨다. exec id log 필터가일치하면파라미터를지원하는외부스크립트 / 바이너리를실행시킨다. 예 ) SecRule REQUEST_URI "^/cgi-bin/script\.pl" \ "log, exec:/usr/local/apache/bin/test.sh, phase:1" 룰이나체인에 unique ID 를할당한다. 예 ) SecRule &REQUEST_HEADER:Host "@eq 0" \ "log, id:60008, severity:2, msg:'request Missing a Host Header'" 필터가일치하였을때로그를남긴다. 이동작은 Apache 의 error log 와 ModSecurity 의 audit log 를비교한다. msg 룰이나체인에사용자메시지를지정한다. noauditlog nolog pass pause phase 필터가일치하였을때해당트랜젝션을 audit log 에기록하는기준으로하지않는다. 예 ) SecRule REQUEST_HEADER:User-Agent "Test" "allow, noauditlog" 만약 SecAuditEngine 이 On 으로설정되어있으면모든트랜젝션은로깅된다. 만약 RelevantOnly 로설정되어있으면, noauditlog 로제어할수있다. noauditlog 가설정되고 audit event 가발생한다면트랜젝션을로깅할수있다. 확실하게 audit logging 을비활성화하려면 "ctl:auditengine=off" 를쓰면된다. 에러와감사로그에서나타나는일치현상을방지한다. 예 ) SecRule REQUEST_HEADERS:User-Agent "Test" "allow, nolog" 필터에일치해도요청을그냥허용하고다음단계로진행한다. 예 ) SecRule REQUEST_HEADERS:User-Agent "Test" "log,pass" 요청에대한응답을하기전에정의된수 milliseconds 동안중지시킨다. 예 ) SecRule REQUEST_HEADERS:User-Agent "Test" "log,deny,pause:5000" Brute Force scanner 의속도를떨어트리거나보호할수있다. DoS 유형의공격아래에있을때는 pause 가완료할때까지 child process 가무력화되는경우가발생할수있다. 룰이나체인이속하게되는 1~5 까지의처리단계예 ) SecDefaultAction "log,deny,phase:1,t:removenulls,t:lowercase" SecRule REQUEST_HEADERS:User-Agent "Test" "log,deny,status:403" 잘못된 phase 를지정하지않게유의해야한다. 대상변수가무의미할수있다. 변수나정규식이 false negative 를일으킨다면올바른작동이다. 그러나악성데이터를처리하지못하는것은잘못된 phase 를지정했기때문이다

21 행위설명 proxy redirect skip status 필터가일치하면트랜젝션을가로채어프록시가구동중인다른웹서버로요청을포워딩한다. 예 ) SecRule REQUEST_HEADERS:User-Agent "Test" \ "log, proxy: 이동작은 mod_proxy가반드시설치되있어야한다. 필터가일치하면사용자를주어진 URL로리다이렉트시킨다. 예 ) SecRule REQUEST_HEADERS:User-Agent "Test" \ "redirect:/failed.html" 만약 status 액션이현재사용하고있거나가능한값이 301,302,303,307 이라면그것은 redirection에사용될것이다. 그렇지않다면 302 상태코드를사용한다. 필터가일치하면하나이상의룰이나체인을건너뛸수있다. 예 ) SecRule REQUEST_URI "^/$" "chain,skip:2" SecRule REMOTE_ADDR "^127\.0\.0\1$" "log,deny,status:400" SecRule &REQUEST_HEADERS:Accept "@eq 0" \ "log,deny,log,status:400,msg:'request Missing an Accpet Header'" deny 나 redirect 액션에서사용될상태코드값을지정한다. 예 ) SecDefaultAction "log,deny,status:403,phase:1" t 이액션은룰에지정된연산자가실행되기전변수에지정된변형함수에사용될수있다. 예 ) SecDefaultAction "log,deny,phase:1,t:removenulls,t:lowercase" SecRule REQUEST_COOKIES:SESSIONID "47414e81..." \ "log, deny,status:403,t:md5" 이외에도추가된더다양한기능및옵션들이있으나여기서다루기에는그양이방대하다보니간략한설명으로마친다. ModSecurity 1.x에서지원되는기능들은거의그대로따르고있지만그쓰임이조금변했거나더강화된차이가있다. SecRequestBodyAccess On Off Request 값에서 Body 부분에대한처리를어떻게할것인지구성한다. o On : RequestBody 접근을시도한다. o Off : RequestBody 접근시도를하지않는다. 이지시자는 Request 값에서의 POST_PAYLOAD를검사할때필요하다. POST값을필터링하기위해서는 phase:2와 REQUESET_BODY 변수 / 로케이션, 3가지가모두구성되어야만처리가가능하다

22 SecRequestBodyLimit ModSecurity가 Request Body 크기로할당할수있는메모리최대크기를설정한다. o SecRequestBodyLimit KB ( byte) 가기본값이다. SecReponseBodyAccess On Off Response 값에서 Body 부분에대한처리를어떻게할것인지구성한다. o On : ResponseBody 접근을시도한다. ( 그러나 MIME 타입과일치해야만한다.) o Off : ResponseBody 접근시도를하지않는다. 이지시자는 html 응답을조사하기위해필요하다. "phase:4" 의처리단계와 RESPONSE_BODY 변수 / 로케이션, 3가지가설정되어있지않으면, response body를검사할수없다. SecResponseBodyLimit ModSecurity가 Response Body 크기로할당할수있는메모리최대크기를설정한다. o SecRequestBodyLimit 이값을넘어가면서버는 500 내부서버오류메시지만표시할것이다. SecReponseBodyMimeType mime/type Response 값에서 Body 값을버퍼링할 MIME 타입을설정한다. o SecResponseBodyMimeType text/plain text/html // 기본값 Mime 타입은복수로추가할수있다. SecReponseBodyMimeTypesClear ResponseBody의버퍼링을위해 Mime 타입의목록을지우며, 처음에위치시킨다. o SecResponseBodyMimeType

23 3.2.2 사용자 Rule 정의 SecRule REQUEST_URI "attack" SecRule 은 ModSecurity 의핵심지시자이다. 데이터분석과액션실행의기본이된다. o SecRule REQUEST_URI "attack" SecRule 은다음세가지로구성되어있다. o SecRule VARIABLES OPERATOR [ACTIONS] - Operator 는어떻게검사할것인지를지정하며, - Actions 는 operator 을통해변수가실행되어일치하였을때어떤행동을취할것인지를지정 1 변수 (Variables) 다음예제는 dirty' 를포함한트랜젝션을거부한다. ex) SecRule REQUEST_URI dirty 중복하여사용할수도있다. ex) SecRule REQUEST_URI QUERY_STRING dirty 2 연산자 (Operator) 연산자에는정규식을사용할수있다. 로시작하여야하며정규식을이용해특별한패턴으로대상을검사할수있다. ex) SecRule REQUEST_URI "@rx dirty" 부정을표현할땐다음과같이사용할수있다. ex) SecRule REQUEST_URI "!@rx ^0$" 3 행위 (Actions) 행위는 default action 에서지정되기때문에생략할수있다. 만약생략하지않고추가로지정된다면 default action 과병합되어 action 이작용되게된다. 액션은위에서설명하였다. SecRuleInheritance On Off 상위문맥으로부터룰을상속받을지안받을지설정하기위한지시자이다. o SecRuleInheritance On 각가상호스트마다별도로룰을설정할수있다. <VirtualHost *:80>... ServerName app1.com SecRuleInheritance Off SecDefaultAction log,deny,phase1,redirect: </VirtualHos> <VirtualHost *:80>... ServerName app2.com SecRuleInheritance On SecRule ARGS "attack"... </VirtualHos>

24 SecRuleRemoveById 상위문맥과룰이일치하면일치한룰을제거한다. o SecRuleRemoveById 1 2 " " 다중파라미터를지원하며쌍따옴표를통한범위를지정할수있다. 파라미터는 RULE ID 나하나의범위가될수도있다. SecRuleRemoveByMsg 상위문맥과룰이일치하면일치한룰을제거한다. o SecRuleRemoveByMsg "FAIL" 위지시자는 RULE ID 로룰을제거하지만이지시자는 action 의 msg 가지정한정규식에따라룰을제거한다. SecServerSignature "Netscape-Enterprise/6.0" 응답헤더의 "Server:" 토큰을바꿔표시한다. o SecServerSignature "Microsoft-IIS/5.0" 이지시자를사용하려면 Apache 의설정파일에서 ServerTokens 값이 Full" 로설정되있어야한다. SecDebugLog /path/to/modsec-debug.log ModSecurity 의디버그로그의경로를설정한다. o SecDebugLog /usr/local/apache2/logs/modsec-debug.log SecDebugLogLevel 디버그로그의상세수준을결정한다. o SecDebugLogLevel 4 level 1~3 은항상 Apache 의에러로그로보낸다. level 5 가디버깅에가장유용하며그이상은서버의성능을저하시키기때문에권장하지않는다. 0 로깅하지않는다. 4 트랜젝션의처리과정상세 1 에러만 ( 요청값 ) 로깅 5 4와동일하나각처리의부분별정보가포함 2 경고수준 9 모두로깅, 디버깅정보를상세히포함 3 공지수준 SecDataDir /path/to/dir 영구적데이터를저장할경로를지정한다.(IP 주소, Session 값등 ) o SecDataDir /usr/local/apache2/logs/data 이지시자는 initcol, setsid, setuid 가사용될때필요하다. 반드시웹서버사용자에의해쓰기가가능해야한다

25 SecTmpDir /path/to/dir 임시파일이생성될디렉토리를설정한다. o SecTmpDir /tmp Apache 사용자프로세스에의해쓰기가가능해야한다. 이디렉토리는검사가진행되는동안아파치가메모리가부족할때디스크를스왑하기위한영역이다. ( 메모리크기는 SecRequestBodyInMemoryLimit 지시자에의해설정된크기이다.) SecUploadDir /path/to/dir 가로챈파일을저장하기위한디렉토리를설정한다. o SecUploadDir /tmp SecTmpDir 지시자에의해지정된디렉토리와같은파일시스템에위치해야한다. 이지시자는 SecUploadKeepFiles 와함께쓰인다. SecUploadKeepFiles On Off RelevantOnly 트랜젝션이처리된후에가로챈파일을유지할것인지아닌지를설정한다. o On : 업로드된파일을유지한다. o Off : 업로드된파일을유지하지않는다. o RelevantOnly : 수락된요청과관련된업로드파일만유지한다. 3.3 트래픽감사예외 IP 설정 외부에서취약점점검이나모의해킹등을수행할때에는점검트래픽과공격트래픽이거의유사하기때문에공격으로탐지되어차단된다. 그러므로이러한진단작업을진행하기에앞서, 감사예외 IP로설정하면지정된 IP에대해서는차단조치하지않기때문에전상적인점검이가능하다. 다음은본설정방법을설명하기위한예시 IP 목록이며아래의 IP들에대해감사예외 IP로설정하는방법을알아본다 이 IP 목록을 ModSecurity 설정파일에서버전별로아래와같이입력해주면된다. o ModSecurity 1.9.x 버전

26 형식 SecFilterSelective REMOTE_ADDR " 허용할 IP" allow 사용 SecFilterSelective REMOTE_ADDR "221\.149\.161\.5" allow SecFilterSelective REMOTE_ADDR "211\.252\.151\.24" allow SecFilterSelective REMOTE_ADDR "211\.252\.151\.44" allow o ModSecurity 2.x 버전 형식 SecRule REMOTE_ADDR " 허용할 IP" allow,ctl:ruleengine=off 사용 SecRule REMOTE_ADDR "221\.149\.161\.5" allow,ctl:ruleengine=off SecRule REMOTE_ADDR "211\.252\.151\.24" allow,ctl:ruleengine=off SecRule REMOTE_ADDR "211\.252\.151\.44" allow,ctl:ruleengine=off 위설정은예외처리를해주지만그에대한로그는동일하게기록된다. 취약점점검서비스를통해다량의로그발생시에는 Action 지시자에 nolog를추가해주면로그가기록되지않는다

27 4. ModSecurity 를이용한모의공격차단 ModSecurity 설치를완료한뒤룰설정까지끝났다면정상적으로동작하는지확인해보자. 다음화면은가상서버에운영중인배달서비스홈페이지화면이다. PHP환경에서제로보드를설치하여운영중인이사이트는제로보드 PHP Injection 취약점에노출되어있는상태였다. 아래화면은임의의서버에서공격스트링을포함한파일을 Injection 시도하여대상서버의 passwd 파일을출력시킨화면이다. 이후 ModSecurity 를설치하여동일한공격테스트를시도했더니아래와같은 406 에러를화면에띄우면서정상적으로차단이되었다

28 그리고아래는차단된후 ModSecurity에의해생성된로그내용이다. 네모박스를살펴보면입력된값과매치된 rule, 차단메시지를볼수있다. 이와같이 ModSecurity는 PHP Injection 이외에도 SQL Injection, XSS, Directory Traversal 공격등다양한웹해킹공격으로부터서버를안전하게보호할수있다. 공개웹방화벽인 ModSecurity의특성상이번에안내한기능외에도다양한커뮤니티또는포럼등에서알려진기능및추가호환되는환경에서의사용법등이많이있기때문에 KISA에서도이러한기능들을제공할수있도록많은노력을기울일예정이다. 또한, ModSecurity의공식홈페이지에서도지속적인 Core Rule 업데이트와버전업이이뤄지고있다. 웹보안의기본은 Secure Coding과서버관리자의보안마인드에서부터비롯된다. 아무리웹방화벽이나솔루션들의기능이좋다하더라도궁극적으로위두가지사항을간과한다면웹사이트의보안수준향상에더욱더멀어지게될것이다. 이외에도 KISA에서발간된홈페이지보안안내서나템플릿을참고하면서안전한웹서버운영에도움이되길기대한다