Seite 4: Eine Firewall, die zurückschlagen kann

Inhaltsverzeichnis

Eine Firewall, die zurückschlagen kann

Besonderes Augenmerk fällt auf die Aktion exec, mit der es möglich ist, aus mod_security heraus externe Programme oder Skripte in zu starten. Dadurch lässt sich das Apache-Modul auf einfache Weise einsetzen, um beispielsweise den Server-Zugriff für kompromittierte Rechner schon auf Paketfilter-Ebene vollständig zu blockieren, wie das folgende Beispiel zeigt.

Es ist nicht möglich, den so aufgerufenen Programmen und Skripten Kommandozeilenoptionen zu übergeben. Dies muss über geeignete Umgebungsvariablen erfolgen. Sämtliche CGI-Variablen, wie beispielsweise THE_REQUEST, TIME, REMOTE_USER und DOCUMENT_ROOT stehen den aufgerufenen Programmen als Umgebungsvariablen zur Verfügung. Ausserdem lassen sich durch die Aktion setenv:VARIABLE=WERT eigene Umgebungsvariablen setzen, um mit Skripten und Programmen zu kommunizieren.

Das folgende Beispiel implementiert ein einfache Blacklisting. Zunächst ist dazu in obigem Beispiel die Zeile zur Erkennung von Santy.A-Zugriffen

SecFilterSelective ARG_highlight "%27"

mit dem entsprechenden Skriptaufruf zu versehen:

SecFilterSelective ARG_highlight "%27" \
  "deny,log,exec:/etc/mod-security/ip-blacklist.sh"

Das Skript /etc/mod-security/ip-blacklist.sh hängt lediglich die in der CGI-Variable REMOTE_ADDR gespeicherte IP-Adresse, von der aus der Zugriff getätigt wurde, an eine Blacklist-Datei im Logverzeichnis von Apache an:

#!/bin/sh
echo ${REMOTE_ADDR} >>/var/tmp/blacklist

Um die IP-Adressen in der Blacklist tatsächlich zu blocken, ist nun beispielsweise noch ein mit Root-Rechten laufender Hintergrund-Job notwendig, der die Blacklist auf Änderungen überprüft und in der Firewall durch entsprechende iptables-Aufrufe die Sperrung der IPs veranlasst. Das folgende sehr einfach gehaltene Skript erfüllt diese Aufgabe für den lokalen Paketfilter des Servers:

#!/bin/sh
 
BLACKLIST=/var/tmp/blacklist
 
touch ${BLACKLIST} ; chown www-data:www-data ${BLACKLIST}
tail -f ${BLACKLIST} | while read ip
do
    iptables -A INPUT -s ${ip} -j DROP
done

Ein Skript für den realen Einsatz sollte auch auf doppelte Einträge prüfen und aus Sicherheitsgründen den Inhalt der Datei unbedingt rigiden Tests unterziehen, bevor es ihn in irgendwelche Befehle einbettet. Außerdem ist ein automatisierter Mechanismus zur Sperrung verdächtiger IPs immer mit großer Vorsicht zu genießen. Einerseits finden die Zugriffe möglicherweise nicht direkt von den IPs böswilliger Rechner aus statt, sondern über einen Proxy-Server. Dessen Nutzerschaft würde so unberechtigter Weise vollständig vom Serverzugriff ausgeschlossen. Andererseits ließe sich ein automatisierter Mechanismus zur Firewall-Administration unter Umständen auch von einem Angreifer missbrauchen, um Zugriff auf privilegierte Bereiche zu erlangen oder unbeteiligte Nutzer auszusperren. Im Falle eines Distributed-Denial-Of-Service-Angriffs wäre allerdings auch dieses Mittel recht, um die ressourcenfressenden Anfragen gänzlich vom Server-Prozess fern zu halten.

Grundsicherung in fünf Minuten

Die oben angebebene Basiskonfiguration ohne die Beispielregeln lässt sich leicht für vorgefertigte Filterregelsätze nutzen, wie sie vielerorts im Internet angeboten werden. Ein besonders umfangreiches Angebot an aktuellen Filterregeln findet sich beispielweise bei Got Root[3]. Es deckt ein breites Spektrum bekannter Schadsoftware und manipulativer Serverzugriffe ab. Folgende Befehle laden einen aktuellen Filterregelsatz und integrieren ihn in die bereits erstellte Apache-Konfiguration:

# cd /tmp
# wget http://www.gotroot.com/\
downloads/ftp/mod_security/apache2/\
apache2-gotrootrules-latest.tar.bz2
# tar jxf apache2-gotrootrules-latest.tar.bz2
# cd apache2
# mv exclude.conf 0-exclude.conf
# mv rules.conf \#rules.conf
# mv recons.conf \#recons.conf
# mv * /etc/mod-security.d/

Die Datei exclude.conf stellt gewissermaßen eine Whitelist für bekannte Ausnahmen dar. Sie muss daher umbenannt werden, um sie vor den anderen Regeldateien einbinden zu lassen. Die beiden Regelsätze rules.conf und recons.conf enthalten Regeln, die mod_security erst seit version 1.9.0 unterstützt und müssen daher deaktiviert werden. Der letzte Schritt kann beim Einsatz einer 1.9er Version entfallen, doch Debian liefert derzeit Binärpakete nur für Version 1.8.7.