Eine der gängigsten Web Application Firewalls (WAF) ist die ModSecurity Engine. Als Engine tut sie nicht viel von alleine, es sei denn, sie wird mit Regeln konfiguriert, die ihr sagen, wann sie Anfragen abfangen soll und wie ein Angriff aussieht. Administratoren können ihre eigenen Regeln schreiben oder sich auf kommerzielle Angebote von verschiedenen Anbietern verlassen. Da jedoch jeder gerne kostenlose Angebote nutzt, ist einer der gängigsten Regelsätze das OWASP Core Rule Set. OWASP, das Open Web Application Security Project, ist eine Dachorganisation mit vielen verschiedenen Projekten, die sich der Websicherheit widmen. Das Core Rule Set oder CRS ist eines seiner Vorzeigeprojekte und bietet einen generischen Satz von Angriffserkennungsregeln für ModSecurity oder kompatible WAFs.

ModSecurity integriert sich in den Webserver (es entstand als Apache-Modul, daher der Name) und ermöglicht es, den Datenverkehr zu filtern und zu untersuchen, der durch den Server zu einer der dahinter liegenden Anwendungen läuft. Damit können Sie Angriffe auf die Anwendungen stoppen, indem Sie Anfragen mit bösartigen Eingaben blockieren; die Logs Ihrer Anwendungen verbessern, indem Sie automatisierte Scans und ähnliches Rauschen blockieren, und es kann selbst Logs und Warnungen erzeugen, die Sie nutzen können. Einige der Regeln des Core Rule Sets sind sogar genau dafür gedacht!

Standardmässig macht ModSecurity nichts, sondern gibt Ihnen nur die Möglichkeit, Dinge damit zu tun. Der ursprüngliche Entwickler von ModSecurity, Ivan Ristić, bemerkte, dass das so ist, weil er nicht darauf vertraute, dass Werkzeuge Entscheidungen für ihn treffen. Wie bringt man also ModSecurity dazu, tatsächlich etwas zu tun?

Nun, indem man Regeln definiert. Eine Beispielregel könnte SecRule ARGS "<script>" log,deny,status:404 sein, die nach <script> in den ARGS (allen Anfrageparametern) sucht und dann die Anfrage loggt, sie verweigert und einen 404-Status zurückgibt. Die allgemeinere Formulierung einer Regel lautet:

SecRule VARIABLES OPERATOR ACTIONS

Wobei VARIABLES ModSecurity anweist, wo es hinsehen muss, OPERATOR ihm sagt, wie es schauen soll (typischerweise per regulärem Ausdruck) und die ACTIONS dann beschreiben, was zu tun ist.

Idealerweise würde natürlich jeder Regeln schreiben, die spezifisch für seinen Anwendungsfall und seine Anwendung sind, wodurch Fehlalarme minimiert und der Schutz durch ModSecurity maximiert wird. Leider haben in der realen Welt nur wenige Menschen die Zeit, dies zu tun, weshalb vorgefertigte Regelsätze zum Einsatz kommen. Das CRS von OWASP ist ein Satz von etwa 200 Regeln, die verschiedene Probleme auf eine generische Art und Weise erkennen. Das CRS weiss nichts über Ihre Anwendung, aber es enthält eine Menge Know-how darüber, wie ein Angriff erkannt werden kann. Damit kann das CRS viele verschiedene Angriffe gegen eine grosse Bandbreite von Anwendungen abdecken. Es enthält mehrere so genannte Paranoia-Stufen, die standardmässig auf der niedrigsten Stufe beginnen und nach und nach mehr und aggressivere Regeln aktivieren. Höhere Paranoia-Stufen führen auch mit grösserer Wahrscheinlichkeit zu mehr Fehlalarmen.

Wichtig ist, dass CRS ab Version 3.x nicht mehr die traditionelle Pass/Fail-Methode verwendet, sondern eine Anomaliebewertung. Die Regeln von CRS blockieren nun nicht mehr jede Anfrage, sondern verwenden die Aktion setvar, um für jede Anfrage, die sie verarbeiten, eine Bewertung zu erstellen. Am Ende werten die Regeln in den Blöcken 949 und 959 (für Requests bzw. Responses) diese Punktzahl aus und behandeln die Anfrage, wenn sie über einem bestimmten Schwellenwert liegt. Grundsätzlich besteht die Behandlung im Blockieren und Protokollieren, aber auch dies ist konfigurierbar. Standardmässig sind der Schwellenwert und die aus Regeln gewonnene Punktzahl so eingestellt, dass es ziemlich ähnlich wie bei der traditionellen Methode funktioniert, wobei eine einzige “kritische” Regel genug Punkte gibt, um eine Blockierung auszulösen. Dies kann jedoch genutzt werden, um einer neuen Site einen höheren Schwellenwert zu geben, so dass man trotzdem schon von ModSecurity im blockierenden Modus profitieren kann und nicht für wer weiss wie lange ohne aktiven Schutz einen Monitoring-Only-Modus nutzen muss.

In Kombination mit den Paranoia-Stufen ermöglicht dies eine bequeme Feinabstimmung auf die Bedürfnisse der Anwendung, ohne übermässig komplex zu sein. Christian Folini kann eine grossartige Ressource für jeden sein, der mehr über diese Seite des CRS erfahren möchte.

Worauf sich achten, als Auditor?

Bei einer Überprüfung der Konfiguration eines CRS-Einsatzes sollte als erstes untersucht werden, ob die traditionelle Erkennung oder die Anomalieerkennung verwendet wird und wenn letztere, wie die Schwellenwerte konfiguriert sind. Wenn grössere Schwellenwerte eingestellt sind, sollte es einen Prozess oder einen Stichtag geben, an dem die Schwellenwerte verschärft werden. Zweitens sollten Sie einen Blick auf die konfigurierte Paranoia-Stufe werfen und prüfen, ob diese zur untersuchten Anwendung passt, wobei grössere Risiken höhere Stufen erfordern.

Das Wichtigste, worauf Sie achten sollten, ist das Whitelisting. Welche Regeln sind deaktiviert und warum? Wenn Regeln aus dem IP-Reputation-Block (910XXX) oder dem Scanner-Detection-Block (913XXX) deaktiviert wurden, ist das weniger besorgniserregend als wenn Regeln aus den Blöcken SQLi (941XXX) oder Local-File-Inclusion (930XXX) deaktiviert werden. Netnea hat eine grossartige Liste, erstellt von Christian Folini, aller Regeln im Core Rule Set. Anhand dieser Liste und der eigentlichen Regeldateien können die deaktivierten Regeln ausgewertet und die Auswirkungen richtig eingeschätzt werden.

Wenn jedoch Regeln überhaupt deaktiviert werden, empfehlen wir dringend, dass es einen Prozess geben sollte, der sie regelmässig neu bewertet, um zu sehen, ob sie immer noch deaktiviert sein müssen oder ob es möglich ist, die Anomaliebewertung so zu konfigurieren, dass sie aktiv sind, aber die Bewertung nicht übermässig beeinflussen.

Für die Version 2.2.x hat Netnea einmal den Regelsatz auf die Anzahl der False-Positives, die jede Regel erzeugt, ausgewertet, was eine interessante Lektüre ist und in ihrem Blog-Archiv gefunden werden kann. Diese Ressource hilft auch dabei, Entscheidungen zu verstehen und erlaubt eine bessere Beurteilung von deaktivierten oder modifizierten Regeln. Die meisten Regeln haben zu diesem Zeitpunkt nicht sehr viele False-Positives produziert, aber es ist nützlich, die Ausreisser identifizieren zu können.

Zuletzt werden geänderte oder komplett selbstentwickelte Regeln betrachtet. Überschneiden sie sich, basieren sie auf einem Missverständnis dessen, was das CRS tut, oder handelt es sich um Anpassungen an die spezifischen Bedürfnisse einer Anwendung? Dazu sollten sie mit ihrem dokumentierten Zweck verglichen werden. In jedem Fall ist der Versuch, die Regeln an die eigenen Bedürfnisse anzupassen, zu loben.

Zusammenfassung

Angesichts der Stärken des CRS muss man sich als Prüfer keine grossen Sorgen machen, solange die Konfiguration nicht komplett kaputt ist, z. B. durch die Deaktivierung der Auswertungsregeln für die Anomaliebewertung. Es ist wichtig zu verstehen, welche Regeln deaktiviert werden, und wie ModSecurity und das CRS in das grössere Sicherheitssystem des Kunden eingebettet sind: Um zu sehen, ob die generierten Alarme und die erzeugten Logs in einer sinnvollen Weise gehandhabt werden, und zur Überwachung der Situation genutzt werden. Wenn die Logs für die Alarmierung und Überwachung verwendet werden und keine entscheidenden Regeln deaktiviert werden, dann ist die Verwendung des Core Rule Sets ein bedeutender Sicherheitsgewinn.

Über den Autor

Mark Zeman hat seinen Master of Science in Engineering mit Vertiefung Information and Communication Technologies an der Fachhochschule Nordwestschweiz absolviert. Seit 2017 hat er seine Passion im Bereich Information Security zu seinem Fokus gemacht. Unter anderem hat er schon während seinem Bachelorstudium bei einer Email-Sicherheitsfirma gearbeitet. (ORCID 0000-0003-0085-2097)

Links

• https://twitter.com/chrfolini
• https://twitter.com/ivanristic
• https://www.netnea.com/cms/2016/01/17/most-frequent-false-positives-triggered-by-owasp-modsecurity-core-rules-2-2-x/
• https://www.netnea.com/cms/core-rule-set-inventory/