Quais tipos de vulnerabilidades de segurança são expostas no DNSSEC?

Eu estava planejando assinar minha zona DNS com DNSSEC. Minha zona, o registrador e meu servidor DNS (BIND9) suportam DNSSEC. O único que não suporta DNSSEC é o meu provedor de servidor de nomes secundário (ou seja, buddyns.com ).

Em seu site , eles afirmam isso em relação ao DNSSEC:

O BuddyNS não suporta DNSSEC porque expõe algumas vulnerabilidades inadequadas a um serviço DNS de alto volume.

Bem, achei que o uso do DNSSEC atualmente é questionável, já que a maioria dos resolvedores não verifica se os registros estão assinados corretamente. O que eu não sabia era que - de acordo com a declaração deles - parece que, desde que exponha algum tipo de vulnerabilidade à segurança.

O que são essas "vulnerabilidades"?

O DNSSEC tem alguns riscos, mas eles não estão diretamente relacionados à reflexão ou amplificação. A expansão do tamanho da mensagem EDNS0 é um arenque vermelho neste caso. Deixe-me explicar.

Qualquer troca de pacotes que não dependa de uma prova de identidade anterior está sujeita a abuso por invasores DDoS que podem usar essa troca de pacotes não autenticada como um refletor e, talvez, também como um amplificador. Por exemplo, o ICMP (o protocolo por trás de "ping") pode ser abusado dessa maneira. Assim como o pacote TCP SYN, que solicita até 40 pacotes SYN-ACK, mesmo que o SYN tenha sido falsificado para vir de alguma vítima que não deseja esses pacotes SYN-ACK. E, é claro, todos os serviços UDP são vulneráveis ​​a esse ataque, incluindo NTP, SSDP, uPNP e conforme observado por outras respostas aqui, incluindo também o DNS.

A maioria dos dispositivos de detecção de intrusão, prevenção de intrusão e balanceador de carga são gargalos, incapazes de acompanhar o tráfego de "taxa de linha". Além disso, muitos roteadores não podem funcionar com taxa de linha e alguns comutadores. Esses gargalos, por serem a menor coisa "no caminho" e menores do que os próprios links, são o alvo real dos ataques DDoS baseados em congestionamento. Se você puder manter o firewall de alguém ocupado com o tráfego de ataque, um bom tráfego não passará, mesmo que os links não estejam cheios. E o que reduz a velocidade de um firewall não é o número total de bits por segundo (que pode ser aumentado usando mensagens maiores, e EDNS0 e DNSSEC farão), mas o número total de pacotes por segundo.

Há muitas lendas urbanas por aí sobre como o DNSSEC piora o DDoS por causa do tamanho maior da mensagem do DNSSEC e, embora isso faça sentido intuitivo e "pareça bom", é simplesmente falso. Mas se houvesse um pingo de verdade nessa lenda, a resposta real ainda estaria em outro lugar - [porque o DNSSEC sempre usa EDNS0, mas o EDNS0 pode ser usado sem o DNSSEC] e muitas respostas normais que não são do DNSSEC são tão grandes quanto o DNSSEC resposta seria. Considere os registros TXT usados ​​para representar políticas SPF ou chaves DKIM. Ou apenas qualquer conjunto grande de endereços ou registros MX. Em resumo, nenhum ataque requer DNSSEC e, portanto, qualquer foco no DNSSEC como risco de DDoS é energia gasta.

DNSSEC tem riscos! É difícil de usar e mais difícil de usar corretamente. Freqüentemente, é necessário um novo fluxo de trabalho para alterações nos dados da zona, gerenciamento de registradores e instalação de novas instâncias do servidor. Tudo isso precisa ser testado e documentado, e sempre que ocorrer algo relacionado ao DNS, a tecnologia DNSSEC deve ser investigada como uma possível causa. E o resultado final, se você fizer tudo certo, será que, como signatário da zona, seu próprio conteúdo e sistemas on-line serão mais frágeis para seus clientes. Como operador de servidor remoto, o resultado será que o conteúdo e os sistemas de todos os outros serão mais frágeis para você. Geralmente, esses riscos superam os benefícios, pois o único benefício é proteger os dados do DNS contra modificações ou substituições em andamento. Esse ataque é tão raro que não vale todo esse esforço. Todos esperamos que o DNSSEC se torne onipresente algum dia, devido aos novos aplicativos que ele permitirá. Mas a verdade é que hoje em dia o DNSSEC tem todos os custos, nenhum benefício e riscos altos.

Portanto, se você não quiser usar o DNSSEC, essa é sua prerrogativa, mas não deixe ninguém confundir que o problema do DNSSEC é seu papel como um amplificador DDoS. O DNSSEC não tem um papel necessário como um amplificador DDoS; existem outras maneiras melhores e mais baratas de usar o DNS como um amplificador DDoS. Se você não quiser usar o DNSSEC, é porque ainda não bebeu o Kool Aid e deseja ser o último a mover (depois) e não o primeiro a mover (agora).

Os servidores de conteúdo DNS, às vezes chamados de "servidores de autoridade", devem ser impedidos de serem abusados ​​como amplificadores refletores de DNS, porque o DNS usa UDP e porque o UDP é abusável por pacotes de origem falsificada. A maneira de proteger seu servidor de conteúdo DNS contra esse tipo de abuso não é bloquear o UDP, nem forçar o TCP (usando o truque TC = 1), nem bloquear a QUALQUER consulta, nem optar pelo DNSSEC. Nenhuma dessas coisas irá ajudá-lo. Você precisa limitar a taxa de resposta de DNS(DNS RRL), uma tecnologia totalmente gratuita que agora está presente em vários servidores de nomes de código aberto, incluindo BIND, Knot e NSD. Você não pode corrigir o problema de reflexão de DNS com seu firewall, porque apenas uma caixa intermediária com reconhecimento de conteúdo, como o próprio servidor DNS (com RRL adicionado), conhece o suficiente a solicitação para poder adivinhar com precisão o que é um ataque e o que não é. Quero enfatizar novamente: o DNS RRL é gratuito e todos os servidores de autoridade devem executá-lo.

Para finalizar, quero expor meus preconceitos. Eu escrevi a maior parte do BIND8, inventei o EDNS0 e co-inventei o DNS RRL. Trabalho no DNS desde 1988 com 20 e poucos anos, e agora estou com 50 e poucos anos, com cada vez menos paciência para soluções incompletas para problemas incompreendidos. Aceite minhas desculpas se esta mensagem parecer muito com "ei, crianças, desçam do meu gramado!"

Conheço duas vulnerabilidades específicas. Há a reflexão / amplificação mencionada por Håkan. E existe a possibilidade de enumeração de zona.

Reflexão / amplificação

Reflexão significa ataques nos quais solicitações com um IP de origem falsificado são enviadas para um servidor DNS. O host que está sendo falsificado é a principal vítima do ataque. O servidor DNS, sem saber, enviará a resposta para um host que nunca solicitou.

Amplificação refere-se a qualquer ataque de reflexão no qual a resposta refletida consiste em mais bytes ou mais pacotes do que a solicitação original. Antes da DNSSEC + EDNS0, a amplificação dessa maneira só permitia o envio de até 512 bytes. Com o DNSSEC + EDNS0, é possível enviar 4096 bytes, o que normalmente abrange 3-4 pacotes.

Existem possíveis atenuações para esses ataques, mas não conheço nenhum servidor DNS que os implemente.

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 que os IPs do cliente podem consultar por 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.

Enumeração de zona

Se a enumeração de zona é uma vulnerabilidade em primeiro lugar é assunto de debate. Mas se você não deseja que todos os nomes em sua zona sejam de conhecimento público, provavelmente consideraria uma vulnerabilidade. A enumeração de zonas pode ser atenuada principalmente pelo uso de registros NSEC3.

O problema que ainda persiste mesmo ao usar o NSEC3 é que um invasor pode encontrar o hash de cada rótulo simplesmente consultando nomes aleatórios. Uma vez que o atacante tenha todos os hashes, um ataque de força bruta off-line pode ser executado nesses hashes.

Uma defesa adequada contra a enumeração de zonas exigiria que um invasor fizesse uma consulta ao servidor autoritativo para cada tentativa. No entanto, essa defesa não existe no DNSSEC.

O que vem à mente não é realmente específico do DNSSEC, mas da extensão EDNS0, na qual o DNSSEC se baseia.

O EDNS0 permite cargas UDP maiores e cargas UDP maiores podem permitir piores ataques de reflexão / amplificação de tráfego.

Não sei qual é a porcentagem de validadores de validação, mas o software popular de servidor de nomes parece ter validação ativada por padrão e é fácil encontrar alguns prestadores de serviços notáveis ​​que estão abertos sobre a validação, como a Comcast e os resolvedores públicos do Google.

Com base nisso, eu pensaria que a porcentagem de resolvedores de validação provavelmente está em uma forma significativamente melhor do que a porcentagem de zonas assinadas.