ModSecurity WAF mit einem Whitelist-Ansatz

Eine Web Application Firewall erkennt und verhindert normalerweise Angriffe wie SQL-Injection. Dies wird erreicht, indem reguläre Ausdrücke verwendet werden, um potenziell gefährliche Zeichenfolgen zu filtern. Ein gängiges Setup verwendet ModSecurity als Plugin für Apache in Kombination mit dem OWASP Core Rule Set. Zunächst verwendet man eine "Trainingsphase", um das Regelwerk an die eigentliche Webanwendung anzupassen. Im Prinzip behebt man alle falsch positiven Ergebnisse.

Wir haben einen anderen Ansatz für einen Kunden implementiert, der immer noch unter False Positives litt. Die meisten Konzepte verwenden eine Blacklist von Zeichen oder Zeichenfolgen, die sie herausfiltern oder blockieren. Es ist aber auch möglich, einen Whitelist-Ansatz zu implementieren, der definiert, welche Zeichen für jedes Eingabefeld gültig sind.

In diesem speziellen Kundenfall wird beim Software-Build auch der Whitelist-Regelsatz für ModSecurity erstellt: Das Entwicklungsteam erstellt eine Definitionsdatei mit Software-Endpunkten, Parametern und Eingabetypen. Während des Builds übersetzt ein Tool dies in reguläre Ausdrücke für ModSecurity, um nur sichere Daten durch die WAF passieren zu lassen.

Ein solcher Whitelist-Regelsatz könnte wie folgt aussehen:

SecRule REQUEST_HEADERS:Host "^[\d\.]+$" "id:1000001,log,deny,msg:'BLOCK: Host header must not be a IPv4 address'"
SecRule REQUEST_HEADERS:Host "^[0-9a-f]{1,4}:" "id:1000002,log,deny,msg:'BLOCK: Host header must not be a IPv6 address'"

# Validate filename
SecRule REQUEST_FILENAME "!^[-./_A-Za-z0-9]{1,100}$" "id:1000003,log,deny,msg:'BLOCK: Malformed filename request'"

# Validate stores
SecRule REQUEST_FILENAME "!(^/endpoint1)" "id:1000004,log,deny,msg:'BLOCK: Store not allowed'"

# Validate URL /endpoint1
SecRule REQUEST_URI "@beginsWith /endpoint1" "id:1000005,nolog,noauditlog,setvar:tx.store=0"
SecRule TX:STORE "@eq 0" "id:1000006,chain,deny,msg:'BLOCK: Request method not allowed.'"
  SecRule REQUEST_METHOD "!^POST$" "log,t:urlDecode"
SecRule TX:STORE "@eq 0" "id:1000007,chain,deny,msg:'BLOCK: Argument not allowed on /endpoint1'"
  SecRule ARGS_NAMES "!^cid|msg$" "log,t:urlDecode"
SecRule TX:STORE "@eq 0" "id:1000008,chain,deny,msg:'BLOCK: Invalid parameter cid on /endpoint1'"
  SecRule ARGS:cid "!(^$|^[0-9]+$)" "log,t:urlDecode"
SecRule TX:STORE "@eq 0" "id:1000009,chain,deny,msg:'BLOCK: Invalid parameter msg on /endpoint1'"
  SecRule ARGS:msg "!(^$|^[a-zA-Z]+$)" "log,t:urlDecode"

Der obige Beispielregelsatz prüft auf die folgenden Kriterien:

• Der HTTP-Host-Header darf keine IPv4- oder IPv6-Adresse sein
• Der URL-Endpunkt darf nur alphanumerische und bestimmte Sonderzeichen enthalten.
• Nur der URL-Endpunkt /endpoint1 ist zulässig
• Es ist nur die Methode POST zulässig.
• Es sind nur die beiden Parameter" %} cid und msg erlaubt.
• Der Parameter cid darf nur Zahlen enthalten.
• Der Parameter msg darf nur Klein- und Großbuchstaben enthalten.

• ModSecurity
• WAF
• Web Application Firewall