Stellen Sie sich vor, ein Benutzer legt ein Kennwort wie ' UNION TABLE spaceships; Dies mag wie eine SQL-Injection aussehen, ist aber tatsächlich ein sehr gutes Passwort.
Es ist ziemlich lang, hat Groß- und Kleinbuchstaben, es kommt mit Sonderzeichen usw.
Und es sollte nicht einmal ein Sicherheitsproblem sein, wenn die Entwickler das Richtige getan und die Passwörter, die sie in der Datenbank speichern, gehasht haben. Dies löst das potenzielle SQL-Injection-Problem hier, da das obige Passwort auch für die sichere Verwendung über SQL gehasht würde. Also, was gibt es hier nicht zu lieben?
CRS ist da anderer Meinung! CRS gefällt das überhaupt nicht. Die CRS-Regel 942190 identifiziert dies als "Erkennt MSSQL-Codeausführung und Versuche zum Sammeln von Informationen".
Während wir als Menschen leicht zu dem Schluss kommen können, dass es sich bei dieser Warnung in diesem Zusammenhang um einen Fehlalarm handelt, kann CRS unmöglich den Unterschied erkennen, also müssen wir es lehren: Wir müssen dieses Fehlalarm wegschalten.
In der Sprache von ModSecurity oder CRS müssen wir einen Regelausschluss schreiben. Das hört sich komplizierter an, als es ist, aber Sie müssen das Konzept verstehen, sonst werden Sie das Verfahren nicht verstehen. Lassen Sie uns also zuerst die Theorie angehen.
CRS wird regelmäßig aktualisiert. Wenn wir beginnen, das CRS selbst auf dem lokalen LoadMaster zu bearbeiten, können wir das Update nicht mehr durchführen, oder unsere Änderungen werden überschrieben.
Daher vermeiden wir es, Änderungen am Kernregelsatz vorzunehmen, sondern fügen der Web Application Firewall (WAF) Anweisungen hinzu, die dem Modul mitteilen, wie der Regelsatz so manipuliert werden soll, dass das falsch positive Ergebnis verschwindet. Im ModSecurity / CRS-Jargon nennen wir das einen Regelausschluss.
Wenn Sie ein falsch positives Ergebnis wegschalten, müssen Sie einen Regelausschluss schreiben.
Wie der Name schon sagt, weisen wir die WAF-Engine an, eine bestimmte Regel von der Anwendung auszuschließen. Es gibt verschiedene Möglichkeiten, einen Regelausschluss zu schreiben oder auszudrücken, und wir werden sie nacheinander ausprobieren.
In vielen Situationen, vor allem in den kniffligeren, ist es sehr hilfreich, wenn Sie eine Anfrage oder einen ModSecurity / CRS-Alarm nach Belieben reproduzieren können. Für diesen Test verwenden wir eine Post-Anforderung, um die 942190-Regel erneut auszulösen, wie unten beschrieben.
Es gibt zwei Möglichkeiten, auf den virtuellen Dienst zu verweisen, auf dem WAF ausgeführt wird:
Testmethode 1: Direkter Verweis auf die IP-Adresse des virtuellen Diensts
curl -X POST http://<<IP-Adresse der virtuellen Dienste>>/submit-login -d "username=Christian&password=' UNION TABLE spaceships;"
Testmethode 2: Verweis auf die IP-Adresse des virtuellen Diensts über den Hostnamen
curl -X POST http://blog-4/submit-login -d "Benutzername=Christian&password=' UNION TABLE Raumschiffe;"
Ich verwende ein Ubuntu-System und habe /etc/hosts so konfiguriert , dass die IP-Adresse des virtuellen Dienstes blog-4 zugeordnet wird, wie in Abbildung 1 dargestellt.
Wenn Sie Testmethode 1 verwenden, wird eine zweite Regel, 920350, ausgelöst, die als "Host-Header ist eine numerische IP-Adresse" identifiziert. Für die Übung deaktivieren wir diese Regel in Beispiel 1.
Wir können jetzt also die Warnung 942190 auslösen. Der nächste Schritt besteht darin, die WAF so zu optimieren, dass diese Anforderung keine Warnung mehr auslöst (ein falsch positives Ergebnis).
Die LoadMaster WAF sitzt vor einem Apache-Server. Es gibt keine spezielle Konfiguration der Apache-Anwendung, es handelt sich um eine Standardinstallation. Die LoadMaster WAF wird auf der Paranoia-Stufe 1 und der Anomalie-Bewertungsschwelle auf 3 ausgeführt.
Wenn Sie einen erfolgreichen Test durchführen, wird die LoadMaster WAF an den Apache-Server übergeben und führt wie erwartet zu einem 404-Fehler.
Ich werde mich schnell mit der direkten IP-Adresse des virtuellen Dienstes im curl-Befehl befassen, um das CRS auszulösen, Testmethode 1 oben. Wenn Sie diese Option verwendet haben, klicken Sie unter Web Application Firewall – False Positive-Analyse für diesen virtuellen Dienst auf Regel deaktivieren , wie in Abbildung 2 dargestellt.
Wiederholen Sie dann den curl-Befehl der Testmethode 1 und Sie können fortfahren.
Die LoadMaster-Benutzeroberfläche unterstützt das vollständige Deaktivieren einer Regel. Bei dieser Methode wird eine Regel buchstäblich aus dem Speicher der Engine entfernt. Natürlich ist dies eine sehr effektive Methode, um Regeln zu deaktivieren. Es ist auch ein sehr grober Ansatz für das Problem, da die Regel nicht nur für den Passwortparameter im Anmeldeformular deaktiviert ist, sondern für den gesamten virtuellen Dienst. Ich nenne dies den "Schrotflinten-Ansatz", um Ausschlüsse zu regeln.
Loadmaster ermöglicht es mir, dies auf drei Arten anzugehen. Erster Ansatz:
Navigieren Sie in der WAF-Konfiguration des virtuellen Dienstes zum Abschnitt Regeln verwalten (Virtuelle Dienste – Dienste anzeigen/ändern, wählen Sie den zu testenden virtuellen Dienst aus). Dort klicken Sie auf den Namen der richtigen Regelgruppe/Kategorie, um die vollständige Liste der Regeln pro Gruppe zu erhalten. 942190 ist Teil der Gruppe "application-attack-SQL". Alle Regeln im Bereich 942xxx werden angezeigt, scrollen Sie nach unten, deaktivieren Sie das Häkchen vor der 942191 Regel-ID und klicken Sie auf die Schaltfläche "Anwenden", wie in Abbildung 3 dargestellt.
Wiederholen Sie die curl-Anforderung, und die LoadMaster-WAF wird erfolgreich an die Apache-Anwendung übertragen.
Zweiter Ansatz:
Der zweite Ansatz zum Deaktivieren einer Regel besteht darin, zu Web Application Firewall – False Positive-Analyse für diesen virtuellen Dienst zu navigieren. Dadurch wird eine Ansicht geöffnet, in der Sie aktuelle Regelwarnungen überprüfen können. Es gibt einen Zähler für die einzelnen Regelwarnungen, die 942190 enthalten. Es gibt auch eine Liste der deaktivierten Regeln und dann ein Histogramm, das nach der Anomaliebewertung der Anforderungen organisiert ist, wie in Abbildung 5 dargestellt.
Wenn also eine Anforderung eine Anomaliebewertung von 15 Punkten angesammelt hat, werden die drei Regeln, aus denen sich diese 15 Punkte zusammensetzen, daneben angezeigt. Unsere Anfrage löste 8 Punkte aus, wenn Sie die WAF über ihre IP-Adresse des virtuellen Dienstes aufgerufen haben (Testmethode 1) oder 5 Punkte, wenn Sie einen Hostnamen verwendet haben (Testmethode 2). Sie können sie deaktivieren, indem Sie auf "Regel deaktivieren" klicken, wie in Abbildung 5 dargestellt.
Die Wirkung tritt sofort ein. Wiederholen Sie die curl-Anforderung, und die LoadMaster-WAF wird erfolgreich an die Apache-Anwendung übertragen.
Dies sind also die beiden Regelausschlussansätze, die von der LoadMaster-Benutzeroberfläche unterstützt werden.
Dritter Ansatz:Wir können einen benutzerdefinierten Regel-Upload mit der ModSecurity-Direktive SecRuleRemoveById verwenden. Im Hintergrund ist dies die Aktion, die die LoadMaster-Benutzeroberfläche ausführt, wenn Sie die Regel deaktivieren (Erster Ansatz) oder die Regel deaktivieren (Zweiter Ansatz).
Schreiben wir Folgendes in eine Datei mit dem Namen rule_exclusions_method1.conf:
# Ausschluss von ModSec-Regeln: 942190 : Erkennt die Ausführung von MSSQL-Code und # Versuche zum Sammeln von Informationen SecRule REQUEST_URI "@beginsWith /submit-login" \ "phase:1,nolog,pass,id:10000,ctl:ruleRemoveById=942190"
Tipp: Begleiten Sie Regelausschlüsse immer mit einem kurzen Kommentar darüber, was Sie tun und worum es bei der Regel geht, da es wahrscheinlich mehr Regel-IDs gibt, als Sie sich merken können.
Fügen Sie also den folgenden Befehl in eine benutzerdefinierte Regeldatei ein, laden Sie sie hoch und aktivieren Sie sie. Die vollständigen Details zum Hochladen und Aktivieren von benutzerdefinierten Regeldateien in LoadMaster finden Sie im Blog #3, "Bereitstellen benutzerdefinierter Regeln auf LoadMaster", der hier verfügbar ist .
Die Wirkung tritt sofort ein. Wiederholen Sie die curl-Anforderung, und die LoadMaster-WAF wird erfolgreich an die Apache-Anwendung übertragen.
Das vollständige Deaktivieren einer Regel, um sicherzustellen, dass eine einzige gutartige Verwendung eines verdächtigen Parameters nicht mehr von einer übereifrigen Regel angegriffen wird, könnte eine schlechte Praxis sein, da sie ein größeres Loch in der Verteidigung als nötig öffnet.
Stellen Sie sich vor, der Kennwortparameter wird an drei verschiedenen Stellen in der Anwendung verwendet. Während des Logins, aber auch der Registrierung und des Passwort-Update-Prozesses. Das Deaktivieren von 942190 für den Kennwortparameter würde daher Fehlalarme an allen drei Speicherorten verhindern. Und das ist begrüßenswert. Wie machen wir das?
Schreiben wir Folgendes in eine Datei mit dem Namen rule_exclusions_method2.conf:
# Ausschluss von ModSec-Regeln: 942190 : Erkennt die Ausführung von MSSQL-Code und# Versuche zum Sammeln von InformationenSecRuleUpdateTargetById 942190 "! ARGS:Passwort"
Tipp: Begleiten Sie Regelausschlüsse immer mit einem kurzen Kommentar darüber, was Sie tun und worum es bei der Regel geht, da es wahrscheinlich mehr Regel-IDs gibt, als Sie sich merken können.
Aber was genau bewirkt diese Richtlinie? Es aktualisiert die Zielliste der Regel 942190 und entfernt das Kennwortargument. Die Regel ist also immer noch vorhanden, wird aber nicht mehr auf die Kennwortargumente (ARGS) angewendet.
Wir müssen diesen Regelausschluss über eine benutzerdefinierte Regeldatei übergeben, diese benutzerdefinierte Regeldatei hochladen und aktivieren. Die vollständigen Details zum Hochladen und Aktivieren von benutzerdefinierten Regeldateien in LoadMaster finden Sie im Blog #3, "Bereitstellen benutzerdefinierter Regeln auf LoadMaster", der hier verfügbar ist .
Die Wirkung tritt sofort ein. Wiederholen Sie die curl-Anforderung, und die LoadMaster-WAF wird erfolgreich an die Apache-Anwendung übertragen.
Manchmal möchten Sie eine Regel nur in bestimmten Situationen überspringen. Angenommen, die Regel löst falsch positive Ergebnisse im Anmeldeformular aus, aber Sie möchten sie für das Suchformular beibehalten. An dieser Stelle kommen Ausschlüsse von Laufzeitregeln ins Spiel.
Sie sind komplexer, aber auch kontextsensitiver.
Hier ist ein Regelausschluss für 942190 mit einer URI-Einschränkung für den URI mit der Kennwortübermittlung. Schreiben wir Folgendes in eine Datei mit dem Namen rule_exclusions_method3.conf:
# Ausschluss von ModSec-Regeln: 942190 : Erkennt die Ausführung von MSSQL-Code und # Versuche zum Sammeln von Informationen SecRule REQUEST_URI "@beginsWith /submit-login" "phase:1,nolog,pass,id:10000,\ ctl:ruleRemoveById=942190"
Tipp: Begleiten Sie Regelausschlüsse immer mit einem kurzen Kommentar darüber, was Sie tun und worum es bei der Regel geht, da es wahrscheinlich mehr Regel-IDs gibt, als Sie sich merken können.
Dies ist also eine echte ModSecurity-Regel, die nach einem Anfrage-URI sucht, der mit /submit-login beginnt. Wenn es eine Übereinstimmung gibt, weisen wir die Regel-Engine an, die Regel 942190 für den Rest dieser Anforderung zu entfernen bzw. zu ignorieren. Dies geschieht in Phase 1 (Request Headers). Der Hauptzweck dieser Phase besteht darin, Regelautoren die Möglichkeit zu geben, eine Anforderung zu bewerten, bevor die kostspielige Verarbeitung des Anforderungstexts durchgeführt wird. In ähnlicher Weise ist es oft notwendig, die Art und Weise zu beeinflussen, wie ModSecurity einen Anfragetext verarbeitet, und diese Phase ist der richtige Ort, um dies zu tun.
Die vollständige Beschreibung der fünf ModSecurity-Phasen finden Sie in Kapitel 1 des ModSecurity-Handbuchs, 2 . Auflage, das hier verfügbar ist.
Bitte beachten Sie, dass Regel-IDs eindeutig sein müssen. Wenn Sie also mehrere Regelausschlüsse mit diesem Formular durchführen, müssen Sie die Regel-ID für jeden von ihnen erhöhen. Der Regelraum bis zu 100.000 ist verfügbar; Sie brauchen keine Kollisionen zu befürchten, wenn Sie sich an diesen Bereich halten und Ihre Regelausschlüsse organisiert halten.
Wir müssen diesen Regelausschluss über eine benutzerdefinierte Regeldatei übergeben, diese benutzerdefinierte Regeldatei hochladen und aktivieren. Die vollständigen Details zum Hochladen und Aktivieren von benutzerdefinierten Regeldateien in LoadMaster finden Sie im Blog #3, "Bereitstellen benutzerdefinierter Regeln auf LoadMaster", der hier verfügbar ist .
Die Wirkung tritt sofort ein. Wiederholen Sie die curl-Anforderung, und die LoadMaster-WAF wird erfolgreich an die Apache-Anwendung übertragen.
Nachdem ich jahrelang CRS-Tunings durchgeführt habe, ist dies die Regelausschlussvariante, die ich am wenigsten verwende. Ein Anwendungsfall, in dem diese Variante meine bevorzugte Methode ist, ist das Deaktivieren von "920350 Host-Header ist eine numerische IP-Adresse". Es kommt sehr häufig vor, dass 920350 bei Zustandsprüfungen ausgelöst wird, die von Load Balancern oder Uptime-Agents verwendet werden, da sie mit IP-Adressen anstelle von Hostnamen arbeiten. In den meisten anderen Situationen bevorzuge ich die anderen Varianten.
Die folgende benutzerdefinierte Regel behebt dieses Problem:
# Ausschluss der ModSec-Regel: 920350 : Host-Header ist eine numerische IP-AdresseSecRule REQUEST_URI "@beginsWith /submit-login" "phase:1,nolog,pass,id:10001,\ ctl:ruleRemoveById=920350"
Das bisherige Regelausschlussmuster war bereits recht auf den Punkt gebracht, ebenso wie das über einen einzelnen Parameter. Die in diesem Abschnitt kombiniert die beiden:
Im Folgenden finden Sie einen Regelausschluss für 942190 mit einer URI-Einschränkung für die Kennwortübermittlung, die den Kennwortparameter von der Überprüfung durch Regel 942190 ausschließt. Schreiben wir Folgendes in eine Datei mit dem Namen rule_exclusions_method4.conf:
# Ausschluss von ModSec-Regeln: 942190 : Erkennt die Ausführung von MSSQL-Code und # Versuche zum Sammeln von Informationen SecRule REQUEST_URI "@beginsWith /submit-login" "phase:1,nolog,pass,id:10000,\ ctl:ruleRemoveTargetById=942190; ARGS:Passwort"
Tipp: Begleiten Sie Regelausschlüsse immer mit einem kurzen Kommentar darüber, was Sie tun und worum es bei der Regel geht, da es wahrscheinlich mehr Regel-IDs gibt, als Sie sich merken können.
Die Bedingung bleibt also gleich, aber die Steueranweisung ist sehr kompliziert geworden. Bitte stellen Sie sicher, dass Sie das Format der Steueranweisung korrekt erhalten.
Ein weiteres Deep-Dive-Tutorial zu dieser Regelausschlussmethode für den Umgang mit falsch positiven Ergebnissen finden Sie hier.
Bei den Methoden 3 und 4 handelte es sich um Laufzeitregelausschlüsse mit einer URI-Bedingung. Sie werden also während der Ausführung der Anforderung ausgeführt. Ich habe die Regelausschlüsse in Phase 1 geschrieben, aber LoadMaster führt die benutzerdefinierten Regeln nach den Standardregeln aus. Das bedeutet, dass eine Phase-1-Standardregel ausgeführt wird, bevor unsere Regelausschlussregel, die auf diese Regel abzielt, ausgewertet wird. Das bedeutet, dass für die Regeln der Phase 1 unsere Beispiele 3 und 4 auf LoadMaster zu spät kommen. Die meisten Regeln in CRS befinden sich in Phase 2 und daher haben unsere Regelausschlüsse Vorrang.
Sie können die Phase einer Regel überprüfen, indem Sie auf dem Falsch-Positiv-Analysebildschirm auf die Regel-ID klicken. Wenn Sie feststellen, dass eine Regel in Phase 1 ausgeführt wird, müssen Sie einen Startregelausschluss wie in Methode 1 und Methode 2 schreiben.
Wir haben nun die grundlegenden vier Varianten gesehen, um ein falsch positives Ergebnis mit Hilfe eines Regelausschlusses wegzuschalten. Die erste war sehr grob – und wurde von der LoadMaster-Benutzeroberfläche unterstützt – die letzte war sehr granular, aber ziemlich mühsam zu machen. In der Praxis wählen Sie diejenige Variante aus, die am besten zu Ihnen passt. Im Laufe der Jahre tendiere ich dazu, öfter auf die erste Variante zurückzugreifen. Es stimmt, dass Nummer 4 aus Sicherheitssicht besser ist, aber es stimmt auch, dass die Wirtschaft die Sache aus dem Weg räumen will und es den Leuten normalerweise egal ist, ob wir 180 oder 179 CRS-Regeln aktiv haben.
Teil 1: Einführung in OWASP CRS
Teil 2: Wie führt man OWASP CRS auf dem Load Master aus?
Teil 3: Bereitstellen von benutzerdefinierten Regeln
Teil 4: Falsch-positive Analyse
Teil 5: Berichterstattung