DNS Amplification: Prinzip, Erkennung und Schutz

Wenn ein Hoster dir mitteilt, dein Server habe an einem Angriff teilgenommen, ist das meist keine Verwechslung. Häufig steckt ein DNS-Resolver dahinter, der irgendwann für einen Test eingerichtet wurde und seitdem jedem im Internet antwortet. Genau solche Server sind der Rohstoff für DNS Amplification.

Wie DNS Amplification funktioniert

Das Prinzip lässt sich in drei Beobachtungen erklären, ohne dass man eine Anleitung braucht.

Erstens läuft DNS meist über UDP. UDP kennt keinen Verbindungsaufbau, der Server prüft also nicht, ob die Absenderadresse eines Pakets echt ist. Zweitens kann eine kleine Anfrage eine große Antwort auslösen, etwa wenn viele Einträge oder Signaturen zurückkommen. Drittens gibt es im Internet Server, die jedem antworten: offene Resolver und schlecht konfigurierte autoritative Server.

Fälscht jemand die Absenderadresse und setzt dort die IP eines Opfers ein, schickt der Resolver seine große Antwort an das Opfer. Der Angreifer verschickt wenig, beim Opfer kommt viel an. Weil die Antworten von Tausenden legitimen Servern stammen, lassen sie sich auch nicht einfach per IP-Sperre aussortieren.

Wie stark ist die Verstärkung?

Die US-Behörde CISA hat für UDP-basierte Reflexionsangriffe in ihrem Alert TA14-017A Verstärkungsfaktoren für die Bandbreite veröffentlicht:

Quelle: CISA, UDP-Based Amplification Attacks.

Ein Faktor von 50 bedeutet: 1 Mbit/s an gefälschten Anfragen erzeugt rund 50 Mbit/s beim Opfer. DNS ist dabei nicht das schlimmste Protokoll, aber eines der verbreitetsten, weil fast jedes Netz DNS-Server betreibt. Die Tabelle zeigt auch, warum die Liste der offenen UDP-Dienste auf deinem Server mehr als nur Port 53 umfassen sollte.

Wie sich Reflexionsangriffe von anderen Angriffsklassen unterscheiden, beschreibt der Artikel über DDoS-Arten.

Die zwei Rollen: Opfer und Reflektor

Bei DNS Amplification gibt es zwei Arten von Betroffenen, und die Maßnahmen unterscheiden sich völlig.

Als Opfer kannst du auf deinem eigenen Server wenig tun. Wenn die Leitung voll ist, nützt keine Firewall dahinter. Hier hilft nur, was vor deiner Leitung passiert. Die Sofortmaßnahmen dazu stehen unter DDoS-Attacke: was tun.

Als Reflektor dagegen hast du es selbst in der Hand. Und jeder geschlossene Resolver nimmt Angreifern Material weg.

Offenen Resolver finden

Der wichtigste Test läuft von außen, also von einem Rechner außerhalb deines Netzes:

dig @192.0.2.53 example.com A

Ein offener Resolver antwortet mit Status NOERROR, einer IP-Adresse im Answer-Abschnitt und dem Flag ra (recursion available) im Header. Ein korrekt geschlossener Server liefert etwas wie:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 41870
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

REFUSED und die Warnung sind hier das gute Ergebnis. Auf dem Server selbst zeigt ss -ulpn | grep ':53 ', welcher Prozess auf Port 53 lauscht. Oft ist es ein Dienst, an den niemand mehr gedacht hat.

Resolver schließen: Konfigurationen

BIND als rein autoritativer Server (beantwortet nur eigene Zonen):

options {
    directory "/var/cache/bind";
    recursion no;
    allow-query-cache { none; };

    // Response Rate Limiting
    rate-limit {
        responses-per-second 10;
    };
};

BIND als Resolver für das eigene Netz:

acl intern { 127.0.0.1; ::1; 192.168.0.0/16; 10.0.0.0/8; };

options {
    recursion yes;
    allow-recursion { intern; };
    allow-query-cache { intern; };
};

Unbound erlaubt ab Werk nur Anfragen von localhost. Wenn du es für dein Netz öffnest, dann gezielt:

server:
    interface: 0.0.0.0
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.0.0/16 allow
    access-control: 0.0.0.0/0 refuse

Danach named-checkconf beziehungsweise unbound-checkconf ausführen, den Dienst neu laden und den externen dig-Test wiederholen.

Response Rate Limiting (RRL) begrenzt, wie oft ein autoritativer Server dieselbe Antwort an dieselbe Zieladresse schickt. Legitime Resolver fragen selten zehnmal pro Sekunde exakt dasselbe, ein Reflexionsangriff tut genau das. Ein Startwert von 10 Antworten pro Sekunde ist üblich; beobachte danach die Logs.

Was Netzbetreiber tun können: BCP 38

Die eigentliche Ursache ist die gefälschte Absenderadresse. BCP 38 (RFC 2827) beschreibt Ingress-Filtering: Ein Netz lässt nur Pakete hinaus, deren Absenderadresse auch wirklich aus diesem Netz stammt. Würden alle Provider das umsetzen, gäbe es keine Reflexionsangriffe mit gefälschter Quelle. Das ist bis heute nicht flächendeckend der Fall.

Betreibst du ein eigenes Netz oder einen Server mit mehreren IP-Bereichen, prüfe, ob dein Upstream gefälschte Absender verwirft. Für einen einzelnen Mietserver liegt das beim Hoster.

Checkliste gegen Missbrauch deiner Server

• Externer dig-Test auf jede öffentliche IP mit DNS-Dienst ergibt REFUSED
• Autoritative Server: recursion no;
• Resolver: Rekursion nur für interne Netze
• Response Rate Limiting auf autoritativen Servern aktiv
• ss -ulpn zeigt keine vergessenen UDP-Dienste (NTP, SNMP, SSDP, Memcached)
• Monitoring auf ausgehenden UDP-Verkehr von Port 53
• Rate Limiting auf HTTP-Ebene getrennt geregelt, siehe Rate Limiting

DNSSEC und Amplification ehrlich betrachtet

Signierte Zonen liefern größere Antworten, weil Signaturen und Schlüssel mitkommen. Für Reflexion ist das attraktiv. Deshalb gehören DNSSEC und Response Rate Limiting zusammen. Auf DNSSEC zu verzichten, wäre die falsche Konsequenz: Ohne Signaturen kann ein Angreifer Resolvern gefälschte Einträge unterschieben, und das richtet oft mehr Schaden an als ein paar Minuten Überlast.

Wer seine Zonen nicht selbst betreibt, sollte darauf achten, dass der DNS-Anbieter RRL einsetzt, und die Domain bei einem Registrar mit DNSSEC halten, der DS-Einträge sauber an die Registry weiterreicht. Wie du deine autoritativen Nameserver zusätzlich gegen Ausfälle absicherst, steht unter DNS-DDoS.

Ein guter nächster Schritt ist eine Bestandsaufnahme: Welche Domains hast du, wo liegen ihre Nameserver, ist DNSSEC aktiv? Mehr zur Domain-Sicherheit findest du im Ratgeber von betadomain, und eine Übersicht der Kosten pro Endung in der Preisliste.

Schritt für Schritt

1. Rolle des Servers klärenEntscheide, ob der DNS-Server autoritativ für eigene Zonen ist, als Resolver für ein internes Netz dient oder beides. Ein autoritativer Server braucht keine Rekursion.
2. Von außen auf offene Rekursion testenFrage von einem fremden Netz aus mit dig @deine-IP example.com A einen fremden Namen ab. Kommt eine Antwort mit dem Flag ra und einer IP, ist der Resolver offen. Status REFUSED ist das gewünschte Ergebnis.
3. Rekursion abschalten oder einschränkenIn BIND bei rein autoritativen Servern recursion no setzen, bei Resolvern allow-recursion auf das eigene Netz begrenzen. Bei Unbound access-control nur für interne Netze erlauben.
4. Response Rate Limiting aktivierenAuf autoritativen BIND-Servern im options-Block rate-limit mit responses-per-second setzen, zum Beispiel 10. Das bremst identische Antworten an dieselbe Zieladresse.
5. Konfiguration prüfen und neu ladenMit named-checkconf die Syntax prüfen, den Dienst neu laden und den externen Test wiederholen.
6. Andere UDP-Dienste prüfenMit ss -ulpn alle offenen UDP-Ports auflisten und Dienste wie NTP, SNMP, SSDP oder Memcached schließen oder per Firewall auf interne Netze beschränken.