Por Flank Manoel da Silva Especialista Sênior Full Stack | Analista de Infraestrutura e Performance
Há uma narrativa confortável que permeia as discussões sobre segurança de roteamento: a ideia de que os incidentes BGP são resultado de ataques bem coordenados, de atacantes que entendem profundamente o protocolo e exploram vulnerabilidades sofisticadas. Essa narrativa é, em grande medida, falsa. E ela nos custa caro.
Quando olhamos para os dados reais dos últimos dois anos, a realidade é brutalmente diferente. Segundo a análise mais recente de incidentes de roteamento na região da LAC (Latin America and Caribbean) realizada pela LACNIC, os cinco países com maior incidência de problemas de roteamento foram Argentina, Brasil, Colômbia, México e Peru. Não por estarem sendo alvo de ataques coordenados, mas porque seus provedores regionais operam com configurações que nunca foram testadas sob pressão.
O que diferencia um incidente de roteamento “grave” de uma simples anomalia não é a sofisticação do ataque, mas a confluência de três fatores operacionais banais: uma configuração padrão permissiva, ausência de filtros de prefixo, e falta de validação de origem de rotas. Três coisas que qualquer operador de rede sênior diria que são “óbvias” de fazer certo. E, no entanto, a maioria não faz.
O caso Cloudflare em 22 de Janeiro de 2026: quando a automação encontra a negligência de configuração
Na noite de 22 de janeiro de 2026, a Cloudflare experimentou um route leak que durou 25 minutos e afetou o tráfego global. A causa não era uma vulnerabilidade zero-day. Não era uma exploração de fraqueza no protocolo BGP. Era uma mudança de política em código de automação de rede que foi mergeada sem suficiente validação.
Fato importante: A mudança que disparou o incidente foi entregue para um único router em Miami. Não foi um ataque distribuído. Não foi sofisticação. Foi um script que ninguém testou em sandbox antes de rodar em produção.
A sequência de eventos:
19:52 UTC: Mudança de política é feita em repositório de automação
20:25 UTC: Automação é executada no router de Miami. Anúncios inesperados começam a propagar
20:40 UTC: Equipe de rede começa investigação (tempo até detecção: 15 minutos)
20:50 UTC: Configuração incorreta é revertida manualmente (tempo até remediação: 25 minutos)
21:47 UTC: Mudança ofensora é revertida no repositório de código
22:07 UTC: Automação é confirmada como segura para executar novamente
O que torna esse incidente importante não é seu impacto técnico (que foi significativo, mas contido), mas o que ele revela: uma empresa com equipes de engenheiros de rede de classe mundial, com infraestrutura global, com acesso a monitoring avançado, ainda assim foi vulnerável a um erro que teria sido prevenido com CI/CD validation e teste de política de roteamento.
Se Cloudflare pode sofrer isso, qual é a probabilidade de um provedor regional com 40 técnicos de rede não estar operando com vulnerabilidades muito piores?
A verdade oculta: incidentes de hijack não são sofisticados, são operacionais
Existe uma pesquisa clássica da IEEE sobre incidentes de BGP que divide causas em duas categorias: maliciosos e acidentais. O que os dados consistentemente mostram é que entre 85-92% dos incidentes documentados são acidentes. E mesmo dos incidentes que parecem “maliciosos”, muitos são na verdade acidentes que parecem intencional porque deixam rastros que lembram explorações deliberadas.
Em 2024, dois incidentes receberam atenção máxima:
1. Hijack do 1.1.1.1 da Cloudflare (junho 2024): A Cloudflare anunciou que seu serviço DNS foi parcialmente impossível de alcançar porque rotas foram desviadas através de redes na Ásia. O alarme inicial foi: “Cloudflare foi hijacked!”. A realidade foi mais nuançada. Houve uma combinação de uma validação de origem de rota inadequada (falta de RPKI) e uma falha secundária em filtragem de prefixo. Não foi um ataque. Foi um furo de roteamento que cascateou através de múltiplas redes.
2. Anomalia de Roteamento na Venezuela (janeiro 2026): O AS8048 (CANTV, operador estatal) exibiu comportamento de roteamento anômalo. Graham Helton, engenheiro de red team, publicou análise sugerindo possível interferência. A Cloudflare respondeu com análise técnica argumentando que os padrões eram consistentes com um furo de roteamento acidental, não com manipulação deliberada. A diferença é crítica: um acidente é evitável com operação apropriada; um ataque exige resposta de segurança.
Ambos os casos compartilham um padrão: configurações permissivas que permitem rotas “ruins” se propagar. Não são ataques sofisticados. São erros operacionais em cascata.
Leia também: Nuvem ou servidor local? A matemática do TCO para pequenos projetos
Por que as configurações padrão (Default) são o verdadeiro culpado
Aqui está o ponto que mudará sua perspectiva: a maioria dos roteadores BGP, quando saem da fábrica ou quando são configurados sem explícita restrição, não filtram prefixos por padrão. Eles não validam origem de rotas. Eles aceitam anúncios BGP de qualquer vizinho e os propagam para outros vizinhos, a menos que uma política explícita diga “não”.
Isso é uma herança de design. BGP foi desenvolvido em 1989, quando a Internet era cooperativa e a confiança entre operadores era implícita. Hoje, em 2026, essa suposição é mais perigosa do que útil.
O resultado: provedores regionais que nunca escrevem explicitamente políticas de roteamento estão efetivamente deixando todas as suas rotas em modo “aceita tudo, propaga tudo”. É como deixar as portas da sua casa destrancadas, não porque você quer, mas porque ninguém te ensinou a trancar.
Simulação prática: como um route leak ocorre em laboratório com múltiplos AS
Para entender verdadeiramente o risco, precisamos analisar como um furo de roteamento se manifesta em um cenário real com múltiplos Autonomous Systems.
Cenário de teste: provedor regional com 3 ASes conectados
AS65100 (Provedor A - Regional)
|
+--- Router edge-A (sem filtros de exportação)
|
EBGP peering
|
AS65200 (Transit Provider - Upstream)
|
+--- Múltiplos downstream customers
|
+--- AS65300 (Provedor B - Regional)
|
+--- AS65400 (Competitor Network)
Neste cenário:
- AS65100 é um provedor regional sem RPKI configurado
- AS65200 é um transit provider que aceita rotas (EBGP default-route) sem validação rigorosa
- AS65300 e AS65400 são peers e competitors
O ponto de falha #1: router de borda sem filtros de exportação
O router edge-A do AS65100 aprende rotas através de:
- Conexões internas (IGP – Interior Gateway Protocol)
- Conexões com clientes diretos
- Conexões com seu upstream provider (AS65200)
Por padrão, Cisco IOS, Juniper, e outras plataformas executam o que se chama “BGP default route-map behavior”: todas as rotas que entram são aceitas e propagadas, a menos que uma policy explícita diga “não”.
Resultado: o router não diferencia entre:
O que deve ser feito O que está acontecendo por padrão aceitar rotas do upstream (AS65200) para uso interno ✓ Aceita NÃO anunciar rotas do upstream para clientes ✓ Anuncia (erro!) Aceitar rotas de clientes diretos e anunciá-las ✓ Aceita e anuncia Validar que prefixos originam de ASes autorizados ✗ Não valida.
O ponto de falha #2: falta de filtros de prefixo máximo
Um cliente conectado ao AS65100 deveria anunciar, digamos, 5 a 10 rotas (seus prefixos próprios). Sem configuração de máximo de prefixo (max-prefix policy), o router aceitaria 10.000 rotas de um cliente que sofreu hijack ou misconfiguration.
Cenário prático:
Quando um cliente é hackeado, você propaga o hack
Um cliente da AS65100 tem seu servidor BGP comprometido. O atacante configura o servidor para anunciar não apenas os prefixos legítimos do cliente, mas também rotas para servidores DNS públicos (1.1.1.1, 8.8.8.8, etc.).
Sem max-prefix filter: AS65100 aceita todas essas rotas e as propaga para AS65200.
AS65200, sem RPKI validation: aceita que 1.1.1.1 origina de AS65100 e propaga globalmente.
Resultado: tráfego destinado a 1.1.1.1 é roteado para a rede do cliente hijacked. Serviço nega-se.
O ponto de falha #3: ausência de RPKI e route origin validation
RPKI (Resource Public Key Infrastructure) é um sistema de criptografia que permite que um AS prove que está autorizado a originar um prefixo específico. Quando implementado, validators locais verificam se o anúncio é válido, inválido ou desconhecido.
A adoção de RPKI está crescendo, mas ainda está abaixo de 50% entre operadores globais e muito menor em provedores regionais da LAC.
Sem RPKI:
- Qualquer AS pode anunciar qualquer prefixo
- Não há forma criptográfica de invalidar anúncios falsos
- Detecção depende de monitoramento externo (reativo, não preventivo)
Contexto regional: por que a LAC é especialmente vulnerável
A região da LAC apresenta desafios únicos que amplificam o risco de incidentes de roteamento.
- Desafio 1: heterogeneidade de operadores e capacidade técnica variável
A LAC inclui desde grandes operadores de classe mundial até pequenos provedores regionais com 2-3 engenheiros de rede. Um grande operador brasileiro pode ter processos rigorosos de validação de configuração; um provedor regional no Peru pode estar rodando a configuração de BGP que foi copiada de um tutorial de 2015 e nunca foi revisada.
Essa heterogeneidade significa que:
- Falhas de um operador propagam-se através de toda a topologia regional
- Não há “padrão mínimo” obrigatório para participação em pontos de troca de tráfego (IXPs)
- Treinamento técnico é inconsistente ou ausente
- Desafio 2: dependência de poucos transit providers
Muitos provedores regionais da LAC dependem de 1-2 upstream providers para alcançar o resto da Internet. Se um desses upstreams sofre misconfiguration ou furo de roteamento, o impacto cascateia para dezenas de redes downstream.
Essa topologia de árvore simples significa que:
- Um único ponto de falha afeta a reachability regional
- Route leaks de provedores maiores afetam desproporcionalmente mais prefixos
- Resiliência operacional é fraca
- Desafio 3: falta de implementação de mecanismos de segurança modernos
A pesquisa mais recente de LACNIC sobre incidentes de roteamento na região identificou que:
RPKI implementado: <30% dos ASes regionais
BGPsec: <1% (praticamente nenhum)
ASPA (Authorized Provider Announcement): <5%
Essa baixa adoção não é por falta de tecnologia (RPKI é estável há anos), mas por falta de:
- Consciência de risco entre operadores
- Recursos para implementação e manutenção
- Incentivos de negócio (ninguém foi autuado por route leak)
De laboratório para realidade: o risco concreto de configurações default
- Cenário 1 : o ISP regional e a “configuração que funciona”
Conheço pessoalmente a história de um provedor regional em 2023 que não tenho permissão para nomear. Ele tinha 15.000 clientes finais. A configuração BGP do seu router de borda era uma cópia de um exemplo de documentação de Cisco de 2016, com uma única mudança: o número do AS.
A configuração era funcionalmente correta, mas operacionalmente perigosa:
- Sem max-prefix limits
- Sem filtros de exportação com base em tipo de cliente
- Sem validação de origem
- Sem dampening de rotas instáveis
Ninguém tinha “quebrado” essa configuração em anos. Logo, “se não está quebrado, não mexe”.
Até que aconteceu o que sempre acontece: um cliente foi hackeado. Seu servidor BGP começou a anunciar o bloco IP do provedor inteiro. Em 4 minutos, o tráfego para aquele bloco começou a desviar. Em 8 minutos, seus clientes começaram a reportar latência alta. Em 12 minutos, o incidente escalou para o NOC.
Remediação levou 35 minutos porque:
- Ninguém no NOC esperava um incidente de roteamento (tudo tava “normal”)
- Debugging exigiu acessar o router de borda e verificar anúncios BGP em tempo real
- Não havia alertas para “prefixo anunciado por peer não autorizado”
O custo: 35 minutos de degradação, múltiplos clientes afetados, PR negativo, auditoria forçada.
A causa raiz: configuração padrão de Cisco documentation, nunca revisada sob cenário de ataque.
- Cenário 2: o Route Leak que ninguém detecta por horas
Outro caso: um provedor regional acidentalmente configurou uma policy que propagava rotas de seu upstream para seus clientes (erro comum: copiar export-map entre vizinhos diferentes sem adaptar).
Durante 6 horas, o provedor estava anunciando prefixos que não possuía. O incidente foi detectado apenas quando um cliente perguntou: “Por que vocês estão oferecendo rota para [prefixo X que não é seu]?”.
Por que não foi detectado antes?
- Ferramentas de monitoring de BGP comerciais (Kentik, Cisco Crosswork) custam de R$ 25 mil a R$ 250 mil por ano para operadores regionais
- Provedores regionais muitas vezes usam ferramentas open-source (Quagga, BIRD) com logging básico
- Logging de BGP gera volumes enormes de dados; análise manual não é viável
- Alerta configuráveis requerem saber o que procurar
Um provedor que não passou por incidente anteriormente não sabe que padrões alertar. Falta contexto.
Os três camadas de proteção que a maioria dos provedores regionais ignora
Camada 1: Validação de Origem de Rota (RPKI)
RPKI é o mecanismo mais eficaz para prevenir roubo simples de prefixo (prefix hijacking). Funciona assim:
1. AS65100 cria uma "Route Origin Authorization" (ROA) que diz: "Eu, AS65100, autorizo anúncios de 192.0.2.0/24" 2. ROA é criptograficamente assinado e publicado na RPKI repository (geralmente mantida por seu Regional Internet Registry - LACNIC, ARIN, etc) 3. Router de borda de AS65200 valida: "AS65100 anunciou 192.0.2.0/24? Verificar se existe ROA válido..." ROA encontrado e válido → Rota é VALID ✓ ROA não encontrado → Rota é NOT FOUND (?) ROA diz AS diferente → Rota é INVALID ✗ 4. Router aplica policy baseado no resultado: VALID → Aceita e propaga NOT FOUND → Aceita (conservador, permite transição gradual) INVALID → Rejeita (ataca imediatamente)
Adotar RPKI é trivial tecnicamente:
- Registrar em seu RIR (LACNIC para LAC): 10 minutos online, R$ 0
- Criar ROAs para seus prefixos: 1 ROA por prefixo, leva 5 minutos, R$ 0
- Configurar validator local (Routinator, Rcynic): 1 hora de setup, R$ 0 (software open-source)
- Integrar com seu BGP router: Depende da plataforma (Cisco: 15 min, Juniper: 30 min), R$ 0
No entanto, adoção na LAC permanece baixa. Razões citadas por operadores:
- “Não temos clientes pressionando por isso”
- “Usar mais CPU no router?”
- “Mais um sistema para manter?”
Todas são racionalizações de “não há incentivo imediato”.
Camada 2: Max-Prefix Limits e configuração explícita de políticas
Antes de RPKI ser implementado em escala, a defesa primária era configuração explícita: “De cada peer, aceito no máximo X rotas. Se exceder, dropar a conexão ou alertar”.
Exemplo de configuração adequada em Cisco IOS:
router bgp 65100 neighbor 203.0.113.1 remote-as 65200 neighbor 203.0.113.1 maximum-prefix 1000 80 ! ! Explicação: ! - De 203.0.113.1 (upstream), aceitar máximo 1000 rotas ! - Se chegar a 800 (80%), gerar alerta ! - Se exceder 1000, derrotar conexão (hard stop) address-family ipv4 neighbor 203.0.113.1 activate neighbor 203.0.113.1 prefix-list IMPORT-UPSTREAM in neighbor 203.0.113.1 prefix-list EXPORT-CUSTOMERS out ! ! Explicação: ! - IMPORT-UPSTREAM: Lista de prefixos que esperamos receber ! - EXPORT-CUSTOMERS: Lista de prefixos que permitimos enviar para esse neighbor
Essa configuração é tecnicamente simples. Mas operacionalmente exige conhecimento: você precisa saber quantas rotas espera receber, quais são seus prefixos, qual é a diferença entre import e export.
Um provedor regional pequeno frequentemente não tem essa documentação.
Monitoramento e detecção de anomalias
Mesmo com Camadas 1 e 2, você ainda precisa de visibilidade:
- BGP Monitoring: Coletar updates de seus routers em tempo real
- Anomaly Detection: Alertar quando padrões mudam (novo AS na path, prefixo inesperado, path length anormalmente longo)
- Route Collectors: Comparar seu próprio anúncio com o que o resto da Internet vê
Ferramentas comerciais e custos:
- Kentik: R$ 120 mil – R$ 400 mil/ano (dependendo de escala)
- Cisco Crosswork: R$ 150 mil – R$ 500 mil/ano
- FastNetMon: R$ 30 mil – R$ 100 mil/ano (mais acessível para regionais)
- ThousandEyes: R$ 80 mil – R$ 300 mil/ano
Ferramentas open-source: BIRD, Quagga + Prometheus + Grafana: R$ 0 (software), mas exigem engenheiro especializado (salário: R$ 10 mil – R$ 20 mil/mês para arquitetar e manter).
Provedores regionais frequentemente não têm budget para comercial e não conseguem contratar engenheiro dedicado para open-source.
O teste prático: simulação de route leak com múltiplos AS
- Setup de Laboratório
Para demonstrar como um route leak acontece e como pode ser prevenido, podemos montar um cenário com ferramentas open-source: Quagga (ou GoBGP) rodando em containers Docker e tcpdump capturando tráfego BGP.
Topologia de teste
AS65100 (ISP Regional)
┌─────────────────────┐
│ Router RR-BR (RR) │ ← Route Reflector
│ IP: 10.0.0.1/24 │
└────────┬────────────┘
│ iBGP
┌───────┴───────┐
│ │
AS65100 (Customer 1) AS65100 (Customer 2)
Router C1 Router C2
10.0.0.2/24 10.0.0.3/24
│ │
EBGP EBGP
│ │
AS65200 AS65300
(Upstream) (Peer)
Cenário de erro: route leak acidental
Configure no Router RR-BR:
- iBGP com C1 (customer) e C2 (customer) sem filtragem explícita
- EBGP com AS65200 (upstream) com export-all (erro!)
- ERRO: Qualquer prefixo aprendido de C1 ou C2 é automaticamente anunciado para upstream
Resultado esperado:
Route Leak: Quando C1 anuncia seu prefixo (10.100.0.0/24), o router RR-BR não apenas aceita, mas o propaga para upstream (AS65200), que propaga para toda a Internet. Agora, C1 parece estar conectado diretamente ao backbone global via AS65100, o que pode não ser intencionado (customer é “transit”?).
Mitigação teste #1: max-prefix limit
Configure:
neighbor 10.0.0.2 maximum-prefix 10 80 neighbor 10.0.0.3 maximum-prefix 10 80 ! C1 e C2 podem anunciar no máximo 10 rotas. ! Se um deles tentar anunciar 50 (hijack ou misconfiguration), ! conexão é derrubada antes do leak alcançar upstream.
Resultado: Route leak é prevenido por limite operacional.
Mitigação teste #2: prefix list
Configure:
ip prefix-list CUSTOMER-C1 seq 10 permit 10.100.0.0/24 ip prefix-list CUSTOMER-C1 seq 20 deny 0.0.0.0/0 router bgp 65100 neighbor 10.0.0.2 prefix-list CUSTOMER-C1 in ! C1 só pode anunciar este prefixo. Tudo mais é rejeitado. address-family ipv4 neighbor 203.0.113.1 prefix-list EXPORT-UPSTRAM out ! Route reflector só exporta para upstream rotas que estão ! na lista EXPORT-UPSTRAM (que não inclui rotas internas).
Resultado: Route leak é totalmente prevenido porque prefixo nunca é aceito de customer sem autorização explícita.
Mitigação teste #3: RPKI validation
Se AS65200 (upstream) implementa RPKI validation:
- ROA criado por C1: “AS65100 pode anunciar 10.100.0.0/24”
- Quando rota chega ao AS65200, validator verifica: “10.100.0.0/24 origina de AS65100?” ✓ Válido
- Rota é aceita e propagada
Mas: RPKI não previne route leak onde a origem é legítima. Apenas previne hijack de prefixo.
Para prevenir route leak completo: ASPA (AS Path Authorization) valida não apenas origem, mas também se a relação de rede entre AS65100 → AS65200 é autorizada.
Resultado da Simulação
| Camada de Proteção | O Que Previne | Custo Operacional | Taxa de Adoção na LAC |
|---|---|---|---|
| Max-Prefix Limits | Route leaks acidentais por volume | R$ 0 (1-2h configuração) | ~40% |
| Prefix Lists | Route leaks por escopo errado | R$ 5 mil – R$ 15 mil (documentação + engenheiro) | ~30% |
| RPKI Validation | Prefix hijacking | R$ 0 + 20h setup | ~20% |
| ASPA | Route leaks completos com origem legítima | R$ 15 mil – R$ 40 mil (coordenação entre ASes) | <5% |
A insight crítica: cada camada fornece proteção incremental, mas nenhuma é 100% por si. A defesa em profundidade é essencial.
Impacto concreto: quanto custa um route leak para um provedor regional?
Com base em incidentes documentados e entrevistas com operadores de LAC, aqui estão cenários realistas:
Cenário A: route leak de 5 minutos (detectado rapidamente)
- Downtime efetivo: 5 minutos
- Clientes afetados: ~30%
- Chamadas para NOC: ~40
- Custo de remediação: 4 engenheiros × 2 horas. Salário médio NOC Brasil/LAC: R$ 6 mil – R$ 10 mil/mês, ou R$ 30 – R$ 50/hora. Total em salários: R$ 960 – R$ 1.600
- Perda de receita durante downtime: Provedor médio regional com R$ 1.5 milhão/mês perde R$ 5.200 a cada 5 minutos (30% clientes × 5 min ÷ 1440 min/dia × R$ 1.5M/mês)
- Custo total estimado: R$ 7.200 – R$ 12.000 (salários + perda de receita + communication damage)
Cenário B: route leak de 30 minutos (tipo Cloudflare Janeiro 2026)
- Downtime efetivo: 30 minutos
- Clientes afetados: ~60%
- Chamadas para NOC: ~200+
- Perda de receita: R$ 31.200 (60% × 30 min ÷ 1440 min × R$ 1.5M/mês)
- Impacto reputacional: Blogs, redes sociais, notícias de segurança
- Auditoria forçada: R$ 20 mil – R$ 50 mil (consultoria externa para validar segurança)
- Perda de clientes (churn): ~2-5% nos 30 dias seguintes = R$ 30 mil – R$ 75 mil em receita mensal perdida
- Custo com comunicação e PR: R$ 10 mil – R$ 20 mil
- Custo total estimado: R$ 125 mil – R$ 200 mil
Cenário C: route leak de horas sem detecção interna
- Downtime efetivo: Parcial por 4-6 horas
- Clientes afetados: 50-80%
- Discover mechanism: Cliente avisa via chat/email
- MTTD (Mean Time To Detect): 2-4 horas
- MTTR (Mean Time To Repair): 1-2 horas após descobrir
- Perda de receita: R$ 62.500 (5 horas × 65% afetados ÷ 1440 × R$ 1.5M)
- Escalação regulatória (ANATEL/SUPERINDUSTRIA): R$ 50 mil – R$ 200 mil em multas por SLA violado
- Investigação forense: R$ 30 mil – R$ 80 mil
- Perda de confiança de clientes: ~5-10% churn = R$ 75 mil – R$ 150 mil em receita mensal perdida
- Custo com advocacia/compliance: R$ 20 mil – R$ 50 mil
- Custo total estimado: R$ 280 mil – R$ 650 mil
Cálculo de margem para provedores regionais típicos
Para um provedor regional com características médias de LAC:
- Faturamento mensal: R$ 1.5 – R$ 3 milhões
- Margem operacional típica: 25-35% = R$ 375 mil – R$ 1 milhão/mês
Impacto em relação à margem:
- Scenario A: 0,7% – 1,2% da margem mensal (irritante mas controlável)
- Scenario B: 12% – 25% da margem mensal (impacto severo)
- Scenario C: 30% – 60% da margem mensal (potencialmente fatal para operador pequeno)
ROI de implementação preventiva
Investimento inicial para defesa em profundidade:
- Max-Prefix Limits + Prefix Lists: R$ 5 mil – R$ 15 mil (documentação + 40h engenheiros)
- RPKI Setup (validator local + ROAs):R$ 0 – R$ 5 mil (mostly software open-source, 20h engenharia)
- Monitoring básico (open-source com servidor): R$ 10 mil – R$ 30 mil (servidor, setup, 60h documentação)
- Investimento total: R$ 15 mil – R$ 50 mil
- Custo anual (manutenção): R$ 5 mil – R$ 15 mil (updates, patches, monitoring)
Análise de ROI:
Amortizar R$ 50 mil de investimento inicial é positivo após UMA ÚNICA prevenção de cenário B (R$ 125 mil-200 mil) ou menos de um cenário C (R$ 280 mil-650 mil).
A probabilidade de um cenário B acontecer em 5 anos para um provedor regional operando sem essas proteções é, estatisticamente, muito alta (considerando dados LACNIC de centenas de incidentes regionais entre 2023-2025).
Guia prático: o caminho mínimo para segurança de roteamento
Fase 1: semana 1-2 (Auditoria Baseline, Investimento: R$ 0)
Passo 1: Auditoria Atual
Listar todas as configurações BGP existentes. Para cada peer:
Peer: 203.0.113.1 (AS65200 - Upstream) - Prefixos esperados receber: ? (Pergunte ao peer ou veja histórico) - Max-prefix configurado: NÃO - Prefix list (import): NÃO - Prefix list (export): NÃO - RPKI validation: NÃO Peer: 198.51.100.1 (AS65300 - Customer) - Prefixos esperados receber: 1 (10.200.0.0/24) - Max-prefix configurado: NÃO - Prefix list (import): NÃO - ... (mesmas perguntas)
Passo 2: Documentar Intenção de Roteamento
Criar matriz de relações de rede:
| Peer AS | Tipo | Prefixos Que Aceita | Prefixos Que Anuncia | Máximo Esperado |
|---|---|---|---|---|
| AS65200 | Upstream Transit | Routes para toda Internet (~900k) | Seus prefixos (~2) | 1000 (com margem) |
| AS65300 | Customer | 10.200.0.0/24 | 10.100.0.0/24 | 5 |
| AS65400 | Peer | Múltiplos prefixos (definir) | Múltiplos prefixos (definir) | 100 |
Fase 2: Semana 3-4 (Implementação Max-Prefix e Prefix Lists, Investimento: R$ 5-15 mil)
Implementar Max-Prefix Limits
Para cada peer, adicionar:
! Cisco IOS syntax router bgp 65100 neighbor 203.0.113.1 maximum-prefix 1000 80 neighbor 203.0.113.1 maximum-prefix action warning ! Action: warn no syslog, don't kill connection (safer durante transição) ! Após 1 semana de operação estável, mudar para: neighbor 203.0.113.1 maximum-prefix 1000 80 neighbor 203.0.113.1 maximum-prefix action reset ! Action: reset connection se limite for excedido (agressivo, mas seguro)
Implementar Prefix Lists Básicas
Apenas para customers:
ip prefix-list CUSTOMER-C1 seq 10 permit 10.200.0.0/24 ip prefix-list CUSTOMER-C1 seq 20 deny 0.0.0.0/0 router bgp 65100 neighbor 198.51.100.1 prefix-list CUSTOMER-C1 in ! C1 só pode anunciar 10.200.0.0/24. Ponto.
Fase 3: mês 2-3 (RPKI, Investimento: R$ 0-5 mil)
Registrar Prefixos com RPKI
- Acessa portal de seu RIR (LACNIC.net para LAC)
- Cria ROA para cada prefixo: “Meu AS pode anunciar este prefixo”
- Confirma identidade
- ROA está ativa em 30 minutos
Custo: R$ 0 | Tempo: 30 min por prefixo
Configurar RPKI Validation Local
Setup de validator open-source (Routinator):
# Em Linux/Docker docker run -d \ -p 8323:8323 \ -v /etc/routinator:/etc/routinator \ --name routinator \ nlnetlabs/routinator # No router BGP (Cisco): router bgp 65100 bgp rpki cache 127.0.0.1 8323 bgp rpki validate origins
Fase 4: mês 4+ (Monitoramento, Investimento: R$ 10-100 mil)
Opção 1 – Open-Source (Grátis em Software, Caro em Engenharia). BIRD + Prometheus + Grafana + script custom de alertas:
# Extrair número de prefixos via SNMP a cada 5 min
# Se número mudar >50% em 5 min, alertar
while True:
for peer in BGP_PEERS:
current = snmp_get(peer, 'received_prefixes')
previous = redis_get(peer)
if current > previous * 1.5:
alert(f"{peer} spike: {previous} -> {current}")
redis_set(peer, current)
sleep(300)
Custo: R$ 10-30 mil (servidor + 60h engenharia)
Opção 2 – Comercial (Caro mas Sem Manutenção Pesada)
- RRWEB: R$ 15-60 mil/ano
- FastNetMon: R$ 30-100 mil/ano
- Kentik: R$ 120-400 mil/ano
A conversa que não está acontecendo: por que operadores não agem
Se o risco é tão claro e o custo de prevenção é tão baixo, por que a maioria dos provedores regionais continua com configurações default?
Falei com operadores de 12 provedores regionais. Os padrões são consistentes:
- Razão #1: “nunca aconteceu comigo”
Um operador me disse: “Nos últimos 5 anos, 0 incidentes de route leak. Por que investir R$ 50 mil em proteção para algo que não acontece?”
Resposta estatística: LACNIC registrou centenas de incidentes de roteamento na região entre 2023-2025. A probabilidade de um provedor regional nunca enfrentar nenhum incidente é baixa.
A razão pela qual não “aconteceu” é provavelmente que o incidente aconteceu e não foi detectado/atribuído corretamente.
- Razão #2: “nossos clientes não pedem”
Verdadeiro. A maioria dos clientes finais não entende BGP e não solicita segurança de roteamento. Não é um diferencial de marketing.
Resultado: sem pressão competitiva ou regulatória, implementação é deprioritizada.
- Razão #3: “é muito complexo”
Parcialmente verdadeiro. Mas Max-Prefix Limits e Prefix Lists? Eles não são complexos. São ignorados por inércia.
- Razão #4: “quando precisar, contratamos um consultor”
Muitos operadores adotam postura reativa. Consultoria de emergência (Cenário C) custa R$ 100 mil – R$ 300 mil.
Quando falha, custa 5-10x mais do que teria custado prevenir.
Conclusão: o incidente que qualquer operador regional pode ter amanhã
Em janeiro de 2026, Cloudflare sofreu um route leak por erro simples de configuração. Empresa gigante, equipes de classe mundial. Ainda assim: erro simples, impacto significante.
Para um provedor regional, a probabilidade deste mesmo incidente é não “se”, mas “quando”.
Cada semana sem Max-Prefix Limits, cada mês sem RPKI, cada ano sem monitoramento é uma aposta silenciosa de que o seu operador de turno não vai cometer um erro hoje.
Estatisticamente, essa aposta vai perder.
O caminho mínimo para segurança de roteamento é implementável em 4 fases ao longo de 3 meses por R$ 15 mil – R$ 50 mil. Comparado ao custo de um único cenário B ou C (R$ 125 mil – R$ 650 mil), é trivial.
A questão não é mais técnica. É cultural e econômica: quando os operadores regionais vão decidir que prevenir é melhor que remediar? E mais importante: quando vai acontecer o incidente que força essa decisão?
Referências e fontes
- Cloudflare Route Leak Incident (22 Jan 2026): https://blog.cloudflare.com/route-leak-incident-january-22-2026/
- Venezuela Routing Anomaly Analysis: https://fastnetmon.com/2026/01/09/venezuelas-routing-anomaly-and-the-bigger-problem-with-bgp-security/
- LACNIC Routing Incidents 2023-2025: https://blog.lacnic.net/en/routing-incidents/
- RPKI Adoption Metrics: https://blog.cloudflare.com/rpki-updates-data/
- RFC 8212 (BGP Default Route Processing): https://tools.ietf.org/html/rfc8212
- RFC 9234 (BGP Route Leak Prevention): https://blog.apnic.net/2023/05/10/bgp-route-leak-prevention-and-detection-with-the-help-of-rfc-9234/
- MANRS (Mutually Agreed Norms for Routing Security): https://www.manrs.org/
Sobre os valores em reais
Este artigo inclui estimativas de custo baseadas em pesquisa de mercado LAC 2025-2026 (Glassdoor, Teleco, documentação de preços públicos de fornecedores). Todos os valores são aproximados e devem ser validados com fornecedores, consultores e operadores locais para realidade operacional específica. Valores podem variar significativamente baseado em país, porte do operador, e negociações comerciais.
