Vor einiger Zeit hatte ich ein ziemlich beschissenes Problem: Mein Server war regelmäßig durch einen SYN-Flood lahmgelegt. Plötzlich gingen Webseiten und Dienste nicht mehr richtig, obwohl die Hardware kaum ausgelastet war. Nach ein wenig suchen habe ich herausgefunden, dass es an halb-offenen TCP-Verbindungen lag – ein klassischer Distributed-Denial-of-Service Angriff [DDoS].
Da ich an einigen Stelle OPNsense als Firewall einsetze, habe ich mich hingesetzt und eine saubere Lösung gesucht und gefunden. Folgend habe ich dann das Problem weitestgehend gelöst so gelöst.
Schritt 1: Portweiterleitung auf den Webserver
Mein Webserver läuft hinter OPNsense, deshalb habe ich eine klassische Portweiterleitung (DST NAT) von WAN-Port 443 (HTTPS) auf die interne IP des Servers eingerichtet.
Das Gute: Wenn man in der OPNsense eine solche NAT-Regel erstellt, wird automatisch auch eine Firewall-Regel auf dem WAN-Interface erzeugt. Genau diese Regel habe ich anschließend angepasst, um den SYN-Flood-Schutz einzubauen.
Schritt 2: SYN Flood Schutz aktivieren
In der automatisch erstellten WAN-Regel (für Port 443) habe ich im Bereich Advanced Options die entscheidende Änderung gemacht:
- State Type: auf Synproxy state gesetzt.
Dadurch übernimmt die Firewall den TCP-Handshake (SYN → SYN/ACK → ACK) selbst. Erst wenn der Client die Verbindung korrekt bestätigt, wird der Traffic an meinen eigentlichen Server weitergereicht.
Das hat zwei Vorteile:
- Halb-offene Verbindungen (z. B. von Bots, die nur SYN schicken, aber kein ACK) landen gar nicht erst auf meinem Webserver.
- Die Firewall erkennt und blockiert Clients, die den Handshake absichtlich nicht beenden.
Gerade bei DDoS-Angriffen mit tausenden Fake-Verbindungen macht das einen riesigen Unterschied, weil mein Server selbst kaum noch belastet wird.
Schritt 3: Verbindungen pro Client begrenzen
Das zweite Problem: Manche Clients (oder Angreifer) öffnen extrem viele parallele Verbindungen. Selbst wenn sie den Handshake schaffen, können sie den Server damit blockieren.
Auch hier bietet OPNsense in den Advanced Options der Firewall-Regel nützliche Einstellungen:
- Max. established connections per host: →
20
→ Pro Quell-IP werden nur 20 gleichzeitige TCP-Verbindungen zugelassen. - Max. new connections per second per host: → z. B.
5
→ So können Bots nicht in einer Sekunde hunderte neue Verbindungen aufreißen. - Max. state entries per host: optional, wenn man auch UDP oder andere Protokolle begrenzen möchte.
Wichtig: Diese Limits gelten pro Regel. Wenn man also mehrere Dienste veröffentlicht (z. B. HTTP auf Port 80 und HTTPS auf Port 443), sollte man die Werte konsistent eintragen.
In meinem Fall reicht ein Limit von 20 HTTPS-Verbindungen pro Client völlig aus – normale Browser kommen damit problemlos klar, aber Angreifer laufen sofort ins Limit.
Schritt 4: Erweiterte Firewall-Einstellungen
Unter Firewall → Settings → Advanced habe ich außerdem „enable syncookies“ aktiviert auf always. Das ist eine systemweite Schutzfunktion, die zusätzlich unterstützt.
Fazit
Seit diesen Anpassungen läuft mein Server stabil – auch wenn wieder mal ein Botnetz versucht, ihn mit TCP-SYN-Paketen lahmzulegen. Ehrliche Nutzer merken nichts, aber Angreifer laufen ins Leere.
Gerade wenn man Portweiterleitungen (z. B. für HTTPS) nutzt, sollte man die automatisch erzeugten Regeln nicht einfach so stehen lassen, sondern unbedingt diese Schutzmechanismen aktivieren.
5. September 2025 um 00:43 Uhr
Hi Dennis,
nach einigem Hin und Her habe ich die automatische WAN Regel geklont um die erweiterten Einstellungen zu setzen. Wie war das bei dir? Ich konnte die bestehende Regel nicht editieren.
Grüße
5. September 2025 um 08:40 Uhr
Wenn ich mich dunkel erinne, habe auch ich das geklont.
26. September 2025 um 19:50 Uhr
„enable syncookies“ aktiviert auf always sorgt dann allerdings dafür, dass das System auf alle Verbindungsversuche mit SYN-ACK antwortet. Bedeutet, für einen Port-Scanner sind alle Ports auf dem System offen und akzeptieren Verbindungen.