Wazuh-Anbindung der WAF (Coraza) Rocky - Versionsgeschichte

Thomas.will: /* Kontrolle */

2026-09-09T11:14:21Z

Kontrolle

Thomas.will: /* SELinux und Leserechte */

2026-09-09T11:07:15Z

SELinux und Leserechte

Thomas.will: /* Audit-Log in Coraza aktivieren */

2026-09-09T11:02:59Z

Audit-Log in Coraza aktivieren

Thomas.will: /* Audit-Log in Coraza aktivieren */

2026-09-09T11:01:25Z

Audit-Log in Coraza aktivieren

Thomas.will am 9. September 2026 um 09:24 Uhr

2026-09-09T09:24:01Z

Thomas.will: Die Seite wurde neu angelegt: „=Wazuh-Anbindung der WAF (Coraza)= Die '''WAF''' (HAProxy + Coraza-SPOA) liefert die Abwehr-Telemetrie an das SIEM: welcher Angriff wurde von welcher Regel geb…“

2026-09-09T09:17:44Z

Die Seite wurde neu angelegt: „=Wazuh-Anbindung der WAF (Coraza)= Die '''WAF''' (HAProxy + Coraza-SPOA) liefert die Abwehr-Telemetrie an das SIEM: welcher Angriff wurde von welcher Regel geb…“

Neue Seite

=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
<syntaxhighlight lang="bash">
rpm --import https://packages.wazuh.com/key/GPG-KEY-WAZUH
</syntaxhighlight>
;Repository hinzufügen
<syntaxhighlight lang="bash">
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
</syntaxhighlight>

== Agent installieren ==
;Agent mit Manager-Adresse und Namen installieren
<syntaxhighlight lang="bash">
WAZUH_MANAGER="wazuh.dkbi.com" WAZUH_AGENT_NAME="waf" dnf install -y wazuh-agent
</syntaxhighlight>
;Dienst aktivieren und starten
<syntaxhighlight lang="bash">
systemctl daemon-reload
systemctl enable --now wazuh-agent
</syntaxhighlight>
;Repository deaktivieren (verhindert ungewollte Updates)
<syntaxhighlight lang="bash">
sed -i "s/^enabled=1/enabled=0/" /etc/yum.repos.d/wazuh.repo
</syntaxhighlight>

== Coraza-Audit-Log auf JSON umstellen ==
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.

'''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.
;In ''/etc/coraza-spoa/coraza-spoa.yaml''
<syntaxhighlight lang="yaml">
applications:
- name: default
directives: |
SecRuleEngine On
SecAuditEngine RelevantOnly
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
;Daemon neu starten
* systemctl restart coraza-spoa
;Eine Zeile prüfen — muss jetzt mit { beginnen
* tail -1 /var/log/coraza/audit.log

== Audit-Log anbinden ==
;In ''/var/ossec/etc/ossec.conf'' auf der WAF
<syntaxhighlight lang="xml">
<localfile>
<log_format>json</log_format>
<location>/var/log/coraza/audit.log</location>
</localfile>
</syntaxhighlight>
;Syntax prüfen, bevor neu gestartet wird
* /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
* ls -Zd /var/log/coraza /var/log/coraza/audit.log
;Erwartet wird ''var_log_t'' — sonst dauerhaft setzen
<syntaxhighlight lang="bash">
semanage fcontext -a -t var_log_t "/var/log/coraza(/.*)?"
restorecon -Rv /var/log/coraza
</syntaxhighlight>
;Gegenprobe bei Verdacht auf SELinux
* ausearch -m avc -ts recent

== 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
<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
;Kontrolle, dass die Datei überwacht wird
* grep "audit.log" /var/ossec/logs/ossec.log

== 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''
<syntaxhighlight lang="xml">
<decoder name="coraza-audit">
<prematch>^{"transaction":</prematch>
<plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>
</syntaxhighlight>
;Regel in ''/var/ossec/etc/rules/local_rules.xml'' ergänzen
<syntaxhighlight lang="xml">
<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>
</syntaxhighlight>
;Eigentümer und Rechte setzen
<syntaxhighlight lang="bash">
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
</syntaxhighlight>
;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
<syntaxhighlight lang="bash">
curl -k "https://waf.it213.xinmen.de/?id=1'+OR+'1'='1"
</syntaxhighlight>
;Im Dashboard
* Öffne ''Threat Hunting'', Filter ''rule.id:100101''
* Der Alert "Coraza WAF: Angriff geblockt" muss erscheinen

== Fehlersuche ==
Kommt im Dashboard nichts an, die Kette von unten nach oben prüfen.
;1. Schreibt Coraza überhaupt?
* tail -f /var/log/coraza/audit.log — dann den curl absetzen
;2. 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
<syntaxhighlight lang="xml">
<global>
<logall_json>yes</logall_json>
</global>
</syntaxhighlight>
* 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?
* 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

[[Kategorie:WAZUH]]
[[Kategorie:Coraza]]

@@ Zeile 72: / Zeile 72: @@
 ;Angriff absetzen und eine Zeile prüfen — muss mit { beginnen
 <syntaxhighlight lang="bash">
-curl -ik "https://www.it2XX.xinmen.de/?id=1' OR '1'='1"
+Über den browser auf www.it2XX.xinmen.de und dann eine SQL Injection auslösen.
 tail -1 /var/log/coraza/audit.log
 </syntaxhighlight>

@@ Zeile 72: / Zeile 72: @@
 ;Angriff absetzen und eine Zeile prüfen — muss mit { beginnen
 <syntaxhighlight lang="bash">
-curl -ik "https://waf.it2XX.xinmen.de/?id=1' OR '1'='1"
+curl -ik "https://www.it2XX.xinmen.de/?id=1' OR '1'='1"
 tail -1 /var/log/coraza/audit.log
 </syntaxhighlight>

@@ Zeile 160: / Zeile 160: @@
 ;Angriff von der Kali gegen die WAF
 <syntaxhighlight lang="bash">
-curl -k "https://waf.it2XX.xinmen.de/?id=1'+OR+'1'='1"
+Angriff über die Weboberfläche www.it2XX.xinmen.de - Command und SQl Injection
 </syntaxhighlight>
 ;Im Dashboard

@@ Zeile 86: / Zeile 86: @@
 ;Syntax prüfen, bevor neu gestartet wird
 * /var/ossec/bin/wazuh-logcollector -t
 == SELinux und Leserechte ==
@@ Zeile 106: / Zeile 108: @@
 setfacl -m u:wazuh:r /var/log/coraza/audit.log
 </syntaxhighlight>
 == Agent neu starten ==

@@ 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''
 <syntaxhighlight lang="yaml">
      directives: |
        SecRuleEngine On
        SecAuditEngine RelevantOnly
        SecAuditLogType Serial
        SecAuditLogFormat JSON
        SecAuditLog /var/log/coraza/audit.log
 </syntaxhighlight>
-;Bindet die Konfiguration stattdessen eine externe Regeldatei ein, gehören die drei Audit-Zeilen dorthin
+;Bedeutung der Zeilen
 ;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
 == Audit-Log anbinden ==
@@ Zeile 73: / Zeile 87: @@
 * /var/ossec/bin/wazuh-logcollector -t
-== SELinux-Kontext des Audit-Logs ==
+== SELinux und Leserechte ==
-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.
+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
+;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 98: @@
 ;Gegenprobe bei Verdacht auf SELinux
 * ausearch -m avc -ts recent
+;Lesezugriff 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
 setfacl -m u:wazuh:rx /var/log/coraza/
 setfacl -m u:wazuh:r /var/log/coraza/audit.log
@@ Zeile 98: / Zeile 108: @@
 == Agent neu starten ==
-* systemctl restart wazuh-agent
+<syntaxhighlight lang="bash">
 ;Kontrolle, dass die Datei überwacht wird
 * grep "audit.log" /var/ossec/logs/ossec.log
 == Decoder und Regel (auf dem Wazuh-Manager) ==
@@ Zeile 127: / Zeile 140: @@
 </group>
 </syntaxhighlight>
 ;Eigentümer und Rechte setzen
 <syntaxhighlight lang="bash">
@@ Zeile 141: / Zeile 157: @@
 ;Angriff von der Kali gegen die WAF
 <syntaxhighlight lang="bash">
-curl -k "https://waf.it213.xinmen.de/?id=1'+OR+'1'='1"
+curl -k "https://waf.it2XX.xinmen.de/?id=1'+OR+'1'='1"
 </syntaxhighlight>
 ;Im Dashboard
 * Öffne ''Threat Hunting'', Filter ''rule.id:100101''
 * Der Alert "Coraza WAF: Angriff geblockt" muss erscheinen
 == 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?
 * 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 184: @@
 * 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