Upstream Filtering gegen DDoS: Angriffstraffic stoppen, bevor die Infrastruktur sättigt

Definition des Problems

Das Problem ist, dass Angriffstraffic den Kundenlink erreicht, bevor lokale Filter greifen können. Ist der Port bereits gesättigt, hilft die beste Serverlogik nicht mehr. Viele Teams erkennen das erst im ersten ernsten Incident, wenn Routen bereits unter Druck geändert werden.

upstream filtering DDoS zwingt dazu, den kompletten Pfad zu betrachten: BGP-Announcement, gewählter Upstream, echte Portkapazität, verfügbares Filtering, Clean-Traffic-Handoff und Verhalten des Dienstes. Bleibt ein Punkt undefiniert, kann die Mitigation theoretisch funktionieren und praktisch scheitern.

Auch die kommerzielle Sprache ist ein Problem. “Viel Kapazität” erklärt nicht, was mit legitimem UDP, etabliertem TCP, Latenz, BGP-Communities oder temporären Regeln geschieht. Technische Käufer brauchen Mechanik, nicht nur Zahlen.

Warum es wichtig ist

Eine falsche Entscheidung wird sofort als Ausfall sichtbar. Endnutzer unterscheiden nicht zwischen Transit-Sättigung, schlechter BGP-Policy und zu aggressivem Filter; sie sehen Timeouts, Paketverlust oder Disconnects.

Auch Kosten sind betroffen. Angriffstraffic auf dem falschen Pfad kann 95th Percentile, Backbone-Nutzung und Supportaufwand erhöhen. Die Architektur muss den Angriff früh reduzieren, ohne legitimen Traffic zu opfern.

Für latenzsensitive Dienste wie FiveM, Minecraft, VoIP oder interaktive APIs muss Stabilität erhalten bleiben. Schutz, der den Dienst online hält, aber die Nutzung ruiniert, reicht nicht.

In der Praxis sollte jedes Design vor der Kundenmigration getestet werden: kontrollierte Traffic-Samples, klare Grenzwerte, definierte Rollback-Schritte und ein Ansprechpartner pro Carrier. Diese Vorbereitung wirkt weniger spektakulär als große Kapazitätszahlen, entscheidet aber oft darüber, ob eine Plattform während eines echten Angriffs stabil bleibt oder ob das Team im Notfall improvisieren muss.

Mögliche Lösungen

Zuerst muss das Ingress-Modell dokumentiert sein: welche Präfixe, welches ASN, welche Upstreams und welche BGP-Policy. Ohne diese Basis kann Automation den Incident verschlimmern.

Zweitens braucht es proportionale Filterung. Blackhole, ACL, FlowSpec, Scrubbing und Rate-Limit haben unterschiedliche Auswirkungen. Jedes Werkzeug braucht Rolle und Ablaufzeit.

Drittens muss Clean-Traffic-Delivery vor dem Angriff feststehen. GRE, IPIP, VXLAN, Router-VM und Cross-Connect sind gültige Optionen, aber sie unterscheiden sich in Latenz, Kontrolle und Rollout.

Ziel ist es, nutzloses Volumen beim Upstream zu entfernen, ohne den Dienst komplett abzuschalten. Die Regel muss präzise sein: Protokoll, Ports, Paketlänge, TCP-Flags oder erkennbare Reflexionsquellen.

Ein weiterer Punkt ist die Abstimmung mit dem Geschäftsmodell des Kunden. Ein Game-Hoster, ein SaaS-Anbieter und ein Betreiber eigener ASN haben nicht dieselben Risikotoleranzen. Bei einem Game-Service kann zu hartes Filtern von UDP sofort Spieler trennen, während bei einer Unternehmensanwendung einzelne Zielports deutlich strenger geschützt werden können. Genau deshalb sollte Upstream-Filtering nicht als Standardknopf verstanden werden, sondern als Werkzeug, das an Portmodell, Protokollprofil, Kundentyp und Angriffsmuster angepasst wird.

Upstream filtern, ohne Kundentraffic zu beschädigen

Peeryx betrachtet das zuerst als Netzwerkdesign: Traffic zu einer absorptionsfähigen Schicht ziehen, offensichtliches Angriffsvolumen reduzieren und sauberen Traffic zurückgeben, ohne die Topologie zu verschleiern.

Es geht nicht um permanente generische Regeln. FlowSpec oder Upstream-Filtering müssen präzise, zeitlich begrenzt und beobachtbar sein. Tunnel oder Cross-Connect müssen dokumentiert sein.

Kommerziell zählt eine Schutzlösung, die der Kunde versteht: Pfad, Grenzen, Schwellen, Support und Rollback statt unendlicher Mitigationsversprechen.

Ein wirksames Upstream-Filtering beginnt deshalb vor der Krise mit einer klaren Signaturstrategie: welche Protokolle sind für den Kunden erlaubt, welche Quell- und Zielportbereiche sind plausibel, welche Paketgrößen oder TCP-Flags kommen im normalen Betrieb vor und welche Ausnahmen müssen erhalten bleiben. Ohne diese Vorarbeit wird eine Notfallregel oft zu breit und kann legitime Sessions stören.

Konkreter Anwendungsfall

Ein Hoster mit Gameservern erhält einen UDP-Flood oberhalb seiner Portkapazität. Das offensichtliche Muster wird upstream gefiltert, legitimes UDP bleibt erhalten und sauberer Traffic kommt über GRE, IPIP, VXLAN oder Cross-Connect zurück.

Im Incident prüft das Team Volumen, PPS, Protokoll, Ports, aktive Routen und Latenz je ASN. Reduziert die Aktion den Angriff ohne legitimen Traffic zu beschädigen, bleibt sie aktiv; sonst wird sie enger gefasst oder entfernt.

Nach dem Incident werden Daten in das Runbook übernommen: welche Community, welches Präfix, welche Regel nicht wiederholen und welche Kapazität später nötig ist. So verbessert sich die Schutzlogik mit jedem Angriff.

Im Betrieb sollte jede Regel zeitlich begrenzt, messbar und reversibel sein. Entscheidend ist nicht nur, ob der Upstream Traffic verwirft, sondern ob der Kunde danach noch erreichbar bleibt, ob UDP-Antworten, BGP-Sessions, Monitoring und administrative Zugänge weiter funktionieren und ob die Regel nach dem Angriff automatisch oder manuell sauber entfernt wird.

Häufige Fehler

• Kapazität mit echter Mitigation verwechseln.
• BGP-Änderungen im Angriff improvisieren.
• Zu breite Filter auf UDP oder TCP anwenden.
• Latenz und Paketverlust während Mitigation nicht messen.
• Den Rückweg für Clean Traffic vergessen.
• Keinen klaren Rollback für temporäre Regeln haben.

FAQ