BGP para ISPs: os 7 erros de configuração mais custosos (e como evitá-los)
BGP — Border Gateway Protocol — é o protocolo de roteamento que sustenta a internet. Para um ISP, também é o protocolo cuja má configuração pode causar os incidentes mais custosos, mais visíveis e mais difíceis de justificar diante de um cliente.
Diferente de um servidor fora do ar ou um enlace físico quebrado, um incidente BGP pode propagar efeitos muito além da sua rede. Em casos extremos, pode afetar outros ISPs, chegar à imprensa especializada e gerar responsabilidades legais.
Este artigo documenta os sete erros de configuração BGP que vemos com maior frequência em ISPs da América Latina, suas consequências e as medidas concretas para evitá-los.
Erro 1: Não filtrar prefixos recebidos de clientes (sem prefix-lists)
O problema: Aceitar todos os prefixos que um cliente anuncia sem validar se realmente lhe pertencem.
Consequência: Um cliente — por erro ou má intenção — pode anunciar prefixos que não lhe pertencem. Se sua rede os aceita e repropaga, você participa de um route hijack. As consequências vão desde afetar a conectividade de terceiros até aparecer em blocklists de operadores.
A solução: Implementar prefix-lists explícitos por cada sessão BGP com clientes, permitindo apenas os prefixos atribuídos a esse cliente. Combinar com filtragem IRR (Internet Routing Registry) e RPKI para validação criptográfica de origem.
! Ejemplo Cisco IOS
ip prefix-list CLIENTE-ASN65001-IN seq 5 permit 203.0.113.0/24
!
router bgp 65000
neighbor 192.168.1.1 prefix-list CLIENTE-ASN65001-IN in
Erro 2: Não filtrar prefixos enviados a upstreams (route leaks)
O problema: Propagar para seus upstreams rotas aprendidas de clientes ou peers sem filtrá-las.
Consequência: Um route leak pode fazer sua rede virar trânsito involuntário entre duas redes, saturando seus enlaces e potencialmente causando incidentes em escala global. Alguns dos apagões de internet mais notórios dos últimos anos (incluindo o famoso incidente da Cloudflare em 2019) tiveram route leaks como causa ou amplificador.
A solução: Implementar comunidades BGP para marcar a origem de cada prefixo e usar políticas de exportação explícitas. Para upstreams, exportar apenas prefixos próprios (originados no seu AS) e os de clientes que pagam por trânsito.
Erro 3: Não ter max-prefix configurado em sessões de peering
O problema: Não estabelecer um limite máximo de prefixos aceitos por sessão BGP.
Consequência: Se um peer sofre um problema de configuração e passa a anunciar dezenas de milhares de prefixos inesperados, seu roteador pode saturar a tabela de roteamento, consumir toda a CPU processando atualizações ou simplesmente colapsar.
A solução: Configurar maximum-prefix em cada sessão BGP com um limite razoável e uma ação definida (alerta primeiro, depois tear-down):
! Cisco IOS
router bgp 65000
neighbor 10.0.0.1 maximum-prefix 1000 80
O valor 80 gera alerta ao atingir 80% do limite antes de encerrar a sessão. Calibre o limite conforme o que você espera receber de cada peer.
Erro 4: Não implementar RPKI (Resource Public Key Infrastructure)
O problema: Confiar em anúncios BGP sem validação criptográfica de que o AS de origem tem autorização para anunciar aquele prefixo.
Consequência: Sua rede fica vulnerável a ataques de route hijacking em que um AS malicioso ou mal configurado anuncia prefixos que não lhe pertencem. Seu tráfego — e o dos seus clientes — pode ser desviado para destinos incorretos.
A solução: Implementar um validador RPKI (Routinator, OctoRPKI, Fort) e configurar seus roteadores para rejeitar prefixos com estado INVALID. É um dos avanços mais importantes em segurança de roteamento dos últimos anos e o custo de implementação é relativamente baixo.
! Ejemplo de política en JunOS
policy-statement RPKI-POLICY {
term INVALID {
from {
protocol bgp;
validation-database invalid;
}
then reject;
}
}
Erro 5: Sessões BGP sem autenticação MD5
O problema: Estabelecer sessões BGP sem autenticação TCP-MD5.
Consequência: Um atacante na rede pode tentar injetar pacotes TCP forjados para manipular ou encerrar sessões BGP. Embora o vetor exija acesso à rede de transporte, em ambientes compartilhados (IX, colocation) é um risco real.
A solução: Configurar autenticação MD5 em todas as sessões eBGP. É medida básica com custo de implementação quase nulo.
Erro 6: Não monitorar o estado das sessões BGP em tempo real
O problema: Só descobrir que uma sessão BGP caiu quando um cliente liga dizendo que não tem conectividade.
Consequência: Tempo de detecção elevado = MTTR elevado = descumprimento de SLA = penalidades e perda de confiança.
A solução: Monitoramento ativo de sessões BGP com alertas imediatas. Ferramentas como Zabbix, Prometheus com alertas via PagerDuty/Telegram, ou sistemas especializados como pmacct ou GoBGP para análise de roteamento. Os alertas devem chegar em segundos, não em minutos.
Um ISP que opera com NOC 24/7 tem visibilidade de todas as sessões BGP em um painel centralizado, com escalonamento automático quando uma sessão cai.
Erro 7: Não documentar a política de roteamento
O problema: A política de roteamento existe na cabeça de um ou dois engenheiros, sem documentação formal.
Consequência: Em um incidente, o engenheiro que “sabe como funciona” pode não estar disponível. Mudanças de configuração feitas sem entender a política completa podem ter efeitos inesperados. (De novo, o problema do herói técnico que descrevemos aqui.)
A solução: Documentar em um SSOT (Single Source of Truth) a política de roteamento da organização: quais prefixos se aceita de cada tipo de peer, quais comunidades se usam e com que significado, quais filtros existem e por quê. Essa documentação deve estar em controle de versões (Git) e atualizada a cada mudança.
A perspectiva operativa
BGP é um protocolo que pouco perdoa. Uma configuração incorreta pode ter consequências muito além da sua rede. Mas também é um protocolo em que as melhores práticas estão bem documentadas e acessíveis: MANRS (Mutually Agreed Norms for Routing Security), documentos da LACNIC e ARIN, a comunidade NANOG.
O desafio para um ISP não é falta de informação: é ter tempo, time e processos para implementar essas práticas em operação em curso, sem interromper o serviço. Nossos serviços de engenharia de redes são desenhados exatamente para esse contexto.
Quer auditar a segurança BGP da sua rede?
Na Ayuda.LA fazemos revisões de configuração BGP e políticas de roteamento para ISPs na América Latina. Se quiser avaliar o estado da sua rede frente a essas melhores práticas, podemos fazer uma revisão sem compromisso.
Este artigo faz parte da nossa série sobre operações de rede para ISPs. Se quiser receber os próximos textos, acompanhe-nos no LinkedIn.