LACNIC Blog > Roteamento > Martians, Bogons e Invalids: por que as organizações deveriam filtrá-los
Martians, Bogons e Invalids: por que as organizações deveriam filtrá-los
28 de julho de 2026
Imagem assistida/criada por IA
Por Sergio Kleiman, IP Network Architect and Manager na Telefonica
Na Internet existem prefixos que não deveriam ser propagados e, ainda assim, estão lá. Todos sabemos que os endereços privados definidos pela RFC 1918 (192.168.0.0/16, 172.16.0.0/12 e 10.0.0.0/8) não devem ser anunciados nem recebidos via BGP, mas eles fazem parte de um conjunto mais amplo: os chamados bogons, prefixos que não deveriam aparecer na tabela global de roteamento (DFZ).
Dentro dos bogons estão os martians, prefixos que jamais deveriam aparecer na DFZ por possuírem um uso especial definido por normas técnicas ou pela IANA. Além dos endereços definidos na RFC 1918, esse conjunto inclui os espaços especificados na RFC 6890 e outros registrados pela IANA. Há um excelente vídeo do LACNIC (en espanhol) que aborda esse tema em detalhes.
O restante dos bogons corresponde principalmente ao espaço de endereços que ainda não foi delegado nem alocado (allocated) para uso na Internet. Diferentemente dos martians, os prefixos ainda não alocados mudam constantemente, pois, assim que um RIR delega ou aloca um prefixo a um de seus membros, ele deixa de ser um bogon e pode ser anunciado legitimamente.Enquanto permanece não alocado, porém, esse prefixo pode ser anunciado por engano ou de forma maliciosa por meio do BGP, gerando incidentes que afetam a estabilidade do sistema global de roteamento.
(Acesso livre, não requer assinatura)
O caso de um anúncio classificado como RPKI Invalid (inválido) é diferente: nesse caso, o prefixo existe, está alocado e o ASN de origem também existe. No entanto, o anúncio observado no BGP não corresponde à autorização publicada pelo titular do recurso através do RPKI (ROA). Isso pode ocorrer devido a um erro na criação do ROA ou a uma tentativa de sequestro de rota (route hijacking). Em julho de 2026, o MANRS Observatory detectou mais de 4.200 prefixos inválidos na Internet.
Uma analogia simples é:
Conceito
Analogia
Martian
O endereço não existe no mapa.
Não alocado
O endereço existe, mas ninguém deveria ocupá-lo ainda.
RPKI Invalid (inválido)
O endereço existe e está ocupado, mas o nome do ocupante não corresponde ao registro oficial.
Embora esses conceitos pareçam teóricos, eles continuam sendo observados diariamente na Internet e geram milhares de incidentes operacionais todos os anos.
O caso de um anúncio classificado como RPKI Invalid (inválido) é diferente: nesse caso, o prefixo existe, está alocado e o ASN de origem também existe. No entanto, o anúncio observado no BGP não corresponde à autorização publicada pelo titular do recurso através do RPKI (ROA). Isso pode ocorrer devido a um erro na criação do ROA ou a uma tentativa de sequestro de rota (route hijacking). Em julho de 2026, o MANRS Observatory detectou mais de 4.200 prefixos inválidos na Internet.
Uma analogia simples é:
Conceito
Analogia
Martian
O endereço não existe no mapa.
Não alocado
O endereço existe, mas ninguém deveria ocupá-lo ainda.
RPKI Invalid (inválido)
O endereço existe e está ocupado, mas o nome do ocupante não corresponde ao registro oficial.
Embora esses conceitos pareçam teóricos, eles continuam sendo observados diariamente na Internet e geram milhares de incidentes operacionais todos os anos.
Incidentes
Em um estudo detalhado publicado pelo LACNIC sobre incidentes de roteamento observados entre outubro de 2023 e outubro de 2024, foram registrados mais de 300 anúncios de bogons na América Latina e no Caribe. Longe de ser um problema do passado, os bogons continuam surgindo regularmente. Durante o primeiro semestre de 2026, o MANRS Observatory identificou mais de 800 incidentes relacionados a esse tipo de anúncio.
Um anúncio de bogon pode provocar o encaminhamento de tráfego para destinos inacessíveis, gerar desvios de tráfego, dificultar a operação da rede e facilitar atividades maliciosas. Geralmente, é um indicativo de erros de configuração ou de uma higiene deficiente do sistema de roteamento.
Os RIRs e seus prefixos reservados
Os RIRsnão publicam diretamente uma lista de bogons. Em vez disso, publicam periodicamente informações sobre os recursos delegados, alocados, reservados e disponíveis. A partir desses dados, é possível identificar os prefixos que ainda não foram delegados ou alocados e que, portanto, não deveriam aparecer na tabela global de roteamento.
Ferramentas como o Team Cymru Fullbogons constroem listas dinâmicas com base nessas informações e as disponibilizam para a comunidade.
Os ROAs AS0também vêm sendo utilizados por alguns RIRs como um mecanismo para proteger recursos que não devem ser anunciados com origem na Internet. O LACNIC e o APNIC publicam recursos protegidos por meio de AS0 em suas respectivas infraestruturas de RPKI.
Na AFRINIC, existe uma política para o uso de AS0 em recursos ainda não alocados, ratificada em 2022. No entanto, até o momento da redação deste artigo, essa política ainda não havia sido implementada.
Boas práticas operacionais
Filtrar, no BGP, os prefixos indesejados é uma tarefa complexa devido às constantes mudanças, e esse processo deve ser realizado tanto na entrada (inbound) quanto na saída (outbound).
Os filtros de entrada impedem que martians, prefixos não alocados ou prefixosinválidos entrem na rede por meio de provedores, peers ou clientes. Já os filtros de saída evitam que erros internos propaguem esses prefixos para o restante da Internet.
Ambos são igualmente importantes: os filtros de entrada protegem a infraestrutura da organização, enquanto os filtros de saída protegem o restante da Internet contra erros originados internamente ou em redes de clientes.
Quando um bogon, uma rota RPKI Invalid ou outro incidente é detectado, entrar rapidamente em contato com o operador responsável acelera a resolução do problema. Por isso, é recomendável manter atualizadas as informações de contato no WHOIS e no IRR, verificar os dados publicados no PeeringDB e garantir que os endereços de e-mail divulgados estejam sendo monitorados. Muitos incidentes são resolvidos em poucos minutos quando o canal de comunicação é claro e eficiente.
Cinco orientações básicas
Estas são orientações básicas para proteger a rede contra prefixos indevidos:
Filtrar estaticamente os martians, utilizando os registros de espaços de uso especial da IANA e aplicar filtros aos anúncios de clientes e peers, permitindo apenas os prefixos autorizados.
Utilizar a validação RPKI (por exemplo, com o FORT) para filtrar anúncios classificados como RPKI Invalid e prefixos abrangidos por ROAs AS0.
Opcionalmente, utilizar serviços como o Team Cymru Fullbogons para receber atualizações dinâmicas de prefixos bogon e automatizar sua filtragem.
Manter atualizados e validar periodicamente os dados de contato no WHOIS, IRR e PeeringDB.
Participar da iniciativa MANRS e utilizar seu observatório para monitorar o estado da segurança e da conformidade dos ASNs da organização.
Conclusões
Os bogons e as rotas RPKI Invalid continuam aparecendo diariamente nas tabelas globais de roteamento. Embora a maioria desses incidentes seja decorrente de erros operacionais, e não de atividades maliciosas, seus efeitos podem se estender muito além da rede onde se originam.
Filtrar prefixos, implementar a validação RPKI, utilizar ROAs AS0 e recorrer a fontes atualizadas de informações sobre bogons são medidas relativamente simples que contribuem para o aprimoramento da higiene do roteamento global. Na Internet, um prefixo que não deve ser propagado jamais deveria ser anunciado.
Seja um bogon ou um prefixo RPKI Invalid, a melhor maneira de evitar incidentes é impedir sua propagação desde a origem.
As opiniões expressas pelos autores deste blog são próprias e não refletem necessariamente as opiniões de LACNIC.
