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.