Sicherheitslog #

Diese Seite ist für Systemadministratoren und Sicherheitsverantwortliche bei einem Hoster, die viele Exponential-Websites auf Angriffe und Missbrauch beobachten. Sie beantwortet: welche Logs Sicherheitssignale enthalten, was eine Zeile in security.log bedeutet, wie der Klassifizierer abgestimmt wird, was er nicht tut (er blockiert nie) und wie Sie die Signale von der Maschine in Ihre eigene Überwachung bekommen.

Die Details stehen in Anfrage-Logs, Das Prüfprotokoll und Sicherheitshärtung: beobachten.

Inhalt #

1. Die Sicherheitsquellen auf einen Blick
2. security.log: der Request-Klassifizierer
3. Den Klassifizierer abstimmen
4. Blockieren ist nicht die Aufgabe des Klassifizierers
5. auth.log und csp.log
6. Das Prüfprotokoll und seine Senken
7. Eine wöchentliche Routine
8. Checkliste

Die Sicherheitsquellen auf einen Blick #

Quelle: Sicherheitshärtung.

security.log: der Request-Klassifizierer #

Jede Anfrage wird einmal eingestuft, an ihrem Ende, was auch immer ihr Status ist. Eine Anfrage, die eine Regel erkennt, wird statt in 404.log oder notice.log in security.log geschrieben:

[ Oct 17 2026 09:00:00 ] [203.0.x.x] probe/wp-login confidence=high 404 GET /wp-login.php siteaccess=site namespace=/wp-login.php ua=3f2a9c1b "curl/8.5.0"

Die Regel threshold kennzeichnet einen Client, der innerhalb von WindowSeconds=60 mehr als Max404PerMinute=30 Antworten „nicht gefunden“ erhält (requestclassifier.ini [ThresholdSettings]); ihr Zähler wird über einen gesalzenen Hash der Adresse geführt, nie über die Adresse selbst.

Die Fehlerübersicht (Setup > Logdateien > Fehlerübersicht) gruppiert security.log nach <category>/<rule>, sodass eine Woche voller Abtastungen sich als wenige Zeilen wie probe/wp-login 312 liest.

Den Klassifizierer abstimmen #

settings/requestclassifier.ini, überschrieben in settings/override/requestclassifier.ini.append.php, einem Siteaccess oder einer Erweiterung:

Ein Kunde, dessen eigene Anwendung einen Pfad nutzt, den eine Regel kennzeichnet (zum Beispiel einen legitimen Pfad /administrator/), erhält einen Eintrag in Excludes[] statt eines ausgeschalteten Regelsatzes. Die Regelnamen jedes Satzes stehen in der mitgelieferten Datei.

Blockieren ist nicht die Aufgabe des Klassifizierers #

Nichts wird blockiert. Der Klassifizierer stuft nur ein: Die Anfrage bekommt die Antwort, die sie ohnehin bekäme. Das Blockieren gehört zu:

• einem Schutz vor dem Kernel, request-shield, der läuft, bevor Exponential startet, und eine Anfrage in seinem eigenen Log ablehnen oder festhalten kann (Ein Schutz davor, request-shield und Request-Regeln);
• dem Webserver oder einer Firewall des Hosters;
• einem Listener, der in [ClassifierSettings] Listeners[] registriert ist (eine Klasse, die expRequestVerdictListenerInterface implementiert), der Stelle, an der später eine Sperrliste, eine Ratenbegrenzung oder eine Benachrichtigung hinzugefügt werden kann.

Hinweis Eine Anfrage, die der Schutz ablehnt, erreicht den Kernel nie und steht daher nicht in security.log. Im Beobachtungsmodus des Schutzes kann dieselbe Abtastung in beiden Logs stehen. Zählen Sie sie nicht doppelt, wenn Sie einem Kunden Angriffszahlen berichten.

auth.log und csp.log #

• auth.log hält jeden Schritt der zweistufigen Anmeldung fest, nie einen Code oder ein Geheimnis. Eine Häufung gescheiterter zweiter Schritte bei einem Konto ist einen Blick wert (Zweistufige Anmeldung).
• csp.log enthält die Meldungen der Browser zur Content Security Policy, in der Übersicht nach Direktive und blockierter Quelle gruppiert. Eine Flut von Meldungen ergibt eine Zeile abuse/csp-report-flood pro Minute in security.log (Anfrage-Logs, Content Security Policy).

Das Prüfprotokoll und seine Senken #

Das Prüfprotokoll ist eine signierte, manipulationssichtbare Aufzeichnung darüber, wer was getan hat, ab 6.0.15 standardmäßig an, in var/<site>/log/audit/ (Das Prüfprotokoll):

./console exp:audit status --allow-root-user
./console exp:audit tail --channel=access --lines=20 --allow-root-user
./console exp:audit verify --allow-root-user     # exit 1 when a chain is broken

Eine Kopie auf derselben Maschine kann zusammen mit ihr zerstört werden. Leiten Sie das Protokoll mit einer Senke weiter: syslog (RFC 5424; mit Transport=local der native Socket von journald, sodass journalctl -t exponential die Einträge findet), ein signierter Webhook (HMAC-SHA-256, mit Warteschlange und Wiederholungen) oder E-Mail bei kritischen Ereignissen. Die Senken werden in settings/audit.ini konfiguriert ([AuditSink_syslog], [AuditSink_webhook], [AuditSink_mail]); die vollständige Referenz ist die Anleitung zum Audit. Die Sicht des Hosters, einschließlich der Frage, wer das Protokoll lesen darf, steht auf Prüfprotokoll.

Warnung settings/override/audit.ini.append.php enthält die Signatur- und Pseudonymschlüssel. Sichern Sie sie mit jedem Backup, und halten Sie sie so vertraulich wie das Datenbankpasswort (Was gesichert werden muss).

Eine wöchentliche Routine #

Aus der eigenen Checkliste des Projekts (Sicherheitshärtung):

1. Führen Sie die Cronjob-Gruppe frequent aus, damit die Alarmregeln des Audits laufen, und prüfen Sie, wer Alarm-Mails erhält (./console exp:audit alerts recipients).
2. Leiten Sie das Prüfprotokoll mit einer Senke an ein zentrales Log oder SIEM weiter, und führen Sie regelmäßig exp:audit verify aus.
3. Sehen Sie sich wöchentlich die Fehlerübersicht und security.log an; ein plötzlicher Anstieg einer Regel ist einen Blick wert.
4. Geben Sie audit/read und den Log-Viewer nur Administratoren.

Checkliste #

• To do: security.log ist in Setup > Logdateien aufgeführt und wird rotiert (mitgeliefert: 5 Archive, nach 90 Tagen bereinigt).
• To do: Ausnahmen von Regeln für Anwendungen von Kunden werden mit Excludes[] gemacht und pro Kunde dokumentiert.
• To do: Blockiert wird vor dem Kernel (Schutz, Webserver, Firewall), nicht vom Klassifizierer erwartet.
• To do: Das Prüfprotokoll wird von der Maschine weitergeleitet und nach Zeitplan geprüft.
• To do: Die Schlüsseldatei des Audits ist in jedem Backup.
• To do: Jemand sieht sich wöchentlich die Übersicht von security.log an.

Zeilen demo/mode. Jeder Prozess, der mit der Umgebungsvariablen EXP_DEMO_MODE=1 startet, schreibt eine Zeile: demo/mode on pid=<pid> sapi=<sapi> EXP_DEMO_MODE=1: .... Auf einer öffentlichen Demo ist das erwartet; auf jeder anderen Website bedeutet es, dass der Demomodus sie erreicht hat: Lösen Sie darauf einen Alarm aus. Probleme mit dem Demomodus.

Verwandte Seiten #

• Anfrage-Logs
• Log-Viewer und Log-Rotation
• Härtung für Hoster
• Kompromittierte Website (Runbook)
• Sicherheitshärtung
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.