Freorit

Warum deine Firewall monitoren?

Eine Firewall blockt Traffic. Das ist wichtig. Aber genauso wichtig ist zu wissen, was sie blockt und wann.

Ohne Monitoring siehst du nur das Ergebnis: „Verbindung abgelehnt." Mit Monitoring siehst du das Muster: „50 SSH-Versuche pro Minute von dieser IP, eskalierend über 2 Stunden." Das ist handlungsfähig.

Das Problem

OpenBSDs PF Firewall ist ausgezeichnet beim Filtern. Aber die Standard-Konfiguration lässt kritische Fragen unbeantwortet:

• Wie viele aktive Verbindungen verarbeitet deine Firewall jetzt?
• Welche IPs werden am häufigsten blockiert?
• Ist diese Rate normal oder ein Zeichen für einen Angriff?
• Sind deine Rate Limits zu eng (legitime Nutzer blockiert) oder zu locker?

Ohne zentrales Monitoring bedeutet die Beantwortung dieser Fragen, sich per SSH zum Router zu verbinden und Logs manuell zu inspizieren. Das skaliert nicht.

Die Lösung

Dieser Guide zeigt, wie du einen Monitoring-Stack aufbaust, der deine Firewall von einem stillen Beschützer in einen kommunikativen umwandelt. Das Ergebnis:

• Echtzeit-Transparenz in Firewall-Status und Traffic-Muster
• Automatisierte Alerts, wenn Anomalien auftreten
• Historische Daten zum Trennen und Kapazitätsplanen
• Schöne Dashboards für den täglichen Betrieb

Architektur-Übersicht

Der Monitoring-Stack hat zwei Datenflüsse: Metriken und Logs.

Kern-Komponenten

Datenflüsse

Metriken-Fluss:

Log-Fluss:

Schicht 1: Gehärtete PF Firewall

Die Firewall selbst muss konfiguriert werden, um nützliche Metriken zu sammeln und zu exportieren. Drei Schlüsselaspekte:

Source Tracking für Angriffserkennung

Source Tracking ermöglicht PF, Connection-Muster pro IP-Adresse zu überwachen. Das ist essentiell zum Erkennen von Brute-Force- und Port-Scan-Angriffen.

# Aktiviere Source Tracking
set limit src-nodes 20000

# Dynamische Blocking-Tables
table <bruteforce> persist
table <port_scanners> persist

# SSH Brute Force Schutz
pass in on pppoe0 proto tcp to port 22 \
keep state (max-src-conn 3, max-src-conn-rate 3/60, \
        source-track rule, overload <bruteforce> flush global)

# Blockiere erkannte Angreifer
block quick from <bruteforce>
    

Rate Limiting

Über Brute-Force-Schutz hinaus verhindert Rate Limiting Resource-Erschöpfung:

# Allgemeines Outbound Rate Limiting
pass in on re0 from (re0:network) to any \
keep state (max-src-conn 100, max-src-conn-rate 50/10)

# Globales WAN Limit
pass out on pppoe0 proto tcp \
keep state (max 10000, max-src-conn-rate 100/10)
    

Anti-Spoofing

Verhindere IP-Spoofing-Angriffe und filtere ungültige Quell-Adressen:

# Verhindere gefälschte Pakete
antispoof quick for pppoe0
antispoof quick for re0

# Blockiere ungültige Private Ranges
table <martians> const { 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8 }
block in quick on pppoe0 from <martians> to any
    

Aktiviere SNMP-Metriken-Export

OpenBSDs SNMP Daemon (snmpd) exportiert Firewall-Metriken, die Prometheus scrapen kann:

listen on 127.0.0.1
listen on 10.20.1.1  # Zugänglich vom Monitoring-Host

# Nur-Lesen-Zugriff vom Monitoring-Netzwerk
read-only community "public" 10.20.1.0/24
    

Kern-SNMP-Metriken, die PF exportiert:

• pfStateCount - Aktuelle aktive Verbindungen
• pfStateLimit - Maximale State Table Größe
• pfTableCount - Einträge in Blocking-Tabellen
• ifHCInOctets - Interface Traffic (Bytes In)
• ifHCOutOctets - Interface Traffic (Bytes Out)

Aktiviere snmpd beim Booten:

rcctl enable snmpd
rcctl start snmpd
    

Schicht 2: Zentralisiertes Monitoring

Der Monitoring-Stack aggregiert Metriken und Logs in Prometheus und Loki, dann visualisiert sie in Grafana.

Prometheus Setup: Metriken-Sammlung

Installiere den SNMP Exporter (konvertiert SNMP zu Prometheus-Format):

docker run -d \
  --name snmp-exporter \
  -p 9116:9116 \
  prometheuscommunity/snmp-exporter
    

Konfiguriere Prometheus zum Scrapen von SNMP- und Node-Metriken:

global:
  scrape_interval: 30s

scrape_configs:
  - job_name: 'snmp-router'
static_configs:
  - targets: ['10.20.0.1']
metrics_path: /snmp
params:
  module: [if_mib]
relabel_configs:
  - source_labels: [__address__]
target_label: __param_target
  - source_labels: [__param_target]
target_label: instance
  - target_label: __address__
replacement: localhost:9116
    

Loki Setup: Log Aggregation

Loki erfasst Logs von syslog-ng oder Grafana Alloy. Konfiguration:

auth_enabled: false

ingester:
  chunk_idle_period: 3m
  max_chunk_age: 1h
  max_streams_per_user: 10000

schema_config:
  configs:
- from: 2025-01-01
  store: tsdb
  object_store: filesystem
  schema: v13
  index:
prefix: index_
period: 24h

storage_config:
  filesystem:
directory: /loki/chunks
    

Grafana Dashboards

Grafana visualisiert die gesammelten Daten. Schlüssel-Dashboard-Panels:

Security Overview

• Blocked Connections (letzte Stunde) - Rate blockierter Pakete zeitlich
• Top Blocked IPs - Welche Quellen werden am meisten blockiert
• Brute Force Detection - Einträge in <bruteforce> Table
• Port Scans - Rapid SYN-Versuche erkannt

Firewall Health

• State Table Usage - % aktuelle Connections vs. Limit
• Source Tracking Entries - Aktive Source-Tracked Connections
• Table Sizes - <bruteforce>, <port_scanners> Table Einträge

Traffic Analysis

• WAN Traffic In/Out - Bandbreitennutzung zeitlich
• LAN Traffic - Interner Network Traffic
• Top Talkers - Welche IPs generieren meisten Traffic

Alert Rules

Definiere Alerts für Anomalien in Prometheus:

groups:
  - name: firewall_alerts
rules:
  - alert: StateTableNearFull
expr: (pfStateCount / pfStateLimit) > 0.8
for: 5m
annotations:
  summary: "Firewall State Table >80% voll"

  - alert: BruteForceSpike
expr: rate(pfTableCount{table="bruteforce"}[5m]) > 1
for: 2m
annotations:
  summary: "Brute Force Spike erkannt"

  - alert: HighBlockRate
expr: rate(pfBlockPackets[5m]) > 100
for: 5m
annotations:
  summary: "Ungewöhnlich hohe Block-Rate"
    

Angriffserkennung in Aktion

Beispiel 1: SSH Brute Force Angriff

Szenario: Angreifer versucht schnelle SSH-Anmeldeversuche.

Zeitleiste

Gesamte Erkennungszeit: 10-15 Sekunden vom initialen Angriff

Monitoring-Transparenz:

• Prometheus-Metrik: pfTableCount{table="bruteforce"} inkrementiert
• Grafana-Alert fired: „Brute Force Spike Erkannt"
• Loki-Logs zeigen PF Block-Regeln passend die IP

Beispiel 2: Port Scan Erkennung

Szenario: Angreifer führt nmap -p- <router-ip> aus um alle Ports zu scannen.

Was passiert:

1. Rapid SYN-Pakete zu vielen Ports von einzelner IP
2. PF Source Tracking verzeichnet hohe Connection-Rate von dieser IP
3. Rate Limit Rule: max-src-conn-rate 50/10 (50 Connections per 10 Sekunden) überschritten
4. IP wird zu <port_scanners> Table hinzugefügt
5. Gesamter zukünftiger Traffic von IP blockiert mit block quick from <port_scanners>

Monitoring-Erkennung:

Prometheus Query zur Port Scan Erkennung:

rate(pfTableCount{table="port_scanners"}[5m]) > 0.1
    

Dies Alert wenn neue IPs zur Port Scanners-Table mit Rate > 1 pro 50 Sekunden hinzugefügt werden.

Ergebnisse & Metriken

Quantitative Verbesserungen

Real-World Beispiel: Erste Woche

Nach Deployment von Monitoring zeigte die erste Woche:

• 43 unique IPs blockiert für SSH Brute Force Versuche
• 12 Port Scan Versuche erkannt und blockiert
• Peak State Table Nutzung: 45% (gesunder Spielraum)
• Durchschn. Blockierte Packet-Rate: 20/min (normales Baseline)
• Null False Positives in Rate Limiting (legitime Nutzer unbeeinflusst)

Best Practices

1. Starte konservativ mit Limits

Deploye nicht sofort enge Rate Limits. Tune schrittweise:

• Woche 1: Lose Limits (max-src-conn 50, max-src-conn-rate 50/60)
• Woche 2-3: Monitor auf False Positives; enge um 25%
• Woche 4+: Produktions-Werte nach null False Positives

2. Whitelist vertrauenswürdiger IPs

Erstelle Allowlists für bekannt-gute Quellen (dein Büro, Home Devices, vertraute Partner):

table <trusted> persist file "/etc/pf-trusted.txt"

# Höhere Limits für vertrauenswürdige Quellen
pass in on pppoe0 proto tcp from <trusted> to port 22 \
keep state (max-src-conn 20, max-src-conn-rate 20/60)

# Strikte Limits für alle anderen
pass in on pppoe0 proto tcp to port 22 \
keep state (max-src-conn 3, max-src-conn-rate 3/60, \
        overload <bruteforce> flush global)
    

3. Monitore die Monitore

Füge Alerts für Monitoring-Infrastruktur-Fehler hinzu:

• Prometheus Scrape-Fehler (Firewall SNMP runter)
• Loki Ingestions-Fehler
• Disk Space für Log/Metrics Storage

4. Log Volume Control

Zu viel Logging füllt schnell die Festplatte. Sei selektiv:

# Nur State-etablierende Pakete loggen (Standard)
pass out log on pppoe0 proto tcp

# NICHT: pass out log (all) on pppoe0  <- Erstellt 10GB/Tag Logs
    

5. Backup deine Konfigurationen

Keep Kopien von arbeiten pf.conf, snmpd.conf und Prometheus Rules:

cp /etc/pf.conf /etc/pf.conf.backup.$(date +%Y%m%d)
git add -A && git commit -m "Firewall config backup"
    

Gelernte Lektionen

Technische Lektionen

• Source Tracking ist essentiell: Ohne es kannst du Muster nicht erkennen—nur individuelle Pakete.
• Metriken vor Logs: Zeit-Reihen-Metriken (Prometheus) sind einfacher zu implementieren und liefern sofort Wert. Logs fügen forensische Tiefe hinzu.
• Rate Limits brauchen Tuning: Copy-Paste Limits von Guides passen nicht zu deinem Traffic. Monitor und adjust wöchentlich.
• SNMP ist nicht perfekt: Einige Metriken haben Latenz; Logs sind Echtzeit für Event-Erkennung.

Operative Lektionen

• False Positives schädigen Vertrauen: Ein einziger legitimer Nutzer blockiert erodiert Konfidenz in Automation. Tune konservativ.
• Alerting braucht Tuning: Alert zu oft und du bekommst Alert Fatigue. Nutze for: 5m Clauses um Noise zu reduzieren.
• Dokumentation zahlt sich aus: In 6 Monaten wirst du vergessen warum Limits so gesetzt sind. Dokumentiere die Rationale.

Monitoring-Lektionen

• Baselines sind wichtig: Du kannst Anomalien ohne Normalität nicht erkennen. Sammle 1 Woche Baseline-Daten vor Alert-Tuning.
• Dashboards sind nützlicher als Alerts: Alerts sagen dir etwas ist falsch; Dashboards sagen dir warum.
• Retention Policy: Halte Metriken für 30 Tage, Logs für 7 Tage. Balance Transparenz vs. Storage Cost.

Open-Source-Projekte

Dieser Guide basiert vollständig auf Open Source:

• OpenBSD – Sicherheits-fokussiertes Unix-ähnliches OS mit integrierter PF Firewall
• Prometheus – Zeit-Reihen Metriken DB und Monitoring-System
• Loki – Log Aggregation System für Prometheus-Nutzer
• Grafana – Visualisierungs-Plattform für Metriken und Logs
• SNMP Exporter – Prometheus Exporter für SNMP-Daten
• syslog-ng – Advanced Syslog Daemon für Log-Sammlung
• Grafana Alloy – Flexibler Agent zum Sammeln von Logs und Metriken und Versand zu Loki und Prometheus