Ein Test von meinem Arbeitsplatz aus, konnte den Fehler ersteinmal nicht bestätigen. Nachdem ich erst das DNS geprüft habe (zeigt die Domain auch auf den richtigen Server?), prüfte ich die Logdatei des Webservers. Tatsache: Seine Anfragen wurden blockiert, meine nicht.

Die Ursache war die, dass unser Regelwerk in der Datei 00_asl_rbl.conf, welche aus dem Regelwerk von gotroot.com stammt, eine Regel enthielt, welche die IP-Adresse des Clients in der DNSBL xbl.spamhaus.org nachschlägt und, falls die IP-Adresse gelistet ist, den Zugriff verweigert. Die Liste enthält eigentlich Rechner, welche durch Spam auf Webseiten durch Trojaner / Botnetze beispielsweise aufgefallen sind. Problematisch ist das ganze jedoch deswegen, weil IP-Adressen sich hierzulande normalerweise nach 24 Stunden ändern und dann ein unschuldiger Benutzer eine IP-Adresse bekommen kann, die auf der Blackliste steht. Diesem Benutzer ist der Besuch unserer Seiten dann nicht möglich.

Fazit: Der Einsatz einer  DNSBL in einer WebApplication Firewall kann also schnell dazu führen, dass unschuldige Besucher von der Webseite ausgesperrt werden.
Anders als Mailserver, haben Websurfer normalerweise nämlich keine festen IP-Adressen.

Obwohl wir auf vielen unserer Server natürlich Linux einsetzen, betreffen uns die meisten Exploits für Linux nicht direkt, da wir einen stark gehärteten Linuxkernel einsetzen. Wir setzen bei allen Systemen, wo Kunden direkten Zugriff auf das System (Shell / CGI) haben auf Grsecurity.

Grsecurity ließ uns bereits im Februar 2008 ruhiger schlafen, als es einen lokalen Rootexploit für Linux gab (Vmsplice Bug). Sämtliche auffindbaren Exploits funktionieren auf unseren Systemen nicht. Und so ist es auch nun wieder: Sämtliche Exploits, die wir für die aktuelle Lücke finden konnten, funktionieren auf unseren Systemen nicht.

Seit heute wollen wir die ganze Welt an unseren Paketen, die für KVM-Gastsysteme mit Debian Lenny konzipiert sind, teilhaben lassen, und stellen die Pakete für amd64 unter http://grsec.multicept.de zur Verfügung. Dass wir für Probleme, die durch unsere Pakete entstehen keinerlei Haftung übernehmen versteht sich von selbst.

Nähere Informationen, was im Kernel enthalten ist, was nicht, sowie signaturen werden in den nächsten Tagen folgen. Es lohnt sich also die Seite regelmäßig aufzurufen.