DDoS-Schutz für VPN Gateways: Rate Limits, Front Doors und Scrubbing

DDoS-Schutz für VPN Gateways ist heute ein Pflichtbestandteil jeder professionellen Remote-Access- und Site-to-Site-Architektur. VPN-Gateways sind nicht nur „ein Dienst unter vielen“, sondern ein kritischer Einstiegspunkt: Wenn das Gateway nicht erreichbar ist, stehen Remote Work, Incident Response, Betrieb und häufig auch Partnerzugänge still. Gleichzeitig sind VPN-Endpunkte naturgemäß internetexponiert und damit leicht auffindbar und angreifbar. Hinzu kommt eine technische Besonderheit: Handshakes (TLS, IKE) sind rechenintensiv und erzeugen Zustand (State) auf dem Gateway – genau das macht VPNs anfällig für volumetrische Angriffe, Protokollmissbrauch und „Low-and-slow“-Attacken, die CPU, Memory, Session-Tabellen oder AAA-Backends erschöpfen. Ein wirksamer DDoS-Schutz kombiniert deshalb mehrere Ebenen: Rate Limits (um Zustands- und Authentisierungslast zu kontrollieren), Front Doors (um Angriffe vor dem Gateway abzufangen und zu verteilen) sowie Scrubbing (um großen, volumetrischen Traffic upstream zu reinigen). Dieser Artikel zeigt, wie Sie diese Bausteine zu einer robusten Architektur zusammenführen, welche Failure Modes typisch sind und welche Hardening- und Betriebsmaßnahmen in 2026 als Best Practice gelten.

Warum VPN-Gateways besonders DDoS-anfällig sind

Viele Internetdienste sind DDoS-gefährdet, aber VPN-Gateways haben einige ungünstige Eigenschaften: Sie sind geschäftskritisch, sie nutzen oft Protokolle mit aufwendigen Handshakes, und sie sind häufig an weitere Systeme gekoppelt (IdP, RADIUS, PKI, DNS). Ein DDoS muss nicht einmal „Bandbreite saturieren“, um wirksam zu sein – es reicht, wenn er die Kontroll- oder Datenebene so belastet, dass legitime Handshakes nicht mehr durchkommen.

• State Exhaustion: Viele Verbindungen/Handshakes erzeugen Einträge in Session- oder SA-Tabellen (TLS Sessions, IKE SAs, ESP SAs). Tabellen sind endlich.
• CPU Exhaustion: Kryptografische Operationen (Diffie-Hellman/ECDHE, Signaturen, Zertifikatsprüfungen) sind teuer. Angreifer zielen gezielt auf „Handshake-Stress“ statt nur auf Bandbreite.
• AAA Backends als Bottleneck: RADIUS/IdP/MFA können durch Login-Stürme indirekt zum Ausfallpunkt werden – selbst wenn das Gateway Bandbreite hätte.
• Single Entry Point: Viele Unternehmen haben wenige zentrale VPN-Endpunkte. Das erhöht den Impact eines Ausfalls.

Angriffsarten: Volumetrisch, Protokoll, Anwendung

Ein sauberes DDoS-Design beginnt mit einem klaren Angriffskatalog. Für VPNs sind drei Kategorien besonders relevant:

• Volumetrische Angriffe: Ziel ist Sättigung von Uplink/Transit (pps/Gbps). Das trifft vor allem Internetanbindung und Provider-Edges.
• Protokoll-/State-Angriffe: Ziel ist Erschöpfung von Session-Tabellen oder CPU durch viele (halb-)gültige Handshakes.
• Anwendungsnahe Angriffe: Login-/MFA-Stürme, Abuse von Portal-/API-Endpunkten, Überlastung von IdP/AAA/DNS.

Für das Verständnis der Handshake-Last ist es hilfreich, die Protokollgrundlagen zu kennen, etwa TLS 1.3 (RFC 8446) und IKEv2 (RFC 7296).

Designprinzipien für DDoS-resiliente VPN-Architekturen

Unabhängig vom Hersteller haben sich in Enterprise-Designs einige Prinzipien bewährt. Sie sind wichtiger als einzelne Produkte, weil sie Architekturfehler vermeiden, die später teuer werden.

• Early Drop: Unerwünschter Traffic soll so früh wie möglich verworfen werden (idealerweise upstream), bevor er CPU/State erzeugt.
• Stateless vor stateful: Filter, die ohne Zustand arbeiten (z. B. ACLs, uRPF, BGP Blackholing), sind in Angriffslagen stabiler.
• Separation of Planes: Management Plane strikt trennen und nie über denselben öffentlich exponierten Pfad erreichbar machen wie User-Traffic.
• Graceful Degradation: Bei Überlastung lieber kontrolliert neue Handshakes drosseln als „alles geht irgendwie kaputt“.
• Beobachtbarkeit: Sie müssen erkennen, ob Sie Bandbreiten-, pps- oder CPU-limitiert sind, sonst greifen falsche Gegenmaßnahmen.

Rate Limits: Der wichtigste Schutz gegen Handshake- und Login-Stürme

Rate Limits sind für VPNs essenziell, weil sie genau die Ressource schützen, die Angriffe häufig treffen: Zustand und CPU. Ein gutes Rate-Limit-Design ist mehrstufig und differenziert nach Quelle, Protokoll und Phase (Pre-Auth vs. Post-Auth).

Layer-3/4 Rate Limits und Filter

• pps-Guards: Begrenzen Sie Pakete pro Sekunde pro Quell-IP, pro Subnetz und global, um Floods zu dämpfen.
• Source Validation: Ingress Filtering und uRPF reduzieren Spoofing. Als Best Practice wird häufig BCP 38 referenziert, u. a. RFC 2827 und RFC 3704.
• Port-/Protocol Allow-List: Extern nur die zwingend nötigen Ports/Protokolle exponieren; alles andere hart droppen.

IKE/IPsec: IKE-Handshake drosseln, NAT-T berücksichtigen

• IKE Initiation Rate: Begrenzen Sie neue IKE_SA-Init-Anfragen pro Source und global.
• Cookie/Anti-DoS Mechanismen: Viele IKE-Implementierungen unterstützen Cookies/Challenges, um Spoofing und State Exhaustion zu erschweren.
• NAT-T Sensitivität: Angriffe können UDP-Path-MTUs und NAT-Timeouts triggern; stabile Keepalive/DPD-Settings helfen, aber in Angriffslagen dürfen sie nicht selbst Last erzeugen.

TLS-VPN/Portale: Handshake- und Auth-Raten begrenzen

• Handshake Rate Limiting: Neue TLS Handshakes pro Quell-IP begrenzen, besonders wenn Client-Zertifikate oder teure Validierungen aktiv sind.
• Login Throttling: Fehlgeschlagene Logins pro Account und pro IP limitieren (Credential Stuffing und MFA-Spam).
• Step-up nur bei Bedarf: Risk-Based Auth reduziert MFA-Last bei legitimen Sessions; aber in Angriffslagen muss Step-up kontrolliert sein, damit MFA-Systeme nicht kollabieren.

Front Doors: VPN-Endpunkte vor dem Gateway „abfangen“

Front Doors sind vorgelagerte Komponenten, die Attack Surface reduzieren und Verkehr verteilen. Der Vorteil: Sie fangen Lärm ab, bevor er die eigentlichen VPN-Knoten trifft. Das kann ein Provider-Edge, ein DDoS-Schutzdienst, ein Anycast-Netz oder eine „Security Edge“-Plattform sein.

Anycast-Front Door für globale Resilienz

• Anycast IPs: Ein VPN-Endpunkt wird über Anycast aus mehreren PoPs announced. Angriffe verteilen sich geografisch.
• Nearest-Exit: Legitimer Traffic landet beim nächsten PoP, was Latenz reduziert und Kapazität skaliert.
• Operational Point: Anycast kann Session-Stabilität beeinflussen; für stateful VPNs brauchen Sie klare Affinitäts- und Failover-Mechanismen.

Load Balancer als Front Door (L4/L7)

• L4-Proxying: Ein L4 Load Balancer kann pps- und conn-Rate-Limits durchsetzen, bevor Traffic das Gateway erreicht.
• L7-Front für Portale: Für Webportale kann ein L7 Proxy/WAF Login-Stürme dämpfen, Bot-Signaturen erkennen und bestimmte Endpoints schützen.
• Wichtig: Der Load Balancer darf kein Single Point of Failure sein; HA und Capacity Planning sind Pflicht.

SASE/ZTNA als „Front Door“-Alternative

Für viele Use Cases ist es sinnvoll, den VPN-Tunnel gar nicht erst aufzubauen, sondern Zugriff per App (ZTNA) zu steuern. Damit reduzieren Sie die exponierten Handshake-Pfade und verlagern Schutzfunktionen in eine Edge-Schicht. Als konzeptioneller Rahmen eignet sich NIST SP 800-207.

Scrubbing: Volumetrische Angriffe upstream reinigen

Wenn Angriffe Ihre Internetanbindung oder Provider-Edges saturieren, helfen lokale Rate Limits nur begrenzt. Dann benötigen Sie Scrubbing: Traffic wird in Scrubbing Centers umgeleitet, dort gefiltert und als „Clean Traffic“ zu Ihnen zurückgeführt. In der Praxis gibt es drei verbreitete Modelle:

Always-on Scrubbing

• Prinzip: Traffic läuft immer durch den DDoS-Provider. Vorteil: keine Umschaltzeit, stabile Policy.
• Trade-off: Abhängigkeit vom Provider, potenziell höhere Latenz, sauberes Capacity- und SLA-Management nötig.

On-demand Scrubbing (BGP Diversion)

• Prinzip: Normalbetrieb direkt, bei Angriff BGP-Umlenkung zum Scrubbing Center.
• Vorteil: Kosten- und Latenzvorteile im Normalbetrieb.
• Trade-off: Umschaltprozesse müssen geübt sein (Runbooks, automatisierte Trigger), sonst verlieren Sie wertvolle Minuten.

Hybrid: Provider-Edge + lokaler Schutz

• Prinzip: Upstream filtert volumetrisch, lokal filtert stateful und policy-nah (z. B. Handshake-/Auth-Rate).
• Vorteil: Beste Kombination aus Bandbreitenschutz und applikationsnaher Kontrolle.

Clean Pipe bis zum Gateway: Rückführung und Transport

Nach dem Scrubbing muss der Clean Traffic sicher und stabil zu Ihren Gateways gelangen. Häufige Optionen:

• GRE Tunnel: Einfach, breit unterstützt, aber selbst gegen Missbrauch absichern (Source Allow-Lists, TTL/ACLs).
• IPsec Tunnel zum Scrubber: Zusätzliche Vertraulichkeit und Authentisierung, aber mehr Komplexität und ggf. Handshake-Last.
• Private Interconnect: Direkte Provider-Verbindungen reduzieren Latenz und Abhängigkeit vom öffentlichen Internet.

Gerade bei IPsec ist es wichtig, eine robuste Baseline zu nutzen (IKEv2, PFS, klare DH-Gruppen). Ein praktischer Leitfaden ist NIST SP 800-77 (Guide to IPsec VPNs).

Schutz der AAA- und Identity-Backends: Der „indirekte“ DDoS

Viele VPN-Ausfälle entstehen nicht durch Bandbreite, sondern weil IdP, MFA oder RADIUS unter Login-Stürmen kollabieren. Ein DDoS kann also „Applikationsnah“ sein: er erzeugt massenhaft Authentisierungsversuche und zwingt Ihre Backends in Lastspitzen.

• RADIUS/AAA Rate Limits: Begrenzen Sie Auth-Requests pro Gateway, pro User und pro Source; nutzen Sie Backoff statt Retries-Stürme.
• Caching und Failover: Wo sinnvoll, Cache für Policies/Group-Lookups; mehrere AAA-Server, regionale Verteilung.
• MFA-Spam Schutz: Push-MFA sollte Number Matching/Challenge nutzen und bei Push-Fatigue blocken/locken.
• Degraded Mode definieren: Bei IdP-Ausfall: Standardzugänge blocken, Privileged nur via Break-Glass mit strikter Kontrolle (nicht automatisch „alles auf“).

Post-Login Stabilität: DDoS nach Authentisierung

Einige Angriffe zielen auf die Datenebene nach erfolgreichem Login, etwa durch Traffic-Floods aus kompromittierten Clients oder Missbrauch von Split-Tunnel-Ausnahmen. DDoS-Schutz umfasst daher auch interne Kontrollen.

• Per-User/Per-Tunnel Bandbreitenlimits: Verhindert, dass einzelne Sessions Ihre egress/ingress Kapazität dominieren.
• Segmentation: User/Vendor/Admin getrennte Zonen; kompromittierte Nutzer dürfen nicht „das ganze Netz“ erreichen.
• Egress Controls: Full-Tunnel-Designs sollten Proxy/DLP/SWG sauber dimensionieren; sonst wird der Security-Stack selbst zum Bottleneck.

Monitoring und Telemetrie: Erkennen, was Sie gerade trifft

Ohne gute Metriken bleibt DDoS-Abwehr reaktiv und häufig falsch. Ihre Observability muss mindestens drei Engpassklassen sichtbar machen: Bandbreite, pps/conn-rate, und CPU/State.

• Netzmetriken: Interface Utilization, pps, Drops, SYN/UDP-Flood-Indikatoren, asymmetrische Pfade.
• Gateway-Metriken: Handshake-Rate, SA-/Session-Tabellenfüllstand, CPU pro Kryptofunktion, Memory, Queue Depth.
• Auth-Metriken: Login-Fails, MFA-Challenges, RADIUS Timeouts, IdP Latency, Error Codes.
• Scrubbing-Status: Angriffserkennung, diverted prefixes, clean/dirty ratio, mitigation actions.

Für Incident Handling-Prozesse kann NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide) als strukturierende Referenz dienen.

Runbooks und Übungen: DDoS-Abwehr ist ein Betriebsprozess

Technik allein reicht nicht. Bei DDoS zählt Zeit: Wer entscheidet? Wie wird umgeschaltet? Welche Prefixes werden diverted? Welche Rate Limits werden aktiviert? Welche Teams werden informiert? Ohne geübte Runbooks entstehen gefährliche Workarounds.

• Mitigation Playbooks: Volumetric vs. Handshake vs. Login-Storm – jeweils eigene Schritte und Eigentümer.
• BGP Diversion Drill: On-demand Scrubbing muss regelmäßig geübt werden (inkl. Rollback).
• Kommunikationsplan: Statuspage, On-Call Eskalation, Business-Kommunikation, Partnerinformationen.
• Postmortems: Nach jedem Ereignis: welche Limits griffen, wo war Engpass, welche Signale fehlten?

Häufige Fehler beim DDoS-Schutz von VPN-Gateways

• Nur Bandbreite betrachten: Handshake-/CPU-Angriffe werden übersehen, obwohl Uplink frei ist.
• Management-Plane exponiert: Angriffe treffen nicht den VPN-Port, sondern die Admin-GUI/API.
• Rate Limits ohne Tests: Zu harte Limits sperren legitime Nutzer (z. B. NAT-Gateways großer Firmen) oder erzeugen Support-Tickets.
• AAA als Single Point: RADIUS/IdP ohne Resilienz wird durch Login-Stürme zum Ausfallpunkt.
• On-demand Scrubbing ohne Übung: BGP-Diversion dauert zu lange oder wird falsch geroutet.
• Kein Degraded Mode: Bei Backend-Ausfall fällt man in unsichere Defaults oder öffnet ad hoc Regeln.

Checkliste: DDoS-Schutz für VPN Gateways

• Externe Angriffsfläche: Nur notwendige Ports/Protokolle; Legacy deaktivieren; Health/Debug Endpoints nicht öffentlich.
• Rate Limits: pps/conn-rate Limits am Edge; Handshake-Limits für TLS/IKE; Login-Throttling; Schutz vor MFA-Spam.
• Front Door: Anycast/PoPs oder vorgeschaltete L4/L7 Fronts mit DDoS-Fähigkeit; keine Single Points.
• Scrubbing: Always-on oder On-demand (BGP); Clean-Pipe-Rückführung per GRE/IPsec; Runbooks und Drills.
• AAA/IdP Resilienz: Mehrere RADIUS/IdP-Instanzen, sinnvolle Timeouts/Backoff, klare Degraded-Policies.
• Post-Login Controls: Per-Tunnel Bandbreitenlimits, Segmentierung, Bastion/PAM für privilegierte Zugriffe.
• Monitoring: Bandbreite/pps/CPU/State sichtbar; Alerts auf Handshake-Spikes, SA-Table-Füllstand, Auth-Timeouts.
• Operationalisierung: Incident Playbooks, Kommunikationsplan, regelmäßige Tests, Postmortems, kontinuierliche Verbesserung.

• IKEv2 Spezifikation (RFC 7296)
• TLS 1.3 Spezifikation (RFC 8446)
• BCP 38 Ingress Filtering (RFC 2827)
• Ingress Filtering und uRPF Guidance (RFC 3704)
• NIST SP 800-77: Guide to IPsec VPNs
• NIST SP 800-61 Rev. 2: Incident Handling Guide

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.