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.