O Problema
Depois dos diversos problemas de sequestro de prefixos BGP na Internet - como o famoso caso YouTube versus Pakistan Telecom - as ferramentas de monitoração de prefixos BGP, gratuitas ou pagas, ganharam mais visibilidade entre os administradores de rede ao redor do mundo. E nesta última terça-feira, 11 de novembro às 2:00 horas GMT, uma destas ferramentas começou a disparar inúmeros alertas alegando que o AS16735 havia sequestrado uma grande quantidade de prefixos (mais de 50% dos prefixos existentes na Internet). Veja um exemplo do alerta gerado pelo BGPmon:
You Receive this email because you are subscribed to BGPmon.net.
For more details about these updates please visit:
http://bgpmon.net/showupdates.php
Possible Prefix Hijack (Code: 11)
1 number of peer(s) detected this updates for your prefix
10.10.80.0/20:
Update details: 2008-11-11 02:24 (UTC)
10.10.80.0/20
Announced by: AS16735 (Companhia de Telecomunicacoes do
Brasil Central)
Transit AS: 27664 (CTBC Multimídia)
ASpath: 27664 16735
=====================
Como os administradores que receberam estes alertas não conseguiram alcançar o AS16735, logo assumiram que o sequestro realmente tinha acontecido, já que ao verificar a situação dos prefixos sequestrados no
RIS (ferramenta do
RIPE) ou no
looking glass do
PTT-Metro, também constataram que o
AS-path (
27664 16735 ou ainda
22548 16735) não estava correto.
Os FatosO primeiro fato interessante é que tanto o AS27664 e quanto o AS22548 são clientes de trânsito do AS16735 e os dois primeiros (AS27664 e o AS22548) estão alimentando com a tabela BGP completa o projeto RIS do RIPE no PTT-Metro (rrc15). Isso significa que tanto para o RIS quanto para o BGPmon (que utiliza as informações do RIS para monitorar e gerar os alertas) ínumeros prefixos da tabela BGP passaram a ser anunciados pelo AS16735 - o que comumente é conhecido como
leaking (ou vazamento) da tabela BGP. Já que o AS16735 não possui autoridade administrativa sobre estes prefixos, podemos supor então que houve um re-anúncio da tabela BGP, este último causado por algum problema interno ao AS16735.
Esse sequestro de prefixos, no entanto, não foi percebido em nenhum outro ponto da Internet - ficando restrito ao AS16735 e seus clientes, como é o caso do AS27664 e AS22548 - graças aos filtros existentes na maioria dos sistemas autônomos ou grandes operadoras de telecomunicações. Ainda de acordo com as análises do
BGPmon e da
Renesys, este problema durou aproximadamente 5 minutos. Mas, mesmo depois deste período, muitos outros sistemas autônomos continuaram não alcançando a rede do AS16735, pois grande parte do AS16735 não estava acessível em razão de outros problemas. E este último fato aumentou consideravelmente o
burburinho sobre este problema.
As Lições AprendidasA primeira grande lição é não confiar somente em uma fonte de informação, como foi o caso de
muita gente. Para ter certeza do problema, verifique a informação nos mais diversos servidores de
looking glass espalhados pelo mundo. Como exemplo, o primeiro
looking glass que eu verifiquei naquela madrugada, sequer soube da existência do AS16735 no caminho destes inúmeros prefixos... Mesmo assim, esse tipo de problema não deve ser subestimado.
É interessante também utilizar vários sistemas de monitoração e verificação dos prefixos na tabela BGP da Internet, desde que estes sistemas sejam alimentados por fontes de informação diferentes (esse não foi o caso do RIS, BGPmon ou do Looking Glass do PTT-Metro). Alguns exemplos de ferramentas disponíveis para verificação são:
Internet Alert Registry,
WatchMY.net,
BGPmon e
PHAS.
Por último (e já não tão relacionado com o que acabei de descrever) fica a dica de uma ferramenta (ainda beta) para
visualização mais amigável das informações colhidas pelo projeto RIS e pode ser acessada da
página principal do projeto, entrando com a informação de número de AS ou prefixo próximo ao canto superior direito.
Tela da ferramenta de visualização do RIS/RIPE.Ontem a noite, algumas horas depois de terminar este
post,
Danny McPherson publicou no blog da
Arbor Networks uma análise muito semelhante a exposta acima, no entanto, ele acrecentou um ponto que eu também gostaria de destacar aqui:
Toda esta confusão só poderá ser evitada com a utilização de uma solução
segura para roteamento entre-domínios (ou sistemas autônomos). E este padrão está em fase de desenvolvimento dentro do
IETF, mais especificamente através do grupo
SIDR (
Secure Inter-Domain Routing). Queria destacar também a apresentação do
Ricardo Patara (do LACNIC) na última reunião do GTER sobre este tema. Vale a pena dar uma olhada!
Mais informações em:
Mais informações em:
