A infraestrutura da internet sofreu um pequeno abalo no passado dia 22 de janeiro, quando um erro de configuração resultou numa fuga de rotas BGP (Border Gateway Protocol). A situação, que durou cerca de 25 minutos, afetou principalmente o tráfego IPv6, causando congestionamento mensurável e a perda de aproximadamente 12 Gbps de dados que foram descartados.
O sistema BGP funciona como o "GPS" da internet, ajudando a encaminhar dados através de diferentes redes, conhecidas como sistemas autónomos (AS), até ao seu destino final. Quando ocorre uma fuga de rotas, como neste caso, uma rede anuncia incorretamente aos seus pares que é o caminho ideal para determinado tráfego, violando as regras de encaminhamento estabelecidas. O resultado é que o tráfego é enviado por caminhos instáveis ou, em situações onde existem filtros de segurança, acaba por ser totalmente bloqueado e perdido.
Uma configuração errada com impacto global
Segundo a explicação técnica publicada pela Cloudflare, a origem do problema foi uma alteração de política num router localizado em Miami. A intenção era impedir que esse nó anunciasse prefixos IPv6 de Bogotá, mas a remoção de listas de prefixos específicas tornou a política de exportação demasiado permissiva.
Isto fez com que a rede aceitasse todas as rotas internas IPv6 e as exportasse para redes externas. Na prática, a empresa começou a redistribuir rotas dos seus pares e fornecedores de volta para outros pares e fornecedores em Miami, criando o que tecnicamente se designa por fugas de rota de Tipo 3 e Tipo 4. Este erro não afetou apenas os clientes diretos da empresa, tendo impacto também em redes externas que viram o seu tráfego ser desviado incorretamente.
Embora estes incidentes causem primariamente problemas de fiabilidade e velocidade, existe também uma dimensão de segurança, uma vez que o desvio de tráfego pode, em teoria, ser usado para intercetar comunicações, embora neste caso tenha sido puramente acidental.
Resolução rápida e medidas preventivas
As equipas de engenharia da Cloudflare detetaram o problema pouco tempo após o seu início. Para mitigar o impacto, reverteram manualmente a configuração problemática e pausaram os sistemas de automação, conseguindo estancar a fuga de rotas em 25 minutos. Posteriormente, o código que desencadeou a falha foi corrigido e a automação foi reativada com segurança.
A gigante da tecnologia admite que este caso partilha semelhanças com um incidente ocorrido em julho de 2020 e delineou várias medidas para evitar que a história se repita. Entre as ações futuras, a empresa planeia implementar salvaguardas de exportação mais rigorosas baseadas na comunidade, melhorar as verificações de erros nas políticas de CI/CD e promover a adoção de normas de segurança mais robustas como o RPKI ASPA.
Nenhum comentário
Seja o primeiro!