Mit benutzerdefinierten Regeln können wir unsere Sicherheitskonfiguration als Teil der allgemeinen Systemabstimmung optimieren und verfeinern, was ein wesentlicher Bestandteil der Rolle eines Administrators im Bereich Sicherheit ist. Dieser dritte Teil der OWASP CRS-Serie erklärt, wie man benutzerdefinierte Regeln auf dem LoadMaster bearbeitet, hochlädt, aktiviert und in Aktion beobachtet. Wir folgen dabei einem einfachen 4-Schritte-Prozess auf dem LoadMaster. Auf dem Weg dorthin werden die entsprechenden API-Befehle zur Verfügung gestellt.
Schritt 1: Vorbereiten einer benutzerdefinierten Regeldatei
Dies geschieht in der Regel lokal auf Ihrem persönlichen Computer. Eine gute Wahl ist vim (obwohl jeder Texteditor geeignet ist), da die Syntaxhervorhebung für die ModSecurity-Regelsyntax das Verständnis erleichtert.
In diesem Blog werden wir eine Whitelist zum Schutz eines Anmeldeformulars erstellen. Diese Regeln blockieren sofort Anfragen an unbekannte Endpunkte, die unbekannte Parameter oder Parameter mit falschem Format (z. B. Sonderzeichen) übermitteln. Die Tatsache, dass wir diese imaginäre Login-Anwendung nicht auf einem unserer Server laufen lassen, spielt für diese Übung keine Rolle: Alles was wir wollen, ist den LoadMaster zu konfigurieren und wenn die Anfrage den LoadMaster WAF passiert und auf das Backend trifft, dann bekommen wir einfach eine 404 und das ist OK.
Ausführlichere Informationen zu dieser Konfiguration finden Sie in netnea.com Tutorials unter Schritt 8 hier.
Wir würden also versuchen, eine Datei mit dem Titel modsecurity_allowlist.conf mit folgendem Inhalt zu erstellen
SecMarker BEGIN_ALLOWLIST_login
# START allowlisting block for URI /login SecRule REQUEST_URI "!@beginsWith /login" \
"id:11001,phase:1,pass,t:lowercase,nolog,skipAfter:END_ALLOWLIST_login"
SecRule REQUEST_URI "!@beginsWith /login" \
"id:11002,phase:2,pass,t:lowercase,nolog,skipAfter:END_ALLOWLIST_login"
# Validate HTTP method
SecRule REQUEST_METHOD "!@pm GET HEAD POST OPTIONS" \
"id:11100,phase:1,deny,status:405,log,tag:'Login Allowlist',\
msg:'Method %{MATCHED_VAR} not allowed'"
# Validate URIs
SecRule REQUEST_FILENAME "@beginsWith /login/static/css" \
"id:11200,phase:1,pass,nolog,tag:'Login Allowlist',\
skipAfter:END_ALLOWLIST_URIBLOCK_login"
SecRule REQUEST_FILENAME "@beginsWith /login/static/img" \
"id:11201,phase:1,pass,nolog,tag:'Login Allowlist',\
skipAfter:END_ALLOWLIST_URIBLOCK_login"
SecRule REQUEST_FILENAME "@beginsWith /login/static/js" \
"id:11202,phase:1,pass,nolog,tag:'Login Allowlist',\
skipAfter:END_ALLOWLIST_URIBLOCK_login"
SecRule REQUEST_FILENAME \
"@rx ^/login/(displayLogin|login|logout).do$" \
"id:11250,phase:1,pass,nolog,tag:'Login Allowlist',\
skipAfter:END_ALLOWLIST_URIBLOCK_login"
# If we land here, we are facing an unknown URI, # which is why we will respond using the 404 status code SecAction "id:11299,phase:1,deny,status:404,log,tag:'Login Allowlist',\
msg:'Unknown URI %{REQUEST_URI}'"
SecMarker END_ALLOWLIST_URIBLOCK_login
# Validate parameter names
SecRule ARGS_NAMES "!@rx ^(username|password|sectoken)$" \
"id:11300,phase:2,deny,log,tag:'Login Allowlist',\
msg:'Unknown parameter: %{MATCHED_VAR_NAME}'"
# Validate each parameter's uniqueness
SecRule &ARGS:username "@gt 1" \
"id:11400,phase:2,deny,log,tag:'Login Allowlist',\
msg:'%{MATCHED_VAR_NAME} occurring more than once'"
SecRule &ARGS:password "@gt 1" \
"id:11401,phase:2,deny,log,tag:'Login Allowlist',\
msg:'%{MATCHED_VAR_NAME} occurring more than once'"
SecRule &ARGS:sectoken "@gt 1" \
"id:11402,phase:2,deny,log,tag:'Login Allowlist',\
msg:'%{MATCHED_VAR_NAME} occurring more than once'"
# Check individual parameters
SecRule ARGS:username "!@rx ^[a-zA-Z0-9.@_-]{1,64}$" \
"id:11500,phase:2,deny,log,tag:'Login Allowlist',\
msg:'Invalid parameter format: %{MATCHED_VAR_NAME} (%{MATCHED_VAR})'"
SecRule ARGS:sectoken "!@rx ^[a-zA-Z0-9]{32}$" \
"id:11501,phase:2,deny,log,tag:'Login Allowlist',\
msg:'Invalid parameter format: %{MATCHED_VAR_NAME} (%{MATCHED_VAR})'"
SecRule ARGS:password "@gt 64" \
"id:11502,phase:2,deny,log,t:length,tag:'Login Allowlist',\
msg:'Invalid parameter format: %{MATCHED_VAR_NAME} too long (%{MATCHED_VAR} bytes)'"
SecRule ARGS:password "@validateByteRange 33-244" \
"id:11503,phase:2,deny,log,tag:'Login Allowlist',\
msg:'Invalid parameter format: %{MATCHED_VAR_NAME} (%{MATCHED_VAR})'"
SecMarker END_ALLOWLIST_loginSchritt 2: Laden Sie eine benutzerdefinierte Regeldatei in LoadMaster hoch
Nun, da die benutzerdefinierte Regeldatei fertig ist, ist es ein einfacher Schritt, sie hochzuladen und für den/die Virtual Service(s) auf dem LoadMaster verfügbar zu machen.
Importieren Sie die modsecurity_allowlist.conf in den LoadMaster in der Web Application Firewall, die sich in der linken Navigation befindet, klicken Sie auf Benutzerdefinierte Regeln und wählen Sie "Datei auswählen", um die benutzerdefinierte Regeldatei unter dem Titel WAF Benutzerdefinierte Regeln auszuwählen.
Sobald die benutzerdefinierte Regeldatei ausgewählt ist, wählen Sie "Regelsatz hinzufügen", um den Upload abzuschließen.
Im Abschnitt Benutzerdefinierte Regeln können sowohl benutzerdefinierte Regeln als auch zugehörige Datendateien hochgeladen werden. Einzelne benutzerdefinierte Regeldateien können, wie oben gezeigt, oder als Regelpaket in einem gzip-komprimierten Tar-Ball (.tar.gz) geladen werden. Datendateien werden von benutzerdefinierten Regeln referenziert und müssen vor der entsprechenden benutzerdefinierten Regeldatei hochgeladen werden.
Benutzerdefinierte Regeldateien können direkt heruntergeladen oder gelöscht werden (wenn die benutzerdefinierten Regeln nicht von einem virtuellen Dienst verwendet werden).
Das Hochladen der benutzerdefinierten Regeldatei über die RESTful-API lässt sich wie folgt bewerkstelligen:
curl -X POST --data-binary "@./modsec_allowlist.conf" -k https://bal:password@<<LoadMaster IP-Adresse>>/access/addowaspcustomrule\?filename\="./modsec_allowlist.conf"
Schritt 3: Zuweisen der benutzerdefinierten Regeln zu einer bestimmten Anwendung (Virtual Service)
Die LoadMaster Virtual Services (VS) bieten dem Benutzer die Möglichkeit, spezifische Einstellungen (WAF, SSL, Content Rules, Authentication und SSO etc.) für eine Applikation zu konfigurieren.
Nachdem Sie die Datei modsecurity_allowlist.conf importiert haben, navigieren Sie zu Virtual Services, View/Modify Services und wählen Sie den virtuellen Anwendungsdienst aus, für den diese benutzerdefinierte Regel verwendet werden soll. Nach der Auswahl navigieren Sie zu WAF. Aktivieren Sie das Kontrollkästchen, damit das Häkchen verfügbar ist, und klicken Sie auf die Schaltfläche "Anwenden".
Um die einzelnen Regeln in der Datei modsecurity_allowlist.conf zu sehen, klicken Sie auf den Dateinamen modsec_allowlist. Hier können individuelle benutzerdefinierte Regeln ausgewählt und je nach Bedarf deaktiviert (oder aktiviert) werden. Für die Zwecke dieses Blogs sollten alle benutzerdefinierten Regeln wie unten gezeigt aktiviert werden.
Um dieses Beispiel zu vereinfachen, konfigurieren wir den Überwachungsmodus so, dass alle überwacht werden, und legen einen niedrigen Schwellenwert für die Anomaliebewertung von 5 fest.
Stellen Sie unter Erweiterte Einstellungen sicher, dass Inspect HTML POST Request Bodies aktiviert ist. Dies sollte dazu führen, dass Enable JSON Parser, Enable XML Parser und Enable Other Content Types aktiviert werden. Vergewissern Sie sich, dass Enable Other Content Types aktiviert ist, da sonst die Formularparameter ignoriert werden. Dies ist in Abbildung 4 unten dargestellt.
Das Anwenden der benutzerdefinierten Regeldatei auf den virtuellen Dienst über die RESTful-API ist wie folgt einfach:
curl -k https:// bal:password@<<LoadMaster-IP-Adresse>>/access/modvs\?vs\=<<IP-Adresse des virtuellen Dienstes>>\&port\=<<Port des virtuellen Dienstes>>\&prot\=<<Protokoll für den virtuellen Dienst>>\&CustomRules\="modsec_allowlist"
Die LoadMaster Virtual Service-Verarbeitung von benutzerdefinierten Regeln umfasst die folgenden Funktionen:
- Wenn Sie eine neue Regeldatei hochladen und eine vorhandene Datei überschreiben, die zuvor aktiviert wurde, wird die neue Version sofort aktiv
- Wenn eine neue Version einer Regeldatei neue Regeln enthält, müssen Sie diese nicht einzeln aktivieren. Sie werden sofort aktiv
- Wenn Sie versuchen, eine vorhandene Regeldatei mit einer leeren Datei oder mit einer Datei ohne Regeln zu überschreiben, schlägt dies fehl und die ursprüngliche Version bleibt erhalten
- Sie können eine Regeldatei nicht löschen, wenn sie in einem virtuellen Dienst aktiv ist
Schritt 4: Führen Sie einen Test durch, um sicherzustellen, dass alles funktioniert
Für die Zwecke dieses Tests verwende ich einen Standard-Apache-Server (Version: 2.4.46) als Back-End-Anwendung. Es gibt keine spezielle Konfiguration der Anwendung, es handelt sich um eine Standardinstallation.
Beim Ausführen des ersten Tests wird dies über die WAF an die Anwendung weitergeleitet und führt wie erwartet zu einem 404-Fehler.
Request
curl http://10.35.56.31/login/displayLogin.do
Antwort
<! DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//DE"><html><head><title> 404 Not Found</title></head><body><h1>Not Found</h1><p>Die angeforderte URL wurde auf diesem Server nicht gefunden.</p><hr><address>Apache/2.4.29 (Ubuntu) Server unter 10.35.56.31 Port 80</address> </body></html>
Beim zweiten Test gibt es eine zusätzliche Abfragezeichenfolge, z. B. debug=1, die der WAF-Regelsatz nicht kennt. In diesem Fall blockiert die WAF die Anforderung mit einem 403-Fehler.
Request
curl http://10.35.56.31/login/displayLogin.do\?debug\=1
Antwort
<html><head><title>403 Verboten</title></head><body>Zugriff verweigert</body>
Logs
Es gibt mehrere Protokolle, die der LoadMaster generiert, und das interessanteste hier ist die WAF-Ereignisprotokolldatei unter Systemkonfiguration – Protokollierungsoptionen – Systemprotokolldateien. Das Protokoll, das aus diesem Zugriffsversuch generiert wird, wird hier angezeigt:
2021-04-13T08:25:50+00:00 lb100 wafd: [Client 10.0.31.231] ModSecurity: Zugriff mit Code 403 verweigert (Phase 2). Übereinstimmung von "rx ^(username|password|sectoken)$" mit "ARGS_NAMES:debug" erforderlich. [Datei "/tmp/waf/2/modsec_allowlist.conf"] [Zeile "39"] [ID "11300"] [msg "Unbekannter Parameter: ARGS_NAMES:debug"] [Tag "Login-Zulassungsliste"] [Hostname "10.35.56.31"] [uri "/login/displayLogin.do"] [unique_id "8aeea40b-c364-47c0-82db-3982b36e6bb7"]
Wir sehen uns mehrere Einträge in diesem Protokoll an
- ID, die uns mitteilt, dass die benutzerdefinierte Regel 11300 getroffen wurde
- msg, um zu erfahren, was passiert ist, in diesem Fall ein unbekannter Parameter debug
- Zugriff verweigert, was darauf hinweist, dass dieser Zugriffsversuch mit einem 403-Fehler blockiert wurde
Die LoadMaster-Protokolle werden in die ModSecurity-Protokolle gespiegelt und die Zuordnung lautet:
Zusammenfassung
Benutzerdefinierte Regeln bieten Administratoren eine flexible Möglichkeit, ihre individuelle WAF-Konfiguration innerhalb des LoadMaster für ihre spezifische Anwendung zu erstellen/anzupassen und ermöglichen die Behandlung von False Positives. Nächste Woche werden wir Ihnen zeigen, wie die False-Positive-Analyse auf dem LoadMaster durchgeführt wird und welche verbesserte Sichtbarkeit dies mit sich bringt.
Wenn Sie derzeit die Web Application Firewall (WAF) verwenden möchten, s
sollten Sie sich die Kemp WAF hier ansehen.
Lesen Sie den Rest der OWASP CRS-Serie
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-Positiv-AnalyseTeil 5: Berichterstattung
