# OPNsense DDoS Protection: Härtung gegen Überlastungsangriffe

TL;DR / Management Summary Ein massiver DDoS-Angriff kann jede Firewall lahmlegen, indem er den RAM (State-Tabelle) oder die CPU flutet. OPNsense bietet integrierte Mechanismen wie SYN-Proxy, Rate Limiting und Sticky Tables, um kleine bis mittlere Angriffe (DoS) abzufedern. Ein Senior Admin nutzt diese Features, um automatische Sperren für aggressive Quell-IPs zu verhängen und so die Dienstverfügbarkeit für legitime User zu sichern. Hinweis: Massive volumetrische Angriffe (Gbit/s Bereich) müssen bereits beim ISP oder via Cloud-Dienst (Cloudflare) gefiltert werden.

# 1. Einführung & Bedrohungsszenarien

Die Anatomie des Sturms.

Wir schützen uns gegen drei Arten von Angriffen:

  1. State Exhaustion: Der Angreifer versucht, die State-Tabelle der Firewall zu füllen (Artikel 554).
  2. Application Layer (L7): Zu viele Anfragen an den Webserver (Port 80/443).
  3. SYN Flood: Überflutung mit Verbindungsanfragen, die nie abgeschlossen werden.

# 2. Härtung auf Protokoll-Ebene

Den ‘pf’ Paketfilter tunen.

# 1. SYN-Proxy

Der SYN-Proxy schaltet sich zwischen Client und Server. Er schließt den TCP-Handshake erst ab, bevor er die Verbindung an den internen Server weitergibt.

# 2. Connection Limits

Begrenzen Sie, was ein einzelner Host darf:

# 3. Deep Dive: Sticky Tables & Auto-Block

Vom Scanner zum Blackhole.

OPNsense kann IPs automatisch in eine Sperrliste verschieben, wenn sie sich “schlecht” verhalten.

  1. Alias erstellen: BRUTE_FORCE_BLOCKS (Typ: External).
  2. In der Firewall-Regel (z.B. für Web oder VPN):
    • Setzen Sie das Limit für Max. Source Nodes und Max. src-nodes connections.
    • Wählen Sie im Feld Identify and add to alias den Alias BRUTE_FORCE_BLOCKS.

# 4. Day-2 Operations: Rate Limiting (Shaper)

Drosseln statt Blockieren.

Manchmal ist ein kompletter Block zu radikal.

# 5. Troubleshooting & “War Stories”

Wenn der Schutz den User trifft.

# Top 3 Fehlerbilder

  1. Symptom: Legitime User werden fälschlicherweise geblockt.

    • Ursache: Zu strikte Limits für “Max. connections per host”. Moderne Browser öffnen oft 20-30 parallele Verbindungen für eine einzige Webseite.
    • Lösung: Limit auf mindestens 50-100 erhöhen.

  2. Symptom: Firewall ist CPU-seitig am Limit während eines Angriffs.

    • Ursache: Logging für die Block-Regeln ist aktiv. Das Schreiben tausender Log-Zeilen pro Sekunde verbraucht mehr CPU als das eigentliche Blockieren.
    • Lösung: Logging für DDoS-Blockregeln deaktivieren.

  3. Symptom: Die State-Tabelle läuft trotzdem voll.

    • Lösung: Timeouts für unauthenticated Verbindungen radikal senken (System -> Settings -> Advanced).

# “War Story”: Der “Friendly” DoS

Ein Admin aktivierte ein neues Monitoring-System, das alle 5 Sekunden 50 verschiedene Checks gegen die Firewall ausführte. Das Ergebnis: Innerhalb von 5 Minuten landete der Monitoring-Server im BRUTE_FORCE_BLOCKS Alias. Der Admin verbrachte Stunden mit der Suche nach “Netzwerkfehlern”, bis er in die Alias-Tabelle schaute. Lehre: Whitelisten Sie Ihre eigenen Management-IPs (Artikel 555) in allen Rate-Limiting Regeln!

# 6. Monitoring & Alerting

Die Sturmwarnung.

# IDS (Suricata) Integration

Nutzen Sie Suricata (Artikel 589), um spezifische DDoS-Signaturen (z.B. Slowloris) zu erkennen.

# 7. Fazit & Empfehlung

Schutz gegen Überlastung ist eine Frage der Balance.

# Anhang: Cheatsheet

Aufgabe Pfad
State Limits Firewall -> Rules -> [Edit Rule] -> Advanced
Auto-Block Alias Firewall -> Aliases
SYN-Proxy Check Diagnostics -> Network -> States
Global Timeouts System -> Settings -> Advanced

# Referenzen