Auf dieser Seite
Das Wichtigste
- ACK wirkt legitimDieser Punkt hilft, „ACK-Flood-Schutz“ mit präzisem Blick auf Kapazität zu behandeln.
- PPS zähltDieser Punkt hilft, „ACK-Flood-Schutz“ mit präzisem Blick auf PPS zu behandeln.
- Asymmetrie erschwertDieser Punkt hilft, „ACK-Flood-Schutz“ mit präzisem Blick auf Latenz zu behandeln.
- Ziel ist sauberer TrafficDer Dienst soll erreichbar bleiben, nicht nur der Graph schöner aussehen.
Definition des Problems
Das technische Muster ist einfach, aber zerstörerisch: Unaufgeforderte UDP-Antworten treffen beim Opfer ein, obwohl der Ursprung sie nie angefragt hat. Regeln nur auf dem Server sehen den finalen Flood, nicht die Reflektorkette dahinter.
Da Pakete von realen Internetservern kommen können, ist eine naive Blockliste langsam und erzeugt Kollateralschäden. Nützliche Signale sind Protokollverhalten, Richtung, erwartete Ports, Rate, Entropie und ob der geschützte Dienst diese Antworten überhaupt angefordert hat.
Entscheidend ist der Kontext: Ein isolierter Paketzähler reicht nicht aus. Die Mitigation muss wissen, ob der geschützte Dienst dieses Protokoll normalerweise erwartet, aus welcher Richtung und mit welchem Rhythmus.
- ACK wirkt legitim
- ACK-Floods können Queues überlasten und Schutzsysteme täuschen, die nur auf Bandbreite achten. Die Prüfung muss Bandbreite, PPS, Protokollverhalten und den genauen Punkt trennen, an dem der Dienst ausfällt.
- PPS zählt
- ACK-Floods können Queues überlasten und Schutzsysteme täuschen, die nur auf Bandbreite achten. Die Prüfung muss Bandbreite, PPS, Protokollverhalten und den genauen Punkt trennen, an dem der Dienst ausfällt.
- Asymmetrie erschwert
- ACK-Floods können Queues überlasten und Schutzsysteme täuschen, die nur auf Bandbreite achten. Die Prüfung muss Bandbreite, PPS, Protokollverhalten und den genauen Punkt trennen, an dem der Dienst ausfällt.
Warum es wichtig ist
Das ist geschäftskritisch, weil Kunden den Ausfall bemerken, bevor die Ursache offensichtlich ist. Ein dedizierter Server kann wenig CPU-Last zeigen, während Spieler, Kunden oder BGP-Peers Paketverlust und Timeouts sehen.
Für geschützten Transit zählt auch die Zustellung. GRE, IPIP, VXLAN, Cross-Connect und Router-VM müssen so dimensioniert und gefiltert sein, dass reflektierter Traffic den sauberen Pfad nicht verbraucht.
Für Hosting und Gaming ist das auch ein Verkaufsthema. Kunden beurteilen den Vorfall nicht nach dem Namen des Vektors, sondern danach, ob ihr Dienst erreichbar geblieben ist.
Mögliche Schutzmaßnahmen
Die erste Schicht ist Kapazität: Upstream-Transit und Filterports müssen den Angriff aufnehmen, während die Entscheidungslogik den Vektor klassifiziert. Die zweite Schicht ist protokollbewusste Filterung gegen unmögliche Antworten, anomale Payloads und Traffic außerhalb des erwarteten Profils.
FlowSpec, ACLs und Edge-Filterung können Bruttovolumen schnell senken, sollten aber präzise und kurzlebig sein. Ein Stateful-Firewall am Ursprung ist keine gute erste Linie, wenn der Angriff bereits Link oder PPS-Budget frisst.
Eine praxistaugliche Konfiguration hält Notfallregeln bereit, speichert aber auch Baselines. Paketgrößen, Ports, Länder und Protokollverhältnisse ermöglichen schnelles Filtern ohne blindes Blockieren.
Konkretes Einsatzbeispiel
Stellen Sie sich eine Game-Community auf einem dedizierten Server vor. Der Server ist online, aber die öffentliche IP erhält einen reflektierten UDP-Flood. Spieler sehen Timeouts, Voice wird instabil und das Hoster-Panel zeigt oft nur Bandbreitensättigung.
Mit geschützter Zustellung wird die angegriffene IP oder der Dienst über einen Mitigation-Punkt geroutet. Die Plattform filtert den reflektierten Vektor, hält legitime TCP/UDP-Sitzungen aufrecht und leitet nur sauberen Traffic zur bestehenden Maschine.
Während des Vorfalls ist ein gutes Dashboard mehr als ein Graph für blockierten Traffic. Betreiber benötigen akzeptierten Traffic, Latenz, Tunnelzustand und Nutzersymptome, um die Wirkung zu prüfen.
Häufige Fehler
Der erste Fehler ist ein kompletter UDP-Block. Das kann Games, DNS, Monitoring und legitime Infrastrukturflüsse zerstören. Der zweite Fehler ist, vom Ursprungsserver die Lösung eines Netzwerksättigungsproblems zu erwarten.
Ein weiterer Fehler ist die alleinige Nutzung generischer Rate-Limits. Sie können Grafen senken, aber echte Nutzer treffen, wenn der Dienst Bursts braucht oder der Angreifer knapp unter dem Schwellenwert bleibt.
Ein weiterer Fehler ist dieselbe Vorlage für alle Kunden. BGP-Transit, Dedicated Server und Game-Proxy exponieren unterschiedliche Dienste und tolerieren nicht dieselben False Positives.
