Einleitung

Die Sicherheit einer selbst gehosteten Cloud-Infrastruktur erfordert eine umfassende Überwachung auf mehreren Ebenen. In diesem Artikel beschreiben wir die vollständige Integration von Wazuh SIEM für Security Information and Event Management und Trivy für Container-Schwachstellenanalyse in unsere matzka.cloud Infrastruktur.

Was ist Wazuh SIEM?

Wazuh ist eine Open-Source Security Platform, die Security Information and Event Management (SIEM), Intrusion Detection (IDS), Vulnerability Detection, Log Analysis und Compliance Monitoring in einer einheitlichen Lösung vereint.

Architektur

Wazuh besteht aus mehreren Komponenten, die zusammenarbeiten:

Komponente	Funktion	Port
Wazuh Manager	Zentrale Verarbeitung, Regelauswertung, Active Response	1514, 1515, 55000
Wazuh Indexer	OpenSearch-basierte Speicherung und Indexierung	9200
Wazuh Dashboard	Web-UI für Visualisierung und Analyse	443
Wazuh Agent	Sammelt Logs und Events auf Hosts	-

Kernfunktionen

1. Log Data Analysis

Wazuh sammelt und analysiert Logs aus verschiedenen Quellen:

• System-Logs: auth.log, syslog, kern.log
• Security-Logs: audit.log, fail2ban.log
• Application-Logs: Traefik, Docker, Mailcow
• Custom-Logs: Gitea, Trivy, n8n

2. File Integrity Monitoring (FIM)

FIM überwacht kritische Systemdateien auf Änderungen:

<syscheck>
  <directories check_all="yes" realtime="yes">/etc</directories>
  <directories check_all="yes" realtime="yes">/usr/bin</directories>
  <directories check_all="yes" realtime="yes">/opt/docker/compose</directories>
  <ignore>/etc/mtab</ignore>
</syscheck>

3. Vulnerability Detection

Der integrierte Vulnerability Detector scannt installierte Pakete gegen CVE-Datenbanken (NVD, OVAL, etc.) und meldet bekannte Schwachstellen.

4. Security Configuration Assessment (SCA)

SCA prüft die Systemkonfiguration gegen Best Practices und Compliance-Standards wie CIS Benchmarks, PCI-DSS oder HIPAA.

5. Active Response

Bei erkannten Angriffen kann Wazuh automatisch reagieren:

<active-response>
  <command>firewall-drop</command>
  <location>defined-agent</location>
  <agent_id>001</agent_id>
  <rules_id>100501,100521,100541</rules_id>
  <timeout>900</timeout>
</active-response>

Wazuh in unserer Infrastruktur

Unsere Wazuh-Installation (Version 4.9.2) überwacht:

Kategorie	Quellen	Custom Rules
System	auth.log, syslog, kern.log, audit.log	Standard
Web Proxy	Traefik JSON Access Logs	100400-100460
Authentication	Authentik, Nextcloud, Grafana	100001-100022
Git Service	Gitea Logs	100500-100504
Container	Docker Events, Trivy Scans	100300-100612
Email	Postfix, Dovecot, Rspamd	100040-100051

Was ist Trivy?

Trivy ist ein umfassender Open-Source Security Scanner von Aqua Security. Er analysiert Container-Images, Dateisysteme, Git-Repositories und Kubernetes-Cluster auf Schwachstellen, Fehlkonfigurationen und Secrets.

Scan-Typen

Typ	Beschreibung	Befehl
Image Scan	Container-Images auf CVEs prüfen	trivy image nginx:latest
Filesystem	Lokale Verzeichnisse scannen	trivy fs /path/to/project
Repository	Git-Repos auf Secrets prüfen	trivy repo https://github.com/...
Config	IaC-Dateien auf Misconfigurations	trivy config ./terraform

Vulnerability-Datenbanken

Trivy nutzt mehrere Quellen für Schwachstelleninformationen:

• NVD (National Vulnerability Database) - US-amerikanische CVE-Datenbank
• GitHub Advisory Database - Schwachstellen in Open-Source-Projekten
• Red Hat Security Data - RHEL/CentOS-spezifische Advisories
• Alpine SecDB - Alpine Linux Security Database
• Debian Security Tracker - Debian-spezifische CVEs
• Ubuntu CVE Tracker - Ubuntu Security Notices

Severity-Klassifizierung

Severity	CVSS Score	Beschreibung
CRITICAL	9.0 - 10.0	Remote Code Execution, Root-Zugriff möglich
HIGH	7.0 - 8.9	Erhebliche Auswirkungen, zeitnahe Patches empfohlen
MEDIUM	4.0 - 6.9	Moderate Risiken, Patches in regulärem Zyklus
LOW	0.1 - 3.9	Geringe Risiken, informativ

Trivy in unserer Infrastruktur

Unsere Trivy-Installation (Version 0.68.2) scannt automatisch alle laufenden Container alle 6 Stunden:

#!/bin/bash
# /usr/local/bin/trivy-scan-containers.sh
# Läuft via Cron: 0 */6 * * *

LOG_FILE="/var/log/trivy/container-scan.log"
IMAGES=$(docker ps --format '{{.Image}}' | sort -u)

for image in $IMAGES; do
    SCAN_RESULT=$(trivy image --severity CRITICAL,HIGH \
                  --format json --quiet "$image")

    CRITICAL=$(echo "$SCAN_RESULT" | jq '...' )
    HIGH=$(echo "$SCAN_RESULT" | jq '...' )

    if [ "$CRITICAL" -gt 0 ] || [ "$HIGH" -gt 0 ]; then
        echo "[$TIMESTAMP] ALERT: trivy_scan image=$image \
              critical=$CRITICAL high=$HIGH" >> "$LOG_FILE"
    fi
done

Fail2ban Erweiterung für Gitea und Gotify

Fail2ban schützt Services vor Brute-Force-Angriffen durch temporäre IP-Blockierung nach mehreren fehlgeschlagenen Login-Versuchen. Wir haben zwei neue Services hinzugefügt:

Gitea Git Service

Herausforderung: Gitea gibt bei fehlgeschlagenen Logins HTTP 200 zurück (nicht 401), daher funktioniert der generische Traefik-Filter nicht.

Lösung: Eigener Filter für Gitea-Logs:

# /etc/fail2ban/filter.d/gitea.conf
[Definition]
failregex = ^.+Failed authentication attempt for .+ from <HOST>:\d+:.*$
datepattern = ^%%Y/%%m/%%d %%H:%%M:%%S

Da Gitea in Docker läuft, wurde ein systemd-Service erstellt, der die Logs in eine Datei exportiert:

# /etc/systemd/system/gitea-log-forward.service
[Unit]
Description=Forward Gitea container logs to file for fail2ban
After=docker.service

[Service]
Type=simple
ExecStart=/usr/bin/docker logs -f gitea
StandardOutput=append:/var/log/gitea/gitea.log
Restart=always

[Install]
WantedBy=multi-user.target

Gotify Push Service

Gotify gibt bei fehlgeschlagenen Logins HTTP 401 zurück, was über Traefik-Logs erfasst werden kann:

# /etc/fail2ban/filter.d/gotify.conf
[Definition]
failregex = "ClientHost":"<HOST>".+"DownstreamStatus":401.+"RequestHost":"gotify\.matzka\.cloud"

Jail-Konfiguration

# /etc/fail2ban/jail.d/matzka-bruteforce.conf

[gitea-login]
backend = auto
enabled = true
port = http,https
filter = gitea
logpath = /var/log/gitea/gitea.log
bantime = 3600
maxretry = 5
findtime = 600
action = iptables-multiport[name=GiteaBruteforce, port="http,https"]
         sendmail-whois[name=GiteaBruteforce, dest=reinhard@matzka.cloud]

[gotify-login]
backend = auto
enabled = true
port = http,https
filter = gotify
logpath = /opt/docker/compose/traefik/logs/access.log
bantime = 3600
maxretry = 5
findtime = 600
action = iptables-multiport[name=GotifyBruteforce, port="http,https"]
         sendmail-whois[name=GotifyBruteforce, dest=reinhard@matzka.cloud]

Aktive Fail2ban Jails (12 total)

Jail	Service	Max Retry	Ban Time
sshd	SSH	5	1h
authentik-login	auth.matzka.cloud	5	1h
nextcloud-login	next.matzka.cloud	5	1h
directus-login	cms.matzka.cloud	5	1h
n8n-login	n8n.matzka.cloud	5	1h
grafana-login	monitor.matzka.cloud	3	2h
wazuh-login	siem.matzka.cloud	3	2h
umami-login	analytics.matzka.cloud	10	30m
mailcow-webmail	mail.matzka.cloud	5	1h
traefik-bruteforce	alle (401/403)	5	1h
gitea-login	git.matzka.cloud	5	1h
gotify-login	gotify.matzka.cloud	5	1h

Wazuh Service-Integration

Zusätzlich zu den bestehenden Wazuh-Rules wurden neue Custom Rules für 6 Services erstellt, die bisher nicht explizit überwacht wurden.

Neue Custom Rules (webapp_services_rules.xml)

Gitea Git Service (100500-100504)

<decoder name="gitea-auth">
  <prematch>Failed authentication attempt for</prematch>
  <regex offset="after_prematch">\s(\S+) from (\S+):</regex>
  <order>dstuser,srcip</order>
</decoder>

<rule id="100500" level="5">
  <decoded_as>gitea-auth</decoded_as>
  <description>Gitea: Failed login attempt for $(dstuser) from $(srcip)</description>
  <group>authentication_failed,gitea,</group>
</rule>

<rule id="100501" level="10" frequency="5" timeframe="120">
  <if_matched_sid>100500</if_matched_sid>
  <same_source_ip />
  <description>Gitea: Brute-force attack detected from $(srcip)</description>
  <group>authentication_failures,gitea,attack,</group>
</rule>

Gotify Push Notifications (100520-100522)

<rule id="100520" level="5">
  <decoded_as>json</decoded_as>
  <field name="RequestHost">gotify.matzka.cloud</field>
  <field name="DownstreamStatus">401</field>
  <description>Gotify: Authentication failed from $(ClientHost)</description>
  <group>authentication_failed,gotify,</group>
</rule>

<rule id="100521" level="10" frequency="5" timeframe="120">
  <if_matched_sid>100520</if_matched_sid>
  <same_source_ip />
  <description>Gotify: Brute-force attack detected</description>
</rule>

Directus CMS (100540-100543)

<rule id="100540" level="5">
  <decoded_as>json</decoded_as>
  <field name="RequestHost">cms.matzka.cloud</field>
  <field name="DownstreamStatus">401</field>
  <description>Directus: Authentication failed</description>
</rule>

<rule id="100543" level="4">
  <decoded_as>json</decoded_as>
  <field name="RequestHost">cms.matzka.cloud</field>
  <field name="RequestPath">/admin</field>
  <description>Directus: Admin panel accessed</description>
</rule>

Umami Analytics (100560-100562)

<rule id="100560" level="5">
  <decoded_as>json</decoded_as>
  <field name="RequestHost">analytics.matzka.cloud</field>
  <field name="DownstreamStatus">401</field>
  <description>Umami: Authentication failed</description>
</rule>

Dockge Container Management (100580-100581)

<rule id="100580" level="6">
  <decoded_as>json</decoded_as>
  <field name="RequestHost">dockge.matzka.cloud</field>
  <field name="DownstreamStatus">401</field>
  <description>Dockge: Unauthorized access attempt</description>
</rule>

Wazuh Dashboard (100590-100591)

<rule id="100590" level="7">
  <decoded_as>json</decoded_as>
  <field name="RequestHost">siem.matzka.cloud</field>
  <field name="DownstreamStatus">401</field>
  <description>Wazuh Dashboard: Authentication failed</description>
</rule>

<rule id="100591" level="12" frequency="3" timeframe="120">
  <if_matched_sid>100590</if_matched_sid>
  <description>Wazuh Dashboard: CRITICAL - Brute-force on SIEM</description>
</rule>

Active Response Integration

Die neuen Brute-Force-Rules wurden zur Active Response hinzugefügt:

<active-response>
  <command>firewall-drop</command>
  <location>defined-agent</location>
  <agent_id>001</agent_id>
  <rules_id>100002,100012,100021,100041,100051,
             100501,100521,100541,100561,100581,100591</rules_id>
  <timeout>900</timeout>
</active-response>

Trivy-Wazuh Integration

Die vollständige Integration von Trivy in Wazuh ermöglicht die zentrale Überwachung von Container-Schwachstellen im SIEM-System.

Log-Quelle Konfiguration

Trivy-Logs werden vom Wazuh Manager überwacht:

<!-- /var/ossec/etc/ossec.conf -->
<localfile>
  <log_format>syslog</log_format>
  <location>/host-logs/trivy/container-scan.log</location>
</localfile>

Trivy Decoder

<!-- /var/ossec/etc/decoders/trivy_decoder.xml -->

<!-- Alert Decoder -->
<decoder name="trivy-alert">
  <prematch>ALERT: trivy_scan</prematch>
  <regex>image=(\S+) critical=(\d+) high=(\d+) total=(\d+)</regex>
  <order>url,srcuser,dstuser,srcport</order>
</decoder>

<!-- CVE Decoder -->
<decoder name="trivy-cve">
  <prematch>CVE: trivy_vulnerability</prematch>
  <regex>image=(\S+) cve=(\S+) package=(\S+) severity=(\S+)</regex>
  <order>url,data,dstuser,action</order>
</decoder>

<!-- Clean Decoder -->
<decoder name="trivy-clean">
  <prematch>INFO: Image=</prematch>
  <regex>Image=(\S+) Status=(\S+)</regex>
  <order>url,action</order>
</decoder>

Trivy Rules (100600-100612)

Rule ID	Level	Beschreibung
100601	12	CRITICAL vulnerabilities in container
100602	10	HIGH vulnerabilities in container
100606	11	CRITICAL CVE detected
100607	8	HIGH CVE detected
100610	3	Container image is clean
100611	3	Scan started
100612	3	Scan completed

Beispiel-Alert in Wazuh

** Alert 1770235283.9166585: mail  - trivy,vulnerability,high,
2026 Feb 04 20:01:23 wazuh->/host-logs/trivy/container-scan.log
Rule: 100602 (level 10) -> 'Trivy: HIGH vulnerabilities in prometheus:latest'
[2026-02-04T20:00:00+00:00] ALERT: trivy_scan image=prometheus:latest
                           critical=0 high=4 total=4

Alerting & Benachrichtigungen

Das Alerting-System nutzt mehrere Kanäle für verschiedene Severity-Level:

Benachrichtigungskanäle

Kanal	Level	Verwendung
Email	10+	Kritische Alerts, tägliche Zusammenfassungen
Gotify Push	7+	Echtzeit-Benachrichtigungen auf Mobilgeräte
Wazuh Dashboard	alle	Vollständige Analyse und Forensik

Alert-Flow

Container-Scan (Trivy)
       ↓
Log-Datei (/var/log/trivy/container-scan.log)
       ↓
Wazuh Logcollector (überwacht Datei)
       ↓
Wazuh Decoder (extrahiert Felder)
       ↓
Wazuh Rules (klassifiziert Severity)
       ↓
Alerting:
├── Level 12: Email + Gotify (Priority 9)
├── Level 10: Email + Gotify (Priority 8)
├── Level 7+: Gotify (Priority 5)
└── Level <7: Dashboard only

Gotify Integration

Wazuh sendet Push-Benachrichtigungen über das custom-gotify Integration-Script:

# /var/ossec/integrations/custom-gotify

# Priority-Mapping:
# Level 12+ → Priority 9 (höchste)
# Level 10+ → Priority 8
# Level 7+  → Priority 5

curl -X POST "https://gotify.matzka.cloud/message" \
     -H "X-Gotify-Key: $GOTIFY_TOKEN" \
     -F "title=Wazuh Alert (Level $LEVEL)" \
     -F "message=$DESCRIPTION" \
     -F "priority=$PRIORITY"

Zusammenfassung

Implementierte Änderungen

Security-Status Übersicht

Komponente	Status	Überwachung
Host System	✓ Aktuell	Wazuh Agent + FIM
CVE-2026-0861 (glibc)	✓ Behoben	Vulnerability Detector
Container Images	⚠ 4 HIGH	Trivy + Wazuh
Brute-Force Schutz	✓ 12 Jails	Fail2ban + Wazuh AR
Service Monitoring	✓ Vollständig	Wazuh Custom Rules

Nächste Schritte

• Container-Updates überwachen (Prometheus, Mailcow Dovecot)
• Wazuh SCA Baseline-Verbesserungen umsetzen
• Alerting-Schwellwerte fine-tunen