Core Rule Set als Teil von DevOps (CI Pipeline) – Teil 1

Oft wird befürchtet, dass eine Web Application Firewall (WAF) nicht in die DevOps Methodik passt. Wenn die WAF erst in der Produktion implementiert wird, kann dies Probleme verursachen, weil die Auswirkungen auf eine Applikation zu spät getestet werden. Die WAF kann den reibungslosen Zugriff auf eine Applikation verhindern und zu Störungen führen.

Aber was wäre, wenn die Entwickler früh im Prozess Feedback erhalten würden?

Der gesamte DevOps Prozess macht nur dann Sinn, wenn alle Komponenten Teil davon sind! Eine Webapplikation kann erst erfolgreich durch eine WAF ergänzt werden, wenn die WAF von Anfang an Teil der Pipeline ist. Deshalb möchte ich anhand eines Beispiels mit ModSecurity und dem Core Rule Set (CRS) aufzeigen, wie die Integration einer WAF mit DevOps funktioniert. Auch das Einbinden von Tests in Continuous Integration (CI) soll Teil dieses Blogposts sein.

Die drei Hauptziele dieses Blogposts sind:

– Das Core Rule Set bekannt machen
– Die Bedenken vor WAFs nehmen
– Wie WAFs in DevOps eingebunden werden

Das Problem

Trotz der Tatsache, dass die Anzahl der False Positives in CRS3 massiv reduziert wurden, besteht immer noch die Möglichkeit, dass legitime Anfragen von einem Nutzer eine CRS-Regel triggern. Der Benutzer erhält eine ‚403 – Forbidden‘ Meldung und kann nicht mehr auf eine Anwendung zugreifen. Er oder sie wird von der WAF ausgesperrt.

Dieses Problem verschlimmert sich mit DevOps noch zusätzlich. Alle Komponenten sind automatisiert und getestet. Wenn wir erst am Ende des Prozesses eine WAF hinzufügen, also in der Produktion, führt dies in den meisten Fällen zu unerwünschten Effekten. Wenn Produktionsprobleme auftauchen, ist es oft zu spät die Probleme zu finden und zu beheben. Es ist wahrscheinlicher, dass der Betreiber die WAF deaktiviert und diese dann nie wieder zum Einsatz kommt. Security hat leider nicht immer die nötige Priorität. Doch dieses Problem ist definitiv lösbar.

Die Lösung

Die Lösung besteht darin, die WAF / CRS sehr früh in den DevOps Prozess einzubinden und den Entwicklern und Betreibern frühzeitig Feedback zu geben:

• Beim Automatisieren von Anwendungstests muss das CRS den Tests hinzugefügt werden. Alle Tests müssen zuerst ohne, dann mit dem CRS erfolgreich sein. Ausserdem sollte durch die Tests keine CRS-Regel getriggert werden.
• Jeder Commit des Anwendungscodes in das Repository löst einen Continuous Integration Workflow aus. Dadurch werden die Anwendung und die WAF gestartet und die Anwendungstests ausgeführt. Mit jedem Commit erfolgt ein Test der Anwendung mit dem CRS.
• Die Anwendung soll sich mit dem CRS immer in einem einsatz- und lauffähigen Zustand befinden. Auf diese Weise ist sichergestellt, dass der Traffic unserer aktuellen App-Version nicht durch das CRS blockiert wird.
• Mit dem Testen von Anwendung und CRS in einer produktionsähnlichen Umgebung ist dieser Zustand gewährleistet. Es kann immer False Positives geben, diese können jedoch mit den entsprechenden Konfigurationsanpassungen ausgemerzt werden. Durch diese laufenden Anpassungen während der Entwicklung entsteht bereits eine Konfiguration für die Produktion, da die Testung in einer produktionsähnlichen Umgebung erfolgt.
• Die Anwendung sollte erst dann freigegeben werden, wenn sie vollständig mit dem CRS getestet wurde. Fehler in der Anwendung müssen vor der Produktivsetzung behoben werden. Bei jedem False Positive ist die Entscheidung zu fällen, ob ein Fix in der Anwendung oder dem CRS nötig ist.

Auf diese Weise wird der Datenverkehr der Anwendung laufend mit dem CRS getestet. In der Produktion sind somit kaum Probleme zu befürchten.

CRS Docker Container

Die Installation des Core Rule Sets benötigt nur wenige Schritte (siehe hierzu: https://coreruleset.org/installation). Mit einem Docker Container wird es sogar noch einfacher.

Ich habe ein Docker Image erstellt, welches ein Fork des offiziellen OWASP ModSecurity Core Rule Set Containers ist (https://hub.docker.com/r/owasp/modsecurity-crs/). Das Image fügt eine Apache Reverse-Proxy Konfiguration hinzu. Diese stellt das CRS vor eine Applikation und es werden auch einige weitere CRS-Variablen hinzugefügt. Der CRS-Container ist unter https://hub.docker.com/r/franbuehler/modsecurity-crs-rp/ zu finden. Auf diese Weise ist eine Integration des CRS in automatisierte Tests sehr schnell und einfach.

Folgender Befehl startet den CRS Docker Container:

docker run -dt --name apachecrsrp -e PARANOIA=1 -e \
ANOMALYIN=5 -e ANOMALYOUT=4 -e BACKEND=http://172.17.0.1:8000 \
-e PORT=8001 --expose 8001 franbuehler/modsecurity-crs-rp

Unter anderem sind folgende CRS Umgebungsvariablen konfigurierbar:

• PARANOIA: paranoia_level
• ANOMALYIN: inbound_anomaly_score_threshold
• ANOMALYOUT: outbound_anomaly_score_threshold
• BACKEND: IP address and TCP port of application backend
• PORT: listening TCP port of Apache, this port must also be exposed: --expose

Erläuterungen zu den einzelnen Parametern sind in der Hauptkonfigurationsdatei crs-setup.conf zu finden (aktuelle Version: https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.0/master/crs-setup.conf.example) oder im Rahmen der Tutorialreihe über ModSecurity und CRS bei netnea.

Wie die technische Umsetzung bei der Einbindung des CRS in eine CI Pipeline funktioniert, folgt in einem zweiten Teil der Blogpost-Serie.