# Firewall Monitoring: Den Datenverkehr sichtbar machen

TL;DR / Management Summary Eine Firewall, die nur blockiert, ohne zu protokollieren, ist ein Blindflug. Wir müssen wissen, wer wann versucht hat, auf welche Ports zuzugreifen. In diesem Modul lernen wir, wie wir Log-Regeln in nftables und iptables einbauen, wie wir das System-Journal durch hunderte Log-Meldungen pro Sekunde entlasten (ulogd2) und wie wir Firewall-Statistiken in Dashboards (Grafana) überführen.

# 1. Einführung & Architektur

Der Weg vom Paket zum Log-Eintrag.

Normalerweise schreibt der Kernel Firewall-Events direkt in das Kernel-Log (dmesg). Bei hohem Aufkommen kann dies das System verlangsamen.

# Die Logging-Pipeline (Mermaid)

graph LR
    A[Firewall Rule: log] --> B{Strategy}
    B -->|Standard| C[Kernel Log: syslog / journald]
    B -->|Performance| D[Netlink Group: ulogd2]
    C --> E[Admin: journalctl -k]
    D --> F[Database: MySQL / Postgres]
    D --> G[Metrics: Prometheus Exporter]
    F/G --> H[Dashboard: Grafana]

# 2. Logging in Aktion

Regeln schärfen.

# In firewalld (Einfach)

# Logge alle abgelehnten Pakete
sudo firewall-cmd --set-log-denied=all

# In nftables (Präzise)

# Innerhalb einer Chain
tcp dport 22 log prefix "SSH_ATTEMPT: " limit rate 5/minute accept

# 3. Performance-Logging mit ulogd2

Den User-Space nutzen.

In Enterprise-Umgebungen mit viel Traffic nutzen wir ulogd2. Es entlastet den Kernel, indem es Pakete über Netlink-Multicast-Gruppen an einen User-Space-Dämon sendet.

# Einrichtung

sudo apt install ulogd2 # Debian/Ubuntu
# Konfiguration in /etc/ulogd.conf
# Hier können Sie CSV, SQL oder JSON als Output wählen.

# 4. Day-2 Operations: Visualisierung

Zahlen statt Text.

Statistiken sind oft wertvoller als einzelne Logzeilen.

# Paket-Zähler in nftables

Jede nftables-Regel zählt automatisch mit.

# Zeige Zähler für alle Regeln
sudo nft list ruleset

# Prometheus Integration

Nutzen Sie den nftables-exporter, um Daten wie “Anzahl DROPs pro Interface” in Grafana zu visualisieren. So erkennen Sie Port-Scans oder DDoS-Attacken sofort an einem steilen Kurvenverlauf.

# 5. Troubleshooting & “War Stories”

Wenn das Loggen den Server killt.

# Story 1: “Der hängende Syslog”

Symptom: Der Server reagiert extrem träge, kswapd und syslogd verbrauchen 100% CPU. Ursache: Ein Angreifer flutet einen geschlossenen Port mit Millionen Paketen. Die Firewall loggt jedes einzelne Paket in das System-Journal. Der Schreibvorgang blockiert den Kernel. Lösung: Nutzen Sie Rate-Limiting direkt in der Log-Regel oder nutzen Sie ulogd2 mit einem Puffer.

# Story 2: “Das verschwundene Prefix”

Symptom: In ELK kommen Logs an, aber die Filter funktionieren nicht, weil das Feld prefix leer ist. Ursache: In nftables muss das Prefix in Anführungszeichen stehen und darf eine bestimmte Länge (meist 64 Zeichen) nicht überschreiten. Lösung: Halten Sie Prefixes kurz und bündig (z.B. FW_DENY_HTTP).

# 6. Fazit & Empfehlung

• Rate-Limit: Loggen Sie niemals ohne limit rate.
• Zentralisierung: Senden Sie Firewall-Logs immer an ein SIEM (Artikel 148).
• Performance: Nutzen Sie ulogd2, wenn Ihr Server mehr als 1000 Pakete pro Sekunde loggen muss.

# Anhang: Cheatsheet