이전에는 주로 특정 데몬의 취약성 등 이른바 시스템의 취약성을 이용해 각종 인증을 우회함으로써 접속하거나 상위 권한을 획득했지만, 최근 1~2년 사이에는 다른 양상을 보이고 있다. 즉, 웹 서버 내 설정상의 오류나 웹 애플리케이션의 취약성을 이용한 소위 ‘웹 해킹’을 통해 웹 서버의 실행 권한을 획득하는 경우가 많아지고 있다는 것이다.

이전에는 주로 특정 데몬의 취약성 등 이른바 시스템의 취약성을 이용해 각종 인증을 우회함으로써 접속하거나 상위 권한을 획득했지만, 최근 1~2년 사이에는 다른 양상을 보이고 있다. 즉, 웹 서버 내 설정상의 오류나 웹 애플리케이션의 취약성을 이용한 소위 ‘웹 해킹’을 통해 웹 서버의 실행 권한을 획득하는 경우가 많아지고 있다는 것이다.

이는 최근 sendmail이나 ssh 등 전통적으로 취약했던 애플리케이션에서 그다지 심각한 취약성이 나타나지 않으면서 상대적으로 취약성이 많이 공개된 웹 해킹 쪽으로 관심을 돌리고 있기 때문이다. 실제로 웹 해킹을 이용할 경우 80번 포트를 통해 접속하므로 정상적인 웹 접속과 구분이 잘 되지 않아 로그도 남지 않고, 설사 남는다해도 찾기가 어려운 것이 사실이다. 또한 파이어월이 설치된 환경이라도 웹은 항상 열려있으므로 제한 없이 공격 시도를 할 수 있다는 점도 공격자 입장에서는 큰 이점이다.

특히 국내에서는 제로보드나 technote 등 각종 게시판 프로그램의 사용률이 매우 높아 한번 취약성이 공개되면 그 피해는 매우 크다. 특히 웹 해킹을 이용할 경우 전통적인 방식처럼 IP를 바꿔가면서 무작위로 스캔을 하는 것이 아니라 구글 등의 검색 엔진을 이용해 직접 공격을 하는 양상을 보이고 있다.

이런 웹  해킹의 증가에 대해 여러 대응 방법이 논의되고 있다. 물론 고가의 웹 보안 솔루션을 설치하는 것도 좋겠지만 자유롭게 사용할 수 있는 대표적인 웹 서버 보안 모듈인 modsecurity(www.modesecurity)를 활용하는 방법도 추천할 만 하다. 특히 오랜 개발 과정을 통해 현재에는 상당 부분 기능이 안정화돼 현재 운영중인 서비스에 적용해도 무난할 것이다.

(화면 4) modsecurity 홈페이지

modsecurity는 아파치 웹 서버의 모듈 형태로 작동하는데, DSO 방식을 이용할 수도 있고 정적(Static)으로 바이너리에 포함하도록 할 수 있다. 여기에서는 후자의 방식을 이용해 설치하도록 하겠다.

먼저 홈페이지에서 소스 파일을 다운로드받아 압축을 해제하고, 모듈파일인 mod_security.c 파일을 아파치의 소스내 모듈 디렉토리인 src/modules/extra/ 디렉토리에 복사한다.
그리고 다음과 같이 modsecurity를 포함하도록 아파치를 재설정하면 된다.

[root@www apache_1.3.xx]# ./configure --prefix=/usr/local
     --activate-module=src/modules/php4/libphp4.a
     --activate-module=src/modules/extra/mod_security --enable-module=security

이제 컴파일한 후 다음과 같이 재설치하면 모든 작업이 끝난다.

[root@www apache_1.3.xx]# make; make install

modsecurity는 많은 지시자(directive)를 제공해 웹 서버 관리자가 원하는 기능을 설정하거나 제어할 수 있는데, 바로 적용해 사용할 수 있도록 ‘www.modsecurity.org/documentation/quick-examples.html’에서 설정 예를 제공하고 있으니 참고하기 바란다.

modsecurity는 아파치 설정 파일인 httpd.conf에서 다음과 같이 <IfModule        mod_security.c>와 </IfModule> 사이에 지정하면 된다.

<IfModule mod_security.c>
 SecFilterEngine On
 SecFilterScanPOST On
 .........
 ...중략...
</IfModule>
 
몇 가지 중요한 지시자에 대해 구체적으로 확인해 보도록 하자. 자세한 설명은 반드시 매뉴얼을 참고하기 바란다.

우선 ‘SecFilterEngine On’은 mod_security의 필터링 기능을 사용할 것인지 여부를 정의하는 것이다. modsecurity 기능을 사용할 것이므로 당연히 On을 지정하면 된다.

‘SecFilterScanPOST On’은 POST 메쏘드로 전달되는 페이로드를 체크(스캔)할 것인지 여부를 지정한다. HTTP는 여러 메쏘드를 제공하는데, GET은 일반적인 브라우징과 같이 주로 서버의 데이터를 읽을 때 사용되고, POST는 파일을 업로드하거나 게시판에 글을 쓰는 등 데이터를 서버에 보낼때 사용된다. 서버에 전달되는 데이터에 대해서도 체크해야 하므로 On을 설정한다.

참고로 GET 메소드는 “변수=값&변수=값&...”의 형식으로 Request Header의 HTTP resource ID를 지정하는 곳에 CGI 프로그램 이름과 함께 연이어 데이터를 전달하는 방식이며, POST 메쏘드는 Resouce ID 필드에 CGI 프로그램 이름만 주고 데이터는 message body 부분에 전달하는 방식이다.

SecFilterDefaultAction은 다음과 같이 지정할 필터에 매칭되는 요청이 있을 경우 어떻게 대응할 것인지에 대한 기본 설정이다. ‘SecFilterDefaultAction “deny,log,status:404”’과 같은 설정의 경우는 요청을 차단(deny) 후 404 에러를 넘겨주고(status:404) 로그(log)를 남기게 된다.
SecFilterDefualtAction에서 제공되는 설정(action)에는 다음과 같은 것이 있다.

pass : 필터링하지 않고 통과하도록 한다.
       예)SecFilter KEYWORD “pass,log”
deny : 필터링에 매칭될 경우 요청을 거부한다. 특별한 상태(status)를 지정하지 않으면 기본적으로 500 error를 낸다.
status : 요청이 거부됐을 경우 제공되는 HTTP 상태 코드를 지정한다.
        예)SecFilter KEYWORD “status:404”
redirect : 필터링에 매칭될 경우 특정 URL로 리다이렉트할 수 있다.
         예)SecFilter KEYWORD “redirect:http://www.abc.co.kr”
exec :  필터링에 매칭될 경우 지정한 명령어 또는 cgi를 실행하도록 한다.
         예)SecFilter KEYWORD “exec:/home/report/report-attack.pl”
log : 필터링에 매칭될 경우 apache의 에러 로그에 남기도록 한다.
nolog :  에러 로그를 남기지 않도록 한다.

SecFilterDebugLog logs/modsec_debug_log
SecFilterDebugLevel 0

이와 같은 설정은 요청이 들어올 때마다 로그를 남길 것인지 설정하는 것이다. 정상적인 로그는 남길  필요가 없으므로 여기에서는 남기지 않도록 0으로 설정한다.

SecFilter KEYWORD

mod_security 의 핵심기능으로서 서버로 들어오는 요청에 대해 특정한 문자열을 포함할 경우 필터링하도록 하는 것이다. GET일 경우 요청의 첫줄만 체크하며, SecFilterScanPOST on인 경우 POST는 메시지 부분까지 체크한다.

만약 ‘SecFilter /bin/sh’와 같이 지정하면 셸 명령어를 실행하려는 시도를 필터링하는데, 이와 같이 경로를 지정할 경우 /bin/.sh와 같이 IDS 등의 필터를 속이기 위한 시도까지 탐지해 필터링할 수 있다.

SecFilterSelective THE_REQUEST "/tmp"

SecFilter가 단순한 매칭을 제공한다면 SecFilterSelective는 더욱 다양한 매칭을 제공하는데, 이와 같은 경우 URL request에 /tmp라는 문자열이 보이면 필터링한다. 물론 이외에 REMOTE_USER나 REMOTE_ADDR 등 많은 변수를 이용할 수 있다.

SecAuditEngine On
SecAuditLog logs/audit_log

기본적으로 제공하는 아파치 로그는 그다지 많은 정보를 제공하지 않는다. 따라서 이같이 설정할 경우 필터링에 매칭되는 요청에 대해서 logs/audit_log 파일에 상세한 정보를 제공하도록 한다. 다음과 같이 미리 설정된 필터에 따라 웹을 통해 ‘/etc/passwd’에 대한 요청이 필터링돼 audit_log에 남은 것을 보여주고 있다.

Request: 202.69.81.170 - - [Fri Aug 29 15:37:00 2005] "GET /................../etc/passwd HTTP/1.0" 500 600
Handler: (null)
Error: mod_security: Access denied with code 500. Pattern match "/etc/passwd" at THE_REQUEST.
----------------------------------------
GET /................../etc/passwd HTTP/1.0
Connection: Keep-Alive
Content-Length: 0
Host: cofw
User-Agent: Mozilla/4.75 (Nikto/1.30 )
mod_security-message: Access denied with code 500. Pattern match "/etc/passwd" at THE_REQUEST.
mod_security-action: 500

이외 보안문제를 해결하기 위한 몇 가지 권장 설정이 있는데, 각각 다음과 같다.

SecFilter "../"

만약 요청중 ‘../’ 이 포함돼 있다면 이는 상위 디렉토리에 접근하기 위한 시도임을 알 수 있는데, 정상적인 웹 접속과 같은 상황에서는 불필요하며, 주로 시스템 명령어를 실행하기 위한 목적으로 사용되므로 필터링하는 것이 좋다.

SecFilter "<[[:space:]]*script"
SecFilter "<(.|n)+>" 

XSS(Cross site scripting) 공격에 대비하기 위한 설정으로 XSS 공격은 공격자가 HTML이나 자바 스크립트 등을 웹 페이지에 몰래 삽입해 다른 사용자가 실행해 쿠키 등의 정보를 획득하는 것을 말한다.

SecFilter "delete[[:space:]]+from"
SecFilter "insert[[:space:]]+into"
SecFilter "select.+from"

SQL Injection 등 SQL과 관련된 공격을 차단할 때 사용한다. 그러나 잘못 사용했을 경우에는 정상적인 SQL 질의도 필터링되므로 적용 시 주의해야 한다.