[Modsecurity] Modsecurity란?

 

Modsecurity에 대해 공부하기 전에 먼저 웹 방화벽에 대해서 알아야 한다.

 

웹 방화벽

 

웹 방화벽(Web Application Firewall, WAF)이란, 일반적인 네트워크 방화벽(Firewall)과는 달리 웹 애플리케이션 보안에 특화되어 개발된 솔루션이다. 

 

웹 방화벽의 기본 역할은 SQL Injection, Cross-Site Scripting(XSS) 등과 같은 웹 공격을 탐지하고 차단하는 역할을 한다. 웹 방화벽은 직접적인 웹 공격 대응과 정보 유출 방지 솔루션, 부정 로그인 방지 솔루션, 웹 사이트 위변조 방지 솔루션 등으로 활용이 가능하다.

 

웹 방화벽의 주요 기능은 웹 방화벽은 HTTP의 Request/Response 메시지 내용을 분석, Positive 정책과 Negative 정책을 혼용하여 탐지 기능을 수행하게 된다. 

 

Modsecurity

 

Modsecurity는 Apache 웹 서버를 위한 오픈 소스 웹 방화벽이다. Ivan Ristic이 개발한 Apache 웹 서버용 공개 웹 방화벽으로 PHP Injection 공격등 Apache 웹 서버의 주요 공격을 차단하는 기능을 가진다. 설치 및 차단 Rule 설정 인터페이스가 불편하다는 점은 있지만 공격 차단 기능은 상당히 우수하다.

 

Apache는 중소기업이나 웹 호스팅 업체에서 많이 사용하고 있는 공개 웹 서버로써, 중소기업에 고가의 상용 웹 방화벽 설치가 어려운 경우가 많다. 이 경우 Modsecurity는 가양한 웹 공격을 효과적으로 막는데 많은 도움을 줄 수 있을 것이다. 하지만, 다수의 웹 서버를 운영하는 대규모 기업이나 복잡한 웹 환경을 가진 기업의 경우 인터페이스 및 기술 지원 측변에서 보다 우수한 사용 웹 방화벽 고입을 권고한다.

 

이 툴은 웹 공격에 대한 침입 탐지 및 침입 방지 기능을 추가해 주는 아파치 웹 서버의 하나의 모듈로 작동한다. 웹 클라이언트와 아파치 웹 서버 사이에 Modsecurity가 존재하여 클라이언트로부터 악의적인 접속요청이 발견되면 공격차단, 로깅 등 사전에 정의된 행위를 수행한다.

 

Modsecurity의 주요 특징

 

- 요청(request) 필터링 : 클라이언트로부터 웹 요청이 들어올 때 웹 서버 또는 다른 모듈들이 처리하기 전에 Modsecurity가 요청 내용을 분석하여 사전에 필터링한다.

 

- 우회 방지 기술

   - 경로와 파라미터를 분석하기 전에 정규화시켜 우회 공격을 차단한다.

   - 즉, "//", "\/", ".", "%00" 등 우회 공격용 스트링을 제거하고, 인코딩된 URL을 디코딩한다.

 

- HTTP 프로토콜 이해 : 엔진이 HTTP 프로토콜을 이해하기 때문에 아주 전문적이고 미세한 필터링을 수행할 수 있다.

 

- POST 페이로드(payload) : GET 방식 뿐만 아니라 POST 메소드를 사용해서 전송되는 컨텐츠도 가로채어 분석할 수 있다.

 

- 감사 로깅

   - POST를 포함하여 모든 요청의 모든 상세한 부분들까지 추후 분석을 위해서 로깅될 수 있다.

   - Modsecurity에서 차단 기능을 비활성화시킨 후, 강력한 로깅 기능만으로 침입탐지 시스템 역할을 수행할 수 있도록     한다.

 

- HTTPS 필터링 : 엔진은 웹 서버에 임베디드되어 있기 때문에 복호화 한 후에 요청 데이터에 접근하여 HTTPS를 통한 공격도 필터링할 수 있다.

 

 

기본 환경설정 및 로깅 관련 지시자

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

- 로그 파일에 기록할 항목을 정의한다.

Parts	세부 내용
A	audit log header (필수)
B	request header
C	request body (request body가 존재하고 modsecurity가 request body를 검사하 도록 설정되어 있는 경우에만)
D	보류중, response header의 중개 (현재 지원 안 됨)
E	response body 중간 단계(현재 modsecurity가 response body를 검사하며 감사 로깅 엔진이 이를 저장하게끔 설정되어 있는 경우에만)
F	최종 response header(마지막 컨텐츠 전달 과정에서 아파치에 의해 매번 추가 되는 날짜와 서버 헤더를 제외한)
G	실제 response body(현재 지원 안됨)
H	감사 로그 트레일러
I	이 옵션은 C를 대체하는 옵션이다. multipart/form-data 인코딩이 사용되었을 때를 제외한 모든 경우엔 C와 같은 데이터를 기록한다.
J	보류중, 이 옵션은 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”이다. 기본적으로 대문자는 모두 소문자로 바뀌어 필터링 된다.

 

SecRequestBodyAccess On | Off

- Request 값에서 Body 부분에 대한 처리를 어떻게 할 것인지 구성한다.

o On : RequestBody 접근을 시도한다.

o Off : RequestBody 접근시도를 하지 않는다.

- 이 지시자는 Request 값에서의 POST_PAYLOAD를 검사할 때 필요하다. POST값을 필터링하기 위 해서는 phase:2와 REQUESET_BODY 변수/로케이션, 3가지가 모두 구성되어야만 처리가 가능하다.

 

SecRequestBodyLimit

- ModSecurity가 Request Body 크기로 할당할 수 있는 메모리 최대 크기를 설정한다.

o SecRequestBodyLimit 134217728

- 131072KB (134217728 byte)가 기본값이다.

 

SecReponseBodyAccess On | Off

- Response 값에서 Body 부분에 대한 처리를 어떻게 할 것인지 구성한다.

o On : ResponseBody 접근을 시도한다. (그러나 MIME 타입과 일치해야만 한다.)

o Off : ResponseBody 접근시도를 하지 않는다.

- 이 지시자는 html 응답을 조사하기 위해 필요하다. "phase:4"의 처리 단계와 RESPONSE_BODY 변 수/로케이션, 3가지가 설정되어 있지 않으면, response body를 검사할 수 없다.

 

SecResponseBodyLimit 524228

- ModSecurity가 Response Body 크기로 할당할 수 있는 메모리 최대 크기를 설정한다.

o SecRequestBodyLimit 524228

- 이 값을 넘어가면 서버는 500 내부 서버 오류 메시지만 표시할 것이다.

 

SecReponseBodyMimeType mime/type

- Response 값에서 Body 값을 버퍼링할 MIME 타입을 설정한다.

o SecResponseBodyMimeType text/plain text/html // 기본값

- Mime 타입은 복수로 추가할 수 있다.

 

SecReponseBodyMimeTypesClear

- ResponseBody의 버퍼링을 위해 Mime 타입의 목록을 지우며, 처음에 위치시킨다.

o SecResponseBodyMimeType

 

SecDefaultAction 지시자의 추가적인 Action

 

구분	설명
Disruptive actions	Modsecurity가 데이터를 중간에서 가로챌 때 일어나는 행위이다. 하나의 체 인에 첫 번째 룰에만 나타낼 수 있다. allow, deny, drop 등이 있다.
Non-Disruptive actions	어디에나 나타낼 수 있다. capture, ctl, exec, initcol 등이 있다.
Flow actions	하나의 체인에 첫 번째 룰에만 나타낼 수 있다. chain 이 있다.
Meta-data actions	하나의 체인에 첫 번째 룰에만 나타낼 수 있다. id, rev, severity, msg가 있다.
Data actions	전면적으로 수동적이고 다른 행위에서 사용된 데이터를 운반하는 역할뿐이다.

 

 

---

[자료: 한국정보보호진흥원(KISA)] _ ModSecurity를 활용한 아파치 웹서버 보안 강화 가이드