Warum ModSecurity standardmäßig auf jeden Kundenserver kommt

ModSecurity, strikt gekoppelt mit dem OWASP Core Rule Set (CRS), wandert auf jeden einzelnen Server, den ich aufsetze – und zwar noch bevor ich überhaupt großartig weiß, welche Applikation letztendlich darauf laufen wird.

Das mag vielleicht rückwärts klingen. Wie konfiguriert man eine Web Application Firewall für eine Applikation, die buchstäblich noch gar nicht existiert? Aber genau das ist der Punkt. Das CRS ist nicht auf eine spezifische Anwendung zugeschnitten. Es ist strikt auf genau die Arten von Requests getunt, die automatisierte Angriffe aggressiv auf jeden Server feuern, in der simplen Annahme, dass irgendwo irgendetwas dagegen anfällig (vulnerable) sein könnte.

Was es tatsächlich abfängt

Betreiben Sie fast jeden beliebigen Webserver mit voll aufgedrehtem Logging, und Sie werden einen konstanten, massiven Strom an Requests sehen, die absolut nichts mit der eigentlichen Anwendung zu tun haben.

Sie werden aggressive Versuche sehen, auf /wp-admin zuzugreifen – auf einem Server, auf dem nicht einmal WordPress läuft. Sie werden SQL-Injection-Payloads sehen, die in Query-Parameter von Seiten gequetscht werden, welche gar keine Query-Parameter verarbeiten. Sie werden Path-Traversal-Versuche (../../etc/passwd) sehen, die gewaltsam gegen statische Dateipfade geworfen werden. Sie werden Requests sehen, die komplett vollgestopft sind mit Payloads, die explizit dafür entworfen wurden, Schwachstellen in Software auszunutzen, die dort nie installiert war.

Absolut nichts davon muss erfolgreich sein, um ein Problem zu sein. Bestenfalls ist es schweres Rauschen (Noise). Schlimmstenfalls ist es ein extrem reales Risiko, falls auch nur eine einzige installierte Software zufällig auf das passt, was dort aggressiv abgetastet (geprobed) wird.

Das CRS erkennt strikt die Muster (Patterns) hinter diesen Angriffen, nicht spezifische Anwendungsschwachstellen. Ein SQL-Injection-Versuch sieht strukturell exakt wie ein SQL-Injection-Versuch aus – egal, ob er auf eine komplett selbst geschriebene PHP-App, ein zufälliges WordPress-Plugin oder eine statische Seite ganz ohne Datenbank abzielt (wo er ohnehin scheitern wird, aber absolut immer noch einen bösartigen Probe darstellt, den man kennen sollte). Genau diese strukturelle Erkennung ist es, die das CRS so unglaublich nützlich macht, ohne dass im Vorfeld eine anwendungsspezifische Konfiguration erforderlich ist.

Immer zuerst der Detection Mode (Erkennungsmodus)

Der häufigste Grund, warum Leute aufgeben und ModSecurity komplett abschalten, ist ein False Positive (Fehlalarm), der legitimen Traffic gewaltsam blockiert. Dies wird normalerweise dann entdeckt, wenn ein wütender Kunde ein simples Formular nicht abschicken kann, weil seine völlig normale Eingabe zufällig mit einem Regel-Muster (Rule Pattern) übereinstimmt.

Die Lösung dafür ist nicht, ModSecurity zu deaktivieren. Die Lösung ist, es zuerst strikt im Detection Mode (Erkennungsmodus) auszurollen:

# modsecurity.conf
SecRuleEngine DetectionOnly

In diesem Modus protokolliert (loggt) ModSecurity leise, was es blockiert hätte, ohne auch nur ein einziges Ding tatsächlich zu blockieren. Lässt man dies ein oder zwei Wochen lang gegen echten, realen Traffic laufen, treten jegliche False Positives für die spezifische Anwendung sauber zutage. Diese können dann mit extrem zielgerichteten Ausnahme-Regeln (Exclusions) spezifisch adressiert werden, lange bevor man in den Blocking Mode wechselt:

SecRuleEngine On

Dieser sorgfältige Zwei-Schritt-Rollout ist der buchstäbliche Unterschied zwischen "ModSecurity hat einen Kunden blockiert und wurde komplett abgeschaltet, sodass der Server völlig nackt und ohne WAF dasteht" und "ModSecurity hat ein paar hochgradig getunte Ausnahmen und blockiert aktiv den gesamten Rest."

Das Tunen von Ausnahmen (Exclusions) ist völlig normal, kein Fehler

Das CRS bringt absichtlich eine "Paranoia Level"-Einstellung mit. Höhere Level fangen aggressiv mehr ab, produzieren aber signifikant mehr False Positives. Das Standard-Level ist ein absolut vernünftiger Startpunkt.

Jegliche Ausnahmen, die darüber hinaus benötigt werden, sind typischerweise extrem eng gefasst – auf eine spezifische Rule-ID und für einen spezifischen URL-Pfad –, anstatt blind breite, ganze Kategorien an Schutz abzuschalten:

SecRuleRemoveByIdWithMsg "rule message text" "specific-form-endpoint"

Eine kleine Handvoll Ausnahmen für die spezifischen Eigenarten einer Applikation (z. B. ein Rich-Text-Editor, der legitimerweise HTML-ähnlichen Content übermittelt) ist völlig normal. Es untergräbt absolut nicht den Schutz für den gesamten Rest des Servers. Das eigentliche Ziel ist nicht null Ausnahmen; das Ziel ist eine WAF, die tatsächlich eingeschaltet ist und aktiv blockiert, mit genau der kleinen Anzahl an exakten Ausnahmen, die eine Anwendung wirklich zwingend benötigt.

Die Performance-Kosten sind deutlich geringer als die Alternative

ModSecurity erzeugt absolut Overhead. Jeder einzelne Request wird aktiv gegen das Regelwerk evaluiert, bevor er überhaupt die Anwendung erreicht.

In der Praxis ist dieser Overhead im Vergleich zur eigenen Verarbeitungszeit der Anwendung für die meisten Requests jedoch unglaublich gering. Darüber hinaus ist es ein Overhead, der strikt mit der Größe des Regelwerks skaliert, nicht mit der Komplexität Ihrer Anwendung. Abgewogen gegen die brutale Alternative – einen komplett nackten Server mit absolut null generischem Schutz gegen die konstante, zermürbende Grundlast an automatisierten Probes – fällt der Trade-off massiv, massiv zugunsten eines eingeschalteten Schutzes aus.

Warum "standardmäßig" (by default) so extrem wichtig ist

Der exakte Grund, warum dies auf jeden einzelnen Server kommt, noch bevor die Applikation überhaupt entschieden ist, liegt darin, dass der generische Schutz, den es bietet, absolut nicht davon abhängt, die Anwendung zu kennen.

Bis eine Applikation endlich deployed wird und ein formelles Security Review vielleicht stattfindet, war ein Server ohne WAF bereits aktiv dem ausgesetzt, was auch immer ihn gewaltsam abgetastet hat, seit er vor einer Sekunde eine öffentliche IP-Adresse bekommen hat.

Vom ersten Tag an mit ModSecurity im Detection Mode zu starten und dann sicher zum Blocking zu wechseln, sobald die spezifischen Traffic-Muster der Anwendung vollständig verstanden sind, bedeutet, dass die verwundbare Lücke zwischen "Server existiert" und "Server hat einen starken Basisschutz" faktisch null ist. Sie wartet nicht erst ab, wie lange es dauert, bis sich endlich jemand daran erinnert, ihn hinzuzufügen.