Meu servidor DNS está aumentando 20mbps, por quê?

Estou executando um servidor DNS no EC2, e ele estava sobrecarregando cerca de 20mbps ontem quando verifiquei meu painel de cobrança e encontrei 1,86 TB de dados usados este mês. Essa é uma grande conta para o meu pequeno laboratório de projetos. Eu nunca notei quedas de desempenho e não me preocupei em configurar limites de tráfego antes, mas agora tenho, pois isso me custou mais de US $ 200 em taxas de largura de banda.

Parece que alguém usou meu servidor DNS como parte de um ataque de amplificação, no entanto, não sei como.

A configuração está abaixo.

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

Dada essa configuração, NÃO devo responder a nenhuma pergunta sobre as zonas que não hospedo localmente, certo? Este servidor é a SOA de alguns domínios, mas não é usado para procurar nada nos meus outros servidores (todos resolvem com o OpenDNS ou o Google). Que diretiva eu tenho errado aqui ou estou esquecendo? Meus logs (63 MB ou mais) estão cheios disso:

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
fonte

Isso não responde à sua pergunta, mas você deve configurar alertas de cobrança docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/…

— Tim

Seria aceitável você forçar o fallback do TCP para todos os clientes sem suporte ao RFC 7873?

— kasperd

limite de taxa em BIND

— Rui F Ribeiro

@RuiFRibeiro A limitação de taxa em servidores DNS autoritativos pode ser útil. Mas a limitação da taxa pode ser um ponto fraco que pode ser explorado em ataques de DoS. Se um invasor inundar um recursor com consultas para um domínio hospedado em um servidor autoritário com limite de taxa, os usuários legítimos desse recursor poderão não conseguir mais resolver registros no domínio sob ataque. Esse ataque pode ser mitigado com o uso agressivo do NSEC / NSEC3, que não é amplamente implantado.

— kasperd

Mesmo que seu servidor esteja configurado para responder apenas a consultas autorizadas como a sua, ainda é possível usá-lo para um ataque de amplificação - ANYconsultas contra a raiz de uma região podem desencadear uma resposta UDP bastante pesada, pois a raiz da zona tende a ter vários registros, principalmente com SPF / DKIM / DNSSEC.

Provavelmente, isso está acontecendo no seu sistema - use tcpdumppara confirmar. Se eles estiverem usando seus registros oficiais em um ataque de amplificação, suas melhores opções serão simplesmente mudar para um novo IP e esperar que não sigam, alterar os registros raiz da zona para torná-lo um vetor de amplificação menos eficaz ou implementar limitação da taxa de resposta (se o seu BIND suportar).

— Shane Madden
fonte

No entanto, eles não estão consultando minhas zonas ... meu servidor não deveria estar descartando-as em vez de responder?

— Russell Anthony

@RussellAnthony Para as entradas de log que você está vendo, sim, acredito que as está descartando - mas, para um tráfego de ataque bem-sucedido, nenhuma entrada de log seria criada; portanto, em termos dos logs, o uso da largura de banda é invisível. Se o ataque ainda estiver em andamento (ainda recebendo novas entradas de log?), Aposto que há várias ANYconsultas bem-sucedidas, além dessas falhas.

— Shane Madden

Adicionado rate-limit { responses-per-second 1; };e parece ter diminuído bastante do tráfego. Eu não estava ciente de que o bind podia RRL por dentro.

— Russell Anthony

Se eles estavam realmente enviando consultas para registros oficiais, significa que eles devem saber o nome do domínio. Nesse caso, não é tão provável que mudar para um novo IP ajude, pois eles poderão encontrar o novo endereço IP tão rápido quanto os usuários legítimos.

— kasperd

Apenas certifique-se de que seu limite de taxa não se transforme em um vetor de ataque DoS: se o invasor esgotar o limite de resposta, os caches legítimos (como o OpenDNS e o google) também poderão não conseguir resolver seu nome.

— Jonas Schäfer