Esta é uma pergunta canônica sobre a proteção de resolvedores de DNS públicos

Os servidores DNS abertos parecem bem arrumados e convenientes, pois fornecem endereços IP que podemos usar de forma consistente em toda a empresa, independentemente de onde eles estejam. O Google e o OpenDNS fornecem essa funcionalidade, mas não tenho certeza se quero que essas empresas tenham acesso às nossas consultas de DNS.

Quero configurar algo assim para uso por nossa empresa, mas ouço muito sobre isso ser uma prática perigosa (principalmente em relação a ataques de amplificação ) e quero garantir que façamos isso corretamente. Que coisas eu preciso ter em mente ao criar esse tipo de ambiente?

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. Isso é legal, também sou administrador de sistemas! Parte do trabalho é entender onde suas responsabilidades terminam e as de outra pessoa começam e, acredite, isso não é um problema que os administradores de sistemas possam resolver por conta própria. Aqui está o porquê:

• UDP é um protocolo sem estado. Não há handshake de cliente.
• As consultas em um servidor DNS são uma transação em duas etapas não autenticada (consulta, resposta). Não há como o servidor saber se o IP de origem é falsificado antes de responder.
• Quando uma consulta chega ao servidor, já é tarde demais para impedir 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 em frente ao servidor DNS.
• Não podemos fornecer uma explicação detalhada 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 se destina a substituir a contratação de profissionais para realizar trabalhos profissionais.
• Não presuma que sua empresa bilionária demais para falhar 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 configurá-lo do que para entender os riscos envolvidos. Este é um daqueles casos em que boas intenções inadvertidamente permitem os delitos (e o sofrimento) de outras pessoas.

• Se o servidor DNS responder a qualquer endereço IP de origem que ele estiver vendo, você estará executando um resolvedor aberto. Estes estão sendo constantemente alavancados em ataques de amplificação contra pessoas inocentes. Novos administradores de sistema estão enfrentando resolvedores abertos todos os dias , tornando lucrativo para indivíduos mal-intencionados procurá-los constantemente. Não há realmente uma dúvida sobre se o seu resolvedor aberto será ou não usado em um ataque: a partir de 2015, é praticamente um dado. Pode não ser imediato, mas vai acontecer com certeza.
• Mesmo que você aplique uma ACL usando seu software DNS (ou seja, BIND), tudo isso faz é limitar a quais pacotes DNS falsificados os quais o servidor responderá. É importante entender que sua infraestrutura DNS pode ser usada não apenas para atacar os dispositivos na ACL, mas também para qualquer dispositivo de rede entre o 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ê.

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

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

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

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

• Você tem uma equipe jurídica ?

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

Para finalizar, eu 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. A Serverfault está aqui para fornecer respostas, e uma resposta "essa é uma péssima idéia, não faça isso" geralmente não é vista como muito útil. Alguns problemas são muito mais complicados do que parecem inicialmente, e esse é um deles.

Se você quiser tentar fazer isso funcionar, ainda poderá solicitar ajuda enquanto tenta implementar esse tipo de solução. O principal a perceber é que o problema é grande demais para que a resposta seja fornecida no formato conveniente de perguntas e respostas. Você precisa ter investido uma quantidade significativa de tempo pesquisando o tópico e nos abordar com problemas lógicos específicos que você encontrou durante sua implementação. O objetivo desta sessão de perguntas e respostas é fornecer uma melhor compreensão do quadro geral e ajudá-lo a entender por que não podemos responder a uma pergunta tão ampla quanto 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 é a mesma.

A melhor solução

Os cookies DNS são um padrão proposto que fornece 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 viagem de ida e volta adicional para a primeira pesquisa, que é a menor sobrecarga que qualquer solução poderia 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 facilitam a invasão do DoS ao servidor DNS. Observe 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 do seu servidor e, portanto, um invasor precisará enviar menos tráfego para causar a queda de solicitações legítimas 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 sobrando, o que permitirá que você faça ssh no servidor e investigue a situação. Além disso, os limites de taxa podem ser projetados para eliminar solicitações de IPs de clientes, enviando 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 esses motivos, um limite de taxa um pouco abaixo da sua capacidade real pode ser uma boa ideia, mesmo que na verdade não proteja contra a amplificação.

Usando TCP

É possível forçar um cliente a usar o TCP enviando um código de erro indicando que a resposta é muito grande para o 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 o TCP. A resposta truncada pode ser tão curta quanto a solicitação (ou mais curta se o cliente usa EDNS0 e a resposta não) que elimina a amplificação.

Qualquer IP do cliente que conclua um handshake TCP e envie uma solicitação DNS na conexão pode ser temporariamente incluído na lista de permissões. Uma vez na lista branca, o 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 desbloqueio novamente.

O método também pode ser revertido usando uma lista negra, o que significa apenas que os IPs do cliente podem consultar sobre UDP por padrão, mas qualquer mensagem de erro ICMP faz com que o IP seja incluído na lista negra, necessitando 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. Os endereços IPv6 teriam que ser armazenados de outra maneira.

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. Tais vulnerabilidades devem ser atenuadas atualizando 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.