6. Oktober 2026 · 6 Min. Lesezeit

Abwehr von DNS-Amplification-Angriffen: offene Resolver schließen, Response Rate Limiting einsetzen, Spoofing unterbinden, Grenzen von BGP FlowSpec kennen.

DNS-Amplification-Angriffe gehören zu den häufigsten volumetrischen Angriffsvektoren und haben eine Eigenschaft, die sie von den meisten anderen unterscheidet: Dasselbe Netz kann zugleich Ziel und Waffe sein. Der Angreifer schickt den Verkehr nicht direkt an das Opfer, sondern nutzt dafür fremde DNS-Server und vervielfacht dabei das Volumen.

Dieser Artikel behandelt beide Seiten des Problems: wie Sie vermeiden, selbst zur Quelle eines solchen Angriffs zu werden, und wie Sie den Schaden begrenzen, wenn Ihr eigenes Netz das Ziel ist.

Der DNS-Amplification-Angriff in drei Sätzen

Der Angreifer sendet eine DNS-Anfrage mit gefälschter Absenderadresse und setzt dabei die Adresse des Opfers ein. Der DNS-Server kann den Absender nicht überprüfen und schickt die Antwort an diese Adresse. Da die Antwort um ein Vielfaches größer sein kann als die Anfrage und der Angreifer seine Anfragen gleichzeitig an Tausende Server verteilt, erhält das Opfer Verkehr, der in keinem Verhältnis zu dem steht, was der Angreifer selbst senden musste.

Daraus folgen zwei praktische Schlüsse. Erstens erreicht der Verkehr das Opfer von sehr vielen echten, nicht gefälschten Adressen: Es handelt sich um reale DNS-Server, nicht um Bots. Zweitens ist der Angriff nur möglich, weil irgendwo auf dem Pfad eine Partei das Fälschen der Absenderadresse zugelassen und eine andere einen Server bereitgestellt hat, der Fremden antwortet.

Teil eins: nicht zur Quelle werden

Dieser Teil gerät leicht in Vergessenheit, weil das Problem dem eigenen Netz nicht schadet. Und doch: Ein offener Resolver in Ihrem Adressraum bedeutet, dass Ihr Netz an Angriffen auf andere beteiligt ist, ausgehenden Verkehr erzeugt, die eigenen Leitungen belastet und in Bedrohungsberichten auftaucht, von wo das Problem in Form von Einschränkungen durch Transit-Provider zu Ihnen zurückkommt.

Prüfung auf offene Resolver

Am einfachsten scannen Sie Ihre eigenen Präfixe nach Servern, die rekursive Anfragen von außen beantworten. Eine von außerhalb des Netzes gesendete Testanfrage sollte abgewiesen werden; kommt eine gültige Antwort zurück, ist der Resolver offen:

dig @<server-address> +short example.com A

Wenn Sie Zugangsdienste anbieten, wiederholen Sie denselben Test im Adressraum Ihrer Kunden: Offene Resolver auf Kundenroutern sind weitaus häufiger als auf Servern des Netzbetreibers.

Rekursion einschränken

Ein rekursiver Server sollte nur seinen eigenen Nutzern antworten, und ein autoritativer Server sollte überhaupt keine Rekursion anbieten. In BIND werden die beiden Rollen explizit getrennt:

acl "trusted" { 10.0.0.0/8; 192.0.2.0/24; localhost; };

options {
    recursion yes;
    allow-recursion { trusted; };
    allow-query-cache { trusted; };
    additional-from-cache no;
};

Ist der Server autoritativ, setzen Sie recursion no; und belassen allow-query { any; }; nur für die Zonen, die er tatsächlich bedient.

Antwortrate begrenzen

Ein autoritativer Server, der sich nicht von der Außenwelt abschotten lässt, wird mit Response Rate Limiting (RRL) geschützt. Es erkennt wiederholte, identische Anfragen aus einem Adressbereich und beginnt, einen Teil der Antworten auszulassen oder gekürzt (truncated) zu senden, wodurch der Angriff wirtschaftlich sinnlos wird:

rate-limit {
    responses-per-second 10;
    window 5;
    slip 2;
};

Die Werte werden an das Verkehrsprofil des jeweiligen Servers angepasst: Betrachten Sie die obigen Angaben als Ausgangspunkt für die Beobachtung, nicht als fertiges Rezept.

Spoofing von Absenderadressen an der Quelle unterbinden

Dies ist die wirksamste einzelne Maßnahme gegen die gesamte Klasse der Amplification-Angriffe und zugleich die am häufigsten ausgelassene. Sendet ein Netz keine Pakete mit Absenderadressen außerhalb des eigenen Adressraums, lässt sich von dort kein Angriff mit gefälschter Absenderadresse starten.

Aktivieren Sie am Netzrand zu den Kunden die Validierung der Absenderadresse gegen die Routing-Tabelle: im Strict-Modus, wo der Verkehr symmetrisch verläuft, und im Loose-Modus, wo das Routing asymmetrisch sein kann.

Juniper:  set interfaces ge-0/0/0 unit 0 family inet rpf-check
Cisco:    ip verify unicast source reachable-via rx

Hinweis. Der Strict-Modus gehört auf Teilnehmeranschlüsse, nicht an Peering- oder Transitgrenzen. An Grenzen mit möglicherweise asymmetrischem Routing schneidet der Strict-Modus völlig legitimen Verkehr ab.

Teil zwei: selbst das Ziel sein

Ist Ihre Adresse das Ziel, sieht das Bild anders aus. Der Verkehr kommt von echten DNS-Servern auf der ganzen Welt, daher ist Blockieren nach Absenderadresse sinnlos: Die Liste wäre endlos, und nebenbei würden Sie Server abschneiden, auf die Sie selbst angewiesen sind.

Was sich filtern lässt

Kennzeichnend für diesen Vektor ist ein fester Quellport 53 über UDP, mit großen und häufig fragmentierten Antworten. Das genügt für eine Filterregel, sofern Sie in diesem Moment keine DNS-Antworten auf der angegriffenen Adresse empfangen müssen.

Eine Regel in BGP FlowSpec, die auf dieses Muster passt, greift auf dem Edge-Router und verwirft den Verkehr, bevor er ins Netz gelangt. Sobald WanGuard die Anomalie erkennt, erzeugt es eine solche Regel automatisch aus dem erkannten Vektor, und der Operator kann sie enger oder weiter fassen.

Was sich nicht filtern lässt

Die Grenzen dieser Methode sollten Sie kennen, um keine falschen Erwartungen aufzubauen. Nutzt der Angriff zufällige Quellports oder kombiniert er mehrere Vektoren gleichzeitig, sind die Filterkriterien nicht mehr trennscharf, und die Filterung erfasst zunehmend legitimen Verkehr. In dieser Situation bleiben eine Ratenbegrenzung für das Muster oder das Abschneiden der Adresse per Blackhole.

Ähnlich verhält es sich mit Fragmentierung: Nicht-initiale Fragmente enthalten keine Layer-4-Header, daher erfasst eine Regel auf den Quellport sie nicht. Sie müssen separat behandelt werden.

Blackholing als letztes Mittel

Wenn das Volumen die Leitungen gefährdet, bleibt nur, den Verkehr zur angegriffenen Adresse abzuschneiden. Blackholing beendet den Angriff auf Kosten dieser einen Adresse und schützt den Rest des Netzes. Damit es korrekt funktioniert, ohne die Konsole oder den Router zu belasten, muss die Discard-Route richtig konfiguriert sein; das behandeln wir in einem eigenen Artikel zum sicheren Blackholing.

Checkliste

  • Präfixe auf offene Resolver gescannt, einschließlich des Adressraums der Teilnehmer.
  • Rekursive Server antworten nur den eigenen Nutzern.
  • Bei autoritativen Servern ist die Rekursion deaktiviert.
  • Öffentlich erreichbare Server haben Response Rate Limiting aktiviert.
  • Die Validierung der Absenderadresse ist auf Teilnehmeranschlüssen aktiv (und an Transitgrenzen nicht im Strict-Modus).
  • Die Erkennungsschwellen decken den DNS-Vektor ab, und Filterregeln werden vor einem Angriff vorbereitet, nicht währenddessen.
  • Das Blackholing-Verfahren wurde außerhalb eines Angriffs getestet.

Die Empfehlungen zur Validierung der Absenderadresse beruhen auf BCP 38 (RFC 2827) und BCP 84 (RFC 3704).