Kettenreaktion

Die Aktionen aus der Gruppe der ablaufsteuernden Aktionen beeinflussen die Reihenfolge, in der sich das Modul durch die Regeln wühlt. So bricht »allow« zwar wie »deny« die Verarbeitung ab, lässt aber die Anfrage zum Webserver durch. »pass« geht trotz zutreffender Regel zur nächsten über. Aufgrund ihres Verhaltens eignen sich die beiden Aktionen hervorragend dazu, bestimmte Ereignisse lediglich zu protokollieren oder Informationen über die Arbeitsweise von ModSecurity zu sammeln.

Noch interessanter ist »skip« . Diese Aktion überspringt gleich eine vorgegebene Anzahl Regeln. Auf diese Weise lässt sich eine Art "Wenn-dann"-Verzweigung aufbauen. Genau umgekehrt verkettet »chain« die eigene Regel mit der direkt nachfolgenden:

SecRule REMOTE_ADDR "^127.0.0.1$" "pass,skip↩
:1,nolog"
SecRule ARGS "attack" "nolog,chain"
SecRule &ARGS !^0$ deny

Diese letzten beiden Regeln behandelt ModSecurity wie eine einzige. Sofern die erste Regel erfüllt ist, überspringt das Modul folglich die beiden nächsten. Das »nolog« sorgt noch dafür, dass die entsprechende Aktion nicht in den Protokollen auftaucht, Anfragen vom localhost erhalten somit einen Freifahrtschein.

Nümmerchen schieben

Mit Hilfe der Aktion »setvar« lassen sich sogar Anfragen bewerten. Dazu pappt ModSecurity standardmäßig an jeden Request einen Punktestand. Die Regeln verändern nun diesen Score jeweils um einen entsprechenden Betrag. Auf diese Weise kann man beispielsweise die Wahrscheinlichkeit messen, mit der die Anfrage einen Angriff darstellt. Sofern am Ende eine bestimmte Punktezahl überschritten wurde, landet der Request im Abfalleimer.

Den aktuellen Punktestand speichert ModSecurity in der Variablen »score« , die wiederum in der Collection »tx« steckt. Letztere ist jeder Anfrage zugeordnet und dient eigentlich zur Speicherung von beliebigen Informationen. Bei der Manipulation ihrer Inhalte hilft die Aktion »setvar« , was auch für den Punktestand gilt:

SecRule ARGS "attack" setvar:tx.score=10,pass
SecRule ARGS "search" setvar:tx.score=+5,pass
SecRule REMOTE_ADDR "^127.0.0.1$" setvar:tx.↩
score=-3,pass
SecRule TX:score "@ge 5" deny

Je nachdem, welche Zeichenkette in den Parametern der Anfrage auftaucht, erhöht oder erniedrigt das Security-Modul den Score-Wert. Am Ende erfolgt die Abrechnung: Erreicht er mindestens fünf Punkte, blockt das Modul die Anfrage. Da Variablen niemals negative Werte annehmen können, sollte man unbedingt alle, den Punktestand erhöhenden Regeln vor die anderen stellen.

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