ModSicherheit: Protokollierung und Debugging

„ Dank ModSecurity können Sie nachts besser schlafen, denn es löst vor allem das Sichtbarkeitsproblem: Sie können Ihren Webverkehr sehen. “

Wenn etwas nicht wie erwartet funktioniert, sollten Sie immer zuerst in den Protokollen nachsehen. Gute Protokolle können wertvolle Erkenntnisse liefern, die Ihnen bei der Behebung Ihrer Probleme helfen. Einer der Gründe, warum Ivan Ristić ursprünglich ModSecurity gegründet hat, war, dass er über die mangelnde Transparenz der von ihm verwendeten Tools frustriert war. Es ist daher keine Überraschung, dass ModSecurity über umfassende Protokollierungs- und Debuggingfunktionen verfügt.

ModSecurity verfügt über zwei Arten von Protokollen:

• Ein Prüfprotokoll. Für jede blockierte Transaktion stellt ModSecurity detaillierte Protokolle über die Transaktion und den Grund der Blockierung bereit.
• Ein Debug-Protokoll. Wenn aktiviert, speichert dieses Protokoll umfassende Informationen über alle Aktivitäten von ModSecurity.

Das Prüfprotokoll ist nicht nur nützlich, um herauszufinden, warum ein einzelner Angriff blockiert wurde, sondern auch, um mehr über die allgemeinen Angriffsmuster herauszufinden. Sie werden überrascht sein, wie viel Bot- und Scanner-Verkehr Sie erhalten, nur weil Sie die Ports 80 und/oder 443 dem Internet zugänglich machen.

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

Prüfprotokoll

Das Hauptprotokoll in ModSecurity ist das Prüfprotokoll, das alle auftretenden Angriffe, einschließlich potenzieller Angriffe, protokolliert. Wenn Sie unsere Installationsanweisungen für ModSecurity (mit NGINX Open Source ) oder das 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 von404 . (Nur für ein Ubuntu 16.04-System befindet sich das Prüfprotokoll in /var/log/modsec_audit.log .)

Das ModSecurity-Auditprotokoll ist in Abschnitte unterteilt. Dies erleichtert das Durchsuchen des Protokolls und das Auffinden der gesuchten Informationen. In der folgenden Tabelle ist der Inhalt der einzelnen Abschnitte aufgeführt:

Bei jeder Transaktion, die einen Prüfprotokolleintrag auslöst, werden einige oder alle der oben genannten Abschnitte protokolliert. Sie können konfigurieren, welche Abschnitte protokolliert werden.

Beispiel für ein Überwachungsprotokoll

Ein Beispiel für einen ModSecurity-Audit-Protokolleintrag könnte folgendermaßen aussehen:

---ICmPEb5c---A--[04. Okt. 2017:21:45:15 +0000] 150715351558.929952 141.212.122.16 64384 141.212.122.16 80
---ICmPEb5c---B--
GET / HTTP/1.1
Host: 54.183.57.254
Benutzer-Agent: Mozilla/5.0 zgrab/0.x
Accept-Encoding: gzip

---ICmPEb5c---D--

---ICmPEb5c---F--
HTTP/1.1 200
Server: nginx/1.13.4
Datum: Mi, 04. Okt. 2017 21:45:15 GMT
Inhaltstyp: Text/HTML
Verbindung: Keep-Alive

---ICmPEb5c---H--
ModSecurity: Warnung. Übereinstimmender „Operator `Rx' mit Parameter `^[d.:]+$' mit Variable `REQUEST_HEADERS:Host' (Wert: `54.183.57.254' ) [Datei "/root/owasp
-v3/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [Zeile "733"] [ID "920350"] [Rev "2"] [Nachricht "Host-Header ist eine numerische IP-Adresse"] [Daten "54.183.57.254"] [S
everity "4"] [Ver "OWASP_CRS/3.0.0"] [Reife "9"] [Genauigkeit "9"] [Tag "Anwendung-Multi"] [Tag "Sprache-Multi"] [Tag "Plattform-Multi"] [Tag "Angriffsprot
ocol"] [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--

Obwohl es aus der obigen Tabelle nicht sofort ersichtlich ist, finden Sie Informationen dazu, warum eine bestimmte Anfrage blockiert wurde, am besten in Abschnitt H und nicht in Abschnitt K. Wenn wir im obigen Beispiel des Prüfprotokolls Abschnitt H durchsuchen, können wir die Meldung „Host-Header ist eine numerische IP-Adresse“ sehen, die darauf hinweist, dass jemand versucht hat, per IP-Adresse und nicht per Hostname auf unsere Site zuzugreifen. Dies kann auf einen Scanner hinweisen.

Konfiguration der Überwachungsprotokollierung

Wenn Sie unsere Anweisungen zur Installation und Konfiguration von ModSecurity befolgt haben, finden Sie die Konfiguration der Audit-Protokollierung in /etc/nginx/modsec/modsecurity.conf . In dieser Datei sehen Sie die folgenden drei Anweisungen, die steuern, was in das Prüfprotokoll eingetragen wird:

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

Wo

• SecAuditEngine – Steuert, was protokolliert werden soll. Optionen sind:

  • Aus – Deaktivieren Sie das Prüfprotokoll.
  • Ein – Alle Transaktionen protokollieren, was beim Debuggen nützlich sein kann.
  • RelevantOnly – Protokollieren Sie nur Transaktionen, die eine Warnung/einen Fehler ausgelöst haben oder einen Statuscode haben, der mit dem in der SecAuditLogRelevantStatus -Direktive übereinstimmt.

• SecAuditLogRelevantStatus – Wenn SecAuditEngine auf RelevantOnly gesetzt ist, steuert diese Anweisung, welche HTTP-Antwortstatuscodes protokolliert werden sollen. Es basiert auf regulären Ausdrücken. Der obige Wert protokolliert alle 5xx- und 4xx -Antworten, außer404 S.

• SecAuditLogParts – Steuert, welche Abschnitte in das Zugriffsprotokoll aufgenommen werden sollen. Durch das Entfernen der Abschnitte, die Sie nicht interessieren, wird die Größe des Prüfprotokolls reduziert und das Scannen erleichtert.

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

Debug-Protokoll

Wenn das Debug-Protokoll aktiviert ist, bietet es eine Fülle von Informationen zu allen Aktivitäten von ModSecurity. Zur Behebung von Problemen, die damit zusammenhängen, dass etwas nicht wie erwartet funktioniert, ist das Debug-Protokoll Ihre Anlaufstelle. Es ist auch großartig, wenn Sie mit ModSecurity beginnen und beobachten möchten, warum es die Dinge auf eine bestimmte Weise macht.

Beispiel für ein Debugprotokoll

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

[4] (Regel: 1234) Ausführen des Operators "Contains" mit dem Parameter "test" gegen ARGS:testparam.[9] Zielwert: "test" (Variable: ARGS:testparam)
[9] Übereinstimmende Variablen aktualisiert.
[4] Ausführen einer [unabhängigen] (unterbrechungsfreien) Aktion: log
[9] Transaktion wird in Protokollen gespeichert
[4] Regel hat 1 zurückgegeben.
[9] (SecDefaultAction) Ausführen einer Aktion: log
[9] Transaktion wird in Protokollen gespeichert
[9] (SecDefaultAction) Ausführen einer Aktion: auditlog
[4] (SecDefaultAction) Ignorieren einer Aktion: pass (Regel enthält eine unterbrechende Aktion)
[4] Ausführen einer (unterbrechenden) Aktion: auditlog
[4] Ausführen einer (unterbrechenden) Aktion: deny

Das Debugprotokoll listet die Regel-ID-Nummer zur einfachen Suche auf. In diesem Beispiel stammt die Ausgabe von unserer Testregel mit der ID-Nummer 1234.

Debug-Protokollkonfiguration

Standardmäßig ist das Debugprotokoll deaktiviert, da es die Leistung beeinträchtigen kann. Genau wie die Audit-Protokollierung wird das Debug-Protokoll in /etc/nginx/modsec/modsecurity.conf konfiguriert. In dieser Datei gibt es zwei auskommentierte Konfigurationsdirektiven. Um die Debugprotokollierung zu aktivieren, heben Sie die Kommentierung auf und ändern Sie sie wie folgt:

SecDebugLog /var/log/modsec_debug.logSecDebugLogLevel 9

Wo

• SecDebugLog – Gibt den Pfad zur Debug-Protokolldatei an.
• SecDebugLogLevel –0 –9 gibt an, wie viele Informationen protokolliert werden sollen, mit9 das Meiste sein. Wenn Sie eine Fehlerbehebung durchführen, setzen Sie diesen Wert auf9 ist am hilfreichsten.

Abschluss

In diesem Blogbeitrag haben wir beschrieben, wie Sie die umfangreichen Protokollierungsfunktionen von ModSecurity nutzen können. ModSecurity verfügt sowohl über Prüfprotokolle, die Informationen zu allen blockierten Transaktionen enthalten, als auch über ein Debugprotokoll, das Ihnen weiterhilft, wenn Sie Probleme bei der Verwendung von ModSecurity haben.

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

[ Anmerkung des Herausgebers – Der Verkauf von NGINX ModSecurity WAF endete am 1. April 2022 offiziell, und der Lebenszyklus endet mit Wirkung zum 31. März 2024 . Weitere Einzelheiten finden Sie unter „F5 NGINX ModSecurity WAF wird eingestellt“<.htmla> in unserem Blog.]