February 21, 2026

UDP Amplification Attack: Traffic-Muster und sichere Mitigation

Eine UDP Amplification Attack gehört zu den wirkungsvollsten DDoS-Methoden, weil sie zwei Vorteile kombiniert: sehr hohe Bandbreite am Ziel und vergleichsweise wenig Aufwand beim Angreifer. Die Grundidee ist simpel: Der Angreifer fälscht (spoofed) die Quelladresse von UDP-Anfragen so, dass sie auf das Opfer zeigt. Diese Anfragen gehen an öffentlich erreichbare „Reflektoren“ (z. B. offene DNS-Resolver, NTP-Server oder Memcached-Instanzen), die dann deutlich größere Antworten an die gefälschte Quelladresse senden. Das Opfer wird mit Antworttraffic überflutet, ohne dass es selbst jemals eine Anfrage gesendet hat. Operativ ist das besonders heikel, weil UDP zustandslos ist: Es gibt keinen Handshake wie bei TCP, wodurch Filterregeln und State-basierte Schutzmechanismen am Edge schnell an Grenzen geraten. Gleichzeitig können legitime Dienste (DNS, NTP, QUIC, VoIP) ebenfalls UDP nutzen, was die Mitigation riskant macht, wenn sie zu pauschal ist. Dieser Artikel zeigt praxisnah, wie eine UDP Amplification Attack im Traffic aussieht, welche Muster in Flow-Daten und Telemetrie typisch sind und wie Sie sichere Mitigation umsetzen, ohne legitimen Traffic unnötig zu kappen oder einen „Second Outage“ durch überstürzte Maßnahmen zu provozieren.

Table of Contents

Was eine UDP Amplification Attack technisch ausmacht

Eine UDP Amplification Attack besteht aus drei Rollen: Angreifer, Reflektoren/Amplifier und Opfer. Der Angreifer sendet kleine UDP-Requests an viele Reflektoren, aber mit gefälschter Source-IP (die IP des Opfers). Die Reflektoren antworten dann an das Opfer. Der „Amplification“-Teil entsteht, wenn die Antwort größer ist als die Anfrage. Der „Reflection“-Teil entsteht, weil der Reflektor die Antwort nicht an den Angreifer, sondern an das Opfer sendet.

Reflection: Antworten gehen an das Opfer, weil die Quelladresse gefälscht ist.
Amplification: Response-Bytes sind deutlich größer als Request-Bytes.
Verteiltheit: viele Reflektoren, oft global verteilt, wodurch Blocken einzelner Quellen wenig bringt.

Das grundlegende Problem hinter Reflection-Angriffen ist IP-Spoofing. Best Practices, Spoofing im Netz zu reduzieren (BCP 38 / BCP 84), sind über RFC 2827 und RFC 3704 beschrieben.

Warum UDP Amplification so schwer zu filtern ist

UDP hat keinen Verbindungsaufbau. Das bedeutet: „Antwort ohne Anfrage“ ist in vielen Netzen nicht trivial zu erkennen, weil der Edge-Router oder der Provider-Backbone normalerweise keinen Flow-State über alle Kundenverbindungen hält. In klassischen DDoS-Szenarien ist außerdem das Volumen so hoch, dass detaillierte Paketinspektion (Deep Packet Inspection) nicht immer skalierbar ist. Deshalb stützt sich sichere Mitigation auf eine Kombination aus Mustern (Port, Paketgrößen, PPS/BPS-Verhältnisse), verteilten Signalen (mehrere PoPs) und abgestuften Maßnahmen (Rate-Limits, Filter, Scrubbing).

Typische Protokolle und Ports für UDP Amplification

Viele Amplification-Angriffe nutzen bekannte UDP-Dienste, bei denen kleine Requests große Responses auslösen können – insbesondere, wenn Server falsch konfiguriert oder unnötig offen ins Internet exponiert sind. Häufige Beispiele:

DNS (typisch UDP/53): offene Resolver, DNSSEC- oder „ANY“-Antworten (historisch) können groß sein.
NTP (typisch UDP/123): ältere „monlist“-ähnliche Muster waren besonders anfällig; heute oft durch harte Defaults reduziert, aber Fehlkonfigurationen existieren.
CLDAP (typisch UDP/389): wird seit Jahren in DDoS-Wellen missbraucht, wenn exponiert.
SSDP (typisch UDP/1900): UPnP/SSDP-Geräte als Reflektoren, häufig aus Heimnetzen.
Memcached (typisch UDP/11211): bei exponierten Instanzen kann das Volumen extrem sein.

Für DNS sind RFC 1035 (Grundlagen) und für DNSSEC-bezogene Response-Größen RFC 4035 hilfreiche Referenzen. Für NTP ist RFC 5905 eine gute Grundlage.

Traffic-Muster: So erkennt man UDP Amplification in der Praxis

Im NOC sind drei Muster besonders aussagekräftig: (1) starke Antwortlast auf wenigen UDP-Ports, (2) auffällige Paketgrößenverteilung, (3) sehr hohe Source-Diversität bei gleichzeitig geringer Ziel-Diversität.

Muster 1: Hohe BPS bei moderater PPS – große Response-Pakete

Im Gegensatz zu vielen SYN-Floods (PPS-lastig) sind UDP Amplification Attacks häufig stark bandbreitengetrieben: wenige, aber große UDP-Pakete (z. B. 1200–4000+ Bytes je nach Fragmentierung/EDNS0) fluten den Downstream zum Opfer. Das zeigt sich in einer stark erhöhten Bits/s Rate, während Packets/s zwar steigt, aber nicht zwingend im gleichen Verhältnis.

Muster 2: Port-Konzentration auf Amplifier-Ports

Der Angriff konzentriert sich oft auf einen oder wenige UDP-Ports (z. B. 53, 123, 389, 1900, 11211). In Flow-Daten sehen Sie eine ungewöhnlich hohe Dominanz dieser Ports, häufig mit vielen Source-IPs (Reflektoren) auf eine oder wenige Ziel-IPs (Opfer) und Zielports (die „Antwortports“ am Opfer, oft ephemer, aber das UDP-Ziel kann variieren).

Muster 3: Source-Diversität extrem hoch, aber die Quellen wirken „legitim“

Reflektoren sind echte Systeme mit echten IPs. Das macht IP-basierte Blocklisten am Edge ineffektiv, weil Sie tausende bis Millionen IPs sehen können. Typisch ist, dass viele Quellen aus Heimnetzen oder schlecht administrierten Netzen stammen (SSDP, offene Resolver), also weltweit verteilt. Daraus folgt eine wichtige Diagnose-Regel:

Wenn ein UDP-DDoS viele verschiedene Quellen hat, ist „Blocke Top-N Quellen“ selten nachhaltig.

Muster 4: Asymmetrie – Ihr Netz sieht nur Antworten

Weil die Requests vom Angreifer an Reflektoren gehen (mit gefälschter Source-IP), sieht das Opfernetz typischerweise nur den Rücktraffic (Responses). Die eigentliche „Anfrage“ existiert aus Sicht des Opfernetzes nicht. Dieses Muster ist ein starker Indikator für Reflection/Amplification.

Amplification-Faktor: Warum kleine Anfragen große Angriffe erzeugen

Operativ hilft es, die Verstärkung greifbar zu machen. Der Amplification-Faktor ist das Verhältnis aus Antwortgröße zu Anfragegröße. In der Realität hängt er vom Protokoll, den Antworttypen und der Serverkonfiguration ab.

Amplification-Faktor (MathML)

$AF = \frac{ResponseBytes}{RequestBytes}$

Wenn AF deutlich größer als 1 ist, kann der Angreifer mit relativ geringer Upstream-Kapazität beim Senden der Requests ein Vielfaches an Bandbreite am Opfer erzeugen. Für Operations ist das relevant, weil Mitigation dann primär bandbreitenorientiert sein muss (Scrubbing, Upstream-Filter, Anycast-Verteilung), nicht nur state-orientiert.

Telemetrie und Flow-Daten: Welche Signale Sie im NOC nutzen sollten

Für eine schnelle und belastbare Diagnose brauchen Sie Signale, die auch bei hohem Traffic noch zuverlässig sind. Eine praxistaugliche Mindestbasis:

NetFlow/IPFIX: Top Destination IPs, Top Ports, Bytes/Packets, Source-Diversität, PPS/BPS pro Port.
Interface-Statistiken: Ingress/egress bits/s und packets/s, Drops/Discards, Queue Drops.
ACL/Policer Counters: Hits auf UDP-Port-Regeln (z. B. DNS/NTP/SSDP), Drops nach Mitigation.
RTT/Health-Probes: Kunden-SLIs (DNS resolution, HTTP/TLS over v4/v6), um Impact zu belegen.
Control-Plane Schutz: CoPP/CPU Indikatoren, damit die Infrastruktur während des Angriffs steuerbar bleibt.

IPFIX ist in RFC 7011 beschrieben. Für DDoS-Response-Prozesse ist außerdem ein strukturierter Incident-Ansatz hilfreich; praxisnahe Leitfäden finden sich bei FIRST.

Sichere Mitigation: Grundprinzipien, bevor Sie filtern

„Sichere Mitigation“ bedeutet im Provider-Kontext: (1) minimaler Kollateralschaden, (2) schnelle Wirksamkeit, (3) reversible Schritte, (4) klare Nachweise, dass die Maßnahme wirkt. Bei UDP Amplification ist die Versuchung groß, einfach UDP/53 oder UDP/123 global zu blocken. Das ist meist nicht akzeptabel, weil es legitime Dienste trifft. Stattdessen sollten Sie nach dem Prinzip „eng, gestaffelt, messbar“ vorgehen.

Eng: nur betroffene Ziele/Prefixes/VRFs, nicht „das ganze Netz“.
Gestaffelt: zuerst Rate-Limits oder Scrubbing, dann härtere Filter, falls nötig.
Messbar: jeder Schritt muss in Telemetrie als Verbesserung sichtbar sein (BPS/PPS runter, SLIs hoch).

Mitigation-Option 1: Upstream/Scrubbing statt „Edge-ACL überall“

Bei großen volumetrischen UDP Amplification Attacks ist lokales Filtern am Edge oft zu spät, weil die Leitung bereits gesättigt ist. Dann ist die sichere Option, Traffic vor dem Engpass zu bereinigen: über Scrubbing-Center, DDoS-Provider oder Upstream-Filtering. Operativ ist wichtig, dass Sie die nötigen Daten liefern können: Zielprefix, Zielport, Zeitfenster, Traffic-Signatur.

Vorteil: Entlastet die eigene Backbone-/Edge-Kapazität.
Risiko: falsche Signatur → Kollateralschaden; deshalb Signatur eng definieren und in Stufen aktivieren.

Mitigation-Option 2: Rate-Limiting und policierte „Notbremsen“

Wenn Sie nicht sofort scrubbing können, ist Rate-Limiting eine häufige erste Stabilisierung: begrenzen Sie die UDP-Paketrate oder Bandbreite zu einem Zielprefix oder Zielservice. Wichtig ist, dass Sie legitime UDP-Services berücksichtigen (z. B. DNS für die eigene Infrastruktur). Sinnvoll ist oft ein differenziertes Vorgehen:

Rate-Limit pro Destination Prefix: schützt das Opfer, ohne globalen Kollateralschaden.
Rate-Limit pro Port: nur für die auffälligen Amplifier-Ports, kombiniert mit Ausnahmen für eigene Resolver/NTP-Infrastruktur.
Priorisierung: Management-, Monitoring- und Control-Traffic muss überleben (CoPP/QoS).

Mitigation-Option 3: Zielgerichtete Filter (ACL) mit minimalem Blast Radius

ACLs sind effektiv, wenn die Signatur eng ist: z. B. „UDP auf Port 11211 zu einem bestimmten /32“. Problematisch werden ACLs bei DNS/53, weil DNS oft geschäftskritisch ist. Sichere ACL-Muster orientieren sich daher an:

Zieladressraum: nur betroffene VIPs/Prefixes.
Protokoll und Port: nur der konkrete Amplifier-Port, nicht „alles UDP“.
Paketgröße: optional (wenn Plattform unterstützt), z. B. große UDP-Pakete auf DNS-Port, die unplausibel für legitime Nutzung sind.
Whitelists: eigene DNS/NTP-Server, Upstream-Resolver, Monitoring-Quellen.

Mitigation-Option 4: RTBH / Flowspec als schnelle Eskalationsschiene

Im Providerbetrieb werden für DDoS häufig standardisierte Mechanismen genutzt, um Traffic schnell umzulenken oder zu verwerfen, z. B. Remote Triggered Black Hole (RTBH) oder BGP FlowSpec. Diese Ansätze sind sehr schnell, aber müssen vorsichtig eingesetzt werden, weil sie Traffic hart droppen können. Sicher sind sie vor allem, wenn ein einzelnes Ziel gerade „unrettbar“ überflutet wird und die Alternative ein kompletter PoP-Ausfall wäre.

Vorteil: sehr schnelle Aktivierung, entlastet Infrastruktur.
Risiko: kompletter Dienstverlust für das Ziel; daher nur mit klarer Freigabe und sauberem Scope.

Mitigation-Option 5: BCP 38 als Prävention – nicht als Incident-Fix

Quelle-Spoofing ist der Kern der Reflection. Langfristig hilft nur, Spoofing systematisch zu reduzieren. Das ist keine Sofortmaßnahme während eines Angriffs, aber ein entscheidender Bestandteil eines sicheren Betriebsmodells: Ingress Filtering, uRPF-Strategien und konsequente Anti-Spoofing-Policies reduzieren die Anzahl möglicher Reflektoren und Angreifer. Best Practices sind in RFC 2827 und RFC 3704 dokumentiert.

Abgrenzung: Legitime UDP-Spitzen vs. Amplification Attack

Damit Mitigation nicht „mehr kaputt macht als der Angriff“, müssen Sie legitime UDP-Spitzen unterscheiden. Typische legitime Peaks:

DNS Peaks: Resolver-Last durch Cache-Misses, Incident beim Upstream, große Rekursion.
Gaming/Streaming: Events erzeugen mehr UDP, aber meist verteilt auf viele Ziele/Ports und mit stabilen Service-SLIs.
QUIC/HTTP3: UDP/443 kann stark zunehmen, ohne Angriff zu sein; dann passen Paketgrößen, Sessions und SLIs.

Ein Amplification-Angriff zeigt dagegen meist: extreme Source-Diversität, unplausible Zielkonzentration, viele große UDP-Pakete auf typischen Amplifier-Ports, und gleichzeitig sinkende Servicequalität (Timeouts, Drops, saturierte Links).

Runbook: UDP Amplification Attack sicher triagieren und mitigieren

Dieses Runbook ist für NOC-Teams gedacht, um innerhalb weniger Minuten von „Verdacht“ zu einem belastbaren, sicheren Mitigation-Plan zu kommen.

Schritt: Scope festlegen

Welche Zielprefixes/IPs? einzelnes /32, VIP, Customer Prefix, Anycast-Service?
Welche Ports dominieren? 53/123/389/1900/11211 oder UDP/443?
Welche PoPs betroffen? lokal oder global?

Schritt: Muster bestätigen (Flows + Telemetrie)

Port-Konzentration: ungewöhnlich hoher Anteil auf einen Amplifier-Port.
Paketgrößen: auffällig große UDP-Pakete, BPS steigt stärker als PPS.
Source-Diversität: sehr viele Quellen, die nicht „zu blocken“ sind.
Impact: Link-Sättigung, Queue Drops, Service-SLIs fallen.

Schritt: Mitigation auswählen und stufenweise ausrollen

Wenn Links saturieren: zuerst Upstream/Scrubbing oder RTBH/Flowspec (eng scoped).
Wenn noch Headroom: Rate-Limits/ACLs auf Zielprefix und Port, plus Whitelists.
Wenn unklar: erst beobachten und eng instrumentieren, nicht global blocken.

Schritt: Erfolg messen und Second Outage vermeiden

Messkriterien: BPS/PPS sinken, Drops gehen zurück, SLIs erholen sich.
Stabilitätsfenster: Maßnahmen nicht sofort zurücknehmen; stufenweise Rollback, besonders vor Peak-Zeiten.
Dokumentation: Signatur, Scope, Zeitpunkt, Effekt – als Basis für RCA und zukünftige Automationen.

Outbound-Ressourcen

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.