Nachdem ich - aus Not, nicht freiem Willen, danke an den Möchtegern-Hacker von gestern - mir nun schon Pakete für ModSecurity gebaut hatte, wollte ich das natürlich auch ernsthaft einsetzen. Als Startpunkt gibt es die ModSecurity Core Rules, welche sich relativ schnell und unproblematisch installieren lassen (entpacken, in der Apache-Konfiguration einbinden und in der Testphase „SecRuleEngine DetectionOnly” setzen). Mit etwas Hirnschmalz kriegt man da dann schon erste Reports - und hofft natürlich, daß das nicht allzu viele sind. Denkste. Mein Logs sind gewachsen als gäbe es kein Morgen.

Sich jede einzelne Sache in den Logs anzuschauen war mir jetzt etwas zu aufwändig, also habe ich mich da nach einer anderen Lösung umgesehen - und die gibt es auch, in Form der ModSecurity Console, für die es auch eine sog. „Community License” gibt. Die Anbindung erfolgt relativ einfach, die Konsole ist als Standalone-Java-Applikation realisiert, hat einen HTTP-Server dabei, und das Tool „mlogc” (ist in meinen Paketen drin) postet die Events dann an die Konsole. In der Konsole hat es dann zunächst mal eine Übersicht, was in den letzten Tagen und Stunden so alles angefallen ist. Das sieht zunächst einmal ganz gut aus, und auch recht übersichtlich.

Zu jedem Alert gibt es eine detaillierte Ansicht, die einem nochmal zeigt, welche Regeln auf den Request bzw. die Transaktion gematched haben, eine Übersicht über den Requests (Header & Body von Request und Response). Und da wird einem jetzt mal anders - schaut Euch bitte mal an, was bei dem gezeigten Requests gematched hat. Der Request sieht in dieser Ansicht wirklich böse aus - ist aber nur eine ganz normale PHP-Applikation. Die Anzahl der Fehlalarme, die diverse PHP-Applikationen im Core-Ruleset auslösen, lässt nur zwei Schlüsse zu:

• Entweder ist die durchschnittliche PHP-Applikation einfach nur Dreck, oder
• das Core-Ruleset wurde von Leuten entwickelt, die sich draußen in der freien Welt eher nicht so viel umgesehen haben.

Jetzt werdet ihr - und das zu Recht - argumentieren, daß es die Aufgabe der Administratoren und Entwickler ist, das Regelset für die eigene Applikation zu erstellen und daß öffentlich verbreitete Regelsets gar nicht „out of the box” funktionieren können. Und ihr werdet auch sagen - und wiederum zu recht - daß die Code-Qualität von vielen PHP-Applikationen wirklich nicht toll ist. Trotzdem: Das CRS sollte ein einfacher Startpunkt für die Erstellung eines eigenen Regelwerks sein. Und diesem Anspruch wird es - aus welchen Gründen auch immer - derzeit nicht gerecht.

Rachmaninov, Klavierkonzert Nummer 4.

Heiß, fettig und seit heute für i386 und x86_64 im Repository: Der Postfix-Snapshot vom 01.01.2010. Neue Features sind automatisches Aufräumen der Datenbanken für postscreen(8) und verify(8), weswegen diese auch einen DB-Typ verwenden müssen, bei dem die „delete”-Operation unterstützt wird (als Standard ist „btree” eingestellt) sowie ein paar kleinere Bugfixes, alles nachzulesen hier ab Changelog-Eintrag 20091209.