Mein DNS-Server überträgt 20 MBit / s. Warum?


22

Ich verwende einen DNS-Server in EC2 und er hat gestern etwa 20 MBit / s übertragen, als ich mein Abrechnungs-Dashboard überprüfte und in diesem Monat 1,86 TB an verwendeten Daten feststellte. Das ist eine große Rechnung für mein kleines Projektlabor. Ich habe noch nie Leistungseinbußen bemerkt und habe mich vorher nicht darum gekümmert, Datenverkehrsschwellen festzulegen, aber jetzt habe ich mehr als 200 USD an Bandbreitengebühren.

Es scheint, dass jemand meinen DNS-Server als Teil eines Verstärkungsangriffs verwendet hat, aber ich bin ratlos, wie.

Konfig ist unten.

// BBB.BBB.BBB.BBB = ns2.mydomain.com ip address

options {
        listen-on port 53 { any; };
//      listen-on-v6 port 53 { ::1; };
        directory "/var/named";
        dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-transfer { BBB.BBB.BBB.BBB; };
        allow-query-cache { BBB.BBB.BBB.BBB; };
        allow-query { any; };
        allow-recursion { none; };

        empty-zones-enable no;
        forwarders { 8.8.8.8; 8.8.4.4; };

        fetch-glue no;
        recursion no;

        dnssec-enable yes;
        dnssec-validation yes;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

zone "mydomain.com" IN {
        type master;
        file "zones/mydomain.com";
        allow-transfer { BBB.BBB.BBB.BBB; localhost; };
};

Angesichts dieser Konfiguration sollte ich KEINE Fragen zu Zonen beantworten, die ich nicht lokal hoste, oder? Dieser Server ist die SOA für einige wenige Domains, wird aber von meinen anderen Servern nicht zum Nachschlagen verwendet (alle richten sich gegen OpenDNS oder Google). Welche Weisung habe ich hier falsch oder vergesse ich? Meine Logs (63MB +) sind voll davon:

client 58.215.173.155#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 58.215.173.155#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 58.215.173.155#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 58.215.173.155#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 58.215.173.155#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 58.215.173.155#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 218.93.206.228#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 218.93.206.228#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 218.93.206.228#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 218.93.206.228#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 218.93.206.228#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 218.93.206.228#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 50.19.220.154#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 50.19.220.154#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 50.19.220.154#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 50.19.220.154#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 50.19.220.154#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 50.19.220.154#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 123.207.161.124#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 123.207.161.124#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 123.207.161.124#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 123.207.161.124#4444: query (cache) 'cpsc.gov/ANY/IN' denied
client 123.207.161.124#4444: query (cache) 'cpsc.gov/ANY/IN' denied

9
Dies beantwortet Ihre Frage nicht, aber Sie sollten Abrechnungsbenachrichtigungen einrichten docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/…
Tim

Wäre es für Sie akzeptabel, für alle Clients ohne RFC 7873-Unterstützung das Zurücksetzen auf TCP zu erzwingen?
Kasperd

1
Ratenbegrenzung in BIND
Rui F Ribeiro

@RuiFRibeiro Eine Beschränkung der Rate auf autorisierenden DNS-Servern kann hilfreich sein. Die Ratenbegrenzung selbst kann jedoch eine Schwachstelle sein, die bei DoS-Angriffen ausgenutzt werden kann. Wenn ein Angreifer einen Recursor mit Abfragen für eine Domäne überflutet, die auf einem autorisierenden Server mit Ratenbeschränkung gehostet wird, können legitime Benutzer dieses Recursors möglicherweise keine Datensätze in der angegriffenen Domäne mehr auflösen. Dieser Angriff kann durch den aggressiven Einsatz von NSEC / NSEC3, das nicht weit verbreitet ist, gemildert werden .
Kasperd

Antworten:


19

Selbst wenn Ihr Server so eingestellt ist, dass er nur autorisierende Abfragen beantwortet, ist es dennoch möglich, dass er für einen Verstärkungsangriff verwendet wird - ANYAbfragen gegen den Stamm einer Zone können eine ziemlich schwere UDP-Antwort auslösen, da der Stamm der Zone dazu neigt, eine zu haben eine Reihe von Datensätzen, insbesondere mit SPF / DKIM / DNSSEC.

Dies ist wahrscheinlich, was auf Ihrem System passiert - verwenden Sie tcpdump, um zu bestätigen. Wenn sie Ihre autoritativen Datensätze bei einem Amplifikationsangriff verwenden, besteht Ihre beste Möglichkeit darin, einfach auf eine neue IP zu wechseln und zu hoffen, dass sie nicht folgen, Ihre Zonenstammdatensätze zu ändern, um sie zu einem weniger effektiven Amplifikationsvektor zu machen oder zu implementieren Antwortratenbegrenzung (wenn Ihr BIND es unterstützt).


Meine Zonen werden jedoch nicht abgefragt. Sollte mein Server diese nicht löschen, anstatt überhaupt zu antworten?
Russell Anthony

4
@RussellAnthony Für die angezeigten Protokolleinträge werden sie wahrscheinlich gelöscht. Für einen erfolgreichen Angriffsverkehr wird jedoch kein Protokolleintrag erstellt, sodass die Bandbreitennutzung in Bezug auf die Protokolle unsichtbar ist. Wenn der Angriff immer noch andauert (immer noch neue Protokolleinträge?), Gibt es ANYneben diesen fehlgeschlagenen sicher eine Reihe erfolgreicher Abfragen.
Shane Madden

2
Hinzugefügt rate-limit { responses-per-second 1; };und es scheint ziemlich viel Verkehr gesunken zu sein. Ich war mir nicht bewusst, dass RRL aus sich selbst heraus gebunden werden konnte.
Russell Anthony

1
Wenn sie tatsächlich Anfragen nach maßgeblichen Datensätzen senden, bedeutet dies, dass sie den Domänennamen kennen müssen. In diesem Fall ist es unwahrscheinlich, dass der Wechsel zu einer neuen IP-Adresse hilfreich ist, da sie die neue IP-Adresse so schnell finden können wie die legitimen Benutzer.
Kasperd

6
Stellen Sie einfach sicher, dass Ihre Ratenbeschränkung nicht zu einem DoS-Angriffsvektor wird: Wenn der Angreifer die Antwortbeschränkung überschreitet, können legitime Caches (wie OpenDNS und Google) möglicherweise auch Ihren Namen nicht auflösen.
Jonas Schäfer
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.