Portas de amplificação DDoS: o que o provedor deve filtrar

As portas de amplificação DDoS são serviços UDP que respondem a uma pergunta pequena com uma resposta grande. Um DNS recursivo aberto, um NTP antigo com monlist ligado, um roteador doméstico com UPnP exposto na WAN. Sozinho, cada um parece inofensivo. Somados aos milhares, viram a munição dos ataques volumétricos que derrubam provedor pequeno em minutos.

O provedor aparece nessa história de dois jeitos. Como vítima, quando o tráfego refletido chega no trânsito e lota o link. E como refletor, quando são os seus clientes (ou os seus servidores) que respondem às consultas forjadas e mandam o lixo para outra rede. No segundo caso chega um e-mail do CERT.br no contato de abuse do seu ASN, com a lista de IPs que precisam ser corrigidos.

Este guia é para o segundo caso, que é o que está ao seu alcance: entender o mecanismo, saber quais portas olhar, achar os clientes que viraram refletor, filtrar sem quebrar quem usa o serviço de verdade e arrumar os servidores da própria casa. Os comandos são de Linux (nmap, tcpdump, nftables) e os endereços são de documentação.

Resposta rápida: quais portas de amplificação DDoS filtrar

1. No sentido internet para cliente, descarte UDP com destino às portas 17, 19, 53, 69, 111, 137, 161, 389, 427, 1900, 3283, 3702, 5353, 5683, 10001 e 11211, com exceção para os clientes corporativos que hospedam algum desses serviços.
2. NTP (UDP 123) não se bloqueia inteiro: descarte a consulta vinda de porta de origem diferente de 123 e aplique limite de taxa no resto, porque muito equipamento usa a porta 123 também como origem.
3. No sentido cliente para internet, descarte pacotes com IP de origem que não é seu (BCP38). Isso tira a sua rede da lista de origens de ataque forjado.
4. Nos seus servidores: DNS recursivo só para os seus prefixos, NTP com noquery, memcached sem UDP e SNMP preso à rede de gerência.
5. Responda às notificações do CERT.br: elas trazem IP, porta e o teste que provou o problema.

Como funciona o ataque por amplificação

O truque depende de duas coisas. A primeira é o UDP não ter handshake: o servidor responde para o IP de origem que estiver no pacote, sem confirmar que aquele endereço pediu alguma coisa. A segunda é existir rede que deixa sair pacote com origem forjada. Com as duas, o atacante manda uma consulta com o IP da vítima no campo de origem, e o servidor consultado entrega a resposta para a vítima.

A amplificação vem do tamanho. Uma consulta DNS de 60 bytes do tipo ANY, pedindo todos os registros de um nome, pode voltar com vários kilobytes. Um monlist de NTP devolve a lista dos últimos 600 endereços que falaram com o servidor. Uma consulta de memcached com UDP aberto pode trazer um valor gigante que o próprio atacante gravou antes. O atacante gasta 1 Mbps e entrega dezenas ou centenas de Mbps na vítima, vindos de milhares de IPs legítimos ao mesmo tempo.

No diagrama, a vítima 203.0.113.80 representa a rede de outra empresa: o endereço é só de documentação e não tem relação com os blocos do provedor usados nos exemplos de configuração.

Por isso filtrar na vítima resolve pouco: quando o tráfego chega na sua borda, o link do trânsito já está cheio. Para a vítima, o recurso é pedir ajuda para cima, com RTBH com blackhole via BGP ou um serviço de mitigação. O corte barato acontece antes: na rede do atacante (BCP38) e na rede do refletor, fechando as portas de amplificação DDoS que os clientes deixaram abertas.

Tabela de portas de amplificação DDoS e fator de cada protocolo

Os fatores abaixo são os do alerta TA14-017A da CISA, medidos como banda da resposta dividida pela banda da consulta. Os números são referência: o fator real depende da versão do software e do que está gravado no servidor. O Ubiquiti não está na lista da CISA, mas está entre os testes publicados pelo NIC.br. SLP, ARMS e CoAP também ficam fora da CISA e aparecem com fator variável.

O CERT.br notifica as redes brasileiras que têm serviços abusáveis para amplificação, e o NIC.br publica na página do programa Por uma Internet mais Segura o teste de cada protocolo (DNS, SNMP, NTP, SSDP, Portmap, NetBIOS e Ubiquiti, entre outros). A notificação vai para o contato de abuse do whois do seu ASN, com o IP, o protocolo e o teste que provou o problema. Vale deixar esse contato apontando para uma caixa que alguém lê.

Como achar clientes que respondem nas portas de amplificação DDoS

O ponto de partida costuma ser a notificação. Pegue um IP da lista e repita o teste que o NIC.br publica na página de amplificação do programa Por uma Internet mais Segura. Rode de uma máquina fora da rede do cliente, porque o que importa é a resposta vista da internet. O exemplo usa 198.51.100.23 como cliente suspeito:

dig @198.51.100.23 example.com A +short
snmpget -v 2c -c public 198.51.100.23 iso.3.6.1.2.1.1.1.0
ntpq -c rv 198.51.100.23
ntpdc -n -c monlist 198.51.100.23
rpcinfo -T udp -p 198.51.100.23
nmblookup -A 198.51.100.23

• dig: se volta um endereço, o IP é um DNS recursivo aberto.
• snmpget: se volta a descrição do sistema, o SNMP responde com community public para qualquer um.
• ntpq -c rv e ntpdc -c monlist: resposta em qualquer um dos dois indica NTP que atende consultas de controle de fora.
• rpcinfo e nmblookup: listas de serviços RPC ou nomes NetBIOS são sinal de servidor ou estação exposto direto na internet.

Em distribuição com ntpsec, o ntpdc não vem instalado; o ntpq -c rv já basta para o teste.

SSDP e Ubiquiti pedem um pacote montado à mão. A consulta M-SEARCH vai numa variável para caber na linha; a segunda linha usa aspas duplas para concatenar o resto. Qualquer resposta HTTP do roteador confirma o UPnP aberto na WAN, e qualquer retorno no hexdump confirma a descoberta Ubiquiti exposta:

MSG='M-SEARCH * HTTP/1.1\r\nHost:239.255.255.250:1900\r\n'
MSG="${MSG}ST:upnp:rootdevice\r\nMan:\"ssdp:discover\"\r\nMX:3\r\n\r\n"
printf "$MSG" | nc -u -w 3 198.51.100.23 1900
printf '\x01\x00\x00\x00' | nc -u -w 3 198.51.100.23 10001 | hexdump -C

Varrer o próprio bloco com nmap

Esperar a notificação é reagir. Dá para varrer os seus prefixos atrás das portas de amplificação DDoS com os scripts do nmap e corrigir antes. Faça isso só nos blocos que são seus e de preferência fora do horário de pico, porque a varredura UDP é lenta e gera tráfego para cada IP:

sudo nmap -sU -Pn -n -p 53 --script dns-recursion 198.51.100.0/24
sudo nmap -sU -Pn -n -p 123 --script ntp-monlist 198.51.100.0/24
sudo nmap -sU -Pn -n -p 1900 --script upnp-info 198.51.100.0/24
sudo nmap -sU -Pn -n -p 11211 --script memcached-info 198.51.100.0/24

-sU faz a varredura UDP e precisa de root. -Pn pula a descoberta por ping (muito cliente não responde ICMP) e -n evita resolução reversa. Os scripts dns-recursion, ntp-monlist, upnp-info e memcached-info fazem a pergunta certa em cada porta e só imprimem resultado quando o serviço responde.

Pegar o refletor em ação com tcpdump

Quando o refletor está sendo usado, a assinatura aparece no uplink: muito UDP saindo dos seus IPs com porta de origem de serviço e pacotes grandes. Os filtros abaixo pegam respostas NTP maiores que 400 bytes e respostas SSDP saindo do bloco de clientes:

sudo tcpdump -ni ens1 -c 300 'udp src port 123 and greater 400'
sudo tcpdump -ni ens1 -c 300 'udp src port 1900 and src net 198.51.100.0/24'

Uma resposta de horário comum fica abaixo de 100 bytes; respostas maiores em sequência, para poucos destinos, são o monlist trabalhando para alguém. Se o seu link de clientes usa CGNAT, lembre que a varredura e o tcpdump enxergam o IP público do pool. O tema é tratado no post sobre o que é CGNAT; em geral, quem está atrás de CGNAT não recebe a consulta de fora, e o refletor típico é o cliente com IP público fixo ou com IPv6.

Filtrar as portas de amplificação DDoS na borda

Com a lista de clientes em mãos, há dois caminhos que convivem. O primeiro é falar com o cliente e corrigir o equipamento. O segundo é filtrar na sua rede, para que a consulta forjada nem chegue ao refletor. A ordem que funciona é avisar primeiro e filtrar depois, com exceção para quem usa algum desses serviços de propósito.

O exemplo abaixo é para uma borda ou um BNG Linux com nftables, com o uplink em ens1 e o acesso em ens2. A tabela fica no gancho prerouting com prioridade -300, a mesma do raw: o pacote descartado ali não chega a criar entrada no conntrack, o que poupa CPU na hora de um ataque.

nft add table inet antiamp
nft add set inet antiamp portas_amp '{ type inet_service; }'
nft add element inet antiamp portas_amp '{ 17, 19, 53, 69, 111, 137, 161, 389, 427, 1900, 3283, 3702, 5353, 5683, 10001, 11211 }'
nft add set inet antiamp excecoes '{ type ipv4_addr; flags interval; }'
nft add element inet antiamp excecoes '{ 203.0.113.0/28 }'
nft add chain inet antiamp pre '{ type filter hook prerouting priority -300; policy accept; }'
nft add rule inet antiamp pre iifname "ens1" ip daddr @excecoes accept
nft add rule inet antiamp pre iifname "ens1" ip daddr 198.51.100.0/24 udp dport @portas_amp counter drop
nft add rule inet antiamp pre iifname "ens1" ip6 daddr 2001:db8:100::/40 udp dport @portas_amp counter drop
nft add rule inet antiamp pre iifname "ens1" ip daddr 198.51.100.0/24 udp dport 123 udp sport != 123 counter drop
nft add rule inet antiamp pre iifname "ens1" ip daddr 198.51.100.0/24 udp dport 123 limit rate over 256 kbytes/second counter drop

Linha por linha:

• portas_amp é um set de portas. Mudar a lista depois é só um add element ou delete element, sem mexer nas regras.
• excecoes guarda os clientes corporativos com servidor DNS, SNMP ou outro serviço legítimo. O flags interval permite prefixos em vez de IPs soltos. A regra de accept vem antes de tudo e só encerra esta chain. Para IPv6, crie um segundo set excecoes6 com type ipv6_addr e a mesma regra com ip6 daddr.
• As duas regras de drop casam tráfego vindo da internet (iifname "ens1") para o bloco de clientes em IPv4 e em IPv6, com destino a qualquer porta do set. O counter mostra quanto foi barrado.
• As duas últimas regras tratam o NTP. A primeira descarta consulta vinda de fora com porta de origem que não é a 123: é assim que chega a consulta de controle e a varredura atrás de refletor. A resposta de um servidor de hora para o cliente vem com origem 123 e continua passando. A segunda limita o que sobra a 256 kbytes/s (cerca de 2 Mbps) para o bloco todo. Bloquear a 123 inteira quebraria a sincronização de quem usa ntpd com porta de origem fixa.

IPv6 muda a conta

No IPv4 com CGNAT, a maior parte da base nem recebe a consulta. No IPv6 cada CPE tem endereço global, as portas de amplificação DDoS dela ficam alcançáveis, então o firewall do próprio roteador do cliente passa a ser a primeira barreira, e a regra ip6 acima a segunda. Se você está começando o IPv6, o post sobre o que é IPv6 explica a lógica dos prefixos que aparecem aqui.

BCP38: o outro lado do mesmo problema

A amplificação só existe porque alguma rede deixa sair pacote com origem forjada. O BCP38 é a regra de não deixar: no sentido do cliente para a internet, só sai pacote com IP de origem que pertence a você. Duas linhas no mesmo nftables resolvem para o exemplo:

nft add rule inet antiamp pre iifname "ens2" ip saddr != { 0.0.0.0, 198.51.100.0/24, 203.0.113.0/24 } counter drop
nft add rule inet antiamp pre iifname "ens2" ip6 saddr != { ::, fe80::/10, 2001:db8:100::/40 } counter drop

O 0.0.0.0 deixa passar o DHCP Discover, e o :: e o fe80::/10 deixam passar o NDP e o DHCPv6; sem eles, a própria borda para de atender os clientes. Ajuste a lista para todos os prefixos que você anuncia e para o pool do CGNAT antes da tradução, se ele passar por esta máquina.

Num BNG PPPoE (accel-ppp, por exemplo), o tráfego do cliente entra pelas interfaces ppp*: troque iifname "ens2" por iifname "ppp*". Depois de aplicar, confira os contadores e salve:

nft list chain inet antiamp pre
echo 'flush ruleset' > /etc/nftables.conf
nft list ruleset >> /etc/nftables.conf

Contador alto na regra de exceção ou na de NTP logo no primeiro dia pede investigação: pode ser um cliente sendo usado agora ou um serviço legítimo que você não conhecia.

Arrumar a casa: servidores e CPEs do provedor

Nenhuma notificação pega pior do que aquela que lista o DNS do próprio provedor. Servidor da casa também responde nas portas de amplificação DDoS se ninguém revisar a configuração. Os blocos abaixo fecham os servidores mais comuns. Para o DNS, a configuração completa está no guia de DNS recursivo com Unbound no provedor; o que importa aqui é a lista de acesso:

# /etc/unbound/unbound.conf.d/acesso.conf
server:
    access-control: 0.0.0.0/0 refuse
    access-control: ::/0 refuse
    access-control: 198.51.100.0/24 allow
    access-control: 203.0.113.0/24 allow
    access-control: 2001:db8:100::/40 allow

O Unbound avalia o prefixo mais específico, então a ordem das linhas não muda o resultado: tudo recusa, menos os seus blocos. No NTP clássico (ntpd), o noquery fecha as consultas de controle (onde mora o monlist) sem impedir que os clientes peguem a hora, e o disable monitor desliga a lista de vez:

# /etc/ntp.conf (ntpd clássico)
restrict default kod limited nomodify notrap nopeer noquery
restrict -6 default kod limited nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict ::1
disable monitor

Memcached e SNMP seguem a mesma ideia: memcached sem UDP (-U 0) e ouvindo só local, SNMP preso à interface de gerência e com community longa aceita só da máquina de monitoramento:

# /etc/memcached.conf
-U 0
-l 127.0.0.1
# /etc/snmp/snmpd.conf
agentaddress udp:127.0.0.1:161,udp:192.0.2.2:161
rocommunity NomeLongoESecreto 192.0.2.10

Desde a versão 1.5.6 o memcached já vem com UDP desligado, mas servidor antigo esquecido num canto da rede é exatamente o que aparece nas notificações.

Se você entrega roteador Mikrotik como CPE, desligue UPnP e SNMP e confira se o firewall padrão continua descartando a entrada que não vem da LAN; é ele que impede o DNS do roteador de responder para a internet. O allow-remote-requests=no desliga o cache DNS também para a LAN, então só use quando o DHCP entrega os resolvedores do provedor:

/ip upnp set enabled=no
/snmp set enabled=no
/ip firewall filter print where chain=input

O hardening completo está no post de segurança no Mikrotik RouterOS v7. Em CPE de outros fabricantes, fechar as portas de amplificação DDoS segue o mesmo caminho: UPnP desligado na WAN, DNS só para a LAN e gerência remota restrita.

Erros comuns ao filtrar portas de amplificação DDoS

• Bloquear o NTP inteiro. Equipamento que usa a porta 123 como origem para de sincronizar e o problema aparece semanas depois, em log com hora errada.
• Filtrar sem avisar o corporativo. O cliente que hospeda um DNS autoritativo ou recebe SNMP de um parceiro abre chamado de “internet caiu”. A lista de exceções existe para isso.
• Filtrar só IPv4. Com IPv6 ativo, a mesma CPE responde pelo endereço global nas mesmas portas de amplificação DDoS.
• Achar que o filtro resolve a notificação. O CERT.br testa de novo; o certo é corrigir o equipamento e usar o filtro como rede de proteção.
• Varrer o bloco de terceiros. Varredura em rede que não é sua gera reclamação de abuse contra você.
• Esquecer os próprios servidores. Servidor de laboratório com IP público e rpcbind aberto conta como refletor do mesmo jeito.

Perguntas frequentes

Quais são as portas de amplificação DDoS mais abusadas?

DNS (53), NTP (123), SNMP (161), SSDP (1900), CLDAP (389) e memcached (11211) são as mais citadas, seguidas de Portmap (111), NetBIOS (137), WS-Discovery (3702), mDNS (5353) e Ubiquiti (10001). CharGEN (19) e QOTD (17) são legados, mas ainda aparecem.

Bloquear as portas de amplificação DDoS não quebra a internet do cliente?

Para cliente residencial, não. O filtro barra UDP com destino nessas portas vindo de fora, e o uso normal recebe respostas com destino em portas altas. A exceção é o cliente que hospeda o serviço, por isso a lista de exceções.

Por que o NTP leva limite de taxa e não bloqueio?

Porque muito equipamento usa a porta 123 também como origem, e a resposta do servidor de hora volta com destino 123. Bloquear quebraria a sincronização. Por isso o filtro descarta só a consulta que vem de porta alta, que é o formato do abuso, e aplica um limite de taxa no restante.

Recebi notificação do CERT.br. O que faço?

Repita o teste indicado de fora da rede, identifique o cliente pelo IP e horário e peça a correção no equipamento. Enquanto isso, o filtro na borda protege. A notificação não é punição, é um aviso de que a sua rede está sendo usada contra outra.

O BCP38 evita que meu provedor seja atacado?

Não diretamente. Ele impede que a sua rede seja origem de pacotes forjados, que é a matéria-prima do ataque. A proteção da sua rede como vítima vem de capacidade, RTBH e mitigação contratada.

Conclusão

As portas de amplificação DDoS são uma lista curta e conhecida. O trabalho do provedor é saber quais clientes respondem nelas, filtrar no sentido certo sem quebrar quem usa o serviço e manter os próprios servidores fechados. Comece pela notificação que já chegou, repita os testes, aplique o set de portas com exceções e confira os contadores por uma semana.

Depois coloque o BCP38 na mesma janela de mudança em que fechar as portas de amplificação DDoS. Uma rede que não deixa sair origem forjada e não responde para fora em UDP desnecessário some da lista de refletores, e as notificações param.

Leitura recomendada: Portas de amplificação DDoS e botnets, da wiki do Brasil Peering Forum (CC BY-NC 4.0), com a lista de portas e a abordagem de filtragem em BNG.