© ADAC

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.