mod_security2 für Apache 2

Früher einmal, zu Zeiten, als man in “sendmail” einmal pro Monat einen Fehler fand, der es ermöglicht hat, auf der Maschine eigenen Code auszuführen, da war die Hauptsorge eines Administrators wohl noch, die installierten Dienste soweit abzusichern, daß das System als ganzes nicht kompromittiert werden konnte. Seit damals ist viel Zeit vergangen. Die erprobten Serverdienste sind sicherer geworden, die Update-Mechanismen der Hersteller schneller und zuverlässiger und die Default-Konfigurationen restriktiver. Es wird zwar immer noch viel über “zero day”-Lücken in irgendwelchen Diensten spekuliert, aber der letzte große Einbruch, der mir einfällt, war die Kompromittierung der Debian CVS-Server im Juli 2006. Und obwohl ich der letzte bin, der sagt, daß man die Sicherheit der installierten Dienste auf einem Server an sich außer acht lassen darf, so muß man doch ehrlich sagen, daß die größten Angriffswellen in letzter Zeit in eine andere Richtung gehen.

Zu einer regelrechten Plage hat sich das “Defacement” von Webseiten entwickelt. Man kann sich zu dem Thema viele nützliche und weniger nützliche Informationen im Netz besorgen, vor allem aber gibt es immer wieder vorgefertigte Exploits, also Schadprogramme, die Lücken in bestimmten Web-Anwendungen ausnutzen. Aufgrund seiner großen Verbreitung trifft es dabei auf die eine oder andere Art und Weise fast immer PHP-Anwendungen, egal, ob es sich um Foren, Content Management Systeme oder Blogs handelt. Die im Webhosting-Bereich weitverbreitete Monokultur von apache/apache2/lighttpd und PHP ist daran nicht ganz unschuldig, vor allem aber trifft die Schuld natürlich die Entwickler der diversen Webappliaktionen. Zumeist sind es einfache Fehler bei der Verarbeitung von Eingabedaten, vor allem in Formularen oder bei der Parameterübergabe via URL, die dann ermöglichen, daß ein Angreifer eigenen Code ausführen oder zumindest eigene PHP-Skripte hochladen kann. Wer nach Dingen wie “c99.php” googlet, der wird denn auch schnell herausfinden, welcher Art die Programme sind, die dann auf dem Server landen.

Obwohl auf einem halbwegs vernünftig konfigurierten System die Integrität des eigentlichen Systems nichtmal halbwegs gefährdet ist, wenn so ein Angriff gelingt, hilft das dem Admin natürlich wenig - die Webseite des Kunden ist verunstaltet und schlimmer, der eigene Server kann als Ausgangspunkt für neue Angriffe oder zum Spamversand benutzt werden - ganz ohne “root”-Rechte. Im Wesentlichen habe ich bisher drei Projekte gefunden, die sich auf die Fahnen geschrieben haben, die Kombination aus PHP und Apache so zu verändern, daß auch unsicherer Code weniger anfällig wird: Zum einen “Suhosin” aus dem Projekt “Hardened-PHP” und zum anderen “ModSecurity”.

Suhosin selbst ist auf einem Debian-System schon als Paket verfügbar, mod_security dagegen nicht. Deswegen werde ich mir im Lauf der nächsten Woche(n) die Mühe machen das ganze säuberlich zu paketieren und hier zum Download anbieten. Wenn ich fertig bin, wird es natürlich auch eine Dokumentation geben, was genau ich an den beiden Projekten auf meinen Webservern eingestellt habe.

Die Angriffe, denen man sich heutzutage ausgesetzt sieht, mögen nicht die gleiche technische Qualität wie früher haben, in ihren Auswirkungen aber sind sie mindestens genauso schlimm. Und solange man - gerade im Shared Hosting Bereich - immer wieder Angebote findet, bei denen alle PHP-Skripte unter einer UID laufen und jeder Kunde die Webroots aller anderen Kunden lesen kann, wird sich die Situation auch nicht entspannen.

(Hinweis: Links entfernt.)