BCPs para provedores: anti-spoofing (BCP 38), RPKI, segurança BGP e MANRS

Boa parte dos incidentes que tiram provedores do ar não começa dentro da rede deles: um vizinho que vaza rotas, um IP falsificado usado em ataque, um prefixo sequestrado. As BCPs (Best Current Practices) são as práticas que, aplicadas por todos, impedem esses problemas na origem.

Neste tutorial você vai conhecer as BCPs que todo provedor com ASN próprio deve aplicar: anti-spoofing, RPKI, segurança das sessões BGP e fechamento de serviços usados em ataques. Também vai ver como o MANRS e o programa do NIC.br organizam essas práticas e como verificar em que ponto a sua rede está.

O que são as BCPs

BCP é uma categoria de documento da IETF: em vez de definir um protocolo, descreve a forma recomendada de operar. Cada BCP tem um número fixo e aponta para um ou mais RFCs, que podem ser atualizados ao longo do tempo. As mais importantes para provedores:

• BCP 38 (RFC 2827): filtragem de pacotes com origem falsificada na entrada da rede.
• BCP 84 (RFC 3704 e RFC 8704): como aplicar a BCP 38 em redes com vários links, usando uRPF.
• BCP 194 (RFC 7454): operação e segurança de sessões BGP.
• RFC 6811 e relacionados: validação de origem de rotas BGP com RPKI.

No Brasil, o NIC.br reúne essas recomendações no Programa por uma Internet mais Segura, e internacionalmente elas formam a base do MANRS.

As práticas em uma tabela

Anti-spoofing: BCP 38 e BCP 84

Ataques de amplificação (DNS, NTP, memcached, SSDP) só funcionam porque o atacante consegue enviar pacotes com o IP da vítima como origem. Se cada rede aceitasse apenas pacotes com origem nos próprios blocos dos seus clientes, esse tipo de ataque deixaria de existir.

A regra é simples: na interface de cada cliente, só entram pacotes com origem nos IPs daquele cliente. Na prática, há duas formas de aplicar:

• ACLs de entrada com os prefixos do cliente. Funcionam bem, mas exigem manutenção a cada mudança de bloco do cliente.
• uRPF (unicast Reverse Path Forwarding): o roteador verifica se a rota de volta para a origem do pacote sai pela mesma interface em que ele chegou. Se não, descarta.

Em clientes com um único link, o uRPF no modo strict resolve com uma linha de configuração:

! Cisco IOS / IOS XE: interface do cliente
interface GigabitEthernet0/1
 ip verify unicast source reachable-via rx
 ipv6 verify unicast source reachable-via rx

# Juniper Junos: interface do cliente
set interfaces xe-0/0/1 unit 0 family inet rpf-check
set interfaces xe-0/0/1 unit 0 family inet6 rpf-check

O modo strict descarta tráfego legítimo de clientes com mais de um link ou com roteamento assimétrico. Para esses, o caminho é ACL ou o uRPF feasible path da RFC 8704. Já o modo loose nas interfaces de trânsito quase não ajuda contra spoofing: só descarta origens que não existem na tabela.

Em provedores de acesso, o ponto principal não é o roteador de borda, e sim o concentrador (BNG, BRAS, concentrador PPPoE ou IPoE), por onde passam todos os clientes residenciais. Cada fabricante tem seu mecanismo de anti-spoofing por sessão, e ele precisa estar ativo para IPv4, IPv6 e para os prefixos delegados por DHCPv6-PD.

RPKI: ROAs e validação de origem

O RPKI responde a uma pergunta que o BGP sozinho não responde: este ASN tem autorização para anunciar este prefixo? São duas partes independentes.

Publicar ROAs dos seus blocos

Um ROA (Route Origin Authorization) é um registro assinado que diz "o prefixo X pode ser anunciado pelo ASN Y, com máscara de até Z". Para blocos recebidos do NIC.br, os ROAs são criados no painel do Registro.br. Com eles publicados, redes que validam RPKI descartam anúncios dos seus blocos feitos por qualquer outro ASN.

Os erros que mais derrubam anúncios ao criar ROAs:

• Esquecer anúncios existentes. Prefixos anunciados por clientes com o próprio ASN, por serviços de mitigação de DDoS ou por outra empresa do grupo precisam de ROA próprio.
• Tamanho máximo errado. Um ROA para um /22 com tamanho máximo /22 torna inválido o anúncio de um /24 de dentro dele. Por outro lado, tamanho máximo folgado demais (/24 para tudo) abre espaço para sequestro com prefixo mais específico.
• IPv6 esquecido. Os blocos IPv6 também precisam de ROAs.

Validar as rotas que você recebe

A outra metade é descartar, nos seus roteadores, as rotas inválidas recebidas de trânsito, peers e IX. Isso exige:

• Validadores, como Routinator, rpki-client ou FORT, que baixam e verificam os dados do RPKI de todos os RIRs. No mínimo dois, em servidores diferentes.
• Protocolo RTR entre os validadores e os roteadores, que passam a marcar cada rota como válida, inválida ou não encontrada.
• Política de rota que descarta as inválidas e mantém as não encontradas, já que boa parte da internet ainda não publicou ROAs.

Antes de descartar, vale passar um período só observando quais rotas seriam descartadas e por quê. É comum encontrar clientes com ROA errado, e é melhor descobrir isso antes de o cliente ficar sem acesso.

Segurança das sessões BGP: BCP 194

Além de filtrar os prefixos dos clientes (veja o tutorial de filtro BGP com bgpq4 e IRR), toda sessão eBGP deve ter:

• Limite de prefixos (maximum-prefix) em todas as sessões, inclusive de trânsito, como última barreira contra vazamentos.
• Filtro de bogons: blocos privados, reservados e não alocados nunca devem ser aceitos nem anunciados.
• Filtro de prefixos muito específicos: mais específicos que /24 em IPv4 e /48 em IPv6 não são aceitos pela maioria das redes.
• Nada de rota padrão vinda de peers e IX.
• Seu próprio ASN não deve aparecer em rotas recebidas, e seus próprios blocos não devem ser aceitos de fora.
• Proteção da sessão com GTSM (TTL security) e senha MD5 ou TCP-AO quando o outro lado suportar.
• Política explícita: sessão eBGP sem filtro de entrada e saída não deve trocar rotas (RFC 8212). Alguns fabricantes já fazem isso por padrão; outros não.

Serviços abertos e amplificação

O anti-spoofing impede que a sua rede seja a origem do ataque. A outra metade é não ter servidores e equipamentos que funcionem como amplificadores para ataques vindos de fora. Os mais comuns:

• DNS recursivo aberto para a internet (veja o tutorial de DNS recursivo, autoritativo e reverso);
• NTP com o comando monlist habilitado ou respondendo a qualquer origem;
• SNMP com comunidade padrão acessível pela internet;
• SSDP, memcached, CLDAP e outros, muitas vezes em CPEs e servidores de clientes.

O CERT.br envia notificações aos provedores com a lista de IPs que respondem a esses serviços. Tratar essas notificações, e não deixar que se acumulem, também faz parte das boas práticas.

MANRS e o Programa por uma Internet mais Segura

O MANRS (Mutually Agreed Norms for Routing Security) é uma iniciativa global em que operadoras se comprometem publicamente com quatro ações:

1. Filtragem: garantir que os anúncios dos clientes e os seus próprios estejam corretos;
2. Anti-spoofing: impedir tráfego com origem falsificada;
3. Coordenação: manter contatos atualizados e acessíveis para outras redes;
4. Validação global: publicar as suas políticas de roteamento no IRR e no RPKI.

Aderir é gratuito e a adesão passa por uma verificação da rede. Para o provedor, é também um argumento comercial: clientes corporativos e operadoras cada vez mais perguntam se o fornecedor de trânsito segue o MANRS.

No Brasil, o NIC.br conduz o Programa por uma Internet mais Segura, com as mesmas práticas, materiais em português, cursos e o acompanhamento da situação dos ASNs brasileiros.

Como verificar a sua rede

Alguns pontos de partida para saber onde a sua rede está:

• Anti-spoofing: o projeto Spoofer, do CAIDA, testa a partir de uma máquina dentro da rede se pacotes com origem falsificada conseguem sair.
• RPKI: ferramentas públicas como o RIPEstat mostram o estado de validação de cada prefixo anunciado pelo seu ASN.
• IRR e contatos: o whois do seu ASN e dos seus blocos deve ter contatos que respondem, e o seu as-set deve refletir os seus clientes atuais.
• Serviços abertos: as notificações do CERT.br e varreduras externas mostram quais IPs da sua rede respondem como amplificadores.

Na maioria dos provedores, a verificação mostra a mesma coisa: algumas práticas aplicadas em parte da rede, e nenhuma aplicada de forma completa e mantida ao longo do tempo.

Do tutorial à produção

Conhecer as BCPs é o primeiro passo. Aplicá-las em uma rede em produção, sem derrubar clientes e de forma que continuem valendo quando a rede cresce, é o que fica fora deste tutorial:

• Diagnóstico completo. Levantamento de cada borda, concentrador e sessão BGP, com a lista do que falta em cada um.
• Anti-spoofing sem efeito colateral. Clientes com mais de um link, IPv6, prefixos delegados e roteamento assimétrico tratados caso a caso.
• RPKI de ponta a ponta. ROAs para todos os anúncios, inclusive de clientes e de mitigação de DDoS, validadores redundantes e período de observação antes de descartar inválidas.
• Filtros automatizados. Prefix-lists, bogons e limites de prefixos gerados e aplicados automaticamente, sem depender de alteração manual.
• Adesão ao MANRS. Preparação da rede e da documentação para a verificação e manutenção das práticas depois da adesão.

Perguntas frequentes

O que é BCP 38?

É a recomendação da IETF (RFC 2827) para que cada rede descarte, na entrada, pacotes com endereço de origem que não pertence ao cliente ou à rede de onde vieram. Com ela, ninguém dentro da sua rede consegue falsificar IPs de terceiros, que é a base dos ataques de amplificação.

Criar ROAs pode derrubar meus anúncios?

Pode, se forem criados errados. Um ROA com o ASN errado ou com tamanho máximo menor que o prefixo anunciado torna o anúncio inválido, e as redes que validam RPKI passam a descartá-lo. Por isso os ROAs devem cobrir todos os anúncios existentes, inclusive os feitos por clientes e por proteção contra DDoS, antes de serem publicados.

Qual a diferença entre uRPF strict e loose?

No modo strict, o pacote só é aceito se a rota de volta para a origem sair pela mesma interface em que ele chegou, o que funciona bem em clientes com um único link. No modo loose, basta existir uma rota para a origem em qualquer interface, o que quase não protege contra spoofing e serve mais para descartar origens não roteadas.

Aderir ao MANRS é obrigatório?

Não. O MANRS é uma iniciativa voluntária, mas as práticas que ele pede (filtros, anti-spoofing, contatos atualizados e validação) são cobradas cada vez mais por operadoras, pontos de troca de tráfego e clientes corporativos, e são as mesmas promovidas pelo NIC.br no Programa por uma Internet mais Segura.