Mein Kollege Andrea Covello war in seinem Labs Post schon auf die Open-Source WAF NAXSI eingegangen. Unter anderem hat er die Vorteile gegenüber ModSecurity kurz hervorgehoben. Auch die Gründe, warum man eine Web Application Firewall (WAF) einsetzten sollte, wurde da erläutert. In meinem heutigen Labs Post möchte ich einen Überblick über die wohl noch immer noch am weitesten verbreitete Open Source Web Application Firewall eingehen.

Security Models

ModSecurity unterstützt den Einsatz von verschiedenen Sicherheitsmodellen:

• Negative Security Model
• Positive Security Model
• Virtual Patching
• Extrusion Detection Model

Wobei die drei erstgenannten die HTTP-Anfrage inspizieren und gegebenenfalls bearbeiten, ist das letzte Model für das Inspizieren von ausgehenden HTTP-Antworten zuständig. Gerne gehe ich hier ganz kurz auf die einzelnen Security Modelle ein.

Negative Security Model

Das Negative Security Model basiert auf einer Blacklist. Wie bei anderen Implementationen einer Blacklist, basiert dieses Model auf dem aktuellen Wissenstand über potenzielle Angriffsmöglichkeiten. Was die Blacklist nicht weiss, macht die Blacklist nicht heiss – oder in diesem Falle, lässt die Blacklist gewähren.

Dieses Model sehe ich eher als Einsteiger-Model an. Es reduziert zwar die Angriffsfläche einer Webseite, doch wenn es hart auf hart kommt, könnte dieses Model am ehesten überwunden werden.

Positive Security Model

Das Positive Security Model ist wohl jenes, welches den grössten Aufwand bedarf. Hier wird mit einer Whitelist gearbeitet. Ist die gestellte HTTP-Anfrage in der Whitelist eingetragen, wird sie weitergeleitet. Unbekannte Anfragen werden verworfen.

Nun frage ich Sie: Kennen Sie oder Ihre Web-Entwickler alle erlaubten HTTP-Anfragen? In den meisten Fällen lautet die Antwort auf diese Frage Nein. Und schon ist der Aufwand erkennbar:

• Zuerst wäre da der Initialaufwand, der abhängig ist vom Umfang und der der Komplexität der Webseite
• Danach kommt der sich wiederholende Aufwand wenn Änderungen an der Webseite vorgenommen wurden.

Dieses Model sollte vor allem bei Webseiten mit kritischen Daten (z.B. E-Banking, Webshops usw.) in Betracht gezogen werden.

Virtual Patching

Dieses Model baut auf dem Negative Security Model auf. Wird eine Schwachstelle auf der Webseite entdeckt, sei dies in einem bekannten Framework oder einer Eigenentwicklung, kann eine Regel hinzugefügt werden, welche genau diese adressiert. Ebenfalls haben sich Anbieter wie Trustwave SpiderLabs sich auf das Erstellen von kommerziell vertriebenen Regelwerken spezialisiert, welche periodisch veröffentlicht und im laufenden Betrieb angewendet werden können. Dies erinnert ein wenig an Virenscanner oder IDS/IPS Pattern Updates. Dieser Ansatz ist mitunter interessant, wenn nur Produkte mit Support in der Infrastruktur eingesetzt werden dürfen.

Extrusion Detection Model

Und nun zum letzten der Modelle, dem Extrusion Detection Model. Dies unterscheidet sich von den anderen dadurch, dass die HTTP-Antworten überprüft werden. Hier werden die Antworten nach gewissen Mustern oder Stichworten durchsucht, um einer möglichen Datenexfiltration zuvor zu kommen.

Dies ist sicher ein zusätzliches schönes Feature, doch muss man sagen dass dieses Feature zwar ganz nett ist, doch im Data Leakage Prevention (DLP) Markt nicht sehr oft anzutreffen ist.

Implementation in die Infrastruktur

Wie kann nun ModSecurity in die Infrastruktur implementiert werden? Hier stehen einem grundsätzlich zwei Wege zur Verfügung. Zum einen kann ModSecurity als Reverse Proxy betrieben werden. Auf die Vor- und Nachteile dieser Implementation ist Andrea Covello in dem NAXSI Labs eingegangen. Der Nachteil von ModSecurity in diesem Modus ist das ein Webserver Unterbau gebraucht wird und dadurch die Installation nicht mehr ganz so schlank NAXSI ist.

Die Embedded Implementation unterstützt die Webserver Apache, IIS und NGINX in der aktuellen Version. Und unterstützt somit einen grossen Anteil der im Internet anzutreffenden Webserver. Die Embedded Implementation teilt sich die Ressourcen mit dem Webserver, was bei der Planung mit einberechnet werden muss. Ebenfalls erhöhen sich natürlich die Komplexität und der Aufwand, wenn man eine Webserver-Farm betreibt, da auf jedem der Webserver die gleiche Konfiguration implementiert sein muss.

Natürlich ist auch eine Kombination der beiden Implementationen und Security Modellen denkbar. Ein vorgeschalteter Reverse Proxy mit dem Negative Security Model Ansatz, welcher auch gleichzeitig mehrere Webserver schützen kann und dann die Embedded Implementation mit einem Positive Security Model, um die Sicherheit um eine weitere Stufe zu erhöhen. Der betriebliche Aufwand bei einer solchen Implementation ist natürlich erhöht. Aber bei Webseiten, welche sehr sensitive Daten (z.B. E-Banking, Bewerbungs-Plattform) zur Verfügung stellen, sollte dieser Ansatz auf alle Fälle in Erwägung gezogen werden.

Ich will starten! Aber wie?

Die Anlaufstelle Nummer Eins ist ganz klar die Webseite von ModSecurity selbst. Nebst der Software und dem frei verfügbaren OWASP ModSecurity Core Rule Set (CRS) gibt es eine grosse Anzahl an Informationen rund um ModSecurity. Seien dies Dokumentationen, empfohlene Bücher oder Links zu Mailing Lists, es hat für jeden was dabei. Die folgenden zwei Ressourcen möchte ich aber besonders hervorheben, da ich sie gerade für Einsteiger in das Thema als sehr nützlich erachte.

• Vertrauen ist gut, Kontrolle ist besser: Die Webseite stellt einen Demo-Bereich zur Verfügung, welcher meistens durch die aktuellste Version von ModSecurity geschützt wird. Hier kann man seinem Können im Bereich HTML-Injection, Cross Site Scripting und SQL Injection freien Lauf lassen und der Software ein erstes Mal auf den Zahn fühlen. Als besonderes Goodie werden die Versuche protokolliert und auf der Webseite selbst allen Benutzern zur Verfügung gestellt.

• Der Berg ist zu steil! Gibt es eine Seilbahn? Vor allem wenn man sich für den Positive Security Ansatz entscheidet, steht man Anfangs vor einem grossen Berg an Arbeit. Jede legitime Anfrage muss erkannt und in das Regelwerk aufgenommen werden. REMO ist eine in der Schweiz entwickelte Software, welche einem hilft, die Anfragen an den Webserver zu analysieren und zusätzlich die Möglichkeit bietet, Regeln on-the-fly zu erstellen. Es ist zwar nicht gerade die _Seilbahn_-Lösung, doch unterstütz sie einem erheblichen Mass.

Fazit

Die Sicherheit einer Webseite sollte nie komplett einer Web Application Firewall überlassen werden. Mit anderen Worten: Eine WAF ersetzt nicht die sichere Programmierung einer Webseite. Eine serverseitige Eingabevalidierung gilt heute nicht nur als nice-to-have sondern als ein absolutes must have und gehört zum Glück immer öfters zum Standard eines Webauftritts.

Leider können auch solche Validierungsfilter Lücken aufweisen, wo dann eine WAF eine zusätzliche Sicherheitsmassnahme darstellt. Dass man die WAF als vorgeschalteter Reverse Proxy oder als Modul innerhalb des Webserver Prozesses laufen lassen kann, ist ein weiteres Plus für ModSecurity. Auch die Möglichkeit, beide Methoden zeitgleich einzusetzen, um so die Stärken der jeweiligen Implementation zu nutzen, erachte ich als eine sehr gute Möglichkeit, die Sicherheit der Webserver auf die nächste Stufe zu bringen.

Links

• http://www.modsecurity.org/
• http://www.modsecurity.org/demo/crs-demo.html
• http://www.netnea.com/cms/?q=remo
• https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
• https://www.trustwave.com/spiderlabs/