Die OWASP CRS sind allgemeiner gehalten als ein kommerzieller Regelsatz und decken eine viel größere Anzahl von Anwendungen mit einer breiteren Angriffsfläche ab. Das bedeutet, dass die CRS Sie eher vor allgemeinen Angriffen als vor einzelnen spezifischen bekannten Exploits schützen. So gibt es beispielsweise keine Regeln für alle bekannten SQL-Injektionsangriffe, sondern einen kleinen Satz von Regeln, die Ihre Anwendung vor jedem Angriff schützen, der wie ein SQL-Injektionsangriff aussieht. Dadurch wird der Schutz vor Zero-Day- und anderen unbekannten Angriffen erheblich verbessert.
Sobald die WAF auf dem LoadMaster aktiviert ist, können wir ihre Funktionsfähigkeit sofort überprüfen:
curl http://<<IP-Adresse der virtuellen Dienste>>/index.html?exec=/bin/bash
Die Abfragezeichenfolge enthält einen Versuch, ein imaginäres Backend auszunutzen. Dieser Exploit funktioniert natürlich nicht, aber er reicht aus, um CRS auszulösen. Die Anfrage wird jedoch nicht sofort blockiert. Keine Sorge, in diesem Blog erklären wir sowohl die Einstellungen als auch, wie man die Anfrage blockiert.
Das LoadMaster-Protokoll, das hier am meisten von Interesse ist, ist die WAF-Ereignisprotokolldatei unter System Configuration -Logging Options -System Log Files. Das von diesem Zugriffsversuch generierte Log ist hier zu sehen:
Wir sehen uns mehrere Einträge in diesem Protokoll an
ID, die uns mitteilt, dass Regel 932160 getroffen wurde
msg, um zu erfahren, was passiert ist, in diesem Fall Remote-Befehlsausführung, Unix-Shell-Code gefunden
hostname ist die Adresse des virtuellen Dienstes, gegen die der Angriff ausgelöst wurde
Wir haben also festgestellt, dass dieser Regelsatz aktiv ist und Angriffe protokolliert, auch wenn er diese Angriffe im Moment noch zulässt.
Bevor wir uns mit der Abwehr dieses Angriffs beschäftigen, wollen wir die WAF-Einstellungen des LoadMaster und ihre Bedeutung durchgehen.
Die wichtigsten Einstellungen sind in Abbildung 1 oben dargestellt und umfassen Folgendes:
Audit-Modus: Dies aktiviert separate ModSecurity Audit- und Debug-Logs (System Configuration –Logging Options –Extended Log files– WAF Audit Logs or System Configuration –Logging Options –System Log Files – WAF Debug Log File), die sehr ausführlich sind: Sie können damit den gesamten Datenverkehr, der über die WAF in LoadMaster ein- und ausgeht, protokollieren. Dies kann schnell den Speicherplatz auf der Festplatte füllen. Deshalb ist die Voreinstellung No Audit. Die Einstellung Audit All protokolliert jede Anfrage, was für eine detaillierte Fehlersuche nützlich wäre. Audit Relevant protokolliert die Anfragen, die CRS-Regelwarnungen auslösen und die Anfragen, die einen HTTP-Statuscode haben, der einen Fehler anzeigt.
Was genau in diesen Dateien protokolliert wird, wird unter Erweiterte Einstellungen – Audit-Teile gesteuert, was unten beschrieben wird.
Schwellenwert für die Anomaliebewertung: Dies ist die wichtigste Einstellung. Jede Erkennungsregel in CRS erhöht den Anomalie-Score. Die meisten Regeln fügen eine Punktzahl von 5 hinzu und wenn der Schwellenwert erreicht ist, wird die Anfrage blockiert. Der standardmäßige Schwellenwert für die Anomaliebewertung bei LoadMaster ist 100. Ein Angreifer müsste also 20 Regeln auslösen, um blockiert zu werden. Dies ist selten, aber es ist auch selten, dass ein gutartiger Benutzer einer Anwendung so viele Regeln auslöst. Für den Anfang ist diese Standardeinstellung also relativ sicher. Dennoch habe ich schon Webanwendungen gesehen, die ein Verhalten zeigten, bei dem normale Benutzer weitaus höhere Anomalie-Scoring-Werte erreichten. Deshalb setze ich persönlich diesen Wert zunächst auf 10.000, bis ich ein gutes Gefühl für den jeweiligen virtuellen Dienst habe. Dann senke ich ihn schrittweise, während ich die falsch-positiven Alarme aussortiere.
Paranoia-Level: Dies ist ein Platzhalter für Informationen. Dies wird unter Erweiterte Einstellungen konfiguriert, die weiter unten behandelt werden. Diese Information ist wichtig, da eine höhere Paranoia-Stufe mehr Fehlalarme bedeutet. Und das wiederum bedeutet eine höhere Anomaliewertung, bis Sie die Fehlalarme beseitigt haben
Regeln verwalten: CRS-Regeln sind in Gruppen organisiert, und diese Liste bietet Ihnen die Möglichkeit, sowohl Gruppen von Regeln als auch einzelne Regeln zu aktivieren und zu deaktivieren. Klicken Sie auf den Namen einer Gruppe, um die Ansicht auf einzelne Regeln in jeder Gruppe zu erweitern. Sie können dann die einzelnen Regeln aktivieren oder deaktivieren.
Fast alle Regelgruppen sind standardmäßig aktiviert. Wenn Sie jedoch unter Regeln verwalten nach unten blättern, stoßen Sie auf einen Abschnitt mit dem Titel Workloads. Dies sind Gruppen, die die Arbeit mit diesen bekannten Anwendungen erleichtern. Sie antizipieren das Verhalten der Software und verhindern, dass bestimmte Regeln angewendet werden, da sie ein falsches Positiv auslösen würden.
Nehmen Sie zum Beispiel Drupal: Drupal übergibt viele Parameter mit eckigen Klammern im Parameternamen (z. B. id [0]). Sobald eine bestimmte Anzahl eckiger Klammern in einem Parameter vorkommt, löst CRS einen Alarm aus. Wenn Sie die Drupal-Arbeitslast in diesem Menü aktivieren, verschwinden diese Fehlalarme, ohne dass Sie sie einzeln einstellen müssen.
Weitere Informationen zu den CRS-Regeln finden Sie hier
Stündlicher Schwellenwert für Alarmbenachrichtigungen: Der LoadMaster sendet Syslog-Benachrichtigungen an einen Syslog-Server eines Drittanbieters oder ein SIEM, wenn Schwachstellen entdeckt werden. Hier stellen wir den Schwellenwert ein, bevor eine Syslog-Benachrichtigung gesendet wird.
Aktivieren Sie die IP-Reputationsblockierung: Diese Einstellung ermöglicht den Zugriff auf täglich aktualisierte Reputationsdaten, die eine Sperrung auf der Grundlage von GEO-IP-Informationen ermöglichen; dabei handelt es sich um den geografischen Standort der IP-Adresse des HTTP-Clients, der die Anfrage durchführt. Dies sollte unter Web Application Firewall - Zugriffseinstellungen aktiviert werden, wo Sie die Download- und Installationszeit für die aktualisierten Reputationsdaten automatisch konfigurieren können.
Klicken Sie hier, um eine False-Positive-Analyse durchzuführen: Auf diese Weise können Sie eine False-Positive-Analyse für diesen speziellen virtuellen Dienst durchführen, um die WAF auf Ihre Anwendung abzustimmen. Dies wird in einem separaten Blog behandelt, bitte bleiben Sie dran!?
Sehen wir uns als Nächstes die erweiterten Einstellungen an, wie in Abbildung 2 unten dargestellt.
Dies sind erweiterte Einstellungen, die mit Vorsicht behandelt werden sollten:
HTML-POST-Anforderungstexte überprüfen: Dies ermöglicht eine Reihe von Optionen, die im Folgenden beschrieben werden: Der JSON- und der XML-Parser sowie die Option, CRS andere Inhaltstypen prüfen zu lassen. Es ist offensichtlich, dass Sie die beiden Parser brauchen, wenn Sie JSON und XML sinnvoll nutzen wollen. Andernfalls handelt es sich lediglich um eine Ansammlung von Sonderzeichen mit spärlichen Informationen. Aber auch das dritte Kontrollkästchen, "Enable Other Content Types", ist wichtig. Es stellt sicher, dass normale Formulareingaben (Inhaltstyp "application/x-www-form-urlencoded") geprüft werden. Sie können dann weiterhin die einzelnen Inhaltstypen eingeben, die geprüft werden sollen, aber es ist OK, das Textfeld so zu lassen ("Any content types") und die WAF wird die Formulare prüfen.
HTTP-Antworten verarbeiten: CRS erkennt 90 % der Angriffe auf die Anfrage und ihren Textkörper. Es gibt jedoch eine ansehnliche Gruppe von Regeln, die auf den Antwortkörper abzielen.
Paranoia-Level blockieren: Die Standard-Paranoia-Stufe ist 1 und reicht für die meisten LoadMaster-Installationen aus. Wenn Sie jedoch ein strengeres Regelwerk wünschen und bereit sind, mehr Fehlalarme einzustellen, dann ist es sinnvoll, die Paranoia-Stufe zu erhöhen.
Wenn Sie die Paranoia-Stufe anheben, reicht es in der Regel aus, die sogenannte Blockier-Paranoia-Stufe zu erhöhen. Wenn Sie diesen auf Paranoia-Stufe 2 setzen, werden die Regeln der Paranoia-Stufe 2 aktiviert. Sie tragen nun zur Bewertung der Anfrage bei, und die WAF entscheidet anhand dieser Bewertung, ob die Anfrage blockiert werden sollte oder nicht.
Paranoia-Level ausführen: Wenn Sie die Paranoia-Stufe anheben, reicht es in der Regel aus, die sogenannte Blocking Paranoia-Stufe zu erhöhen. Wenn Sie diesen auf Paranoia-Stufe 2 setzen, werden die Regeln der Paranoia-Stufe 2 aktiviert. Sie tragen nun zur Bewertung der Anfrage bei, und die WAF entscheidet anhand dieser Bewertung, ob die Anfrage blockiert werden sollte oder nicht.
Bitte beachten Sie, dass die Benutzeroberfläche Sie daran hindert, eine Blocking-Paranoia-Stufe einzustellen, die höher ist als die Executing-Paranoia-Stufe. Es ist offensichtlich, dass Sie nicht auf einer höheren Stufe blockieren können, wenn Sie die Regeln nicht ausführen.
Teile prüfen: Mit den Kontrollkästchen können Sie den Detaillierungsgrad in den Protokolldateien des Überwachungsmodus steuern. Diese Einstellungen werden hier ausführlich beschrieben.
Audit-Teile: Mit den Kontrollkästchen können Sie den Detaillierungsgrad der Protokolldateien im Audit-Modus steuern. Diese Einstellungen werden hier detailliert beschrieben.
Kopf- und Fußzeile In allen Fällen werden die Audit-Log-Formate A (Audit Log Header) und Z (Audit Log Footer) bereitgestellt.
Anfragen bearbeiten In der Standardkonfiguration bei der Verarbeitung von Anforderungen werden die Audit-Log-Formate B (Request-Header) und H (Audit-Log-Trailer ) bereitgestellt.
Antworten verarbeiten: Wenn das Kontrollkästchen HTTP-Antworten verarbeiten aktiviert ist, werden die zusätzlichen (zu den oben genannten) Audit-Protokollformate E (Intended Response Body) und F (Response Headers) bereitgestellt. Abbildung 2 oben zeigt diese Konfiguration. PCRE Match Limit: Dieser Wert steuert das Verhalten der Engine für reguläre Ausdrücke in ModSecurity. Der Standardwert ist 3.000, was konservativ ist und zu einer Vielzahl von PCRE-Fehlermeldungen führen kann ("PCRE limits exceeded"). Es ist also sinnvoll, diesen Wert zu erhöhen. Allerdings erhöht ein höherer Wert auch das Risiko, Opfer eines so genannten "Regular Expression Denial of Service"-Angriffs ("ReDoS") zu werden. Einzelne Länder blockieren: Damit können Sie IP-Adressen aus einzelnen Ländern am Zugriff auf Ihre Anwendung hindern.
Um den Kreis zum ersten Test zu schließen, setze ich den Anomaly Scoring Threshold auf 5 und wiederhole den Test. Ich erhalte das folgende Ergebnis: Die WAF blockiert die Anfrage mit einem 403-Fehler.
Requests
curl http://<<IP-Adresse des virtuellen Dienstes>>/index.html\?exec\=/bin/bash
Die LoadMaster-Protokolle, die hier am interessantesten sind, sind die WAF-Ereignisprotokolldatei unter System Configuration –Logging Options –System Log Files. Die bei diesem Zugriffsversuch erstellten Protokolle werden hier angezeigt:
Wir sehen uns mehrere Einträge in diesem Protokoll an
ID , die uns mitteilt, dass Regel 949110 getroffen wurde
msg , um zu erfahren, was passiert ist, in diesem Fall wurde der Anomaly Score überschritten
hostname ist die Adresse des virtuellen Dienstes, gegen die der Angriff ausgelöst wurde
Zugriff verweigert , was darauf hinweist, dass dieser Zugriffsversuch mit einem 403-Fehler blockiert wurde
Zusammenfassung
Nachdem wir nun die grundlegenden Elemente der Konfiguration des Core Rule Sets auf LoadMaster vorgestellt haben, werden wir nächste Woche ein praktisches Beispiel für die Verwendung von benutzerdefinierten Regeln demonstrieren, um Ihre WAF-Konfiguration innerhalb von LoadMaster für eine bestimmte Anwendung zu erstellen/anzupassen.