ModSecurity: 로깅 및 디버깅

“ ModSecurity는 무엇보다도 가시성 문제를 해결하여 밤에 더 편안하게 잠을 잘 수 있도록 도와줍니다. 웹 트래픽을 볼 수 있게 해주기 때문입니다. ”

예상대로 작동하지 않는 경우 가장 먼저 살펴봐야 할 곳은 바로 로그입니다. 좋은 로그는 귀하가 겪고 있는 문제를 해결하는 데 도움이 되는 귀중한 통찰력을 제공할 수 있습니다. Ivan Ristić이 원래 ModSecurity를 만든 이유 중 하나는 자신이 사용하던 도구의 가시성이 부족해서 좌절했기 때문입니다. 그렇다면 ModSecurity가 광범위한 로깅 및 디버깅 기능을 갖추고 있다는 것은 놀라운 일이 아닙니다.

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

• 감사 기록. 차단된 모든 거래에 대해 ModSecurity는 거래에 대한 자세한 로그와 차단 이유를 제공합니다.
• 디버그 로그. 이 로그가 켜지면 ModSecurity가 수행하는 모든 작업에 대한 광범위한 정보가 보관됩니다.

감사 로그는 개별 공격이 차단된 이유뿐만 아니라 전반적인 공격 패턴에 대해 자세히 알아보는 데 유용합니다. 포트 80 및/또는 443을 인터넷에 노출시키는 것만으로도 얼마나 많은 봇 및 스캐너 트래픽이 발생하는지 놀라실 수도 있습니다.

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

감사 로그

ModSecurity의 주요 로그는 감사 로그로, 잠재적인 공격을 포함하여 발생하는 모든 공격을 기록합니다. NGINX 오픈 소스가 포함된 ModSecurity 또는 NGINX Plus가 포함된 NGINX ModSecurity WAF에 대한 설치 지침을 따랐다면 기본적으로 ModSecurity는 경고나 오류를 트리거한 모든 트랜잭션과 5xx 및 4xx 응답을 초래한 모든 트랜잭션을 기록합니다.404 . (Ubuntu 16.04 시스템에만 해당, 감사 로그는 /var/log/modsec_audit.log 에 있습니다.)

ModSecurity 감사 로그는 섹션으로 분할됩니다. 이렇게 하면 로그를 더 쉽게 스캔하여 원하는 정보를 찾을 수 있습니다. 아래 표는 각 섹션의 내용을 간략하게 설명합니다.

감사 로그 항목을 트리거하는 각 거래에는 위 섹션 중 일부 또는 전체가 기록됩니다. 어떤 섹션을 기록할지 구성할 수 있습니다.

감사 로그 예시

ModSecurity 감사 로그 항목의 샘플은 다음과 같습니다.

---ICmPEb5c---A--[2017년 10월 4일:21:45:15 +0000] 150715351558.929952 141.212.122.16 64384 141.212.122.16 80
---ICmPEb5c---B--
GET / HTTP/1.1
호스트: 54.183.57.254
사용자 에이전트: 모질라/5.0 zgrab/0.x
수락 인코딩: gzip

---ICmPEb5c---D--

---ICmPEb5c---F--
HTTP/1.1 200
서버: nginx/1.13.4
날짜: 수, 2017년 10월 4일 21:45:15 GMT
Content-Type: text/html
Connection: keep-alive

---ICmPEb5c---H--
ModSecurity: 경고. "매개변수 `^[d.:]+$'가 있는 연산자 `Rx'와 변수 `REQUEST_HEADERS:Host'(값: `54.183.57.254')가 일치함 [파일 "/root/owasp
-v3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [줄 "733"] [id "920350"] [rev "2"] [msg "호스트 헤더는 숫자 IP 주소입니다"] [데이터 "54.183.57.254"] [s
심각도 "4"] [버전 "OWASP_CRS/3.0.0"] [성숙도 "9"] [정확도 "9"] [태그 "application-multi"] [태그 "language-multi"] [태그 "platform-multi"] [태그 "attack-prot
ocol"] [태그 "OWASP_CRS/프로토콜_위반/IP_호스트"] [태그 "WASCTC/WASC-21"] [태그 "OWASP_TOP_10/A7"] [태그 "PCI/6.5.10"] [참조 "o0,13v21,13"]

---ICmPEb5c---I--

---ICmPEb5c---J--

---ICmPEb5c---Z--

위의 표에서 바로 알 수 없지만, 특정 요청이 차단된 이유에 대한 정보를 찾을 수 있는 가장 좋은 섹션은 섹션 K가 아니라 섹션 H입니다. 위의 감사 로그 예에서 섹션 H를 스캔하면 "호스트 헤더는 숫자 IP 주소입니다"라는 메시지를 볼 수 있는데, 이는 누군가가 호스트 이름이 아닌 IP 주소로 우리 사이트에 액세스하려고 했다는 것을 나타냅니다. 이는 스캐너를 나타내는 것일 수 있습니다.

감사 로깅 구성

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

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

어디

• SecAuditEngine – 기록해야 할 내용을 제어합니다. 옵션은 다음과 같습니다.

  • 끄기 – 감사 로그를 비활성화합니다.
  • 켜기 – 모든 거래를 기록합니다. 디버깅 시 유용할 수 있습니다.
  • RelevantOnly – 경고/오류를 발생시키거나 SecAuditLogRelevantStatus 지시문에 있는 내용과 일치하는 상태 코드를 갖는 거래만 기록합니다.

• SecAuditLogRelevantStatus – SecAuditEngine 이 RelevantOnly 로 설정된 경우 이 지시문은 어떤 HTTP 응답 상태 코드를 기록해야 하는지 제어합니다. 정규 표현식 기반입니다. 위 값은 다음을 제외한 모든 5xx 및 4xx 응답을 기록합니다.404 에스.

• SecAuditLogParts – 액세스 로그에 어떤 섹션을 포함해야 하는지 제어합니다. 관심 없는 섹션을 제거하면 감사 로그의 크기가 줄어들고 스캔하기가 더 쉬워집니다.

추가 감사 로깅 구성 지침에 대해서는 ModSecurity 위키를 참조하세요.

디버그 로그

디버그 로그를 켜면 ModSecurity가 수행하는 모든 작업에 대한 풍부한 정보가 제공됩니다. 예상한 대로 작동하지 않는 문제에 대한 문제 해결의 경우 디버그 로그가 가장 유용한 리소스입니다. ModSecurity를 처음 사용하고 특정 방식으로 작동하는 이유를 알아보고 싶은 경우에도 유용합니다.

디버그 로그 예제

디버그 로그는 다음과 같습니다. 여기에는 ModSecurity가 모든 거래에 대해 수행하는 작업에 대한 많은 세부 정보가 포함되어 있습니다.

[4] (규칙: 1234) ARGS:testparam.[9]에 대해 매개변수 "test"를 사용하여 연산자 "Contains"를 실행합니다. 대상 값: "test"(변수: ARGS:testparam)
[9] 일치하는 변수가 업데이트되었습니다.
[4] 실행 중인 [독립적] (비방해적) 작업: log
[9] 로그에 트랜잭션 저장
[4] 규칙이 1을 반환했습니다.
[9] (SecDefaultAction) 실행 중인 작업: log
[9] 로그에 트랜잭션 저장
[9] (SecDefaultAction) 실행 중인 작업: auditlog
[4] (SecDefaultAction) 작업 무시: pass(규칙에 방해적 작업이 포함됨)
[4] 실행 중인 (비방해적) 작업: auditlog
[4] 실행 중인 (방해적) 작업: deny

디버그 로그에는 규칙 ID 번호가 나열되어 있어 쉽게 검색할 수 있습니다. 이 예에서 출력은 ID 번호 1234인 테스트 규칙 에서 나온 것입니다.

디버그 로그 구성

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

SecDebugLog /var/log/modsec_debug.logSecDebugLog레벨 9

어디

• SecDebugLog – 디버그 로그 파일의 경로를 지정합니다.
• SecDebugLogLevel –0 –9 기록할 정보의 양을 나타냅니다.9 가장 많은 것. 문제를 해결하려면 이 값을 다음과 같이 설정하세요.9 가장 도움이 됩니다.

결론

이 블로그 게시물에서는 ModSecurity의 광범위한 로깅 기능을 사용하는 방법을 다루었습니다. ModSecurity에는 차단된 모든 거래에 대한 정보가 포함된 감사 로그와 ModSecurity 사용에 문제가 있는 경우 추가 지원을 제공하는 디버그 로그가 모두 있습니다.

ModSecurity 3.0은 NGINX 오픈 소스와 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>를 참조하세요.]