Schriftführer

Die Ausgaben im »error_log« liefern schon recht viele Informationen, auf Wunsch gibt sich ModSecurity aber noch gesprächiger. Jede Anfrage und jede seiner Entscheidungen protokolliert das Modul dann in einem eigenen, so genannten Audit-Log. Die darin gespeicherten Informationen helfen bei einer genauen Analyse von Angriffen und beim Aufbau der Filterregeln. Um die Protokollierung einzuschalten, teilt der Admin ModSecurity zunächst den Dateinamen der Log-Datei mit:

SecAuditLog logs/modsec_audit.log

Der Administrator hat dabei die Wahl, entweder alle Daten in eine einzige Datei laufen zu lassen:

SecAuditLogType serial

oder aber für jede Anfrage ein eigenes Log aufzumachen:

SecAuditLogType concurrent

Damit die Übersicht nicht verloren geht, sollte man letzteres jedoch nur für hoch frequentierte Seiten aktivieren. Die dabei produzierten Dateien landen dann Dank

SecAuditLogStorageDir /var/log/www/sec_logs

im Verzeichnis »/var/log/www/sec_logs« .

Um nicht im Wust von Anfragen zu ersticken, kann der Administrator den Inhalt der Audit-Protokolle auf alle Ereignisse beschränken, die ModSecurity in irgendeiner Weise zum Handeln gezwungen haben:

SecAuditEngine RelevantOnly

Welche Ereignisse dabei als relevant gelten, bestimmt ein:

SecAuditLogRelevantStatus "^[45]"

Der reguläre Ausdruck in den Anführungsstrichen legt fest, dass ab sofort nur noch solche Ereignisse im Audit-Log landen, die einen 400er oder 500er Fehler provozieren. Ein Tausch von »RelevantOnly« gegen »On« , beziehungsweise »Off« schaltet das Logging komplett ein oder aus. Welche Informationen über ein Ereignis im Protokoll landen, regelt die folgende Einstellung:

SecAuditLogParts "ABIFHZ"

Jeder Buchstabe in den Anführungszeichen steht für einen ganz bestimmten Teil der HTTP-Anfrage: »A« repräsentiert den Audit Log-Header und somit den Beginn des aufgezeichneten Ereignisses. Es folgen der Kopf der Anfrage (»B« ), dessen Rumpf (»I« ) und der Kopf der Antwort (»F« ). »H« liefert den Abspann des Protokolleintrages (der so genannte Audit Log Trailer), während »Z« sein Ende markiert. Bis auf »A« und »Z« , die beide zwingend am Anfang, beziehungsweise Ende der Definition auftauchen müssen, ist die Reihenfolge der übrigen Bestandteile veränderbar.

Phasenprüfer

Nachdem eine Anfrage herein kommt, durchläuft ModSecurity nacheinander fünf Phasen:

  • Inspektion des Request Header
  • Inspektion des Request Body
  • Inspektion des Response Header
  • Inspektion des Response Body
  • Logging durchführen

Die Phasen 1, 2 und 5 führt das Modul immer aus. Die anderen beiden muss der Admin explizit aktivieren:

SecRequestBodyAccess On
SecResponseBodyAcces On

Nur dann analysiert ModSecurity auch die Inhalte im Rumpf einer Anfrage, beziehungsweise Antwort. Dazu muss es die übertragenen Daten jedoch puffern, was wiederum entsprechenden Platz im Hauptspeicher kostet. Damit der verbrauchte Zwischenspeicher nicht in die Höhe schnellt, limitiert ihn ein

SecRequestBodyInMemoryLimit 131072

auf 131072 Bytes. Zusätzlich darf der Administrator die maximal erlaubte Größe des Rumpfs einer jeden HTTP-Anfrage festlegen:

SecRequestBodyLimit 134217728

Jeder Request, der mehr als 134217728 Bytes misst, landet im Orkus und erhält als Quittung den Antwortcode »413 Request Entity Too Large« . Der hier im Beispiel angegebene Wert ist übrigens auch die Voreinstellung (131072 KByte).

Wer zusätzlich die Antworten vom Webserver inspizieren lässt, schickt dann automatisch auch binäre Daten zur Prüfung durch das Modul, beispielsweise in Form von JPEG-Bildern. Wenn der Web-Server die MIME-Typen in seinen Antworten zurückschickt, kann der Admin ModSecurity anweisen, nur bestimmte von ihnen zu untersuchen:

SecResponseBodyMimeTypesClear
SecResponseBodyMimeType text/plain ↩
text/html text/css text/xml

Die erste Anweisung leert sicherheitshalber die bislang gültige Liste der zu analysierenden Typen, die zweite beschränkt die zu inspizierenden Daten auf reinen Text, HTML, CSS und XML.

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