BCP38 e uRPF: anti-spoofing no Huawei, Cisco, Juniper e Mikrotik

Todo ataque de amplificação depende de um detalhe: alguém conseguiu mandar para a internet um pacote com o endereço de origem de outra pessoa. O BCP38 é a recomendação que fecha essa porta. Ele pede que cada rede só deixe sair pacotes cuja origem pertence a ela ou aos seus clientes. Parece óbvio, mas muita rede ainda deixa passar qualquer origem.

Este guia mostra onde aplicar o filtro no provedor, a diferença entre uRPF strict e loose, quando usar ACL de origem e a sintaxe no Huawei, no Cisco, no Juniper e no Mikrotik. Os comandos de cada fabricante vêm da documentação oficial; os de Cisco, Juniper e Mikrotik foram montados como quem documenta e testa em laboratório. Os endereços são de documentação: 203.0.113.0/24 e 2001:db8::/32 como blocos do provedor.

Resposta rápida: como aplicar o BCP38

1. Filtre perto do cliente: na interface de agregação ou no BNG, com uRPF strict. É ali que você sabe exatamente qual prefixo cada interface pode usar como origem.
2. Na borda, aplique uma ACL de saída para o trânsito e o IX que só deixa passar origens dos seus blocos (mais os endereços dos enlaces).
3. Use uRPF loose só onde há assimetria, como uplinks múltiplos. Ele barra origens sem rota, mas não garante que a origem é sua.
4. Não aplique strict na interface de trânsito ou de peering: o tráfego de volta é assimétrico e você descartaria pacotes legítimos.
5. Teste de dentro da rede com o Spoofer, da CAIDA, antes e depois da mudança.

Spoofing, DDoS e o que o BCP38 pede

Spoofing é forjar o endereço de origem de um pacote IP. Como o roteador encaminha pelo destino, nada no caminho impede que o pacote chegue, a menos que alguém confira a origem. Nos ataques de reflexão, o atacante envia consultas pequenas a servidores abertos (DNS, NTP, SSDP, memcached) usando o IP da vítima como origem. As respostas, bem maiores, vão todas para a vítima.

O provedor entra nessa história de dois jeitos: como vítima, quando os clientes dele são o alvo, e como origem, quando um cliente infectado manda pacotes com origem falsa. O post sobre portas de amplificação DDoS trata do lado do refletor; o de RTBH via BGP mostra como conter um ataque que já chegou. O BCP38 trata da origem: impedir que a sua rede seja usada para forjar pacotes.

O documento é a RFC 2827, publicada em 2000 como BCP 38. A RFC 3704 (BCP 84) veio depois e detalha como fazer isso em redes com mais de uma saída, descrevendo os modos de uRPF. Em 2020, a RFC 8704 atualizou o BCP 84 com o modo feasible path melhorado (EFP-uRPF), pensado para clientes multihomed. A ação de anti-spoofing também é um dos compromissos do MANRS, o programa de boas práticas de roteamento para operadoras.

Onde aplicar o BCP38 na rede do provedor

O melhor lugar para aplicar o BCP38 é o mais próximo possível do cliente. Na interface onde o cliente chega, você sabe qual prefixo ele recebeu, e qualquer origem diferente é falsa. Na borda, o roteador só consegue dizer se a origem é de algum bloco seu, o que ainda deixa um cliente forjar o IP de outro cliente da mesma rede.

Por isso a recomendação é usar as duas camadas: uRPF strict na agregação e ACL na borda. A ACL de borda pega o que escapou, como uma interface nova sem uRPF ou um equipamento de cliente corporativo que roteia outros blocos.

uRPF strict, loose e feasible path

O uRPF (Unicast Reverse Path Forwarding) faz a pergunta ao contrário: se eu fosse mandar um pacote para o endereço de origem deste pacote, por onde mandaria? O roteador consulta a tabela de encaminhamento usando a origem como se fosse destino e decide se aceita o pacote.

Cuidado com a rota default e a assimetria

No modo loose, uma rota default faz qualquer origem parecer válida, e o filtro deixa de ter efeito. Por isso os fabricantes tratam a default à parte: ela só conta se você ligar uma opção específica (allow-default-route no Huawei, allow-default no Cisco). No modo strict, o risco é o oposto: se a rota de volta de um cliente sai por outra interface, o tráfego legítimo dele é descartado.

O caso clássico é o cliente corporativo com dois links para o provedor, ou o próprio provedor com dois trânsitos. Nesses pontos, use loose ou ACL de origem. Na interface de um concentrador PPPoE, cada sessão tem a sua rota apontando para a própria interface, e o strict funciona sem surpresa.

BCP38 no Huawei (roteadores NE)

Os exemplos usam a sintaxe dos roteadores Huawei da linha NE. A interface de clientes é a GigabitEthernet0/3/1 e o trânsito está na GigabitEthernet0/3/0. Em switches e roteadores de outras linhas, os comandos de uRPF mudam, então confira o manual do modelo.

uRPF strict na interface de clientes

interface GigabitEthernet0/3/1
 ip urpf strict
 ipv6 urpf strict
 quit
commit

ip urpf strict liga o uRPF no modo estrito para IPv4, e ipv6 urpf strict faz o mesmo para IPv6. O commit grava a mudança, como em todo VRP com confirmação em duas etapas. A documentação do NE40E avisa que, em subinterface de terminação dot1q, o modo strict vira loose automaticamente; se os clientes chegam por subinterface, conte com isso.

ACL de origem na borda

acl number 2001
 description BLOCOS-PROPRIOS
 rule 10 permit source 203.0.113.0 0.0.0.255
 quit
acl ipv6 number 2001
 description BLOCOS-PROPRIOS-V6
 rule 10 permit source 2001:DB8::/32
 quit
acl number 2002
 description ORIGENS-DE-SAIDA
 rule 10 permit source 203.0.113.0 0.0.0.255
 rule 20 permit source 192.0.2.2 0
 quit
acl ipv6 number 2002
 description ORIGENS-DE-SAIDA-V6
 rule 10 permit source 2001:DB8::/32
 rule 20 permit source FE80::/10
 quit
commit

A ACL 2001 lista os blocos próprios e será usada na entrada: pacote que chega do trânsito dizendo vir de dentro da sua rede é falso. A ACL 2002 é a lista de origens que podem sair: os blocos, o endereço do seu lado do enlace de trânsito (para o BGP e o ping do enlace) e, no IPv6, o link-local FE80::/10, usado pelo Neighbor Discovery. Repare que o link-local fica fora da ACL de entrada; caso contrário, o ND do vizinho seria descartado.

traffic classifier C-ENTRADA-FALSA operator or
 if-match acl 2001
 if-match ipv6 acl 2001
 quit
traffic classifier C-SAIDA-OK operator or
 if-match acl 2002
 if-match ipv6 acl 2002
 quit
traffic classifier C-QUALQUER operator or
 if-match any
 quit
traffic behavior B-SEGUE
 permit
 quit
traffic behavior B-DESCARTA
 deny
 quit
traffic policy P-SAIDA-BCP38
 classifier C-SAIDA-OK behavior B-SEGUE precedence 1
 classifier C-QUALQUER behavior B-DESCARTA precedence 10
 quit
traffic policy P-ENTRADA-BCP38
 classifier C-ENTRADA-FALSA behavior B-DESCARTA precedence 1
 quit
interface GigabitEthernet0/3/0
 traffic-policy P-ENTRADA-BCP38 inbound
 traffic-policy P-SAIDA-BCP38 outbound
 quit
commit

Os classificadores casam as ACLs. O behavior B-SEGUE usa permit e deixa o pacote seguir; o B-DESCARTA usa deny e descarta. Na política de saída, o que tem origem válida casa primeiro (precedência 1) e o resto cai no if-match any com descarte. Na entrada, só os pacotes com origem dos seus blocos são descartados. As duas políticas ficam na interface de trânsito, uma em cada sentido.

display acl 2002
display current-configuration interface GigabitEthernet0/3/1
display current-configuration interface GigabitEthernet0/3/0

O display acl mostra as regras e, conforme a versão, quantos pacotes casaram cada uma. O display current-configuration interface confirma o que ficou aplicado em cada porta.

BCP38 no Cisco IOS XE

No Cisco, o uRPF depende do CEF ligado. A interface de clientes é a GigabitEthernet0/0/1 e o trânsito, a GigabitEthernet0/0/0. O BCP38 aqui protege a rede, não o roteador; para o plano de controle, veja o post sobre CoPP no Cisco IOS XE.

configure terminal
interface GigabitEthernet0/0/1
 ip verify unicast source reachable-via rx
 ipv6 verify unicast source reachable-via rx
 exit
end

reachable-via rx é o modo strict: a origem precisa ser alcançável pela interface por onde o pacote chegou. O modo loose seria reachable-via any. A linha IPv6 segue a mesma lógica. O comando aceita ainda allow-default, que não faz sentido numa interface de cliente.

configure terminal
ip access-list extended SAIDA-BCP38
 permit ip 203.0.113.0 0.0.0.255 any
 permit ip host 192.0.2.2 any
 deny ip any any
 exit
ipv6 access-list SAIDA-BCP38-V6
 permit ipv6 2001:DB8::/32 any
 permit ipv6 FE80::/10 any
 deny ipv6 any any
 exit
interface GigabitEthernet0/0/0
 ip access-group SAIDA-BCP38 out
 ipv6 traffic-filter SAIDA-BCP38-V6 out
 exit
end

As ACLs de saída liberam os blocos próprios e o endereço do enlace e descartam o resto. O deny no fim é explícito para que o contador mostre quantos pacotes foram barrados. No IPv6, o link-local entra na lista pelo mesmo motivo do Huawei.

show cef interface GigabitEthernet0/0/1
show ip interface GigabitEthernet0/0/1 | include verif
show ip traffic
show ipv6 traffic
show access-lists SAIDA-BCP38

O show cef interface mostra se a verificação de origem está ligada, e o show ip interface traz os descartes dela na interface. show ip traffic e show ipv6 traffic trazem os descartes por RPF do equipamento inteiro, e show access-lists os contadores de cada linha da ACL.

BCP38 no Juniper Junos

set interfaces xe-0/0/1 unit 100 family inet rpf-check
set interfaces xe-0/0/1 unit 100 family inet6 rpf-check

rpf-check liga o uRPF na unidade lógica dos clientes, em IPv4 e IPv6. Nos roteadores MX o modo padrão é strict; o loose seria rpf-check mode loose. Nos switches EX e QFX o comando não tem opção de modo. Também dá para indicar um fail-filter, um filtro que decide o que fazer com o pacote reprovado, útil para deixar passar o DHCP de clientes que ainda não têm endereço.

set firewall family inet filter SAIDA-BCP38 term proprio from source-address 203.0.113.0/24
set firewall family inet filter SAIDA-BCP38 term proprio from source-address 192.0.2.2/32
set firewall family inet filter SAIDA-BCP38 term proprio then accept
set firewall family inet filter SAIDA-BCP38 term resto then count spoof-v4
set firewall family inet filter SAIDA-BCP38 term resto then discard
set firewall family inet6 filter SAIDA-BCP38-V6 term proprio from source-address 2001:db8::/32
set firewall family inet6 filter SAIDA-BCP38-V6 term proprio from source-address fe80::/10
set firewall family inet6 filter SAIDA-BCP38-V6 term proprio then accept
set firewall family inet6 filter SAIDA-BCP38-V6 term resto then count spoof-v6
set firewall family inet6 filter SAIDA-BCP38-V6 term resto then discard
set interfaces xe-0/0/0 unit 0 family inet filter output SAIDA-BCP38
set interfaces xe-0/0/0 unit 0 family inet6 filter output SAIDA-BCP38-V6
commit confirmed 5

O filtro de saída aceita as origens próprias e o endereço do enlace, conta e descarta o resto. As duas condições de source-address no mesmo termo funcionam como um “ou”. O commit confirmed 5 desfaz tudo em 5 minutos se você não confirmar com commit, o que salva o acesso se o filtro cortar a sessão BGP. Veja mais sobre commit confirmed no Junos.

show interfaces xe-0/0/1.100 extensive | match RPF
show firewall filter SAIDA-BCP38
show firewall filter SAIDA-BCP38-V6

No extensive, procure o contador de falhas de RPF da unidade. O show firewall filter mostra os contadores spoof-v4 e spoof-v6, que são o melhor indicador de que o filtro está trabalhando.

BCP38 no Mikrotik RouterOS v7

No Mikrotik, o uRPF é global, em /ip settings, e vale para todas as interfaces. Num concentrador dedicado, como o do post sobre PPPoE server no Mikrotik, o modo strict funciona bem, porque cada sessão tem a sua rota.

/ip settings set rp-filter=strict

A documentação do RouterOS segue a RFC 3704: strict reprova o pacote se a interface de entrada não é a melhor rota de volta, e loose só confere se há rota. Ela recomenda loose quando há roteamento assimétrico ou VRRP e avisa que o strict não funciona com tabelas de roteamento adicionais. Se o equipamento usa policy routing com outras tabelas, fique no loose e use o filtro abaixo.

/ip firewall address-list
add list=ORIGENS-VALIDAS address=203.0.113.0/24
add list=ORIGENS-VALIDAS address=100.64.0.0/10
add list=ORIGENS-VALIDAS address=198.51.100.0/24
/ip firewall raw
add chain=prerouting in-interface=!sfp-sfpplus1 \
    src-address-list=!ORIGENS-VALIDAS action=drop comment=BCP38
/ipv6 firewall address-list
add list=ORIGENS-VALIDAS address=2001:db8::/32
add list=ORIGENS-VALIDAS address=fe80::/10
add list=ORIGENS-VALIDAS address=::/128
/ipv6 firewall raw
add chain=prerouting in-interface=!sfp-sfpplus1 \
    src-address-list=!ORIGENS-VALIDAS action=drop comment=BCP38

A regra em raw descarta, antes do connection tracking, todo pacote que não veio do uplink e não tem origem na lista. A lista inclui o bloco público, a faixa de CGNAT (o pacote do cliente ainda não passou pelo NAT quando entra) e a rede de infraestrutura. No IPv6 entram o link-local e o ::/128, usado como origem na detecção de endereço duplicado. Sem os dois, o ND e o DHCPv6 dos clientes param. Com mais de um uplink ou porta de IX, troque in-interface por in-interface-list com todas as portas externas.

/ip firewall raw print stats
/ipv6 firewall raw print stats

O print stats mostra bytes e pacotes por regra. Se o contador da regra BCP38 sobe, há alguém na rede mandando origem falsa, ou faltou um bloco legítimo na lista. Confira antes de concluir.

Como testar o BCP38 com o Spoofer

O Spoofer, da CAIDA é um cliente que roda num computador dentro da rede e tenta enviar pacotes com origem falsa para servidores de teste. O resultado diz se a rede deixou passar origem forjada, de qual tipo e em qual prefixo. A CAIDA publica estatísticas agregadas por ASN, o que também mostra como a sua rede aparece para quem pesquisa.

1. Rode o Spoofer antes da mudança, de uma máquina ligada como um cliente comum.
2. Aplique o uRPF na agregação e a ACL na borda, um ponto de cada vez.
3. Rode o teste de novo e compare. O ideal é nenhuma origem falsa saindo.
4. Repita a partir de pontos diferentes: um cliente PPPoE, um cliente corporativo e um servidor do próprio provedor.

Erros comuns no anti-spoofing

• uRPF strict no trânsito. A volta de parte do tráfego chega por outro link e os pacotes legítimos são descartados. No trânsito, use ACL.
• Esquecer blocos na ACL. Bloco novo, faixa de CGNAT, prefixo de cliente corporativo com ASN próprio. Mantenha a lista junto com o filtro de anúncios do BGP.
• Cortar o link-local no IPv6. Sem fe80::/10, o Neighbor Discovery para e o IPv6 cai inteiro.
• Esquecer o endereço do enlace. O endereço do seu lado do enlace de trânsito pode não estar nos seus blocos. Em alguns equipamentos, como no Junos, o filtro de saída também vale para o tráfego do próprio roteador e pode derrubar o BGP. Libere esse endereço antes de aplicar a ACL de saída.
• Loose com rota default. Sem cuidado, a default aprova qualquer origem e o filtro vira enfeite.
• Cliente corporativo com bloco próprio. Se ele anuncia o próprio prefixo pelo seu BGP, inclua o prefixo na ACL da borda e confira o uRPF da interface dele.

Perguntas frequentes

O que é BCP38?

É a recomendação da RFC 2827 para que cada rede filtre pacotes com origem falsa na entrada dos clientes. O objetivo é impedir que pacotes forjados saiam da rede e alimentem ataques de reflexão.

Qual a diferença entre uRPF strict e loose?

O strict exige que a melhor rota de volta para a origem saia pela mesma interface por onde o pacote chegou. O loose só exige que exista alguma rota. Strict é para interfaces de cliente; loose, para pontos com assimetria.

Posso aplicar uRPF strict na interface de trânsito?

Não. A internet não garante que a volta use o mesmo caminho da ida, e você descartaria tráfego legítimo. Na borda, use ACL de origem.

O BCP38 protege meu provedor contra DDoS?

Não diretamente. Ele impede que a sua rede seja usada para forjar pacotes contra os outros. Para se proteger, use RTBH, FlowSpec ou um serviço de mitigação.

Como saber se minha rede permite spoofing?

Rode o cliente Spoofer, da CAIDA, a partir de uma máquina dentro da rede. Ele tenta enviar pacotes com origem falsa e informa o que passou.

Conclusão

O BCP38 é barato de aplicar e não muda a vida do cliente quando é bem feito: uRPF strict onde o cliente chega, ACL de origem na borda e loose só onde há assimetria. O cuidado está nos detalhes, como o link-local do IPv6, o endereço do enlace de trânsito e a faixa de CGNAT.

Aplique por partes, acompanhe os contadores e rode o Spoofer antes e depois. Com o filtro no lugar, a sua rede deixa de ser fonte de ataque e o seu ASN aparece limpo para quem verifica.

Leitura recomendada: Aplicando anti-spoof via ACL na borda Huawei, do Brasil Peering Forum (CC BY-NC 4.0), com um exemplo completo de traffic policy em roteadores Huawei da linha NE.