© ADAC

Webapplikationen sind meist beinahe schutzlos den Widrigkeiten des WWW ausgesetzt. Enthalten sie Fehler, hat das fatale Folgen. Das Apache-Modul Modsecurity schafft eine zusätzliche Knautschzone.

Die Hauptaufgabe vieler Webserver besteht darin, dynamische, von Skripten generierte Inhalte zuverlässig auszuliefern. Die Interaktion zwischen Besucher und Webanwendung ermöglicht es Angreifern, diese Applikationen zu missbrauchen, um Aktionen auszuführen, die nicht im Sinne des Erfinders respektive Webmasters sind. Der mögliche Schaden reicht von der Anzeige vertraulicher Inhalte aus Datenbanken und Dateien auf dem Server bis hin zur völligen Kontrolle des Rechners.

Eine sinnvolle Abwehr bieten per se nur sauber programmierte Webanwendungen, die potenzielle Missbräuche ausschließen. Ein schwieriges Unterfangen, dem selbst alte Programmierhasen nicht immer gewachsen sind, wie diverse Sicherheitslücken in etablierten Webapplikationen belegen.

Als Kontroll- und Schutzinstanz (Abbildung 1) setzt hier Modsecurity [1] an. Dabei handelt es sich um eine Web Application Firewall, die als Apache-Modul, aber auch als Stand-alone-Version verfügbar ist (GPL). Das Modul kontrolliert alle eingehenden Anfragen vor der Übergabe an die jeweiligen Skripte nach jenen Regeln, die das Rule-Set vorgibt. Diese bestehen ähnlich wie die Pattern-Files von Virenscannern aus den Signaturen typischer Angriffstechniken.

Abbildung 1: Die Darstellung zeigt, dass Modsecurity den Webserver und die darauf gehosteten Webanwendungen als vorgelagerte Instanz schützt und Übergriffe verhindert.

Stimmt eine Anfrage mit diesen Singnaturen überein, treten die in den Aktionsregeln festgelegten Mechanismen in Kraft. Dazu gehören unter anderem das Blockieren der entsprechenden Anfrage oder das Umleiten auf andere Webseiten. Angriffstechniken, vor denen das Modul wirkungsvoll schützt, sind OS-Command-Injections (Ausführen von Systembefehlen), XSS/Cross-Site-Skripting-Angriffe und SQL-Injections (Ausführen eingeschleuster SQL-Statements).

Ab der Apache-Version 2 ist auch das nahezu beliebige Filtern des ausgelieferten Inhalts möglich. Kommerziellen technischen Support bieten die Betreiber des Projekts über ihre Webseite [1] an.

Hört, was kommt von draußen rein

Gefährlich für Webserver und somit relevant für den Administrator sind in erster Linie OS-Command-Injections, die Systembefehle im Rechtekontext des Webservers ausführen. Das Webstatistik-Tool Awstats beispielsweise erlaubte im Januar 2005 versehentlich das Ausführen beliebiger Befehle. Der String »awstats.pl?configdir=|echo;echo;ls%20-la%20%2F;id;echo;echo« führte das Kommando »ls -la« auf dem Apache Webserver aus.

Ähnlich fatal ist das Auslesen vertraulicher Informationen aus der Datenbank des Webservers. Der im Juni 2005 veröffentlichte Exploit gegen das weit verbreitete CMS Mambo übergibt in der URL SQL-Statements und veranlasst die Webapplikation dazu, die Liste der Passworthashes aller Benutzer anzuzeigen [7]. Das ermöglicht es dem Angreifer, die Kennwörter der Benutzer zu ermitteln, zum Beispiel mit Hilfe von Rainbow-Tables (vorberechnete Hashtabellen zum Knacken von Passwörtern). Folgende URL zeigt die Passworteinträge an:

http://server/mambo/index.php?option=com_content&task=vote&id=%d&Itemid=%d&cid=1&user_rating=1,rating_count=(SELECT/**/i
f((ascii(substring((SELECT/**/password/**/FROM/**/mos_users/**/WHERE/**/id=%d),%d,1)))%s,1145711457,0))[...]

Das in diesem langen String eingebettete SQL-Statement lautet: »SELECT FROM mos_user WHERE id=User-ID«. Die Modesecurity-Regel »SecFilterSelective ARGS “select.+from”« fängt diesen Angriff ab, indem sie die Strings »select« und »from« als Angriffsmerkmale erkennt. Die Attacke läuft daher ins Leere (Abbildung 2), der Angreifer bekommt lediglich die 403-Fehlermeldung des Apache »Forbidden: You don\’t have permission to access« zu Gesicht.

Abbildung 2: Das Apache-Modul Modsecurity wehrt im vorliegenden Beispiel eine SQL-Injection-Attacke erfolgreich ab und vermerkt den Angriff im »error.log« des Webservers.

Der normale Internetsurfer ist eher durch Cross-Site-Scripting-Angriffe bedroht. Dabei versucht der Angreifer auf dem Rechner seines Opfers bösartige Skripte auszuführen, um so beispielsweise an dessen Cookies zu gelangen. Daher ist es sinnvoll, »<script>«-Befehle aus »GET«- und »POST«-Requests zu filtern. Da die Entwicklung recht schnell voranschreitet, sollte jeder Administrator, der plant Modsecurity einzusetzen, regelmäßig die Homepage des Modsecurity-Autors [1] besuchen. Dort stehen Hinweise zu Neuerungen, beispielsweise zum Modsecurity-Rule-Sets-Projekt [2].

Für die meisten Distributionen stehen fertige Binärpakete zum Download bereit. Unter Debian bringt der Befehl »aptitude install libapache2-mod-security« das Paket auf die Festplatte, auf FreeBSD erledigt das »pkg_add -r mod_security«. Danach aktiviert der Aufruf »a2enmod mod-security« unter Debian das Modul, FreeBSD erledigt das von selbst. Der Artikel stützt sich auf Modsecurity 1.9.2, die meisten Funktionen enthält aber auch die weit verbreitete Version 1.8.7.

Erster Test

Der Eintrag »[Fri Feb 24 11:55:12 2006] [notice] mod_security/1.9.2 configured« im »error.log« von Apache zeigt an, dass das Modul erfolgreich installiert wurde. Um die Funktionsfähigkeit zu testen, genügt ein kleines Regel-Set (Listing 1). Die erste Zeile aktiviert die Filter-Engine, die zweite definiert Aktionen, die dritte prüft den Inhalt auf die darin hinterlegten Strings, in diesem Fall »/bin/sh«. Der Übersicht halber ist es ratsam, Regelwerke in separaten Dateien zu speichern und mittels »include Pfad zur Datei« in die »apache2.conf» einzubinden.

01 SecFilterEngine On
02 SecFilterSignatureAction log,deny,status:500
03 SecFilter /bin/sh "id:1001,rev:2,severity:2,msg:'/bin/sh attack attempt'"
04 # Regel für die Version 1.8:
05 # SecFilter /bin/sh

Die erweiterten Parameter der »SecFilter«-Direktive sind Neuerungen der Version 1.9 und in Version 1.8 noch nicht enthalten. Ebenso ist beim Verwenden der Vorgängerversion die Anweisung »SecFilterSignatureAction« durch »SecFilterDefaultAction« zu ersetzen.

Der Aufruf der URL »http:// Hostname/index.php?a=/bin/sh« über einen Webbrowser überprüft die Testregel. Greift sie, blockiert das Modul den Zugriff und zeigt stattdessen einen »Internal Server Error«. Im »error.log« findet sich dann der Eintrag:

[Fri Feb 24 14:25:12 2006] [error] [client 192.168.0.1] mod_security: Access denied with code 500. Pattern match "/bin/sh" at REQUEST_URI [id "1001"] [rev "2"]
[msg "/bin/sh attack attempt"] [severity "2"] [hostname "192.168.0.20"][uri"/modsec/index.php?a=/bin/sh"]

Um das spätere Auswerten der Logdateien mit Skripten zu vereinfachen, sollte jede Regel eine eindeutige ID besitzen. Tabelle 1 informiert über reservierte Namensbereiche.

Koordiniertes Logging

Die einfachste Logging-Variante ist das Schreiben ins »error.log« des Apache Webservers, was allerdings die spätere Analyse erschwert. Alternativ bietet sich das ausführlichere Audit-Logging an (Abbildung 3). Neu ab Version 1.9 ist die Log-Option New Audit Log Type. Sie ermöglicht unter anderem das Loggen mehrerer Ereignisse in eigene Logdateien, setzt aber das aktive Apache-Modul »mod_unique_id« voraus.

Abbildung 3: Das Audit-Log von Modsecurity zeigt im Detail die Vorgehensweise und näheren Umstände eines Angriffs und gibt dem Admin damit wertvolle Hinweise zum Tatgeschehen.

Darüber hinaus enthalten die Versionen ab 1.9 das so genannte Guardian-Log, das die Logdaten an HTTP-Guardian [3] übergibt. Dieser steuert IPtables- und Paketfilter-Firewalls sowie den IDS-Controller Snortsam [4]. Standardmäßig blockiert HTTP-Guardian Clients, die mehr als 120 Anfragen pro Minute oder mehr als 360 Anfragen in fünf Minuten stellen. Das Programm befindet sich noch im Entwicklungsstadium, funktioniert jedoch und ist gut dokumentiert.

Grundkonfiguration

Als Ausgangsbasis für eigene Anpassungen dient die einfache Grundkonfiguration aus Listing 2, die in ähnlicher Form auf der offiziellen Homepage zu finden ist. Wer das Regelwerk auf einem Produktivsystem testet, sollte potenzielle Regelverstöße vorerst nur loggen, um nicht versehentlich legitime Anfragen zu blockieren. Das erledigt der Eintrag »SecFilterDefaultAction«, dessen Parameter auf »pass,log« zu setzen sind.

01 # Modsecurity aktivieren
02 SecFilterEngine On
03 # Fehlerhafte Anfragen loggen und den Zugriff verweigern
04 SecFilterDefaultAction "deny,log,status:403"
05 # Fehler nur loggen
06 # SecFilterDefaultAction "pass,log"
07 
08 # POST-Daten überprüfen
09 SecFilterScanPOST On
10 
11 # URL-Encoding überprüfen
12 SecFilterCheckURLEncoding On
13 
14 # Unicode-Kodierung überprüfen
15 SecFilterCheckUnicodeEncoding On
16 
17 # Nur Ascii-Zeichen von 1 bis 255 annehmen
18 SecFilterForceByteRange 1 255
19 
20 # Server-Signatur auf ein Minimum
21 SecServerSignature "Apache"
22 
23 # Nur relevante Daten loggen
24 SecAuditEngine RelevantOnly
25 SecAuditLog /var/log/apache2/audit_log
26 
27 # GET- oder HEAD- Anfragen im Body nicht akzeptieren
28 SecFilterSelective REQUEST_METHOD "^(GET|HEAD)$" chain
29 SecFilterSelective HTTP_Content-Length "!^$"
30 
31 # Content-Length muss bei jedem POST-Request mitgesendet werden
32 SecFilterSelective REQUEST_METHOD "^POST$" chain
33 SecFilterSelective HTTP_Content-Length "^$"
34 
35 # Unbekannte Transfer-Encodings verwerfen, Ausnahme GET,
36 # weil es mit einigen Clients zu Problemen kommen kann
37 SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
38 SecFilterSelective HTTP_Content-Type 
39 "!(^application/x-www-form-urlencoded$|^multipart/form-data;)"
40 SecFilterSelective HTTP_Transfer-Encoding "!^$"

Anstelle der 403-Fehlermeldung bei Regelverletzungen erlaubt Modsecurity mit dem Eintrag »SecFilterDefaultAction “deny,log,redirect:http://Zielseite.de”« das Anzeigen beliebiger Adressen oder Webseiten. Filter definieren Suchkriterien, die Modsecurity auf eine HTTP-Anfrage anwendet.

Ein Filter ist immer nach dem Schema »SecFilter Suchkriterium« aufgebaut, ab Version 1.9 verfügt das Modul darüber hinaus über zusätzliche Logparameter. Modsecurity unterscheidet zwischen drei Filtermethoden: einfach (»SecFilter wget«), selektiv (»SecFilterSelective ARGS “union.+select”«) und Output (»SecFilterSelective OUTPUT “Fatal error:” deny,status:500«).

Ein einfacher Filter prüft immer die gesamte HTTP-Anfrage, wogegen der selektive Filter lediglich definierte Teile davon prüft. Output-Filter scannen den Content, den der Webserver ausliefert, und verhindern gegebenenfalls dessen Anzeige. Ein Ausrufezeichen (»!«) invertiert Filterregeln. So greift »SecFilter !html« bei jeder Anfrage, die nicht den String »html« enthält.

Filter

Die einfachste Form einer Filterrichtlinie ist »SecFilter Suchmuster«. Modsecurity durchsucht dann alle GET- und POST-Anfragen nach diesem Muster und leitet bei einer positiven Auswertung die in der Default-Policy eingestellten Maßnahmen ein. Als Suchmuster sind sowohl einfache Begriffe, als auch reguläre Ausdrücke erlaubt. Die Filterregeln werden jedoch nicht direkt auf die Anfragen angewendet, sondern auf eine normalisierte Kopie. Das heißt, speziell (Unicode-)kodierte Zeichen (siehe Kasten “Gefahr durch Unicode”) werden zuerst dekodiert und unnötige »/«-Verschachtelungen aufgelöst. Null-Byte-Angriffe, die gezielt auf Schwachstellen der in C oder C++ geschriebenen Serveranwendungen gerichtet sind, verhindert der Filter »SecFilter hidden«.

Die bisher vorgestellten Suchmuster prüfen jeweils den gesamten HTTP-Request. Damit erhöht sich unter Umständen die Performancelast auf der Maschine mehr als nötig. Der Eintrag »SecFilterSelective Ort Suchmuster Aktion« ermöglicht das Filtern bestimmter Teile. Als Ort sind alle CGI-Variablen erlaubt. Mögliche Werte und deren Handhabung erklärt die online verfügbare Dokumentation. Folgende Anweisung erfasst beispielsweise alle Zugriffe, die nicht aus dem 192.168.0.0/24-Netz kommen: »SecFilterSelective “REMOTE_ADDR|REMOTE_HOST” !192.168.0«.

Modsecurity in Kombination mit Apache 2 kann auch die Ausgabe von Webseiten filtern. Falls es einem Angreifer gelingt, eine SQL-Injection anzubringen, welche die Tabelle »user_password« aus einer Datenbank ausgibt, blockiert »SecFilterSelective OUTPUT “user_password” deny,status:500« die Anzeige. Zuvor ist jedoch das Filtern des Outputs mittels »SecFilterScanOutput On« zu aktivieren. Sie ist per Default deaktiviert – aus gutem Grund: Zum einen steigt der Ressourcenbedarf beträchtlich, da Modsecurity den komplett auszuliefernden Content prüft, zum anderen besteht das erhebliche Risiko, versehentlich auch legitime Inhalte zu filtern.

Gilt es, mehrere Virtual Hosts mit verschiedenen Anforderungsprofilen abzusichern, hilft die Regelvererbung von Modsecurity, die sich verzeichnisweise anwenden lässt. Solche Verzeichnisregeln überstimmen globale Regeln:

<Location /subcontext/>
   SecFilterRemove 1001
</Location>

Dieses Beispiel setzt nur die Regel mit der ID 1001 außer Kraft, alle anderen bleiben aktiv. Das folgende Beispiel bewirkt genau das Gegenteil – es deaktiviert alle übergeordneten Regeln mit Ausnahme von 1002 und 1003:

<Location /subcontext/>
   SecFilterInheritance Off
   SecFilterImport 1002 1003
</Location>

Um das Erstellen von Regelwerken zu vereinfachen, bieten das Modescurity-Rule-Sets-Projekt [2] und die Webseite Gotroot [6] vorgefertigte Rule-Sets zum Download an. Die Regeln von Gotroot unterstützen die Neuerungen von Modsecurity 1.9 und sind daher nicht direkt mit älteren Versionen kompatibel.

Weitere Features

Modsecurity bietet neben den reinen Filtermechanismen noch weitere sicherheitsrelevante Optionen. Die Funktion »SecUploadApproveScript Pfad zum script.sh« erlaubt es, hochgeladene Dateien sofort auf Virenbefall zu prüfen indem sie ein Skript startet, das den Virenscanner entsprechend anweist. Ein Beispielskript ist in der Online-Dokumentation von Modsecurity zu finden. Weiterhin erzeugt das Modul über die Anweisung »SecChrootDir /var/www/« einen Changed-Root-Käfig. Er verhindert zuverlässig das Ausführen von CGI-Skripten oder Binärdateien, die sich außerhalb dieses Käfigs befinden.

Performance

Modsecurity verringert je nach Umfang des Regelwerks die Auslieferungsraten des Webservers spürbar. Wie stark die Leistung sinkt, zeigt ein Test mit »ab«. Das Benchmark-Programm gehört zum Apache-Paket. Aufgerufen wurde das Tool mit den Parametern »time ab -n 500 -c 30 http://server/phbBB2/index.php«. Auf einem Rechner mit einer Intel-mobile-CPU Pentium 4 (1,8 GHz) benötigt Apache 2.0.55-4 ohne aktives Modsecurity etwa 55 Sekunden, um alle Anfragen des Benchmarks zu beantworten.

Wurde Modsecurity mit der Grundkonfiguration nach Listing 2 aktiviert, verringert sich die Geschwindigkeit lediglich um etwa zwei Prozent. Kam dagegen das Regelwerk »modsecurity-general« des Modsecurity-Rules-Projekts [6] zum Einsatz, benötigte der Webserver etwa 15 bis 20 Prozent mehr Zeit, um die Seiten auszuliefern.

Die Administratoren stark frequentierter Webserver sollten daher auf jeden Fall darauf achten, das Rule-Set möglichst schlank zu halten, um größeren Performance-Einbußen vorzubeugen. Neben der Anzahl ist die Komplexität der eingesetzten Regeln ein weiteres Kriterium. Kommen zum Beispiel häufig Filter mit regulären Ausdrücken zum Einsatz, benötigt das Regelwerk deutlich mehr Rechenleistung als bei einfachen Vergleichsoperationen. Allgemein gilt: Je genauer das Regelwerk auf das zu filternde Szenario abgestimmt ist, desto weniger Rechenlast erzeugt es.

Da Apache 1 nicht wie Apache 2 über die Engine »PCRE regexp engine« verfügt, liegt die Rechenlast bei Version 1 etwas höher. Ist der Webserver massiven Angriffen ausgesetzt, kann ein gut abgestimmtes Modsecurity-Regelwerk die Performance des Webservers mitunter sogar erhöhen, da die Anfragen die Skripte nicht mehr erreichen.

Wie bei allen regelbasierten Sicherheits-Applikationen hängt der potenzielle Sicherheitsgewinn maßgeblich vom verwendeten Rule-Set ab. Das heißt: Jede Attacke, die nicht explizit von einer Regel abgefangen wird, schlägt durch.

Fazit

Als zusätzliche Barriere gegen Angriffe auf Webapplikationen bietet Modsecurity umfangreiche Schutzmechanismen. Deren Effektivität hängt jedoch, wie bei allen regelbasierten Schutzprogrammen, in erster Linie von der Konfiguration des Rule-Set ab. Bei einer optimalen Abstimmung ist das Modul in der Lage, die meisten Angriffe gegen Webserver und die darauf gehosteten Webapplikationen abzufangen.

Eine unbedachte Konfiguration birgt jedoch neben dem Risiko offener Sicherheitslücken die Gefahr, dass legitimer Inhalt ebenfalls gefiltert wird. Daher ist vor dem Erstellen der Filterregeln deren Notwendigkeit genau abzuwägen. (tle)