ModSecurity: Protokollierung und Fehlerbehebung

NGINX | 22. Oktober 2017

„Mit ModSecurity können Sie nachts ruhiger schlafen, denn vor allem löst es das Problem der mangelnden Transparenz: Sie können damit Ihren Web-Traffic einsehen.“

– Ivan Ristić, Entwickler von ModSecurity

Wenn etwas nicht wie erwartet funktioniert, sollten Sie immer zuerst einen Blick in die Protokolle werfen. Aussagekräftige Protokolle können wertvolle Erkenntnisse liefern und Ihnen bei der Behebung der aufgetretenen Probleme helfen. Einer der Gründe, warum Ivan Ristić ModSecurity ursprünglich entwickelte, war seine Frustration über die mangelnde Transparenz der von ihm verwendeten Tools. Daher überrascht es nicht, dass ModSecurity über umfangreiche Protokollierungs- und Debugging-Funktionen verfügt.

ModSecurity verfügt über zwei Arten von Protokollen:

Ein Audit-Protokoll. Für jede blockierte Transaktion stellt ModSecurity detaillierte Protokolle zur Transaktion und zum Grund für die Blockierung bereit.
Ein Debug-Protokoll. Wenn es aktiviert ist, zeichnet dieses Protokoll ausführliche Informationen zu allen Aktionen von ModSecurity auf.

Das Audit-Protokoll ist nicht nur hilfreich, um herauszufinden, warum ein bestimmter Angriff blockiert wurde, sondern auch, um mehr über allgemeine Angriffsmuster zu erfahren. Sie werden vielleicht überrascht sein, wie viel Bot- und Scanner-Datenverkehr allein dadurch entsteht, dass Sie die Ports 80 und/oder 443 für das Internet freigeben.

In diesem Blogbeitrag beschreiben wir die Grundlagen der Protokollierung und Fehlerbehebung mit ModSecurity.

Audit-Protokoll

Das Hauptprotokoll in ModSecurity ist das Audit-Protokoll, in dem alle auftretenden Angriffe einschließlich potenzieller Angriffe protokolliert werden. Wenn Sie unsere Installationsanleitung für ModSecurity (mit NGINX Open Source) oder die NGINX ModSecurity WAF (mit NGINX Plus) befolgt haben, protokolliert ModSecurity standardmäßig alle Transaktionen, die eine Warnung oder einen Fehler ausgelöst haben, sowie alle Transaktionen, die zu 5xx- und 4xx-Antworten geführt haben, mit Ausnahme von 404. (Nur auf einem Ubuntu-16.04-System befindet sich das Audit-Protokoll unter /var/log/modsec_audit.log.)

Das ModSecurity-Audit-Protokoll ist in Abschnitte unterteilt. Dadurch lässt sich das Protokoll leichter durchsuchen und die gesuchte Information schneller finden. Die folgende Tabelle zeigt, welche Inhalte die einzelnen Abschnitte enthalten:

Abschnitt	Beschreibung
A	Audit-Protokollkopf (obligatorisch)
B	Anfrage-Header
C	Anfrage-Body
D	Reserviert
E	Antwort-Body
F	Antwort-Header
G	Reserviert
H	Audit-Protokollabschluss mit zusätzlichen Daten
I	Kompakte Alternative zum Anfrage-Body (Abschnitt C), die keine Dateien enthält
J	Informationen zu hochgeladenen Dateien
K	Enthält eine Liste aller Regeln, die auf die Transaktion zutrafen
Z	Abschließende Begrenzung (obligatorisch)

Für jede Transaktion, die einen Eintrag im Auditprotokoll auslöst, werden einige oder alle der oben genannten Abschnitte protokolliert. Sie können konfigurieren, welche Abschnitte protokolliert werden.

Beispiel für ein Auditprotokoll

Ein beispielhafter ModSecurity-Audit-Log-Eintrag könnte wie folgt aussehen:

---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--

Auch wenn es aus der obigen Tabelle nicht sofort ersichtlich ist, finden sich die aussagekräftigsten Informationen darüber, warum eine bestimmte Anfrage blockiert wurde, in Abschnitt H und nicht in Abschnitt K. Wenn wir im obigen Beispiel des Audit-Protokolls Abschnitt H durchsehen, finden wir die Meldung "Der Host-Header ist eine numerische IP-Adresse". Dies weist darauf hin, dass jemand versucht hat, über die IP-Adresse statt über den Hostnamen auf unsere Website zuzugreifen. Das könnte auf einen Scanner hindeuten.

Konfiguration der Audit-Protokollierung

Wenn Sie unsere Anleitung zur Installation und Konfiguration von ModSecurity befolgt haben, finden Sie die Konfiguration der Audit-Protokollierung in /etc/nginx/modsec/modsecurity.conf. In dieser Datei finden Sie die folgenden drei Direktiven, die festlegen, was in das Audit-Protokoll geschrieben wird:

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

wobei

SecAuditEngine – Steuert, was protokolliert werden soll. Folgende Optionen stehen zur Verfügung:
- Aus – Deaktiviert das Audit-Protokoll.
- Ein – Alle Transaktionen protokollieren, was bei der Fehlersuche hilfreich sein kann.
- RelevantOnly – Nur Transaktionen protokollieren, die eine Warnung/einen Fehler ausgelöst haben oder deren Statuscode mit den Angaben in der Direktive SecAuditLogRelevantStatus übereinstimmt.
SecAuditLogRelevantStatus – Wenn SecAuditEngine auf RelevantOnly gesetzt ist, legt diese Direktive fest, welche HTTP-Antwortstatuscodes protokolliert werden sollen. Sie basiert auf regulären Ausdrücken. Der obige Wert protokolliert alle 5xx- und 4xx-Antworten mit Ausnahme von 404-Antworten.
SecAuditLogParts – Legt fest, welche Abschnitte in das Zugriffsprotokoll aufgenommen werden sollen. Wenn Sie nicht benötigte Abschnitte entfernen, wird das Überwachungsprotokoll kleiner und lässt sich leichter überblicken.

Weitere Konfigurationsanweisungen für die Audit-Protokollierung finden Sie im ModSecurity-Wiki.

Debug-Protokoll

Wenn das Debug-Protokoll aktiviert ist, liefert es eine Fülle von Informationen zu allen Vorgängen von ModSecurity. Wenn Sie herausfinden möchten, warum etwas nicht wie erwartet funktioniert, ist das Debug-Protokoll Ihre erste Anlaufstelle. Es eignet sich auch hervorragend, wenn Sie gerade erst mit ModSecurity beginnen und nachvollziehen möchten, warum es bestimmte Dinge auf eine bestimmte Weise ausführt.

Beispiel für ein Debug-Protokoll

Das Debug-Protokoll sieht wie folgt aus. Es enthält zahlreiche Details zu den Maßnahmen, die ModSecurity bei sämtlichen Transaktionen ergreift:

[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

Das Debug-Protokoll enthält die Regel-ID, damit sie leicht gefunden werden kann. In diesem Beispiel stammt die Ausgabe von unserer Testregel mit der ID 1234.

Konfiguration des Debug-Protokolls

Standardmäßig ist das Debug-Protokoll deaktiviert, da es die Leistung beeinträchtigen kann. Wie bei der Audit-Protokollierung wird auch das Debug-Protokoll in /etc/nginx/modsec/modsecurity.conf konfiguriert. In dieser Datei sind zwei Konfigurationsanweisungen auskommentiert. Um die Debug-Protokollierung zu aktivieren, entfernen Sie die Kommentarzeichen und ändern Sie die Anweisungen wie folgt:

SecDebugLog /var/log/modsec_debug.logSecDebugLogLevel 9

wobei

SecDebugLog – Gibt den Pfad zur Debug-Protokolldatei an.
SecDebugLogLevel – 0–9 gibt an, wie viele Informationen protokolliert werden, wobei 9 die höchste Stufe ist. Bei der Fehlerbehebung ist es am hilfreichsten, diesen Wert auf 9 zu setzen.

Fazit

In diesem Blogbeitrag haben wir erläutert, wie Sie die umfangreichen Protokollierungsfunktionen von ModSecurity nutzen können. ModSecurity bietet sowohl Audit-Protokolle, die Informationen zu allen blockierten Transaktionen enthalten, als auch ein Debug-Protokoll, das Ihnen bei Problemen mit ModSecurity weiterhilft.

ModSecurity 3.0 ist sowohl für NGINX Open Source als auch als NGINX ModSecurity WAF für NGINX Plus verfügbar. Die NGINX ModSecurity WAF ist ein vorkompiliertes dynamisches Modul, das von NGINX, Inc. gepflegt und umfassend unterstützt wird. Testen Sie es 30 Tage lang kostenlos.

[Redaktion – Der Verkauf von NGINX ModSecurity WAF wurde zum 1. April 2022 offiziell eingestellt. Zum 31. März 2024 erreicht das Produkt das Ende seines Lebenszyklus. Weitere Informationen finden Sie im Beitrag F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> in unserem Blog.]