© arfo, Fotolia.com

Auch sicher konfigurierte und aktuell gehaltene Webserver sind durch Schwachstellen in einer Webapplikation kompromittierbar. Modsecurity ist eine Apache-Erweiterung, die als Web Application Firewall den Webserver vor Einbrüchen schützt .

Sicherheitsprobleme im Web beruhen in der Regel nicht mehr auf der Konfiguration oder der Aktualität ihrer Serversoftware. Tomcat, Apache und selbst der IIS haben in den letzten Jahren eine hohe Reife erzielt, sodass sie kaum über nennenswerte Schwachstellen verfügen – wenn auch Ausnahmen die Regel bestätigen. Diese Entwicklung bringt die Angreifer dazu, ihr Interesse auf die dort laufenden Webapplikationen und Skripte zu richten.

Immer neue Nutzeranforderungen machen Webapplikationen komplexer: Ajax, Interaktion mit externen Datenbanken, Backend-Schnittstellen und Verzeichnisdienste gehören schon zum Standardumfang einer modernen Anwendung. Mit dieser Entwicklung wächst die mögliche Angriffsfläche (siehe Kasten “Attacken auf Webserver”).

Schutzwall fürs Web

Web Application Firewalls (WAFs) untersuchen Daten im Gegensatz zu klassischen Paketfiltern nicht auf der Netzwerk- oder Transportschicht, sondern auf Ebene des HTTP-Protokolls, also auf der OSI-Schicht 7 [1]. Sie verstehen das HTTP-Protokoll selbst. Dazu analysieren sie ein- und ausgehende Clientanfragen und Serverantworten, um auf Basis von Regeln zwischen gutartigen sowie bösartigen Anfragen zu unterscheiden. Gegebenenfalls ergreifen sie sogar Gegenmaßnahmen. Bei entsprechender Konfiguration untersucht die Software selbst verschlüsselte HTTPS-Verbindungen.

Jede Menge Zubehör

Während klassische Netzwerk-basierte Firewalls – überspitzt formuliert – entweder jede oder keine HTTP-Verbindung erlauben, so filtern WAFs also gezielt einzelne HTTP-Verbindungen auf Basis ihres Inhalts. Eine leistungsfähige Web Application Firewall für den Apache ist Modsecurity, ein komplexes Modul für den Apache Webserver, das ursprünglich Ivan Ristic entwickelt hat. Inzwischen kümmert sich das Unternehmen Breach Security um den Vertrieb und die weitere Entwicklung [2].

Die Software ist in zwei Varianten verfügbar. Zum einen gibt es eine Open-Source-Variante unter der GPLv2, außerdem eine kommerzielle Variante mit professionellem Support, vorkonfigurierten Appliances und Management-Konsolen. Modsecurity läuft unter Linux, Solaris, Free BSD, Open BSD, Net BSD, AIX und Windows, wobei die neueren Versionen jedoch nur für Apache 2.x verfügbar sind. Dieser Artikel beschreibt die Version 2.5.10, der nach Redaktionsschluss erschienene Nachfolger 2.5.11 enthält aber auch nur Bugfixes.

Der Funktionsumfang der Software ist enorm, aber umfassend dokumentiert [3]: Sie protokolliert HTTP-Anfragen und ermöglicht Admins feinen Zugriff auf einzelne Elemente einer Anfrage, etwa den Inhalt einer »POST«-Anfrage, detektiert in Echtzeit Angriffe auf Basis von positiven oder negativen Sicherheitsmodellen und erkennt Anomalien durch mitgelieferte Muster bekannter Schwachstellen.

Die mächtigen Regeln erkunden, ob sich Kreditkarten im Datenstrom befinden, oder verwehren mittels Geo IP Zugriffe aus bestimmten Regionen. Modsecurity prüft nicht nur eingehende Anfragen, sondern auch ausgehende Antworten des Servers. Die Software ist in der Lage, Chroot-Umgebungen zu implementieren. Als Reverse Proxy schützt er auch Webapplikationen auf anderen Webservern wie einem Tomcat oder IIS.

Breach liefert zudem zahlreicher Kernregeln mit, die den Grundschutz des Webservers gewährleisten. Umfangreiche Dokumentation, viele Beispiele und eine Mailingliste unterstützen die Benutzer. Modsecurity ist also ein geeignetes Mittel, um Webserver und ihre Anwendungen vor Schwachstellen zu schützen. Vor die mitunter sehr komplexe Konfiguration haben die Götter jedoch die Installation des Drittanbietermoduls gesetzt.

Pakete für jede Distribution

Wer das Paket für den Apache 2 nicht selbst übersetzen will, findet fertige Pakete für Debian, RHEL, Centos, Fedora, Free BSD, Gentoo und Windows. Voraussetzung für die manuelle Installation ist das Apache-Modul »mod_unique_id«, das nicht jede Distribution von Haus aus mitbringt. Der Admin bindet mit der Direktive »LoadModule security2_module modules/mod_security2.so« das Modul in die Konfigurationsdatei »httpd.conf« des Apache ein, wenn das nicht die Distribution selbst erledigt. Nach dem Neustart meldet der Webserver das Modul in seinem »error_log«.

Modsecurity kennt eine Fülle von Konfigurationsoptionen. Um seine Funktionsweise nachzuvollziehen, reicht aber bereits eine Grundkonfiguration. Die Option »SecRuleEngine« aktiviert den eigentlichen Filtermechanismus des Moduls und erlaubt Filterregeln abzuarbeiten. Mögliche Einstellungen sind neben »On« und »Off« noch »DetectionOnly«. Sie dient zur Beobachtung und sorgt dafür, dass das Modul nicht aktiv in eine Client-Server-Verbindung eingreift, selbst wenn einzelne Regeln so konfiguriert sind. Dies ist eine gute Einstellung, um das Modul und eigene Regeln zu testen.

Gerade am Anfang und zur Fehlersuche ist die Option »SecDebugLog« wichtig, da sie die Protokolldatei zur Fehlersuche festlegt, zum Beispiel mittels »SecDebugLog /var/log/httpd/modsec_debug.log«. Zusätzlich lässt sich mit dem Parameter »SecDebugLogLevel« die Detailfülle auf einer Skala von 0 bis 9 definieren, mit der das Modul die eigene Tätigkeit sowie die Verarbeitung der benutzerdefinierten Regeln kommentiert. Die Stufen 4 oder 5 eignen sich fürs Fine-Tuning oder zur Fehlersuche, im Produktivbetrieb stellt der Admin die Option wieder auf 0.

In fünf Stufen zur sicheren Anfrageverarbeitung

Der Parameter »SecDefaultAction« definiert das Standardverhalten von Modsecurity bei Anfragen, die auf eine vorhandene Filterregel zutreffen, für die der Systemverwalter aber keine eigene Aktion spezifiziert. Dazu erwartet die Option, dass der Anwender eine Verarbeitungsphase aus Tabelle 1 angibt, für die die Standardaktion gelten soll.

Modsecurity wendet Filterregeln in fünf verschiedenen Phasen der Verarbeitung und Beantwortung einer Clientanfrage an [4]. In der Praxis sind meist nur Phase 2, die Inhalte einer Clientanfrage filtert, also eingehende Daten, sowie Phase 4 relevant: Die kümmert sich um die Serverantwort, also um ausgehende Daten.

Zusätzlich legt der Admin mit der Option eine oder mehrere Aktionen fest, die die Software bei einem Match ergreift [5]. Um eingehende Clientanfragen in Phase 2 im Auditlog zu protokollieren und den versuchten Zugriff mit der HTTP-Fehlermeldung 403 (“Forbidden”) zu unterbinden, notiert der Admin:

SecDefaultAction phase:2,log,auditlog,deny,status:403

Eine so negative Standardaktion wie Default Deny ist zwar sehr restriktiv, bietet aber größtmöglichen Schutz, wenn der Systemverwalter darüber hinaus geeignete Filter und Aktionen verfasst (siehe dazu den Leser-Aufruf im Kasten “Web-Experten gesucht!”). Dafür bietet die Software eine Reihe von vorgefertigten Alternativen an. Dazu zählen, Anfrageparameter umwandeln, externe Skripte etwa für einen Antiviren-Scan ausführen oder aber bösartige Anfragen weiterleiten. Letzteres dient dazu, die Angriffsversuche zu verstehen oder an einen Honeypot zu übergeben.

Die in Listing 1 vorgestellte Grundkonfiguration protokolliert außerdem den Inhalt eingegangener Anfragen sowie der gesendeten Antworten. Sie trägt die Informationen im erwähnten Auditlog ein. Die erste Direktive »SecAuditEngine« schaltet es ein. Die Option der zweiten Anweisung bestimmt, ob die Software die Einträge im Auditlog wie hier in einer Gesamtdatei (»Serial«) oder in jeweils einer Datei pro Transaktion speichert (»Concurrent«). Letzteres ist notwendig, wenn der Admin das Zusatzprodukt Modsecurity Console verwenden will: Die Software zum Steuern mehrerer Instanzen bietet Breach Security kostenlos an, wenn Anwender damit nicht mehr als drei Server überwachen.

01 SecRuleEngine On
02 SecAuditEngine On
03 SecAuditLogType Serial
04 SecAuditLog logs/audit.log
05 SecAuditLogParts ABCFHZ
06 SecDebugLog logs/debug.log
07 SecDebugLogLevel 5
08 SecRule REQUEST_URI "/etc/passwd"
09 SecDefaultAction phase:2,log,auditlog,deny,status:403

Die dritte Anweisung definiert den Speicherort des Auditlog relativ zum Installationspfad des Apache. Schließlich wählt die Anweisung »SecAuditLogParts« aus, welche Informationen Modsecurity im Auditlog protokolliert (siehe Tabelle 2). In diesem Fall sind das unter anderem Kopfteil und Inhalt der Anfrage sowie die Reaktion von Modsecurity. Das spätere Ergebnis zeigt Abbildung 1.

Abbildung 1: Sobald Modsecurity aktiv ist, loggt es – so detailliert wie in »SecAuditParts« angegeben – verdächtige Zugriffe, in diesem Fall eine SQL Injection.

Regeln festlegen

Nach diesen Vorbereitungen ergänzt der Admin seine Konfiguration durch die wichtigste Anweisung: »SecRule«. Sie definiert eine Filterregel und optional eine Aktion, die das Modul bei einer Übereinstimmung mit der Regel anstoßen soll. Notiert der Systemverwalter keine Aktion, führt das Tool die durch die Anweisung »SecDefaultAction« festgelegten Standardbefehl aus. Der Aufbau solcher Regeln folgt dem Muster:

SecRule Variable Operator [Aktion]

Die Anzahl der verfügbaren Variablen ist groß und umfasst auch alle Elemente einer Clientanfrage – sowohl bei »POST« als auch bei »GET« – sowie die wichtigsten Angaben zur Serverumgebung [6]. Zusätzlich darf der Anwender reguläre Ausdrücke verwenden. Um beispielsweise eine HTTP-Anfrage daraufhin zu untersuchen, ob der Client in ihr mittels der »GET«-Methode die Zeichenkette »/etc/passwd« anfragt, verfasst der Systemverwalter die Regel:

SecRule REQUEST_URI "/etc/passwd"

Trifft sie zu, löst Modsecurity die Standardaktion »deny« aus. Um per Filter auf einen Browsertyp zu prüfen, schreibt der Admin:

SecRule REQUEST_HEADERS:User-Agent "nikto"

Bei diesem Beispiel lehnt der Webserver Anfragen des Sicherheitsscanners Nikto ab [7]. Soll Modsecurity eine besondere Aktion für eine Regel auslösen, so lässt sich die Standardaktion überschreiben:

SecRule REQUEST_HEADERS:User-Agent "nikto" "phase:2,pass,msg:'Nikto-Scan geloggt'"

Diese Regel bedeutet, dass das Modul bei Anfragen des User-Agenten Nikto in einer Clientanfrage in Phase 2 die Nachricht »Nikto-Scan geloggt« in die Protokolldatei schreibt. Anschließend überschreibt die Regel die Standardaktion »drop« – definiert durch »SecDefaultAction« – durch die Aktion »pass«. Das lässt die Clientanfrage passieren. Um Modsecurity zu testen, fasst Listing 1 die vorgestellte Grundkonfiguration zusammen.

Den Ernstfall proben

Nach einem Neustart des Apache löst eine Anfrage wie »http://www.example.com/index.html?file=/etc/passwd« die Beispielregel aus Zeile 8 aus. Anschließend unterbindet die in Zeile 9 festgelegte Aktion die Anfrage. Der Client erhält einen HTTP-Error »403 Forbidden«. Zusätzlich schreibt Modsecurity wegen der Zeilen 3 bis 7 ein Protokoll der Transaktion ins Auditlog sowie eine detaillierte Übersicht über die Abarbeitung der Clientanfrage in das Debuglog. So findet der Admin in der Datei »error_log« des Apache dann einen Hinweis wie in Listing 2 auf das erfolgreiche Blockieren der Clientanfrage. Funktioniert Modsecurity wie erwartet, gilt es, Regeln zu ergänzen und der zu schützenden Webapplikation anzupassen.

01 LoadModule geoip_module modules/mod_geoip.so
02 LoadModule security2_module modules/mod_security2.so
03 GeoIPEnable On
04 GeoIPDBFile /usr/tmp/GeoLiteCity.dat
05 SecRuleEngine On
06 SecGeoLookupDb /usr/tmp/GeoLiteCity.dat
07 SecRule REMOTE_ADDR "@geoLookup" "chain,drop,msg:'Verbindungsversuch aus .CN!'"
08 SecRule GEO:COUNTRY_CODE "@streq CN" "t:none"

Kunst, Angriffe zu erkennen

Um effektiv vor einer Vielzahl von Angriffen zu schützen, muss der Systemverwalter Modsecurity mit einem starken Regelwerk ausstatten. Um Regeln zu formulieren, die etwa gegen SQL Injection, Cross Site Scripting oder Local und Remote File Inclusion schützen, sind umfassende Kenntnisse über den Ablauf und den Aufbau von Angriffen auf Webapplikationen notwendig.

Da nicht jeder Administrator über ein solches Wissen verfügt – und auch nicht unbedingt die Zeit hat, das Rad immer wieder neu zu erfinden – bietet unter anderem das Open Web Application Security Project (OWASP) einen vorgefertigten Regelsatz für Modsecurity an [8]. Er schützt auf Basis von Anomalie-Erkennung gegen viele Standardangriffe, darunter das Senden ungültiger Clientanfragen, SQL Injection, Cross Site Scripting, E-Mail- oder Command-Injection. Das alles bietet schon einen guten Grundschutz, den der Administrator bei Bedarf noch weiter an seine eigene Applikationsumgebung anpasst.

Um diese Core Rules zu installieren, lädt der Admin das Paket herunter und packt es im Konfigurationsverzeichnis »conf« des Apache aus. Die Regeln inklusive Subdirectory »base_rules« legt er ins Verzeichnis »modsecurity«. Er sichtet die Konfiguration in den Dateien »modsecurity_crs_10_global_config.conf« sowie »modsecurity_crs_10_config.conf« und passt sie eigenen Gegebenheiten an. Die Regeln sind in englischer Sprache gut dokumentiert. Zudem empfiehlt es sich, abermals Audit- und Debuglog einzuschalten, um nachzuvollziehen, was das Modul genau macht. Der Admin bindet die Kernregeln in »httpd.conf« ein:

Include conf/modsecurity/*.conf
Include conf/modsecurity/base_rules/*.conf

Nach dem Neustart ist der Indianer mit einer soliden Rüstung ausgestattet, die alle als Angriff klassifizierten Clientanfragen mit einem HTTP 403 ablehnt. Aber Vorsicht: Webmaster sollten die Kernregeln zunächst auf einem Testsystem ausführlich testen, bevor sie diese auf einem Produktionssystem einsetzen. Ansonsten besteht die Gefahr, legitime Benutzeranfragen zu unterbinden. Und schließlich fordert Modsecurity auch einen Tribut von rund fünf Prozent Performance-Einbuße des Webservers.

Angriffe auf die Vereinten Nationen verhindern

Es gibt Situationen, in denen sich eine Schwachstelle in einer Webapplikation nicht unmittelbar beheben lässt. Man stelle sich beispielsweise vor, eine Woche vor Weihnachten erfährt ein großer Onlineshop von einer Sicherheitslücke, die zu beheben mehrere Tage dauern würde. In dieser Zeit wäre der Shop nicht erreichbar. Es ist die unternehmerische Entscheidung, ob Betreiber mit dem Risiko leben und den Shop inklusive Schwachstelle weiterlaufen lassen, um das profitable Weihnachtsgeschäft vollständig mitzunehmen, oder ob sie zum Schutz des Unternehmens und der Kunden die Webseite vom Netz nehmen, um die Sicherheitslücke zu beheben.

Modsecurity bietet eine technische Alternative als vorübergehenden Ausweg aus dieser Zwickmühle. Mit so genanntem Virtual Patching formuliert der Betreiber eine oder mehrere Regeln, die das Ausnutzen der Schwachstelle verhindern, ohne dass er sie selbst entfernt.

Die Dokumentation von Modsecurity berichtet beispielsweise von einem Fall aus dem Jahr 2007, als Angreifer die Website der Vereinten Nationen hackten [9]. Die Unterseite mit den Vorträgen des Generalsekretärs Ban Ki-moon [10] mit dem Parameter »statID« hatte eine SQL-Injection-Schwachstelle (Abbildung 2).

Abbildung 2: Die Website des UN-Generalsekretärs Ban Ki-moon hatte eine Schwachstelle mit einer nicht hinreichend geprüften Parametervariablen. Bis die Systemverwalter der UN das Problem behoben hatten, schützte eine Modsecurity-Regel per Virtual Patching temporär die Website.

Wenn der Webmaster von einer derartigen Schwachstelle weiß, formuliert er temporär eine Regel für Modsecurity, die das Ausnutzen der Schwachstelle unmöglich macht, ohne sie zu beseitigen. Dies ist dauerhaft natürlich keine gute Lösung, verhindert aber zunächst Schlimmeres, bis die Webentwickler die Schwachstelle aus dem Quellcode der Seite entfernen.

Für die Webseite der UN wäre etwa folgende Lösung denkbar:

<Location /apps/news/infocus/sgspeeches/statments_full.asp>
SecRule &ARGS "!@eq 1"
SecRule ARGS_NAMES "!^statid$"
SecRule ARGS:statID "!^d{1,3}$"
</Location>

Eingebettet in einen Location-Container des Apache bewirken die drei Zeilen, dass eine gültige Benutzeranfrage für die Datei »statements_full.asp« nur ein Argument (erste Regel) namens »statid« (zweite Regel) mit ein- bis dreistelligen Zahlen (dritte Regel) als Parameter haben darf. Folgt eine Anfrage nicht diesem Schema, so setzt die Standardaktion ein, definiert durch »SecDefaultAction«. Damit ließe sich die SQL-Injection-Schwachstelle nicht mehr ausnutzen.

Keine Interna ausplaudern

Modsecurity filtert auch ausgehende Daten, insbesondere die Antworten des Servers auf zuvor eingehende Anfragen. Die Programmiersprache PHP erzeugt etwa Fehlermeldungen wie:

Fatal error: Connecting to MySQL server 'dbserv.example.com' failed

Obwohl sich das Senden von PHP-Fehlermeldungen abschalten lässt, finden sich mittels Google eine Menge Webseiten, auf denen PHP-Fehlermeldungen Anwendungsinterna ausposaunen. Solche Informationen sind jedoch für einen Angreifer sehr wertvoll, da sie ihm dabei helfen können, die interne Funktionsweise und den Aufbau einer Webapplikation zu verstehen und diese gezielter anzugreifen. Um Modsecurity zu veranlassen, PHP-Fehlermeldungen abzufangen und nicht an den Benutzer zu schicken, lässt sich folgende Regel verwenden:

SecRule RESPONSE_BODY "Fatal error:"

Die Variable »RESPONSE_BODY« bezeichnet den Inhalt der Antwort des Servers an den Client. Diese Regel ist zwar nicht sehr elegant, verdeutlicht aber das Potenzial. Dennoch: Mit einem gut gemachten regulären Ausdruck lassen sich mit derselben Technik auch Kreditkartennummern abfangen, bevor eine kompromittierte Anwendung sie zum Beispiel nach einem erfolgreichen Angriff per SQL Injection an einen Angreifer sendet.

Chinesische Mauer verkehrt

Eine weitere Möglichkeit der fortgeschrittenen Nutzung von Modsecurity ist das Zusammenspiel mit Geo IP des Anbieters Maxmind. Geo IP lokalisiert einen Nutzer geografisch nach dessen IP-Adresse. Damit lässt sich der Zugriff auf eine Webseite nur auf eine bestimmte Region beschränken – beispielsweise Bayern, wenn es um mundartliche Erörterungen geht, die sowieso sonst niemand versteht – oder der aus einem Land sperren. Dazu installiert der Admin das Modul »mod_geoip2« für den Apache 2 sowie die Software Geo IP inklusive der Geodatenbank »GeoLiteCity.dat« [11].

Wenn schwäbische Maschinenbauer etwa Angst vor Wirtschaftsspionage aus Fernost haben, nutzen sie die Konfiguration aus Listing 3 dazu, um den Zugriffe aus China zu unterbinden – zumindest dann, wenn sich die Chinesen nicht sonderlich anstrengen, um ihre Herkunft zu verschleiern. Die beiden letzten Zeilen bilden eine so genannte verkettete Filterregel. In Zeile 6 lokalisiert sie die geografische Herkunft der anfragenden IP-Adresse. Anschließend verwirft Zeile 7 die Anfrage mit einer entsprechenden Meldung im Logfile, sofern sie aus China kommt. Vielleicht nicht politisch korrekt, aber wirksam.

01 SecAuditLogType Serial [Wed Nov 04 05:39:19 2009] [error] [client 192.168.209.1] ModSecurity: Access denied with code 403 (phase 2). Pattern match"/etc/passwd" at REQUEST_URI. [file "/usr/local/httpd-2.2.14/conf/httpd.conf"] [line "420"] [hostname "www.example.com"] [uri "/index.html"] [unique_id "SvFZ138AAQEAAAc4AgQAAAAA"]

Vollkaskoversichert

Modsecurity hat eine hohe Funktionsvielfalt und bedarf einer umfassenden Konfiguration. Die Mühe, das Modul genauer unter die Lupe zu nehmen, dankt es mit umfassenden Methoden, die einen zusätzlichen Schutz gegen Angriffe auf Webapplikationen bieten. Glücklicherweise gibt es eine Reihe von Regelsätzen, die dem Admin den Einstieg erleichtern. Darüber hinaus bietet der das Projekt betreuende Hersteller kommerzielle Produkte und Dienstleistungen wie zum Beispiel Training an. So ausgerüstet lässt sich kein Admin aus dem Sattel heben, selbst von denen nicht, die etwas im Schilde führen. (mg)