Operatoren

Solange man als zweiten Parameter ebenfalls einen regulären Ausdruck verwendet, führt ModSecurity automatisch einen Mustervergleich durch. In den bisherigen Beispielen war dies immer eine einfache Textsuche, selbstverständlich sind aber auch beliebig komplexere Varianten möglich. Die folgende Regel stellt beispielsweise sicher, dass in der Anfrage keine Argumente enthalten waren:

SecRule &ARGS !^0$

Die Auswertung der regulären Ausdrücke übernimmt im Hintergrund die PCRE Bibliothek, die im wesentlichen alle unter Perl bekannten Konstrukte erlaubt.

Sobald man die Pfade der Mustererkennung verlässt, muss man den gewünschten Operator explizit mit angeben. Dies geschieht über einen Klammeraffen »@« , dem der Name des Operators folgt. Beispielsweise stellt

SecRule ARGS "@validateUtf8Encoding"

sicher, dass die Anfrage die UTF-8 Zeichenkodierung nutzt. Für Zahlenspiele bietet ModSecurity die Vergleichsoperationen »gt« (größer als), »ge« (größer gleich), »eq« (gleich), »le« (kleiner gleich) und »lt« (kleiner als). Damit testet beispielsweise:

SecRule &ARGS "@ge 3"

ob es in der Anfrage mehr als drei Parameter gibt. Besonders interessant ist auch der Operator »inspectFile« , der ein externes Skript zu Rate zieht:

SecRule FILES_TMPNAMES "@inspectFile ↩/Pfad/zu/pruefe.pl"

Alle im Request gesendeten Dateien übergibt ModSecurity an das Perl-Skript »pruefe.pl« , hinter dem beispielsweise ein Virenscanner stecken könnte. Dessen Exit-Code entscheidet darüber, ob die Regel letztendlich greift oder nicht. Für die Prüfung gegen eine Blacklist sorgt »rbl« :

SecRule REMOTE_ADDR "@rbl meine.blacklist↩
.org"

Wer mag, darf auf die Kurzschreibweise bei den regulären Ausdrücken verzichten und den zugehörigen Operator »rx« (für »R« egular e»X« pression) mitschreiben:

SecRule REQUEST_URI "@rx attack"

Wie die Beispiele zeigen, können Operatoren selbst weitere Parameter fordern. Damit durch die zusätzlichen Leerzeichen keine Verwirrung entsteht, ist das gesamte Gebilde durch Anführungszeichen zu begrenzen.

Action!

Neben der reinen Abweisung einer Anfrage, kennt ModSecurity noch viele weitere Aktionen. Diese sind so zahlreich, dass sie zur besseren Übersicht in folgende Gruppen aufgeteilt wurden:

  • Unterbrechende (disruptive) Aktionen
  • Nicht-Unterbrechende (non-disruptive) Aktionen
  • Ablaufsteuernde (flow) Aktionen
  • Metadaten verarbeitende Aktionen
  • Alle anderen Aktionen (Data actions)

Die derzeit gültige Standard-Aktion legt »SecDefaultAction« fest. Da ModSecurity die Regeln nacheinander abarbeitet, darf man sie auch mittendrin wechseln. Auf diese Weise lassen sich Regelblöcke mit verschiedenen Standard-Aktionen schaffen.

Unterbrechende Aktionen beenden grundsätzlich die Verarbeitung einer Anfrage. Dazu gehört in erster Linie der bislang verwendete Standard »deny« . Er stoppt die Transaktion und liefert eine Fehlermeldung zurück. »drop« geht noch einen Schritt weiter und verwirft die Transaktion ohne jegliche Rückmeldung, was sich insbesondere bei Denial-of-Service Attacken (DoS) anbietet. »redirect« und »proxy« sorgen für eine Weiterleitung, »proxy« führt dabei auf einen anderen Server:

SecRule ARGS attack "proxy:'http//Server'"

»pause« legt eine Anfrage für eine definierbare Zeit auf Eis und verlangsamt so die Transaktion.

Eine Regel darf durchaus mehrere Aktionen gleichzeitig auslösen. Dies ist besonders sinnvoll im Zusammenspiel mit den nicht-unterbrechenden Aktionen, wie beispielsweise »log« und den Metadaten verarbeitenden, wie »msg« :

SecRule REQUEST_URI "attack" "log,deny,↩
msg:'Das Wort attack trat auf'"

»log« teilt ModSecurity zunächst mit, dass die erfüllte Regel auf jeden Fall später im Protokoll auftauchen muss. »deny« sorgt gleichzeitig für einen Abbruch der Verarbeitung. Abschließend wandert noch der Text in den Hochkomma hinter »msg« ins Audit-Log.

Zu den nicht-unterbrechenden Aktionen zählt auch »exec« , das ein externes Programm aufruft:

SecRule ARGS "virus" "setenv:SEARCH=↩
'INTESIV',exec:'/usr/bin/virenscanner.pl'"

»setenv« setzt noch die aus CGI-Programmen bekannten Umgebungsvariable »SEARCH« , die der dann aufgerufene »virenscanner.pl« auswertet.

Kommentare

ModSecurity Core Rule Set Project

Die OWASP Leute haben auch ein eigenes Sub Projekt wo sie an den Rulesets arbeiten,
welcher hier auch erwaehnt werden sollte

https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2020