ModSecurity: 로깅 및 디버깅

Faisal Memon소프트웨어 엔지니어

“ModSecurity는 무엇보다도 가시성 문제를 해결해 웹 트래픽을 직접 확인할 수 있게 해주므로, 밤에도 안심하고 숙면을 취할 수 있도록 도와줍니다.”

– Ivan Ristić, ModSecurity 개발자

무언가가 예상대로 작동하지 않을 때는 항상 로그를 가장 먼저 살펴봐야 합니다. 잘 작성된 로그는 현재 겪고 있는 문제를 해결하는 데 도움이 되는 유용한 정보를 제공할 수 있습니다. Ivan Ristić가 처음 ModSecurity를 만든 이유 중 하나는 자신이 사용하던 도구로는 내부 상황을 제대로 파악하기 어려워 답답했기 때문입니다. 따라서 ModSecurity가 광범위한 로깅 및 디버깅 기능을 갖추고 있는 것은 놀라운 일이 아닙니다.

ModSecurity에는 두 가지 유형의 로그가 있습니다:

• 감사 로그. ModSecurity는 차단된 모든 트랜잭션에 대해 해당 트랜잭션의 세부 정보와 차단된 이유를 로그로 제공합니다.
• 디버그 로그. 이 로그를 활성화하면 ModSecurity가 수행하는 모든 작업에 대한 상세한 정보가 기록됩니다.

감사 로그는 개별 공격이 차단된 이유뿐만 아니라 전반적인 공격 패턴을 파악하는 데에도 유용합니다. 포트 80 및/또는 443을 인터넷에 노출하기만 해도 얼마나 많은 봇 및 스캐너 트래픽이 유입되는지 알면 놀랄 수도 있습니다.

이 블로그 게시물에서는 ModSecurity의 로깅 및 디버깅 기본 사항을 설명합니다.

감사 로그

ModSecurity의 기본 로그는 감사 로그로, 발생한 모든 공격과 잠재적 공격을 기록합니다. ModSecurity 설치 지침(NGINX Open Source) 또는 NGINX ModSecurity WAF 설치 지침(NGINX Plus)을 따랐다면, 기본적으로 ModSecurity는 경고나 오류를 발생시킨 모든 트랜잭션뿐만 아니라 5xx 및 4xx 응답이 발생한 모든 트랜잭션을 기록합니다. 단, 404는 제외됩니다. (Ubuntu 16.04 시스템에 한해 감사 로그는 /var/log/modsec_audit.log에 있습니다.)

ModSecurity 감사 로그는 여러 섹션으로 구분되어 있습니다. 따라서 로그를 살펴보고 원하는 정보를 더 쉽게 찾을 수 있습니다. 아래 표에는 각 섹션에 포함된 내용이 요약되어 있습니다.

감사 로그 항목을 생성하는 각 트랜잭션에는 위 섹션 중 일부 또는 전체가 기록됩니다. 기록할 섹션을 구성할 수 있습니다.

감사 로그 예시

ModSecurity 감사 로그 항목의 예시는 다음과 같습니다:

---ICmPEb5c---A--[04/Oct/2017:21:45:15 +0000] 150715351558.929952 141.212.122.16 64384 141.212.122.16 80---ICmPEb5c---B--GET / HTTP/1.1Host: 54.183.57.254User-Agent: Mozilla/5.0 zgrab/0.xAccept-Encoding: gzip---ICmPEb5c---D-----ICmPEb5c---F--HTTP/1.1 200Server: nginx/1.13.4Date: Wed, 04 Oct 2017 21:45:15 GMTContent-Type: text/htmlConnection: keep-alive---ICmPEb5c---H--ModSecurity: Warning. Matched "Operator `Rx' with parameter `^[d.:]+$' against variable `REQUEST_HEADERS:Host' (Value: `54.183.57.254' ) [file "/root/owasp-v3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "733"] [id "920350"] [rev "2"] [msg "Host header is a numeric IP address"] [data "54.183.57.254"] [severity "4"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/IP_HOST"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [ref "o0,13v21,13"]---ICmPEb5c---I-----ICmPEb5c---J-----ICmPEb5c---Z--

위 표만 봐서는 바로 알기 어렵지만, 특정 요청이 차단된 이유를 확인하기에 가장 적합한 곳은 K 섹션이 아니라 H 섹션입니다. 위의 감사 로그 예시에서 H 섹션을 살펴보면 "Host 헤더가 숫자 형식의 IP 주소입니다"라는 메시지를 확인할 수 있습니다. 이는 누군가 호스트 이름이 아닌 IP 주소로 사이트에 접속하려 했음을 의미하며, 스캐너의 접근일 가능성이 있습니다.

감사 로깅 구성

ModSecurity 설치 및 구성 지침을 따랐다면 감사 로깅 구성은 /etc/nginx/modsec/modsecurity.conf에서 확인할 수 있습니다. 이 파일에는 감사 로그에 기록할 내용을 제어하는 다음 세 가지 지시문이 있습니다:

SecAuditEngine RelevantOnlySecAuditLogRelevantStatus "^(?:5|4(?!04))"SecAuditLogParts ABIJDEFHZ

여기서

• SecAuditEngine – 기록할 항목을 제어합니다. 옵션은 다음과 같습니다:
  • Off – 감사 로그를 비활성화합니다.
  • 켜기 – 모든 트랜잭션을 기록합니다. 디버깅할 때 유용할 수 있습니다.
  • RelevantOnly – 경고/오류를 발생시켰거나 상태 코드가 SecAuditLogRelevantStatus 지시문에 지정된 값과 일치하는 트랜잭션만 기록합니다.
• SecAuditLogRelevantStatus – SecAuditEngine가 RelevantOnly로 설정된 경우, 이 지시문은 로깅할 HTTP 응답 상태 코드를 제어합니다. 정규 표현식을 기반으로 합니다. 위 값은 모든 5xx 및 4xx 응답을 로깅하되 404 응답은 제외합니다.
• SecAuditLogParts – 액세스 로그에 포함할 섹션을 제어합니다. 관심 없는 섹션을 제거하면 감사 로그의 크기가 줄어들고 더 쉽게 살펴볼 수 있습니다.

추가 감사 로깅 구성 지시문은 ModSecurity 위키를 참조하세요.

디버그 로그

디버그 로그를 활성화하면 ModSecurity가 수행하는 모든 작업에 관한 풍부한 정보를 확인할 수 있습니다. 무언가가 예상대로 작동하지 않는 이유를 파악하고 문제를 해결할 때 디버그 로그는 가장 먼저 참고해야 할 리소스입니다. ModSecurity를 처음 사용하면서 특정 방식으로 작동하는 이유를 살펴보고 싶을 때도 매우 유용합니다.

디버그 로그 예시

디버그 로그는 다음과 같은 형태입니다. 여기에는 모든 트랜잭션에 대해 ModSecurity가 수행하는 작업의 세부 정보가 다수 포함되어 있습니다:

[4] (Rule: 1234) Executing operator "Contains" with param "test" against ARGS:testparam.[9] Target value: "test" (Variable: ARGS:testparam)[9] Matched vars updated.[4] Running [independent] (non-disruptive) action: log[9] Saving transaction to logs[4] Rule returned 1.[9] (SecDefaultAction) Running action: log[9] Saving transaction to logs[9] (SecDefaultAction) Running action: auditlog[4] (SecDefaultAction) ignoring action: pass (rule contains a disruptive action)[4] Running (non-disruptive) action: auditlog[4] Running (disruptive)     action: deny

디버그 로그에는 쉽게 검색할 수 있도록 규칙 ID 번호가 표시됩니다. 이 예시의 출력은 ID 번호가 1234인 테스트 규칙에서 생성되었습니다.

디버그 로그 구성

기본적으로 디버그 로그는 성능에 부정적인 영향을 줄 수 있으므로 비활성화되어 있습니다. 감사 로깅과 마찬가지로 디버그 로그는 /etc/nginx/modsec/modsecurity.conf에서 구성합니다. 이 파일에는 주석 처리된 구성 지시문이 두 개 있습니다. 디버그 로깅을 활성화하려면 해당 지시문의 주석을 해제하고 다음과 같이 변경합니다:

SecDebugLog /var/log/modsec_debug.logSecDebugLogLevel 9

여기서

• SecDebugLog – 디버그 로그 파일의 경로를 지정합니다.
• SecDebugLogLevel – 0–9는 기록할 정보의 양을 나타내며, 9가 가장 많은 정보를 기록합니다. 문제를 해결하는 중이라면 이 값을 9로 설정하는 것이 가장 유용합니다.

결론

이 블로그 게시물에서는 ModSecurity의 광범위한 로깅 기능을 사용하는 방법을 살펴보았습니다. ModSecurity는 차단된 모든 트랜잭션에 대한 정보가 담긴 감사 로그와, ModSecurity 사용 중 문제가 발생했을 때 추가로 도움을 받을 수 있는 디버그 로그를 모두 제공합니다.

ModSecurity 3.0은 NGINX Open Source용 및 NGINX Plus용 NGINX ModSecurity WAF로 제공됩니다. NGINX ModSecurity WAF는 NGINX, Inc.에서 유지 관리하고 완벽하게 지원하는 사전 컴파일된 동적 모듈입니다. 30일 동안 무료로 사용해 보세요.

[편집자 – NGINX ModSecurity WAF는 2022년 4월 1일부로 공식 판매 종료되었으며, 2024년 3월 31일부로 지원 종료될 예정입니다. 자세한 내용은 블로그의 F5 NGINX ModSecurity WAF 지원 종료 전환 안내<.htmla>를 참조하세요.]

작성자 소개

Faisal Memon소프트웨어 엔지니어

Faisal Memon의 다른 블로그 게시물