Há algumas coisas que você precisa entender sobre isso:

Este é um problema de engenharia de rede.

A maioria das pessoas que desejam configurar esse tipo de ambiente são administradores de sistema. Legal, também sou administrador de sistema! Parte do trabalho é entender onde terminam suas responsabilidades e começam as de outra pessoa e, acredite, esse não é um problema que os administradores de sistema possam resolver sozinhos. Aqui está o porquê:

• O UDP é um protocolo sem estado. Não há aperto de mão do cliente.
• As consultas em um servidor DNS são uma transação não autenticada de duas etapas (consulta, resposta). Não há como o servidor saber se o IP de origem foi falsificado antes de responder.
• No momento em que uma consulta chega ao servidor, já é tarde demais para evitar um pacote UDP falsificado. A falsificação só pode ser evitada por uma prática conhecida como filtragem de entrada , um tópico coberto pelos documentos BCP 38 e BCP 84 . Eles são implementados pelos dispositivos de rede localizados na frente do seu servidor DNS.
• Não podemos fornecer instruções sobre como configurar seu datacenter de ponta a ponta ou como implementar essas práticas recomendadas. Essas coisas são muito específicas para suas próprias necessidades. O formato de perguntas e respostas simplesmente não funciona para isso, e este site não pretende substituir a contratação de profissionais para realizar trabalhos profissionais.
• Não presuma que sua empresa bilionária, grande demais para falir, implementa a filtragem de entrada corretamente.

Esta não é uma prática recomendada. A melhor prática é não fazer isso.

É muito fácil configurar um resolvedor de DNS voltado para a Internet. É preciso muito menos pesquisa para configurar um do que para entender os riscos envolvidos em fazê-lo. Este é um daqueles casos em que as boas intenções inadvertidamente permitem os erros (e o sofrimento) dos outros.

• Se o seu servidor DNS responder a qualquer endereço IP de origem que encontrar, você está executando um resolvedor aberto. Estes são constantemente aproveitados em ataques de amplificação contra partes inocentes. Novos administradores de sistema estão abrindo resolvedores todos os dias , tornando lucrativo para indivíduos mal-intencionados procurá-los constantemente. Não há realmente uma dúvida se o seu resolvedor aberto será ou não usado em um ataque: a partir de 2015, é praticamente certo. Pode não ser imediato, mas com certeza vai acontecer.
• Mesmo se você aplicar uma ACL usando seu software DNS (ou seja, BIND), tudo isso limitará a quais pacotes DNS falsificados seu servidor responderá. É importante entender que sua infraestrutura de DNS pode ser usada não apenas para atacar os dispositivos na ACL, mas também qualquer dispositivo de rede entre seu servidor DNS e os dispositivos pelos quais ele responderá. Se você não possui o datacenter, isso é um problema para mais do que apenas você.

O Google e o OpenDNS fazem isso, então por que eu não posso?

Às vezes é necessário pesar o entusiasmo contra a realidade. Aqui estão algumas perguntas difíceis de se fazer:

• Isso é algo que você deseja configurar por capricho ou é algo em que você tem alguns milhões de dólares para investir e fazer isso certo?

• Você tem uma equipe de segurança dedicada? Equipe de abuso dedicada? Ambos têm os ciclos para lidar com o abuso de sua nova infraestrutura e reclamações que você receberá de terceiros?

• Você tem uma equipe jurídica ?

• Quando tudo isso for dito e feito, todo esse esforço, mesmo que remotamente, começará a se pagar, gerar lucro para a empresa ou exceder o valor monetário de lidar com a inconveniência que o levou a essa direção?

Para encerrar, sei que este tópico de perguntas e respostas é uma espécie de decepção para a maioria de vocês que estão sendo vinculados a ele. Serverfault está aqui para fornecer respostas, e uma resposta de "esta é uma má ideia, não faça isso" geralmente não é percebida como muito útil. Alguns problemas são muito mais complicados do que parecem à primeira vista, e este é um deles.

Se você quiser tentar fazer isso funcionar, ainda pode nos pedir ajuda enquanto tenta implementar esse tipo de solução. A principal coisa a perceber é que o problema é muito grande por si só para que a resposta seja fornecida em um formato conveniente de perguntas e respostas. Você precisa ter investido uma quantidade significativa de tempo pesquisando o tópico e nos abordar com problemas de lógica específicos que você encontrou durante sua implementação. O objetivo desta sessão de perguntas e respostas é fornecer a você uma melhor compreensão do quadro geral e ajudá-lo a entender por que não podemos responder a uma pergunta tão ampla como esta.

Ajude-nos a manter a internet segura! :)

Esteja você executando um recursor DNS aberto ou um servidor DNS autoritativo, o problema é o mesmo e a maioria das soluções possíveis também são as mesmas.

A melhor solução

Os cookies DNS são um padrão proposto que oferece aos servidores DNS uma maneira de exigir que os clientes enviem um cookie para provar que o endereço IP do cliente não foi falsificado. Isso custará uma ida e volta adicional para a primeira pesquisa, que é a menor sobrecarga que qualquer solução pode oferecer.

Fallback para clientes mais antigos

Como os cookies DNS ainda não estão padronizados, é claro que será necessário oferecer suporte a clientes mais antigos agora e nos próximos anos.

Você pode classificar solicitações de limite de clientes sem suporte a cookies DNS. Mas os limites de taxa tornam mais fácil para um invasor fazer DoS em seu servidor DNS. Esteja ciente de que alguns servidores DNS têm um recurso de limite de taxa projetado apenas para servidores DNS autoritativos. Como você está perguntando sobre um resolvedor recursivo, essas implementações de limitação de taxa podem não ser aplicáveis ​​a você. O limite de taxa por design se tornará o gargalo para o seu servidor e, portanto, um invasor precisará enviar a você menos tráfego para fazer com que as solicitações legítimas sejam descartadas do que ele faria se não houvesse limite de taxa.

Uma vantagem dos limites de taxa é que, no caso de um invasor inundar seu servidor DNS com solicitações de DNS, é mais provável que você tenha capacidade restante que permitirá que você envie ssh para o servidor e investigue a situação. Além disso, os limites de taxa podem ser projetados para descartar principalmente solicitações de IPs de clientes que enviam muitas solicitações, o que pode ser suficiente para protegê-lo contra DoS de invasores que não têm acesso a IPs de clientes falsificados.

Por essas razões, um limite de taxa um pouco abaixo de sua capacidade real pode ser uma boa ideia, mesmo que não proteja contra a amplificação.

Usando TCP

É possível forçar um cliente a usar TCP enviando um código de erro indicando que a resposta é muito grande para UDP. Isso tem algumas desvantagens. Custa duas viagens de ida e volta adicionais. E alguns clientes defeituosos não o suportam.

O custo de duas viagens de ida e volta adicionais pode ser limitado apenas à primeira solicitação usando esta abordagem:

Quando o IP do cliente não foi confirmado, o servidor DNS pode enviar uma resposta truncada para forçar o cliente a mudar para TCP. A resposta truncada pode ser tão curta quanto a solicitação (ou menor se o cliente usar EDNS0 e a resposta não), o que elimina a amplificação.

Qualquer IP de cliente que conclua um handshake TCP e envie uma solicitação de DNS na conexão pode ser temporariamente colocado na lista de permissões. Uma vez na lista de permissões, esse IP pode enviar consultas UDP e receber respostas UDP de até 512 bytes (4096 bytes se estiver usando EDNS0). Se uma resposta UDP acionar uma mensagem de erro ICMP, o IP será removido da lista de permissões novamente.

O método também pode ser revertido usando uma lista negra, o que significa apenas que os IPs do cliente podem consultar o UDP por padrão, mas qualquer mensagem de erro ICMP faz com que o IP seja colocado na lista negra, precisando de uma consulta TCP para sair da lista negra.

Um bitmap cobrindo todos os endereços IPv4 relevantes pode ser armazenado em 444 MB de memória. Endereços IPv6 teriam que ser armazenados de alguma outra forma.

Não sei se algum servidor DNS implementou essa abordagem.

Também foi relatado que algumas pilhas TCP podem ser exploradas em ataques de amplificação. No entanto, isso se aplica a qualquer serviço baseado em TCP e não apenas ao DNS. Essas vulnerabilidades devem ser mitigadas com a atualização para uma versão do kernel em que a pilha TCP foi corrigida para não enviar mais de um pacote em resposta a um pacote SYN.