UDP Flood und Amplification: Traffic-Muster, die man beobachten muss

UDP Flood und Amplification gehören zu den häufigsten Ursachen für plötzliche Erreichbarkeitsprobleme von Internet-Services, obwohl „genug Bandbreite“ vorhanden scheint. Der Grund ist, dass diese Angriffsklasse nicht nur auf Bytes pro Sekunde (bps) zielt, sondern oft auf Pakete pro Sekunde (pps), auf die Paketverarbeitung in Routern/Firewalls/Load Balancern und auf das Verhalten verbindungsloser Protokolle. Bei einer klassischen UDP Flood flutet ein Angreifer ein Ziel mit UDP-Paketen, typischerweise mit variierenden Quelladressen und Ports, um Filterregeln zu umgehen und Systeme zu überlasten. Bei Amplification-Angriffen wird zusätzlich ein dritter Dienst missbraucht: Der Angreifer sendet kleine Anfragen mit gefälschter Quell-IP (Spoofing) an öffentlich erreichbare „Amplifier“ (z. B. DNS-, NTP- oder CLDAP-Server), die daraufhin deutlich größere Antworten an das Opfer schicken. In der Praxis entscheidet nicht nur die Angriffsstärke, sondern vor allem, ob Ihre Telemetrie die richtigen Muster sichtbar macht. Wer die charakteristischen Traffic-Signaturen kennt, kann schneller triagieren, die passende Mitigation aktivieren und False Positives vermeiden. Dieser Artikel zeigt, welche Traffic-Muster Sie bei UDP Flood und Amplification beobachten müssen, welche Metriken wirklich helfen und welche Fallstricke in modernen Umgebungen (NAT, Anycast, Cloud-NAT, L7-Proxies) besonders häufig sind.

Warum UDP Angreifer anzieht: Eigenschaften von „verbindungslos“

UDP (User Datagram Protocol) ist bewusst einfach: keine Verbindungszustände, kein Handshake, keine zuverlässige Zustellung. Das macht UDP für viele legitime Zwecke attraktiv (DNS, VoIP, Streaming, Telemetrie), aber auch für Angreifer. Ein einzelnes UDP-Paket kann bereits Arbeit auf Zielsystemen auslösen, ohne dass vorher Ressourcen für eine Verbindung „verhandelt“ werden müssen. UDP-Grundlagen sind in RFC 768 beschrieben.

• Kein Handshake: Filter und Schutzsysteme können weniger Kontext nutzen als bei TCP.
• Leicht zu spoofing: UDP-Anfragen lassen sich häufig mit gefälschter Quell-IP versenden, wenn Upstream-Filter fehlen.
• Protokollvielfalt: Viele UDP-basierte Dienste antworten deutlich größer, als die Anfrage ist.
• pps-Belastung: Kleine Pakete erhöhen pps und stressen Paketverarbeitung und Interrupt-Budgets.

UDP Flood vs. Amplification: Zwei Muster, ähnliche Symptome

Beide Angriffe können „Service down“ verursachen, unterscheiden sich aber in Ursprung und Traffic-Struktur:

• UDP Flood: Pakete kommen direkt vom Angreifer (oder Botnet) zum Opfer; Ziel ist meist pps/bps und Paketverarbeitung.
• Amplification/Reflection: Pakete kommen scheinbar von vielen legitimen Servern (Reflektoren/Amplifier); der Angreifer ist im Traffic nicht direkt sichtbar.

Operativ ist die Unterscheidung entscheidend, weil sie beeinflusst, ob Sie primär am Edge filtern (Ports/Patterns), ob Sie Spoofing-Indikatoren prüfen oder ob Sie mit Upstreams/Providers koordinieren müssen.

Das zentrale Kennzeichen von Amplification: Asymmetrie

Amplification lebt von einem Missverhältnis zwischen Anfrage und Antwort. Der Angreifer investiert wenig Traffic in Anfragen, das Opfer erhält viel Traffic als Antworten. Das lässt sich als Verstärkungsfaktor ausdrücken:

$\mathrm{AmplificationFactor}=\frac{\mathrm{AntwortBytes}}{\mathrm{AnfrageBytes}}$

In der Realität ist dieser Faktor nicht konstant: Er hängt von Protokolloptionen (z. B. EDNS0 bei DNS), vom konkreten Query-Typ, vom Serververhalten und von Fragmentierung ab. EDNS0 ist in RFC 6891 dokumentiert und spielt bei DNS-Amplification eine zentrale Rolle, weil es größere Antworten ermöglicht.

Traffic-Muster, die Sie bei UDP Flood beobachten müssen

Eine klassische UDP Flood hat typische Signaturen, die sich in NetFlow/IPFIX, sFlow und Packet Captures relativ zuverlässig zeigen. Entscheidend ist, dass Sie nicht nur „Traffic hoch“ messen, sondern auch Verteilungen, Entropie und zeitliche Dynamik.

Pakete pro Sekunde: Wenn bps niedrig ist, aber pps alles killt

Viele UDP Floods nutzen kleine Pakete (z. B. 60–200 Byte), weil pps die Paketverarbeitung stärker belastet als große Pakete. Ein einfacher Zusammenhang ist:

$\mathrm{pps}=\frac{\mathrm{bps}}{\mathrm{BytesPerPacket}\times 8}$

Wenn BytesPerPacket klein ist, steigt pps bei gleicher Bandbreite stark. Praktische Indikatoren:

• Hoher pps-Anstieg ohne proportionalen bps-Anstieg
• CPU-Spikes auf Edge-Geräten (Firewall, Router, Load Balancer)
• Drop-Counter mit Gründen wie „pps limit“, „CPU protection“, „policer“

Port- und Protokollmuster: Single-Port Flood vs. Port-Randomisierung

• Single-Port Flood: Ein dominanter Zielport (z. B. UDP/53, UDP/123, UDP/389) steigt abrupt; häufig bei Reflection oder bei gezielten Service-Floods.
• Multi-Port/Random: Zielports streuen; Ziel ist oft, einfache ACLs zu umgehen oder die Klassifizierung zu erschweren.
• Quellport-Entropy: Sehr hohe Variation kann auf automatisierte Tools oder Botnet-Profile hindeuten.

Die Kombination aus „ein Zielport dominiert“ plus „Quelladressen sind extrem verteilt“ ist bei Reflection besonders auffällig.

Quell-IP-Entropie: Wie „breit“ ist der Ursprung wirklich?

Bei Botnet-Floods sehen Sie viele echte Quelladressen. Bei Spoofing kann die Quell-IP-Liste künstlich breit wirken. Telemetrie, die hilft:

• Anzahl eindeutiger Quell-IPs pro Zeitfenster (z. B. pro 10 Sekunden)
• Top-N-Verteilung: Ist der Traffic gleichmäßig verteilt oder dominieren wenige Quellen?
• Geografie/ASN: Häufung in bestimmten Netzen kann auf Botnet-Cluster oder fehlende Filter in Upstreams hinweisen.

Paketgrößen-Verteilung: Kleine Floods vs. fragmentierte Antworten

Bei UDP Floods ohne Reflection sind Paketgrößen oft relativ konstant. Bei Amplification sehen Sie häufiger mehrere „Bäuche“ in der Größenverteilung, etwa durch:

• Standardisierte Antwortgrößen bestimmter Dienste
• Fragmentierung bei großen UDP-Antworten (mehrere Fragmente pro Antwort)
• MTU-Effekte: Viele Pakete nahe MTU oder typische Fragmentgrößen

Fragmentierung ist nicht automatisch ein Angriffssignal, aber bei plötzlich massenhaft fragmentierten UDP-Paketen in Richtung eines Dienstes ist sie ein starker Hinweis auf Amplification oder Misskonfiguration im Pfad.

Traffic-Muster, die Sie bei Amplification/Reflection beobachten müssen

Amplification ist oft leichter zu erkennen als zu stoppen, weil der Traffic „legitim“ aussieht: Antworten kommen von realen Servern, nicht vom Botnet direkt. Die Telemetrie muss daher auf Reflektionssignaturen fokussieren.

Viele Quellen, wenige Ziele: Fan-in auf eine VIP/IP

• Fan-in: Sehr viele unterschiedliche Quell-IPs senden an denselben Ziel-IP/Port.
• Antwortcharakter: Pakete wirken wie Responses, nicht wie Requests (z. B. DNS responses statt queries).
• Kurze Lebensdauer: Peaks sind oft bursty, abhängig vom Botnet-Controller.

Unplausible Request/Response-Relation: Antworten ohne sichtbare Anfragen

Im Opfernetz sehen Sie bei Reflection typischerweise viele Antworten, ohne dass passende Anfragen aus Ihrem Netz herausgehen. Falls Sie Egress-Telemetrie haben, ist das ein starkes Signal. Auch ohne Egress können Sie Hinweise sammeln:

• Inbound dominiert: Inbound UDP steigt extrem, outbound bleibt relativ stabil.
• State fehlt: Bei UDP gibt es ohnehin keinen Handshake, aber Application-Gateways können „no matching request“ melden.
• Gleiche Zielports: Häufig sind die Zielports am Opfer „ephemeral“ oder spezifisch (je nach Angriffsmethode), nicht zwingend der Dienstport.

Typische Amplification-Vektoren und ihre erkennbaren Spuren

Bestimmte UDP-Dienste sind historisch für Amplification missbraucht worden, weil kleine Anfragen große Antworten erzeugen. Beispiele (ohne Anspruch auf Vollständigkeit):

• DNS Amplification: Große Antworten über EDNS0; häufig mit ANY-ähnlichen Mustern oder großen Records. Relevante Grundlagen: RFC 6891 (EDNS0).
• NTP Amplification: Bestimmte NTP-Features wurden früher missbraucht; NTP-Protokoll ist in RFC 5905 beschrieben.
• CLDAP/LDAP Reflection: Sichtbar über UDP/389-Muster mit auffälligen Antwortgrößen.
• SSDP/UPnP: Häufig aus Consumer-Netzen; erkennbar über Portmuster und typische Paketgrößen.

Wichtig für die Triage ist weniger „welcher Vektor ist es“, sondern ob Ihr Traffic eher nach „Antwortflut aus vielen Quellen“ aussieht (Reflection) oder nach „direkter Flood aus Botnet“.

Die wichtigsten Observability-Bausteine: Ohne diese Daten bleibt es Spekulation

UDP-Angriffe lassen sich schnell falsch einordnen, wenn die Telemetrie zu grob ist. Für zuverlässige Mustererkennung brauchen Sie mindestens:

• Interface- und Direction-Metriken: Inbound vs. Outbound getrennt, idealerweise pro Edge-Link.
• Flow-Daten: NetFlow/IPFIX oder sFlow mit 5-Tuple (src/dst IP, src/dst Port, proto) und Bytes/Packets.
• Drop-Reason-Counter: Nicht nur „drops“, sondern „warum“ (policer, ACL, CPU-protect, fragment, buffer).
• Packet-Sampling: Kurze PCAP-Snapshots oder Header-Samples, um „Antwort vs. Anfrage“ zu prüfen.
• Kapazitätsmetriken: pps/bps pro Device, CPU, Buffer, Interrupts, NIC drops.

Praktische Musteranalyse: Was Sie in Flow-Daten konkret suchen

Flow-Daten sind oft der schnellste Weg zur Hypothese. Folgende Abfragen liefern typischerweise innerhalb weniger Minuten verwertbare Hinweise:

• Top Zielports (UDP) nach Packets und Bytes: Gibt es einen dominanten Port?
• Top Quell-ASNs: Kommt der Traffic aus wenigen Netzen (Botnet-Cluster) oder sehr breit (Reflection)?
• Top Quell-IPs vs. Gleichverteilung: Reflection ist oft „flach“ verteilt (viele Quellen, wenige dominieren).
• Bytes/Packet pro Flow: Kleine, gleichförmige Pakete deuten auf Flood; größere, variierende Pakete eher auf Responses/Amplification.
• Flow-Dauer: UDP-Flows sind oft kurz; bei massiver Flood entstehen viele „one-shot“-Flows.

Packet-Evidence: Welche Header-Indikatoren schnell helfen

Wenn Sie kurzfristig Packet-Sampling oder PCAP bekommen, sind folgende Merkmale besonders nützlich, ohne dass Sie tief in Payload-Inhalte einsteigen müssen:

• IP Fragmentation Flags/Offsets: Häufige Fragmente bei großen UDP-Antworten.
• TTL/Hop-Limits: Große Streuung kann auf viele Quellen/Reflektoren hindeuten.
• UDP Length: Typische Längenmuster können bestimmte Vektoren nahelegen.
• Checksummenfehler: Können bei Spoofing/Fehlpfaden auftreten, sind aber allein kein Beweis.

False Positives vermeiden: Legitime UDP-Spitzen sehen ähnlich aus

Nicht jede UDP-Spitze ist ein Angriff. Legitime Ursachen können sehr ähnliche Muster erzeugen, wenn Observability nicht sauber ist:

• DNS-Resolver-Störung: Clients retryen aggressiv, wodurch UDP/53 massiv steigt.
• NTP-Fehlkonfiguration: Viele Systeme synchronisieren gleichzeitig oder gegen falsche Targets.
• Video/VoIP Events: Große Meetings oder Streaming-Events erhöhen UDP-Last.
• Service Discovery: mDNS/SSDP kann in Campus-Netzen plötzlich dominieren.

Ein robuster Unterschied ist die Quellstruktur: Legitime Peaks kommen oft aus dem eigenen Adressraum oder aus erwartbaren Peers, während Reflection breit aus dem Internet „einschlägt“.

Mitigation-Orientierung anhand der Muster: Was passt wozu?

Die richtige Gegenmaßnahme ergibt sich aus dem Muster. Bei UDP ist „blocken“ häufig schnell, aber riskant, weil Sie legitime Dienste treffen können. Darum ist das Ziel, so präzise wie möglich zu filtern.

Mitigation bei direkter UDP Flood

• Rate-Limits (pps) am Edge: Policer oder ACL-basierte Limits für spezifische Ports.
• Geo/ASN-basierte Maßnahmen: Wenn klar ist, dass legitimer Traffic nicht aus bestimmten Regionen kommt.
• Service-Härtung: Unnötige UDP-Dienste deaktivieren, nur benötigte Ports exponieren.
• Kapazitätsreserven: pps-fähige Plattformen, ausreichend Headroom in NIC/Kernel.

Mitigation bei Amplification/Reflection

• Upstream-Scrubbing: Reflection kommt aus vielen legitimen Quellen; Filterung ist upstream oft effizienter.
• Destination-Port-Filter: Wenn ein klarer Zielport getroffen wird, gezielte Filter (mit Ausnahme-Listen für legitime Nutzung).
• Anti-Spoofing fördern: Langfristig hilft BCP-38/Ingress Filtering im Internet-Ökosystem; operativ heißt das meist Provider-Koordination.
• Anycast/Verteilung: Für öffentliche Services kann Anycast helfen, Attack Traffic zu verteilen, setzt aber sauberes Monitoring pro PoP voraus.

Was Sie dauerhaft messen sollten: Baselines für UDP, damit Anomalien sofort auffallen

UDP-Verkehr ist oft „spiky“. Ohne Baselines alarmieren Sie entweder ständig oder gar nicht. Sinnvoll sind Baselines pro Dienstport und pro Richtung (in/out), ergänzt um Verteilungsmetriken:

• pps und bps pro UDP-Port (Top-Ports und „Other“)
• Unique source IPs pro Zeitfenster (Anstieg als Early Warning)
• Bytes per packet pro Port (Änderungen deuten auf andere Vektoren)
• Fragment-Anteil (plötzlicher Anstieg als Amplification/Path-MTU-Signal)
• Drop Reasons und Buffer/Queue-Auslastung (zeigt, wo es wirklich klemmt)

Outbound-Quellen für Protokollgrundlagen und konkrete Angriffskontexte

• RFC 768: User Datagram Protocol (Grundlagen zu UDP und seinem verbindungslosen Modell)
• RFC 6891: Extension Mechanisms for DNS (EDNS0) (relevant für DNS-Antwortgrößen und Amplification-Muster)
• RFC 5905: Network Time Protocol Version 4 (NTP-Grundlagen; hilft beim Verständnis von NTP-bezogenem Missbrauch)

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.