Mecanismos de Reflexão DDoS, Vetores de Protocolo e Engenharia Defensiva
Os ataques de Negação de Serviço Distribuída (DDoS, Distributed Denial of Service) consolidaram-se como uma das armas mais destrutivas e financeiramente asfixiantes da cibercriminalidade moderna. Entre as variadas metodologias empregadas por adversários para derrubar infraestruturas corporativas, governamentais e de telecomunicações, os ataques de reflexão e amplificação distribuída (DrDoS, Distributed Reflection Denial of Service) destacam-se pela extraordinária assimetria de poder de fogo proporcionada ao atacante.
Em um ataque convencional de força bruta direta, a capacidade ofensiva do invasor é estritamente limitada pela soma da largura de banda de upload dos computadores escravizados que compõem sua rede zumbi (botnet). No entanto, ao explorar falhas de concepção em protocolos de transporte e serviços desprotegidos na Internet, a técnica de amplificação atua como uma alavanca multiplicadora: uma pequena transmissão de comando de alguns megabits por segundo desencadeia avalanches volumétricas na escala de centenas de gigabits ou mesmo terabits por segundo sobre o enlace da vítima.
A mecânica de um ataque DrDoS apoia-se na interação coordenada entre três atores distintos na topologia de rede:
A execução do ataque desenrola-se em três tempos perfeitamente encadeados:
| Fase | Ação Primordial | Mecanismo Técnico Envolvido |
|---|---|---|
| 1. Injeção Forjada | Atacante despacha pequenas requisições para refletores | Falsificação de cabeçalho IP (IP Spoofing) sobre UDP sem verificação de handshake |
| 2. Reflexão Assimétrica | Servidores refletores processam e geram respostas volumosas | Multiplicação assimétrica de carga pelo Fator de Amplificação de Banda (BAF) |
| 3. Inundação da Vítima | Respostas convergem simultaneamente sobre o alvo | Exaustão física de enlaces de conectividade e esgotamento de tabelas de estado de firewalls |
Diferente do protocolo TCP, que exige a validação mútua do aperto de mãos de três vias (SYN, SYN-ACK, ACK) antes de despachar qualquer carga útil, o protocolo UDP (User Datagram Protocol) opera sem conexão (connectionless). O remetente pode preencher arbitrariamente o campo de endereço IP de origem no cabeçalho do pacote IP com o endereço de sua vítima. O servidor refletor, ao processar a mensagem, responde com fidelidade para o remetente impresso no envelope, disparando a resposta diretamente contra o alvo.
A severidade de um ataque de amplificação é mensurada pela desproporção matemática existente entre o tamanho do pacote de requisição despachado pelo invasor e o tamanho do pacote (ou conjunto de pacotes) de resposta gerado pelo refletor.
A engenharia de segurança de redes formaliza esse impacto através de dois índices:
Diversos protocolos utilitários da Internet foram projetados para serem concisos na solicitação e prolixos na resposta:
| Protocolo e Serviço | Porta UDP | Fator Típico de Amplificação (BAF) | Comando ou Gatilho de Exploração |
|---|---|---|---|
| Memcached | UDP 11211 | 10.000x a 51.200x | Requisições GET em chaves massivas previamente populadas |
| NTP (Network Time Protocol) | UDP 123 | 556,9x | Comando monlist (retorno dos últimos 600 clientes) |
| CHARGEN | UDP 19 | 358,8x | Geração infinita de fluxo alfanumérico legado |
| DNS Recursivo (Open Resolver) | UDP 53 | 28x a 54x | Consultas ANY e registros de chaves criptográficas DNSSEC |
| TFTP (Trivial File Transfer) | UDP 69 | 60x | Requisições RRQ de arquivos binários e imagens de firmware |
| LDAP / CLDAP | UDP 389 | 46x a 55x | Consultas de diretório Active Directory sem conexão |
| SSDP / UPnP | UDP 1900 | 30,8x | Descoberta M-SEARCH com retorno de arquivos XML de dispositivos |
| Portmapper / RPCbind | UDP 111 | 7x a 28x | Comando PMAP_DUMP listando daemons RPC registrados |
| SNMPv2c | UDP 161 | 6,3x a mais de 100x | Consultas GetBulk navegando em árvores MIB inteiras |
| mDNS (Multicast DNS) | UDP 5353 | 2x a 100x | Consultas _services._dns-sd._udp.local expostas na WAN |
| NetBIOS Name Service | UDP 137 | 3,8x | Requisições de status de nó em equipamentos legados |
Em fevereiro de 2018, agentes maliciosos descobriram centenas de milhares de servidores Memcached com portas UDP 11211 expostas na Internet pública. Com um BAF astronômico de mais de 50.000x, o ataque gerou tsunamis de tráfego de 1,35 Tbps contra a plataforma GitHub e 1,7 Tbps contra uma grande operadora americana, inaugurando a era dos ataques terabit no cenário mundial.
Embora dezenas de serviços possam ser convertidos em refletores, a grande maioria dos incidentes de alta gravidade concentra-se em três tecnologias predominantes no parque instalado global.
O Memcached é um sistema de cache de dados em memória distribuído, concebido para acelerar aplicações dinâmicas de banco de dados. Em sua arquitetura nativa, o software foi desenhado para operar exclusivamente em redes internas e confiáveis de datacenters, sem qualquer mecanismo nativo de autenticação.
Por razões históricas de compatibilidade de código, versões antigas vinham com suporte ao transporte UDP ativado por padrão. O vetor de ataque desenrola-se em duas manobras:
get <chave>) contendo menos de 100 bytes via UDP, forjando o endereço IP da vítima.O Network Time Protocol (NTP) é o padrão universal que mantém os relógios de todos os sistemas de computação em perfeita sincronia temporal. Para fins de diagnóstico de rede, versões do daemon ntpd anteriores à versão 4.2.7p26 continham uma funcionalidade de monitoramento chamada monlist.
Ao receber uma solicitação monlist em um único pacote UDP modesto, o servidor respondia entregando uma lista circunstanciada dos últimos 600 endereços IP que haviam sincronizado relógio com aquele nó. Como 600 registros não cabem em um único pacote UDP padrão, o servidor dividia a resposta em até 100 datagramas de tamanho máximo, entregando um fator de amplificação de 556,9x diretamente nas portas da vítima.
O Sistema de Nomes de Domínio é o vetor mais resiliente e frequente de amplificação devido à enorme quantidade de servidores recursivos abertos (Open Resolvers) operando na Internet.
No padrão original da RFC 1035, o tamanho máximo de uma resposta DNS via UDP era estritamente limitado a 512 bytes. No entanto, com a introdução dos Mecanismos de Extensão para DNS (EDNS0, formalizado na RFC 6891), resolvers e autoritativos passaram a aceitar buffers de resposta UDP de até 4.096 bytes para viabilizar a entrega de chaves criptográficas de DNSSEC e registros TXT complexos.
O invasor explora essa capacidade despachando uma consulta de tipo ANY ou solicitando as chaves DNSKEY de zonas grandes assinadas criptograficamente com DNSSEC. Uma consulta de 60 bytes gera facilmente uma resposta densa de 3.200 a 4.000 bytes, alcançando fatores de multiplicação na ordem de 54x.
Além dos três grandes vetores históricos, uma vasta gama de protocolos operacionais convive diariamente nas redes corporativas, apresentando comportamentos de resposta desproporcionais que são frequentemente convertidos em armas de reflexão.
O protocolo de gerenciamento de rede SNMPv2c é amplamente utilizado para coletar métricas de switches, roteadores e no-breaks. Ele possui a operação GetBulkRequest, concebida para permitir que estações de gerenciamento solicitem blocos inteiros de variáveis de monitoramento (árvores MIB completas) com uma única mensagem.
Quando equipamentos de rede possuem community strings fáceis ou padrão de fábrica (como public ou private) e suas portas UDP 161 são deixadas expostas na interface WAN, atacantes forjam consultas GetBulk contra a tabela de interfaces físicas. O dispositivo responde com centenas de linhas de telemetria, alcançando fatores de amplificação que variam de 6,3x a mais de 100x.
O SSDP é o mecanismo de descoberta de serviços do padrão Universal Plug and Play (UPnP), empregado por impressoras, roteadores domésticos de banda larga, televisores inteligentes e câmeras de segurança para anunciar sua presença na rede local.
Ao receber uma requisição de busca M-SEARCH em sua porta UDP 1900, o dispositivo responde com uma série de cabeçalhos HTTP formatados em texto claro apontando para arquivos descritivos em XML que contêm metadados completos de fabricante, número de série e portas suportadas. Roteadores domésticos mal configurados que respondem a mensagens SSDP na interface WAN entregam um BAF de aproximadamente 30,8x para os atacantes.
O protocolo Connectionless LDAP utiliza pacotes UDP na porta 389 para realizar consultas rápidas de localização de controladores de domínio e validação de autenticação em redes Microsoft Active Directory. Uma solicitação de busca (searchRequest) de tamanho reduzido força o servidor a responder com listas abrangentes de atributos de domínio e esquemas funcionais, resultando em ampliações que chegam a 55x o tamanho do pacote original.
PMAP_DUMP força a entrega da lista completa de portas de serviços registrados, gerando amplificações de até 28x.A persistência global dos ataques de amplificação e reflexão é fruto direto de uma omissão arquitetural de operadores de telecomunicações que toleram o trânsito de pacotes com endereços IP de origem forjados. Se a infraestrutura de rede fosse incapaz de transportar pacotes com IP spoofing, os ataques DrDoS seriam matematicamente impossíveis.
Publicada formalmente pelo IETF em maio de 2000 como RFC 2827 e BCP 38, a diretiva estabelece o princípio do Network Ingress Filtering (Filtragem de Entrada na Borda). A regra de ouro da BCP 38 é elementar:
Se um assinante residencial ou uma empresa contrata uma conexão com o bloco 198.51.100.0/24, o roteador de agregação do provedor não pode permitir que saia daquela interface nenhum pacote contendo o IP de origem 203.0.113.50. Ao descartar esse pacote na origem, o atacante é impedido de forjar o IP da vítima, quebrando o mecanismo da reflexão.
A implementação técnica mais eficiente e padronizada da BCP 38 em roteadores de borda (Cisco, Juniper, Huawei e Mikrotik) é o uRPF (RFC 3704). O algoritmo automatiza a conferência de rotas invertidas:
A BCP 38 possui um paradoxo econômico perverso: implementá-la em sua rede não protege os seus próprios clientes de sofrerem DDoS; protege os clientes de redes de terceiros. Provedores negligentes que economizam recursos de processamento em seus roteadores de agregação tornam-se celeiros globais para o lançamento impune de ataques mundiais.
Toda organização que opera servidores, roteadores e serviços conectados à Internet possui o dever operacional e ético de garantir que seus ativos não atuem como cúmplices involuntários em ataques de reflexão contra terceiros.
A blindagem perimetral deve contemplar medidas mandatórias para cada protocolo sensível:
/etc/memcached.conf) e adicione o parâmetro -U 0 para desativar integralmente a escuta na porta UDP. Em paralelo, restrinja a escuta do daemon exclusivamente ao endereço de loopback local (-l 127.0.0.1) e bloqueie a porta 11211 nos firewalls perimetrais.ntp ou chrony para versões contemporâneas. No arquivo /etc/ntp.conf, certifique-se de que a diretiva de restrição padrão inclua as palavras-chave de segurança que desativam o comando monlist e consultas remotas de controle:
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
disable monitor
public ou private em switches e roteadores. Migre toda a telemetria para o protocolo SNMPv3 no nível de segurança authPriv, que exige autenticação com hash criptográfico SHA-256 e cifra do payload com AES-128/256. Em paralelo, aplique ACLs restritivas limitando o tráfego da porta UDP 161 apenas aos IPs dos servidores de monitoramento homologados.Utilize ferramentas de teste de penetração autorizadas ou varreduras periódicas a partir de pontos externos da nuvem para auditar se alguma filial ou roteador da sua organização responde a requisições monlist, consultas DNS abertas ou comandos SNMP com strings padrão.
Quando a sua organização é o alvo selecionado para um ataque volumétrico DrDoS, a dinâmica da defesa muda radicalmente. O desafio deixa de ser uma questão de configuração de software local e passa a ser uma batalha de saturação física de infraestrutura de telecomunicações.
Se a sua empresa possui um link dedicado contratado de 1 Gbps e o ataque de amplificação gerado por dezenas de milhares de refletores atinge 20 Gbps na porta de entrada da sua operadora, nenhuma configuração no seu firewall local (pfsense, Fortinet, Palo Alto) conseguirá salvar a conectividade. O canal físico de fibra óptica estará 100% saturado antes mesmo que os pacotes alcancem a porta WAN do seu roteador.
A defesa contra ataques volumétricos massivos deve atuar obrigatoriamente upstream, ou seja, na nuvem de trânsito dos provedores e em centros de depuração especializados.
A contratação de serviços especializados de mitigação de DDoS (como Cloudflare Magic Transit, Akamai Prolexic, Imperva e Radware) é mandatória para organizações com serviços públicos críticos:
Para ataques menores que não esgotam a capacidade do link físico, configure regras de firewall descartando pacotes UDP fragmentados não solicitados e bloqueie preventivamente portas de origem de refletores conhecidos (ex.: pacotes UDP com porta de origem 11211, 19 ou 1900) que não façam parte de nenhuma comunicação legítima iniciada internamente.
Para Provedores de Serviço de Internet (ISPs), operadoras regionais e corporações que operam como Sistemas Autônomos (AS) com conectividade BGP direta, o protocolo de roteamento interdomínio oferece poderosas ferramentas de controle cirúrgico de tráfego malicioso.
O RTBH é a técnica mais tradicional de mitigação de emergência. Ele permite que um roteador de borda da vítima solicite aos seus provedores de trânsito (Upstreams) que descartem todo o tráfego destinado a um endereço IP específico antes que ele atinja sua rede:
/32 (host único) correspondente ao servidor sob ataque, associando-a a uma comunidade BGP especial combinada previamente com a operadora (geralmente conhecida como comunidade blackhole, como AS:666).O BGP Flowspec (Flow Specification) revolucionou a mitigação de ataques DrDoS ao transformar o protocolo BGP em um distribuidor dinâmico de regras de firewall de camada 3 e camada 4 em escala de internet:
flow-route {
match {
destination 203.0.113.50/32;
protocol udp;
source-port 11211; // Bloqueia apenas o refletor Memcached
packet-length 1000-1500; // Bloqueia apenas pacotes volumosos
}
then discard;
}
Sistemas modernos de detecção de tráfego integram analisadores de fluxo a roteadores de borda para calcular automaticamente os parâmetros do ataque de amplificação e disparar anúncios de BGP Flowspec em questão de segundos, neutralizando o ataque de forma autônoma.
Um ataque de amplificação não deve ser descoberto porque os clientes começaram a telefonar reclamando de lentidão. A detecção de anomalias volumétricas deve ocorrer nos primeiros segundos da investida, sustentada por tecnologias de análise estatística de fluxo de rede.
Inspecionar todos os pacotes que transitam em interfaces de 10G, 40G ou 100G exigiria recursos computacionais proibitivos. As tecnologias de telemetria baseiam-se em amostragem estatística:
Ferramentas de análise de telemetria em tempo real (como FastNetMon, Elastiflow e Kentik) identificam ataques de reflexão detectando desvios agudos em relação à linha de base (baseline) histórica:
Assimetria Extrema de Bytes
O volume de tráfego de entrada UDP sobre determinado endereço IP explode subitamente, enquanto o tráfego de saída correspondente permanece residual ou nulo.
Concentração de Portas de Origem
Milhares de pacotes recebidos de milhares de IPs públicos distintos exibem exatamente a mesma porta de origem UDP (como 123, 11211, 19 ou 53).
Tamanho Homogêneo de Pacotes
Entrada massiva de datagramas UDP com tamanhos máximos de MTU (entre 1.400 e 1.500 bytes), característica típica de cargas amplificadas saturando enlaces.
Quando a infraestrutura é atingida por um ataque de amplificação volumétrica, o estresse da equipe operacional atinge níveis críticos. A improvisação em momentos de crise agrava a indisponibilidade e retarda a recuperação. A organização deve possuir um roteiro formalizado e previamente testado de resposta a incidentes DDoS.
A equipe de segurança e operações deve seguir passos ordenados:
Durante um ataque volumétrico severo, o servidor de e-mail e os comunicadores internos da empresa podem ficar inacessíveis. Manter os números de telefone de emergência do NOC dos provedores de trânsito impressos na sala de controle é uma exigência elementar de prontidão operacional.
Os ataques de amplificação e reflexão permanecem como uma ameaça existencial e recorrente à resiliência dos serviços digitais na Internet global. Sua longevidade histórica decorre da combinação explosiva entre protocolos de rede utilitários projetados sem mecanismos nativos de autenticação e a persistência de servidores e roteadores mal administrados expostos na rede mundial.
A neutralização definitiva dessa classe de ameaças exige a consolidação de três pilares de engenharia e responsabilidade compartilhada:
Na arquitetura aberta da Internet, a segurança da sua infraestrutura é indissociável da postura defensiva que você adota para proteger o restante do ecossistema contra o abuso dos seus próprios recursos.
Este apêndice detalha as portas de transporte UDP críticas que devem ser bloqueadas ou auditadas na borda perimetral e apresenta o checklist operacional de conformidade para prevenção de abusos de amplificação.
| Porta UDP | Protocolo / Serviço | Ação Recomendada na Borda WAN | Justificativa Técnica |
|---|---|---|---|
11211 |
Memcached | Bloqueio incondicional (Drop) | Serviço interno de cache; nunca deve escutar na WAN (fator até 51.200x) |
19 |
CHARGEN | Bloqueio incondicional e desinstalação | Protocolo obsoleto de teste gerador de caracteres (fator 358x) |
1900 |
SSDP / UPnP | Bloqueio incondicional na entrada e saída | Protocolo de rede local doméstica vazando metadados XML (fator 30x) |
5353 |
mDNS | Bloqueio incondicional na borda | Descoberta local de serviços; tráfego na WAN é anômalo ou malicioso |
137-139 |
NetBIOS Name Service | Bloqueio incondicional na borda | Protocolo de compartilhamento Windows antigo, inseguro e sem cifra |
111 |
Portmapper / RPCbind | Bloqueio para IPs externos não autorizados | Mapeamento de chamadas RPC internas (NFS); não deve ser público |
69 |
TFTP | Bloqueio na borda WAN | Transferência sem autenticação de firmware; uso restrito a VLANs de rede |
123 |
NTP | Restrição de monlist e controle por ACLs | Desativar monitoramento no ntpd e liberar tráfego cliente para stratum confiável |
53 |
DNS | Proibição de Open Resolver e RRL ativo | Recursão exclusiva para sub-redes internas; RRL em autoritativos |
161 |
SNMP | Bloqueio na WAN e uso exclusivo de SNMPv3 | Substituir strings public por SNMPv3 authPriv com restrição de gerência |
O checklist estruturado a seguir deve ser auditado periodicamente por equipes de engenharia de rede, DevOps e analistas de segurança perimetral.
| Domínio de Controle | Requisito Técnico de Segurança | Critério de Conformidade | Status |
|---|---|---|---|
| 1. Filtragem BCP 38 | Implementação de Network Ingress Filtering para descartar IPs forjados saintes. | uRPF estrito ou ACLs de saída ativas nos roteadores de borda | [ ] |
| 2. Blindagem Memcached | Desativação compulsória de UDP e restrição de escuta à interface de loopback. | Parâmetro -U 0 ativo e porta 11211 inacessível na WAN | [ ] |
| 3. Saneamento do NTP | Desativação do comando monlist e restrição de consultas de controle remoto. | Diretiva disable monitor e restrict default no ntp.conf | [ ] |
| 4. Mitigação Open Resolver | Erradicação de recursão aberta e ativação de Response Rate Limiting (RRL). | ACLs em allow-recursion e RRL ativo em autoritativos | [ ] |
| 5. Migração SNMPv3 | Erradicação de community strings padrão e adoção de SNMPv3 com criptografia. | SNMPv3 authPriv ativo com usuários nominais e ACLs | [ ] |
| 6. Descarte de Protocolos | Desativação e bloqueio de CHARGEN (19), TFTP (69), SSDP (1900) e mDNS (5353). | Portas UDP bloqueadas na borda e daemons desinstalados | [ ] |
| 7. Telemetria de Fluxo | Exportação contínua de registros NetFlow/sFlow com detecção precoce de anomalias. | Alertas automáticos para estouro de tráfego UDP em portas de reflexão | [ ] |
| 8. BGP Flowspec / RTBH | Configuração e homologação de comunidades de RTBH e suporte a BGP Flowspec. | Capacidade de descarte upstream testada em homologação | [ ] |
| 9. Contratos Anti-DDoS | Contrato ativo de mitigação em nuvem (Scrubbing Center) para serviços essenciais. | SLA de desvio de tráfego via Anycast / túneis GRE homologado | [ ] |
| 10. Prontidão Operacional | Playbook de resposta a DDoS atualizado com lista de contatos OOB do NOC da operadora. | Lista impressa na sala de controle e simulado anual realizado | [ ] |
Cartilha CiberLab · Ciência Embarcada · Lucas Rayan Guerra