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

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

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

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

<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

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

semanage fcontext -a -t var_log_t "/var/log/coraza(/.*)?"
restorecon -Rv /var/log/coraza

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

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

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

<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>

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

curl -k "https://waf.it213.xinmen.de/?id=1'+OR+'1'='1"

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

<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

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

Wazuh-Anbindung der WAF (Coraza) Rocky

Inhaltsverzeichnis