Mon serveur DNS pousse à 20 Mbps, pourquoi?

J'utilise un serveur DNS dans EC2, et il poussait hier à environ 20 Mbps lorsque j'ai vérifié mon tableau de bord de facturation et trouvé 1,86 To de données utilisées ce mois-ci. C'est une grosse facture pour mon petit laboratoire de projet. Je n'ai jamais remarqué de baisse de performances et je n'ai pas pris la peine de configurer des seuils de trafic auparavant, mais je l'ai maintenant car cela m'a coûté 200 $ + en frais de bande passante.

Il semble que quelqu'un ait utilisé mon serveur DNS dans le cadre d'une attaque d'amplification, mais je ne sais pas comment.

La configuration est ci-dessous.

// 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; };
};

Compte tenu de cette configuration, je ne devrais PAS répondre à des questions sur les zones que je n'héberge pas localement, n'est-ce pas? Ce serveur est le SOA de quelques domaines, mais n'est pas utilisé pour rechercher quoi que ce soit par mes autres serveurs (tout le monde se résout contre OpenDNS ou Google). Quelle directive ai-je tort ici, ou est-ce que j'oublie? Mes journaux (63 Mo +) sont remplis de ceci:

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

— Russell Anthony
source

Cela ne répond pas à votre question, mais vous devez configurer des alertes de facturation docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/...

— Tim

Serait-il acceptable pour vous de forcer le repli sur TCP pour tous les clients sans prise en charge RFC 7873?

— kasperd

limitation de taux dans BIND

— Rui F Ribeiro

@RuiFRibeiro La limitation du débit sur les serveurs DNS faisant autorité peut être utile. Mais la limitation de débit peut elle-même être un point faible qui peut être exploitée dans les attaques DoS. Si un attaquant inonde un récursif de requêtes pour un domaine hébergé sur un serveur faisant autorité avec limitation de débit, les utilisateurs légitimes de ce récurseur peuvent ne plus être en mesure de résoudre les enregistrements du domaine attaqué. Cette attaque peut être atténuée par une utilisation agressive de NSEC / NSEC3 qui n'est pas largement déployée.

— kasperd

Même si votre serveur est configuré pour répondre uniquement aux requêtes faisant autorité comme la vôtre, il est toujours possible de l'utiliser pour une attaque d'amplification - les ANYrequêtes contre la racine d'une zone peuvent déclencher une réponse UDP assez lourde, car la racine de la zone a tendance à avoir un certain nombre d'enregistrements, en particulier avec SPF / DKIM / DNSSEC.

C'est probablement ce qui se passe sur votre système - utilisez tcpdumppour confirmer. S'ils utilisent vos enregistrements faisant autorité dans une attaque d'amplification, vos meilleures options seront simplement de passer à une nouvelle adresse IP et d'espérer qu'ils ne suivent pas, de modifier vos enregistrements racine de zone pour en faire un vecteur d'amplification moins efficace, ou de mettre en œuvre limitation du taux de réponse (si votre BIND le prend en charge).

— Shane Madden
source

Cependant, ils n'interrogent pas mes zones ... mon serveur ne devrait-il pas les supprimer au lieu de répondre du tout?

— Russell Anthony

@RussellAnthony Pour les entrées de journal que vous voyez, oui, je pense que cela les supprime - mais, pour un trafic d'attaque réussi, aucune entrée de journal ne sera créée, donc en termes de journaux, l'utilisation de la bande passante est invisible. Si l'attaque est toujours en cours (vous obtenez toujours de nouvelles entrées de journal?) Je parie qu'il y a un tas de ANYrequêtes réussies à côté de celles qui échouent.

— Shane Madden

Ajouté rate-limit { responses-per-second 1; };et il semble avoir perdu pas mal de trafic. Je ne savais pas que lier pouvait RRL de l'intérieur de lui-même.

— Russell Anthony

S'ils envoyaient effectivement des requêtes pour des enregistrements faisant autorité, cela signifie qu'ils doivent connaître le nom de domaine. Dans ce cas, il est peu probable que le passage à une nouvelle adresse IP soit utile, car ils pourraient trouver la nouvelle adresse IP aussi rapidement que les utilisateurs légitimes.

— kasperd

Assurez-vous simplement que votre limitation de débit ne se transforme pas en un vecteur d'attaque DoS: si l'attaquant dépasse la limite de réponse, les caches légitimes (tels que OpenDNS et google) peuvent également ne pas résoudre votre nom.

— Jonas Schäfer