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
la source
Réponses:
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
ANY
requê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
tcpdump
pour 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).la source
ANY
requêtes réussies à côté de celles qui échouent.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.