Aktuelle Version vom 9. September 2026, 11:14 Uhr

Wazuh-Anbindung der WAF (Coraza)

Die WAF (HAProxy + Coraza-SPOA) liefert die Abwehr-Telemetrie an das SIEM: welcher Angriff wurde von welcher Regel geblockt. Das ergänzt die VulnSite-Sicht — dort sieht Wazuh den Angriffsversuch im Apache-Log, hier sieht es die Abwehr davor.

Hinweis: Wazuhs eingebaute ModSecurity-Regeln greifen nur auf das Apache-error.log klassischer ModSecurity. Coraza-SPOA schreibt ein eigenes Audit-Log und läuft nicht über Apache — daher binden wir das Coraza-JSON-Audit-Log ein und ergänzen einen eigenen Decoder samt Regel auf dem Manager.

Repository einrichten

GPG-Schlüssel importieren

rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH

Repository hinzufügen

cat > /etc/yum.repos.d/wazuh.repo << 'EOF'
[wazuh]
name=Wazuh repository
baseurl=https://packages.wazuh.com/4.x/yum/
gpgcheck=1
gpgkey=https://packages.wazuh.com/key/GPG-KEY-WAZUH
enabled=1
protect=1
EOF

Agent installieren

Agent mit Manager-Adresse und Namen installieren

WAZUH_MANAGER="wazuh.dkbi.com" WAZUH_AGENT_NAME="waf" dnf install -y wazuh-agent

Dienst aktivieren und starten

systemctl daemon-reload
systemctl enable --now wazuh-agent

Repository deaktivieren (verhindert ungewollte Updates)

sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo

Audit-Log in Coraza aktivieren

Die Grundinstallation aus WAF-Demo: HAProxy mit Coraza auf Rocky Linux setzt nur SecRuleEngine On. Coraza blockt damit zwar, protokolliert die Treffer aber nirgends. Ohne Audit-Log hat der Agent nichts zu lesen.

Wichtig: Die SecAudit-Direktiven sind SecRules-Anweisungen, keine YAML-Optionen. Sie gehören in den directives-Block der Anwendung — und hinter die Includes, da @coraza.conf-recommended eigene Audit-Voreinstellungen mitbringt, die sonst gewinnen.

Zielverzeichnis anlegen

mkdir -p /var/log/coraza

In /etc/coraza-spoa/config.yaml den directives-Block der Anwendung revproxy ergänzen

    directives: |
      Include @coraza.conf-recommended
      Include /etc/coraza-spoa/crs-setup.conf
      Include /etc/coraza-spoa/coreruleset/rules/*.conf
      SecRuleEngine On
      SecAuditEngine RelevantOnly
      SecAuditLogRelevantStatus "^(?:4|5)"
      SecAuditLogParts ABIJDEFHZ
      SecAuditLogType Serial
      SecAuditLogFormat JSON
      SecAuditLog /var/log/coraza/audit.log

Bedeutung der Zeilen

SecAuditEngine RelevantOnly — nur auffällige Transaktionen, nicht jeder normale Seitenaufruf
SecAuditLogRelevantStatus — was als auffällig gilt; hier alle 4xx und 5xx, damit der 403 der WAF sicher erfasst wird
SecAuditLogType Serial — eine gemeinsame Logdatei. Ohne diese Zeile legt Coraza pro Transaktion eine eigene Datei in einem Verzeichnisbaum an, und der Agent findet nichts
SecAuditLogFormat JSON — statt des nativen ModSecurity-Formats (Multiline mit Trennern wie --aaCuCNaqNi-A--), das Wazuh nicht parsen kann

Daemon neu starten

systemctl restart coraza-spoa
systemctl status coraza-spoa

Angriff absetzen und eine Zeile prüfen — muss mit { beginnen

Über den browser auf www.it2XX.xinmen.de und dann eine SQL Injection auslösen. 
tail -1 /var/log/coraza/audit.log

Audit-Log anbinden

In /var/ossec/etc/ossec.conf auf der WAF

<localfile>
  <log_format>json</log_format>
  <location>/var/log/coraza/audit.log</location>
</localfile>

Syntax prüfen, bevor neu gestartet wird

/var/ossec/bin/wazuh-logcollector -t

Agent neu starten

systemctl restart wazuh-agent

Kontrolle, dass die Datei überwacht wird

grep "audit.log" /var/ossec/logs/ossec.log

Der Logcollector liest nur Zeilen, die nach dem Öffnen der Datei dazukommen. Angriffe von vorher tauchen nicht mehr auf.

Decoder und Regel (auf dem Wazuh-Manager)

Coraza-JSON wird vom generischen JSON-Decoder zerlegt, aber von keiner eingebauten Regel klassifiziert. Beides ergänzen.

Decoder in /var/ossec/etc/decoders/local-coraza_decoders.xml

<decoder name="coraza-audit">
  <prematch>^{"transaction":</prematch>
  <plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>

Regel in /var/ossec/etc/rules/local_rules.xml ergänzen

<group name="coraza,waf,">
  <rule id="100100" level="0">
    <decoded_as>json</decoded_as>
    <field name="transaction.client_ip">\.+</field>
    <description>Coraza WAF Audit-Log.</description>
  </rule>
  <rule id="100101" level="10">
    <if_sid>100100</if_sid>
    <field name="transaction.is_interrupted">true</field>
    <description>Coraza WAF: Angriff geblockt auf $(transaction.request.uri) von $(transaction.client_ip).</description>
    <group>attack,web,</group>
  </rule>
</group>

Regel-IDs prüfen

Sind 100100/100101 auf diesem Manager bereits vergeben, startet wazuh-manager nicht mehr und meldet Duplicated rule ID im ossec.log. Dann auf freie IDs ausweichen.

grep -rh 'rule id="1001' /var/ossec/etc/rules/

Eigentümer und Rechte setzen

chown wazuh:wazuh /var/ossec/etc/decoders/local-coraza_decoders.xml /var/ossec/etc/rules/local_rules.xml
chmod 660 /var/ossec/etc/decoders/local-coraza_decoders.xml /var/ossec/etc/rules/local_rules.xml

Vor dem Neustart mit logtest prüfen — eine echte JSON-Audit-Zeile reinpasten

/var/ossec/bin/wazuh-logtest

Erwartete Ausgabe: transaction.is_interrupted: 'true in Phase 2 und Rule id: '100101 in Phase 3.

Erst dann Manager neu starten

systemctl restart wazuh-manager

Kontrolle

Angriff von der Kali gegen die WAF

Angriff über die Weboberfläche www.it2XX.xinmen.de - Command und SQl Injection

Im Dashboard

Öffne Threat Hunting, Filter rule.id:100101
Der Alert "Coraza WAF: Angriff geblockt" muss erscheinen

Beide Blickwinkel nebeneinander

Filter rule.id:100101 OR rule.id:31103 zeigt die geblockte Anfrage auf der WAF und — falls durchgelassen — dieselbe Anfrage im Apache-Log der VulnSite

Fehlersuche

Die Kette von unten nach oben prüfen, in dieser Reihenfolge.

1. Blockt Coraza überhaupt?

curl -k -o /dev/null -w "%{http_code}\n" "https://waf.it2XX.xinmen.de/?id=1'+OR+'1'='1"

Kommt 200 statt 403, ist die Rule-Engine das Problem, nicht das SIEM.

2. Schreibt Coraza ins Audit-Log?

tail -f /var/log/coraza/audit.log — dann den curl absetzen

3. Liest der Agent die Datei?

grep "Analyzing file" /var/ossec/logs/ossec.log

4. Erreichen die Zeilen den Manager? Auf dem Manager logall_json aktivieren

<global>
  <logall_json>yes</logall_json>
</global>

tail -f /var/ossec/logs/archives/archives.json | jq 'select(.agent.name=="waf")'
Nach der Übung wieder auf no — Archives werden nicht rotiert

5. Steht die Verbindung?

Auf dem Manager: /var/ossec/bin/agent_control -l
Auf der WAF: grep -E "Connected to the server|Unable to connect" /var/ossec/logs/ossec.log

@@ Zeile 37: / Zeile 37: @@
 </syntaxhighlight>
-== Coraza-Audit-Log auf JSON umstellen ==
+== Audit-Log in Coraza aktivieren ==
-Das Audit-Log liegt standardmäßig im nativen ModSecurity-Format (Multiline mit Trennern wie ''--aaCuCNaqNi-A--''). Das kann Wazuh nicht sauber parsen. Auf JSON umstellen.
+Die Grundinstallation aus [[WAF-Demo: HAProxy mit Coraza auf Rocky Linux]] setzt nur ''SecRuleEngine On''. Coraza blockt damit zwar, protokolliert die Treffer aber nirgends. Ohne Audit-Log hat der Agent nichts zu lesen.
-'''Wichtig:''' ''SecAuditLogFormat'' ist eine SecRules-Direktive, keine YAML-Option. Sie darf nicht auf oberster Ebene der ''coraza-spoa.yaml'' stehen — dort gehört sie in den ''directives''-Block der Anwendung.
+'''Wichtig:''' Die ''SecAudit''-Direktiven sind SecRules-Anweisungen, keine YAML-Optionen. Sie gehören in den ''directives''-Block der Anwendung — und '''hinter''' die Includes, da ''@coraza.conf-recommended'' eigene Audit-Voreinstellungen mitbringt, die sonst gewinnen.
-;In ''/etc/coraza-spoa/coraza-spoa.yaml''
+;Zielverzeichnis anlegen
+<syntaxhighlight lang="bash">
+mkdir -p /var/log/coraza
+</syntaxhighlight>
+;In ''/etc/coraza-spoa/config.yaml'' den ''directives''-Block der Anwendung ''revproxy'' ergänzen
 <syntaxhighlight lang="yaml">
-applications:
-  - name: default
      directives: |
+      Include @coraza.conf-recommended
+      Include /etc/coraza-spoa/crs-setup.conf
+      Include /etc/coraza-spoa/coreruleset/rules/*.conf
        SecRuleEngine On
        SecAuditEngine RelevantOnly
+      SecAuditLogRelevantStatus "^(?:4|5)"
+      SecAuditLogParts ABIJDEFHZ
        SecAuditLogType Serial
        SecAuditLogFormat JSON
        SecAuditLog /var/log/coraza/audit.log
-      SecAuditLogParts ABIJDEFHZ
-      Include @coraza.conf-recommended
-      Include @crs-setup.conf.example
-      Include @owasp_crs/*.conf
 </syntaxhighlight>
-;Bindet die Konfiguration stattdessen eine externe Regeldatei ein, gehören die drei Audit-Zeilen dorthin
+;Bedeutung der Zeilen
+* ''SecAuditEngine RelevantOnly'' — nur auffällige Transaktionen, nicht jeder normale Seitenaufruf
+* ''SecAuditLogRelevantStatus'' — was als auffällig gilt; hier alle 4xx und 5xx, damit der 403 der WAF sicher erfasst wird
+* ''SecAuditLogType Serial'' — eine gemeinsame Logdatei. Ohne diese Zeile legt Coraza pro Transaktion eine eigene Datei in einem Verzeichnisbaum an, und der Agent findet nichts
+* ''SecAuditLogFormat JSON'' — statt des nativen ModSecurity-Formats (Multiline mit Trennern wie ''--aaCuCNaqNi-A--''), das Wazuh nicht parsen kann
 ;Daemon neu starten
-* systemctl restart coraza-spoa
+<syntaxhighlight lang="bash">
-;Eine Zeile prüfen — muss jetzt mit { beginnen
+systemctl restart coraza-spoa
-* tail -1 /var/log/coraza/audit.log
+systemctl status coraza-spoa
+</syntaxhighlight>
+;Angriff absetzen und eine Zeile prüfen — muss mit { beginnen
+<syntaxhighlight lang="bash">
+Über den browser auf www.it2XX.xinmen.de und dann eine SQL Injection auslösen.
+tail -1 /var/log/coraza/audit.log
+</syntaxhighlight>
 == Audit-Log anbinden ==
@@ Zeile 73: / Zeile 87: @@
 * /var/ossec/bin/wazuh-logcollector -t
-== SELinux-Kontext des Audit-Logs ==
+<!---
-Wurde ''/var/log/coraza'' von Hand angelegt, trägt es nicht zwingend den richtigen Kontext. Der Logcollector liest die Datei dann nicht — ohne sichtbare Fehlermeldung im ossec.log.
-;Kontext prüfen
+== SELinux und Leserechte ==
+Beide Dienste laufen auf dieser Maschine unbeschränkt — coraza-spoa als eigene Unit ohne Policy, der Wazuh-Logcollector als ''root''. In der Regel ist hier nichts zu tun. Die folgenden Schritte sind Kontrollen für den Fall, dass das Audit-Log zwar gefüllt wird, aber nichts im SIEM ankommt.
+;Kontext prüfen — erwartet wird ''var_log_t''
 * ls -Zd /var/log/coraza /var/log/coraza/audit.log
-;Erwartet wird ''var_log_t'' — sonst dauerhaft setzen
+;Bei abweichendem Kontext dauerhaft setzen
 <syntaxhighlight lang="bash">
 semanage fcontext -a -t var_log_t "/var/log/coraza(/.*)?"
@@ Zeile 84: / Zeile 100: @@
 ;Gegenprobe bei Verdacht auf SELinux
 * ausearch -m avc -ts recent
+;Lesezugriff testen
-== Leserechte für den Agent ==
-Der Logcollector läuft als ''root'', Rechte sind daher selten die Ursache. Nur wenn die Datei einem Dienstuser mit restriktiver Maske gehört, ist eine ACL nötig.
-;Zugriff testen
 * sudo -u wazuh cat /var/log/coraza/audit.log > /dev/null
-;Bei "Permission denied" — ''acl'' ist auf Rocky-Minimal nicht vorinstalliert
+;Nur bei "Permission denied" — ''acl'' ist auf Rocky-Minimal nicht vorinstalliert
 <syntaxhighlight lang="bash">
 dnf install -y acl
-chmod 640 /var/log/coraza/audit.log
 setfacl -m u:wazuh:rx /var/log/coraza/
 setfacl -m u:wazuh:r /var/log/coraza/audit.log
 </syntaxhighlight>
+--->
 == Agent neu starten ==
-* systemctl restart wazuh-agent
+<syntaxhighlight lang="bash">
+systemctl restart wazuh-agent
+</syntaxhighlight>
 ;Kontrolle, dass die Datei überwacht wird
 * grep "audit.log" /var/ossec/logs/ossec.log
+Der Logcollector liest nur Zeilen, die '''nach''' dem Öffnen der Datei dazukommen. Angriffe von vorher tauchen nicht mehr auf.
 == Decoder und Regel (auf dem Wazuh-Manager) ==
@@ Zeile 127: / Zeile 143: @@
 </group>
 </syntaxhighlight>
+;Regel-IDs prüfen
+Sind 100100/100101 auf diesem Manager bereits vergeben, startet ''wazuh-manager'' nicht mehr und meldet ''Duplicated rule ID'' im ossec.log. Dann auf freie IDs ausweichen.
+* grep -rh 'rule id="1001' /var/ossec/etc/rules/
 ;Eigentümer und Rechte setzen
 <syntaxhighlight lang="bash">
@@ Zeile 141: / Zeile 160: @@
 ;Angriff von der Kali gegen die WAF
 <syntaxhighlight lang="bash">
-curl -k "https://waf.it213.xinmen.de/?id=1'+OR+'1'='1"
+Angriff über die Weboberfläche www.it2XX.xinmen.de - Command und SQl Injection
 </syntaxhighlight>
 ;Im Dashboard
 * Öffne ''Threat Hunting'', Filter ''rule.id:100101''
 * Der Alert "Coraza WAF: Angriff geblockt" muss erscheinen
+;Beide Blickwinkel nebeneinander
+* Filter ''rule.id:100101 OR rule.id:31103'' zeigt die geblockte Anfrage auf der WAF und — falls durchgelassen — dieselbe Anfrage im Apache-Log der VulnSite
 == Fehlersuche ==
-Kommt im Dashboard nichts an, die Kette von unten nach oben prüfen.
+Die Kette von unten nach oben prüfen, in dieser Reihenfolge.
-;1. Schreibt Coraza überhaupt?
+;1. Blockt Coraza überhaupt?
+<syntaxhighlight lang="bash">
+curl -k -o /dev/null -w "%{http_code}\n" "https://waf.it2XX.xinmen.de/?id=1'+OR+'1'='1"
+</syntaxhighlight>
+Kommt 200 statt 403, ist die Rule-Engine das Problem, nicht das SIEM.
+;2. Schreibt Coraza ins Audit-Log?
 * tail -f /var/log/coraza/audit.log — dann den curl absetzen
-;2. Liest der Agent die Datei?
+;3. Liest der Agent die Datei?
 * grep "Analyzing file" /var/ossec/logs/ossec.log
-;3. Erreichen die Zeilen den Manager? Auf dem Manager ''logall_json'' aktivieren
+;4. Erreichen die Zeilen den Manager? Auf dem Manager ''logall_json'' aktivieren
 <syntaxhighlight lang="xml">
 <global>
@@ Zeile 161: / Zeile 187: @@
 * tail -f /var/ossec/logs/archives/archives.json | jq 'select(.agent.name=="waf")'
 * Nach der Übung wieder auf ''no'' — Archives werden nicht rotiert
-;4. Steht die Verbindung?
+;5. Steht die Verbindung?
 * Auf dem Manager: /var/ossec/bin/agent_control -l
 * Auf der WAF: grep -E "Connected to the server|Unable to connect" /var/ossec/logs/ossec.log

Wazuh-Anbindung der WAF (Coraza) Rocky: Unterschied zwischen den Versionen