DDoS-Attacke durch recursive DNS-Queries

Zahlreiche Admins erhalten die letzten Tage verzweifelte E-Mails ihrer durch eine DDoS-Attacke angegriffenen Kollegen. Für den Angriff werden ihre falsch konfigurierte DNS-Server mißbraucht, um eine Traffic-DDoS-Attacke auszulösen. Das Opfer klagt, über 50.000 DNS-Server wären weltweit in den Angriff involviert. Einzige Abhilfe: Eine wichtige (und richtige) Konfigurationsänderung.

Unser Schaubild zeigt den Ablauf des Angriffs: Durch das in DNS-Abfragen übliche UDP-Protokoll kann der Angreifer sehr leicht DNS-Queries an beliebige Nameserver stellen, die als Quell-IP die IP-Adresse des angegriffenen Opfers tragen (1).

Der angefragte DNS-Server wird seine spätere Antwort darum an den Opfer-Server zurücksenden (3).

Schaubild einer DDOS-Attacke durch offene DNS-ServerDas alleine wäre noch kein DDoS-Angriff. Der Angreifer muß es also nun darauf anlegen, möglichst viel Traffic zum Opfer senden zu lassen. Also fragt er nach speziell präparierten TXT-Records seiner eigenen Domain (2).

Der Vorteil am TXT-Feld im DNS ist, daß sich hier viel Text und damit echtes Datenvolumen unterbringen läßt.  Da die mißbrauchten DNS-Server die DNS-Abfrage lokal cachen, kann der Angreifer nun fortlaufend Tausende von gefälschten DNS-Queries per UDP lossenden, ohne daß seine eigene DNS-Infrastruktur durch den Traffic ernsthaft belastet wird (4). Die mißbrauchten DNS-Server arbeiten jedoch nun für den Angreifer und erzeugen fortlaufend große Datenpakete zum Opfer — ein klassischer Distributed Denial of Service (DDoS).

So muß der Nameserver konfiguriert werden

Das Problem ist, daß die mißbrauchten DNS-Server „open recursive“ sind. Das heißt: DNS-Abfragen für ihre eigenen von ihren authoritativ gehosten Domains („primary/secondary DNS“) müssen sie natürlich aus dem ganzen Internet annehmen und beantworten.

DNS-Abfragen nach fremden Domains („recursive Queries“), für die sie also keine lokalen Zonefiles besitzen, dürfen sie genaugenommen nur für eigene Server, Netze oder Einwahlbereiche vornehmen.  Oft ist das jedoch für alle IP-Adressen der Welt offen — es stört in der Regel ja nicht, weil ja niemand sonst diese DNS-Abfragen stellt.

Wichtig ist in diesem DDoS-Angriff also, daß die mißbrauchten DNS-Server keine Queries mehr von überall her („any“) zulassen — dann würde der gefälschte DNS-Query des Angreifers kurzerhand abgelehnt und nicht beantwortet werden.

In der Konfigurationsdatei des populären DNS-Servers bind ist das schnell eingetragen. An passender Stelle (named.conf, named.conf.local bzw. bei Debian named.conf.options) ist in den options-Block einzutragen:

options {
  [...]
        allow-recursion { x.x.x.x/x, 10.0.0.0/8; 192.168.0.0/16;
127.0.0.0/8; ::1; };
  [...]
}

wobei x.x.x.x/x natürlich durch die jeweiligen eigenen IP-Netzbereiche zu ersetzen ist.

Anschließend muß named neu gestartet werden.

Und so wird getestet

Der Erfolg ist schnell zu sehen. Während zuerst eine rekursive Abfrage nach einer fremden Domain noch beantwortet wurde:

peer@booster:~> dig heinlein-support.de  @ns.example.com

 ; <<>> DiG 9.7.4-P1 <<>> heinlein-support.de @ns.example.com
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6997
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

 ;; QUESTION SECTION:
 ;heinlein-support.de.           IN      A

 ;; ANSWER SECTION:
 heinlein-support.de.    34      IN      A       91.198.250.115

 ;; AUTHORITY SECTION:
 heinlein-support.de.    3334    IN      NS      ns.jpberlin.de.
 heinlein-support.de.    3334    IN      NS      ns2.jpberlin.de.

 ;; ADDITIONAL SECTION:
 ns.jpberlin.de.         1534    IN      A       213.203.238.4
 ns2.jpberlin.de.        1534    IN      A       194.150.191.56

 ;; Query time: 29 msec
 ;; SERVER: xxx
 ;; WHEN: Mon Jul 23 15:55:30 2012
 ;; MSG SIZE  rcvd: 129

Wird anschließend die Beantwortung abgelehnt. Der Angreifer kann keinen nennenswerten Traffic mehr zum Opfer erzeugen:

peer@booster:~> dig heinlein-support.de  @ns.example.com

 ; <<>> DiG 9.7.4-P1 <<>> heinlein-support.de @ns.example.com
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 18795
 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
 ;; WARNING: recursion requested but not available

 ;; QUESTION SECTION:
 ;heinlein-support.de.           IN      A

 ;; Query time: 27 msec
 ;; SERVER: xxx
 ;; WHEN: Mon Jul 23 15:55:44 2012
 ;; MSG SIZE  rcvd: 37

Wer diese Konfigurationsanpassung nicht vornimmt muß ein schlechtes Gewissen haben. Er ist dann Teil des Angriffs und hilft dem Angreifer bei seiner Attacke (und bezahlt den Traffic…).

Dieser Beitrag wurde unter Blog, Security abgelegt und mit , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

12 Kommentare zu DDoS-Attacke durch recursive DNS-Queries

  1. aram sagt:

    Bei mir funktioniert es nicht Bind antwortet weiter rekursive Anfragen!

  2. Tja… Wenn Du die Config schickst, dann kann ich gerne mal reinschauen und den Fehler suchen. Schick mir Config und die IP des Nameservers per Mail, dann schau ich rauf.

  3. Georg sagt:

    Danke für die interessante Darstellung; ich habe unseren DNS entsprechend konfiguriert, weiß aber jetzt nicht, wie ich das testen kann (unser eigenes Netzt darf entsprechend auflösen).

    Vielen Dank und beste Grüße aus Österreich

    Georg

  4. Hallo Georg. Testen kannst Du es eben, indem Du mal von einer externen IP aus kommst. DSL-Dialup, UMTS, sonstwas. Oder indem Du mal Abends Dein eigenes Netz aus der DNS-ACL rausnimmst und dann schaust, ob nichts mehr geht :-)

  5. Georg sagt:

    Hallo,
    vielen Dank für die Anleitung. Ich lasse bei mir recursive Queries nur von localhost zu

    options {
    [...]
    allow-recursion { 127.0.0.1/32; };
    };

    Danach erhalte ich statt eines Eintrags bei ANSWER 13 unter AUTHORITY. Damit ist das Problem nicht wirklich behoben, oder?

    ; <> DiG 9.7.3 <> heinlein-support.de @myserver
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45475
    ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
    ;; WARNING: recursion requested but not available

    ;; QUESTION SECTION:
    ;heinlein-support.de. IN A

    ;; AUTHORITY SECTION:
    . 3600000 IN NS I.ROOT-SERVERS.NET.
    . 3600000 IN NS J.ROOT-SERVERS.NET.
    . 3600000 IN NS K.ROOT-SERVERS.NET.
    . 3600000 IN NS L.ROOT-SERVERS.NET.
    . 3600000 IN NS M.ROOT-SERVERS.NET.
    . 3600000 IN NS A.ROOT-SERVERS.NET.
    . 3600000 IN NS B.ROOT-SERVERS.NET.
    . 3600000 IN NS C.ROOT-SERVERS.NET.
    . 3600000 IN NS D.ROOT-SERVERS.NET.
    . 3600000 IN NS E.ROOT-SERVERS.NET.
    . 3600000 IN NS F.ROOT-SERVERS.NET.
    . 3600000 IN NS G.ROOT-SERVERS.NET.
    . 3600000 IN NS H.ROOT-SERVERS.NET.

    ;; Query time: 15 msec
    ;; SERVER: xxx
    ;; WHEN: Mon Mar 18 16:08:56 2013
    ;; MSG SIZE rcvd: 248

  6. Doch, sieht doch alles gut aus. Du kriegst keine Antwort und es gibt ja sogar explizit den Hinweis,daß recursion nicht erlaubt ist.

  7. Christian sagt:

    Danke für die ausführliche Beschreibung, aber was mache ich auf einem Windows Server SBS 2011 mit Exchange, der scheint das rekursive DNS zu benötigen, ich finde aber keine Möglichkeit die allow-recursion zu verändern?

    Danke
    Christian

  8. Hmm, tja. Windows-Admins vor. Ich habe leider ECHT keine Ahnung von Windows-Servern…

  9. Bernhard sagt:

    Hallo Peer, (hoffe du liest das noch mit)

    als jüngstes Opfer einer DDoS Attacke und Herzklopfen nach einer abuse-email habe ich nach langen Recherchen im Internet genau deine Anleitung gefunden und auch so umgesetzt. Jedoch haben mich die weiterhin eintreffenden DDoS Anfragen sehr beunruhigt obwohl sie nun „Refused“ werden.
    Ist das nun noch gefährlich oder kann ich nun beruhigt sein?
    Am liebsten würde ich eine Firewall-Regel einbinden, die solche Anfragen nicht zu lässt oder die Beantwortung unterdrückt.
    Oder sind solche Antworten mit 39 Bytes nur als Internet Müll zu betrachten?

    Dank
    Bernhard

  10. Das eigentliche Ziel dieser DDoS-Attacken ist ja nicht der Recursive Nameserver — der wird ja nur als Mittel zum Zweck genutzt um das eigentliche Opfer zu fluten.

    Die 39 Byte Anfragen sollten Dich und Deinen Server kalt lassen. Müll, Grundrauschen, total egal. Du lehnst das ab und damit ist gut. Und eine ernsthafte Belastung für den Server sollte das ja nicht sein.

    Höchstens WENN es eine spürbare Belastung ist würde ich mich da drum kümmern.

  11. Bernhard sagt:

    Hallo Peer,

    ok, muss mir also kein Sorgen (Herzklopfen) mehr machen :-)

    Danke.

  12. Thhunder sagt:

    Hallo Peter,
    gibt es hier noch andere methoden um einen DNS-server gegen diese methoden zu schützen?
    ich würde gern meinen DNS-Server weiterhin für ein projekt offen betreiben und kann daher keine ip-ranges explizit zuweisen/verbieten…
    wäre hier sehr dankbar für weitere hilfe damit diese DDoS kram aufhört.

    Gruß

    Thhunder

    P.S.: mail wäre bevorzugt zur kontaktaufnahme :-)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.