ModSecurity - An Open-Source WAF

ModSecurity

An Open-Source WAF

Pascal Schaufelberger
von Pascal Schaufelberger
Lesezeit: 8 Minuten

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:

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:

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.

ModSecurity als Reverse Proxy oder als Embedded Implementation

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.

ModSecurity als Dual Implementation

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.

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.

Über den Autor

Pascal Schaufelberger

Pascal Schaufelberger ist seit 2003 im Bereich der Informationssicherheit tätig. Seine Schwerpunkte liegen im Engineering, wobei er sich hauptsächlich im Bereich OS-Security, Remote Access, Firewalling und Virtualisierung bewegt.

Links

Sie wollen die Sicherheit Ihrer Firewall prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×
Crypto-Malware

Crypto-Malware

Ahmet Hrnjadovic

TIBER-EU Framework

TIBER-EU Framework

Dominik Altermatt

Vertrauen und KI

Vertrauen und KI

Marisa Tschopp

Datenverschlüsselung in der Cloud

Datenverschlüsselung in der Cloud

Tomaso Vasella

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv