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.
Nachdem eine Anfrage herein kommt, durchläuft ModSecurity nacheinander fünf Phasen:
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.
ModSecurity Core Rule Set Project
Montag, 08. August 2011 15:35:33