UDP Reflection e DNS Amplification: quando uma consulta vira uma enxurrada

Uma infraestrutura pode ficar indisponível sem que o atacante consiga executar código nela. Em ataques de reflexão e amplificação, serviços acessíveis pela rede são usados como intermediários para direcionar tráfego ao alvo. O DNS é um dos exemplos mais conhecidos dessa combinação.

Para o Red Team, entender esse mecanismo ajuda a investigar duas exposições: a possibilidade de a organização atuar como refletor e sua capacidade de responder a um ataque volumétrico. Cada hipótese exige evidências diferentes e regras de engajamento próprias.

Reflexão e amplificação são coisas diferentes

Reflexão acontece quando a resposta de um serviço é enviada a um terceiro cujo endereço foi apresentado como origem da solicitação. Amplificação é o aumento de volume entre a solicitação e as respostas que ela provoca. Pode haver reflexão sem ganho expressivo de tamanho; juntas, as duas técnicas permitem direcionar mais tráfego ao alvo do que o emissor originalmente enviou.

O UDP, definido pela RFC 768, não estabelece uma conexão com um handshake que confirme a alcançabilidade do remetente antes de uma resposta. Sem controles adicionais, um serviço pode responder ao endereço de origem informado no pacote, mesmo que ele tenha sido falsificado. A aplicação pode acrescentar mecanismos de validação, por isso usar UDP, sozinho, não torna todo serviço um amplificador. A CISA descreve essa combinação em seu alerta sobre ataques de amplificação baseados em UDP.

Como o DNS entra nessa cadeia

O fluxo de reflexão DNS, discutido na RFC 4732 sobre negação de serviço, tem três participantes:

1. Emissor: envia uma consulta DNS por UDP com o endereço de origem falsificado para coincidir com o endereço do alvo.
2. Refletor: recebe a consulta e envia a resposta ao endereço indicado como origem.
3. Alvo: recebe respostas que não solicitou; quando o volume excede sua capacidade, a disponibilidade pode ser afetada.

O ganho de volume depende do tamanho das respostas em relação às consultas. Ao distribuir o processo entre vários refletores, o tráfego converge de múltiplas origens. O alvo não precisa operar um servidor DNS: basta receber o tráfego destinado ao seu endereço. Esse funcionamento é explicado pela Cloudflare em sua análise de DNS amplification.

O servidor intermediário também não precisa estar comprometido. Um resolvedor recursivo aberto, que aceita solicitações de clientes externos sem restrição adequada, pode ser abusado usando sua funcionalidade normal. Servidores autoritativos também podem participar de reflexão, mesmo sem oferecer recursão. A distinção entre os papéis é essencial para escolher a correção, como explica a RFC 5358.

O fator de amplificação não é um número fixo

A CISA define o fator de amplificação de banda a partir dos bytes de payload UDP enviados nas respostas em relação aos bytes de payload da solicitação:

Fator de amplificação = bytes de payload nas respostas ÷ bytes de payload na consulta.

Em um exemplo puramente didático, uma consulta de 80 bytes que provoca uma resposta de 800 bytes tem fator 10 nessa métrica. Isso não representa uma medição de um servidor real, nem inclui os cabeçalhos das demais camadas.

A tabela histórica do alerta da CISA não deve ser tratada como promessa de desempenho atual. Registros consultados, implementação e configuração influenciam as respostas. Um relatório técnico precisa registrar o que mediu, em qual contexto e quais limites impedem extrapolar o resultado.

Três simplificações que atrapalham a análise

“Qualquer consulta ANY devolve todos os registros.” Essa expectativa é inadequada. A RFC 8482 descreve respostas mínimas para consultas ANY, inclusive com apenas um subconjunto dos registros. Uma explicação baseada em respostas sempre enormes pode não representar o servidor avaliado.

“Basta fechar a recursão.” Restringir recursão é uma medida central para resolvedores privados, mas um DNS autoritativo público precisa continuar respondendo por suas zonas. A RFC 5358 já reconhece que servidores autoritativos podem ser usados como refletores. Eles exigem controles apropriados ao serviço público que oferecem.

“O firewall do alvo resolve sozinho.” Se o enlace de entrada já está saturado, descartar pacotes depois desse ponto não recupera a capacidade perdida. A proteção precisa considerar o provedor e os caminhos anteriores ao gargalo. A Cloudflare discute essa limitação das mitigações locais.

O que avaliar em um exercício de Red Team

Uma avaliação começa com uma pergunta verificável. Por exemplo: “nosso resolvedor privado aceita recursão de uma rede que não deveria ter acesso?” ou “a equipe reconhece respostas DNS não solicitadas e aciona o provedor correto?”.

As regras de engajamento devem identificar os ativos permitidos, a janela, os responsáveis, os limites de tráfego e os critérios de parada. Autorizar uma avaliação de segurança não implica autorizar testes de negação de serviço; qualquer teste de disponibilidade precisa estar previsto expressamente.

Um roteiro de avaliação pode seguir esta sequência:

1. Mapear os papéis dos serviços. Identificar resolvedores privados, servidores autoritativos, interfaces expostas e controles de acesso previstos.
2. Revisar configurações e acessos. Verificar se clientes externos ao conjunto autorizado conseguem usar a recursão, com verificações pontuais de baixo volume nos ativos em escopo.
3. Observar a assimetria em laboratório. Usar clientes, servidores e destinos próprios, em uma rede isolada, para comparar tamanhos de mensagens e capturar o fluxo. Se o exercício incluir origem falsificada, mantê-lo contido nessa rede e autorizado no escopo.
4. Validar a visibilidade. Conferir quais eventos chegam ao monitoramento, se os alertas permitem distinguir os papéis dos ativos e quem recebe a ocorrência.
5. Repetir após a correção. Comparar os mesmos cenários e confirmar que clientes legítimos continuam resolvendo nomes.

O registro deve incluir hipótese, topologia, configuração relevante, horários, evidências e resultado esperado. Comprovar exposição não exige saturar o serviço. Uma demonstração de baixo volume também não comprova resistência a um ataque volumétrico; essa capacidade pede uma avaliação específica.

Quais sinais ajudam a investigar

Na borda do alvo, uma hipótese de reflexão DNS pode começar por um aumento de respostas UDP com porta de origem 53, vindas de múltiplos servidores, sem consultas correspondentes observadas. No possível refletor, interessa comparar consultas recebidas, respostas emitidas, destinos e crescimento de volume.

Esses sinais são pistas para correlação, não prova isolada. Uma captura parcial, rotas assimétricas ou perda de telemetria podem ocultar consultas legítimas. A investigação deve relacionar fluxos, conteúdo DNS quando disponível, métricas do enlace e comportamento dos serviços.

O exercício ganha valor quando registra o tempo até a detecção, a qualidade da triagem e o tempo até acionar a mitigação. São critérios propostos para a avaliação: os limites aceitáveis devem ser definidos pela organização conforme seus serviços e sua capacidade operacional.

Mitigação em camadas

No resolvedor privado: limitar a recursão aos clientes autorizados e revisar a exposição em todas as interfaces relevantes. A RFC 5358 recomenda que servidores não ofereçam recursão a redes externas por padrão.

No DNS autoritativo: avaliar Response Rate Limiting (RRL) e políticas de resposta compatíveis com o serviço. A documentação do BIND 9 descreve o controle de respostas UDP excessivas e semelhantes. Ela também alerta que seu uso em resolvedores recursivos pode prejudicar aplicações legítimas; restringir recursão aberta continua sendo a medida preferível nesse caso.

Na rede de origem: aplicar validação de endereços de origem para reduzir a saída de pacotes falsificados. A BCP 38, publicada como RFC 2827, estabelece a prática de filtragem que combate esse tipo de spoofing.

No caminho até o alvo: manter um plano de mitigação com o provedor ou serviço de proteção DDoS, incluindo contatos e condições de acionamento. Bloquear indiscriminadamente tráfego DNS pode interromper resolução legítima, e o controle precisa ocorrer onde ainda exista capacidade para tratar o volume.

Cada camada atua em uma parte da cadeia. O relatório do Red Team deve mostrar qual exposição foi confirmada, qual controle foi avaliado e o que ainda depende de validação. É essa ligação entre mecanismo, evidência e correção que transforma o estudo de DNS amplification em uma melhoria verificável de segurança.

Como próximo passo, escolha um resolvedor sob sua responsabilidade e documente quem deveria poder usá-lo. Compare a configuração com essa expectativa e registre uma verificação autorizada de baixo volume antes de considerar qualquer exercício de disponibilidade.