Frage Mein DNS-Server drückt 20 Mbps, warum?


Ich betreibe einen DNS-Server in EC2, und gestern war es etwa 20mbps, als ich mein Billing-Dashboard überprüfte und diesen Monat 1,86 TB an gebrauchten Daten fand. Das ist eine große Rechnung für mein kleines Projektlabor. Ich habe nie Leistungseinbußen bemerkt und habe mich nicht darum gekümmert Traffic-Schwellenwerte einzurichten, aber ich habe jetzt, da dies mich $ 200 + an Bandbreitengebühren gekostet hat.

Es scheint, dass jemand meinen DNS-Server als Teil eines Amplifikationsangriffs benutzt hat, aber ich weiß nicht, 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 Anfragen für Zone Ich werde nicht lokal hosten, richtig? Dieser Server ist die SOA für einige Domains, wird aber von meinen anderen Servern nicht dazu benutzt, etwas nachzusehen (jeder löst gegen OpenDNS oder Google). Welche Anweisung habe ich hier falsch oder vergesse ich? Meine Protokolle (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

22
2017-12-14 19:00


Ursprung


Dies beantwortet Ihre Frage nicht, aber Sie sollten Abrechnungsbenachrichtigungen einrichten docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/... - Tim
Wäre es akzeptabel, dass Sie für alle Clients ohne RFC 7873-Unterstützung ein Fallback auf TCP erzwingen? - kasperd
Ratenbegrenzung in BIND - Rui F Ribeiro
@RuiFRRibeiro Die Beschränkung auf autorisierende DNS-Server kann nützlich sein. Aber die Ratenbegrenzung kann selbst ein Schwachpunkt sein, der bei DoS-Attacken ausgenutzt werden kann. Wenn ein Angreifer einen Recursor mit Abfragen für eine Domäne überschwemmt, die auf einem autoritativen Server mit Ratenbegrenzung gehostet wird, können berechtigte Benutzer dieses Recursors möglicherweise nicht mehr in der Lage sein, Datensätze in der angegriffenen Domäne aufzulösen. Dieser Angriff kann mit abgeschwächt werden Aggressiver Einsatz von NSEC / NSEC3 das ist nicht weit verbreitet. - kasperd


Antworten:


Selbst wenn Ihr Server so eingestellt ist, dass er nur autorisierende Anfragen beantwortet wie Sie, kann er trotzdem für einen Amplifikationsangriff verwendet werden - ANY Abfragen gegen die Wurzel einer Zone können eine ziemlich schwere UDP-Antwort auslösen, da die Zonenwurzel tendenziell eine Anzahl von Datensätzen aufweist, insbesondere mit SPF / DKIM / DNSSEC.

Dies ist wahrscheinlich, was auf Ihrem System passiert - verwenden Sie tcpdump bestätigen. Wenn sie Ihre autoritativen Datensätze in einem Amplifikationsangriff verwenden, werden Ihre besten Optionen darin bestehen, einfach zu einer neuen IP zu wechseln und hoffen, dass sie nicht folgen, ändern Sie Ihre Zonenstammdaten, um sie zu einem weniger effektiven Verstärkungsvektor zu machen Response Rate Limiting (wenn Ihr BIND es unterstützt).


19
2017-12-14 19:57



Sie fragen meine Zonen nicht ab ... sollte nicht mein Server diese fallenlassen, anstatt überhaupt zu antworten? - Russell Anthony
@ RussellAnthony Für die Protokolleinträge, die Sie sehen, ja, ich glaube, sie werden gelöscht - aber für erfolgreichen Angriff Verkehr, würde kein Protokolleintrag erstellt werden, so dass in Bezug auf die Protokolle die Bandbreite Verwendung ist unsichtbar. Wenn der Angriff noch andauert (immer noch neue Log-Einträge?) Ich wette, es gibt eine Reihe von erfolgreichen ANY Abfragen neben diesen versagenden. - Shane Madden♦
Hinzugefügt rate-limit { responses-per-second 1; }; und es scheint ziemlich viel Verkehr verloren zu haben. Mir war nicht bewusst, dass Bind RRL von innen heraus könnte. - Russell Anthony
Wenn sie tatsächlich Abfragen für autorisierende Datensätze senden, bedeutet dies, dass sie den Domänennamen kennen müssen. In diesem Fall ist es nicht so wahrscheinlich, 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
Stellen Sie nur sicher, dass Ihr Ratenbegrenzer nicht zu einem DoS-Angriffsvektor wird: Wenn der Angreifer das Antwortlimit erschöpft, können legitime Caches (wie OpenDNS und Google) Ihren Namen ebenfalls nicht auflösen. - Jonas Schäfer