Como resultado de um anúncio errado do BGP, mais de 8800 prefixos de redes estrangeiras através da rede Rostelecom, o que levou a um colapso de curto prazo no roteamento, interrupção da conectividade da rede e problemas de acesso a alguns serviços em todo o mundo. Problema mais de 200 sistemas autônomos de propriedade de grandes empresas de Internet e redes de distribuição de conteúdo, incluindo Akamai, Cloudflare, Digital Ocean, Amazon AWS, Hetzner, Level3, Facebook, Alibaba e Linode.
O anúncio errôneo foi feito pela Rostelecom (AS12389) no dia 1º de abril às 22h28 (MSK), depois foi captado pelo provedor Rascom (AS20764) e mais adiante na cadeia se espalhou para Cogent (AS174) e Level3 (AS3356) , cujo campo abrangia quase todos os provedores de Internet de primeiro nível (). O BGP notificou prontamente a Rostelecom sobre o problema, então o incidente durou cerca de 10 minutos (de acordo com os efeitos foram observados durante cerca de uma hora).
Este não é o primeiro incidente envolvendo um erro por parte da Rostelecom. Em 2017, dentro de 5 a 7 minutos via Rostelecom redes dos maiores bancos e serviços financeiros, incluindo Visa e MasterCard. Em ambos os incidentes, a origem do problema parece ser trabalhos relacionados à gestão de tráfego, por exemplo, pode ocorrer vazamento de rotas na organização do monitoramento interno, priorização ou espelhamento do tráfego que passa pela Rostelecom para determinados serviços e CDNs (devido ao aumento da carga da rede devido ao trabalho em massa de casa no final de Marchar a questão da redução da prioridade do tráfego de serviços estrangeiros em favor de recursos nacionais). Por exemplo, há vários anos, foi feita uma tentativa no Paquistão As sub-redes do YouTube na interface nula levaram ao aparecimento dessas sub-redes nos anúncios do BGP e ao fluxo de todo o tráfego do YouTube para o Paquistão.
É interessante que na véspera do incidente com a Rostelecom, o pequeno provedor “Nova Realidade” (AS50048) da cidade. através da Transtelecom foi 2658 prefixos afetando Orange, Akamai, Rostelecom e as redes de mais de 300 empresas. O vazamento da rota resultou em diversas ondas de redirecionamentos de tráfego que duraram vários minutos. No seu auge, o problema afetou até 13.5 milhões de endereços IP. Uma perturbação global notável foi evitada graças ao uso de restrições de rota pela Transtelecom para cada cliente.
Incidentes semelhantes ocorrem na Internet e continuarão até que sejam implementados em todos os lugares Anúncios BGP baseados em RPKI (BGP Origin Validation), permitindo o recebimento de anúncios apenas dos proprietários da rede. Sem autorização, qualquer operador pode anunciar uma sub-rede com informações fictícias sobre o comprimento da rota e iniciar o trânsito por si mesmo de parte do tráfego de outros sistemas que não aplicam filtragem de anúncios.
Ao mesmo tempo, no incidente em consideração, uma verificação utilizando o repositório RIPE RPKI revelou-se . Por coincidência, três horas antes do vazamento da rota BGP na Rostelecom, durante o processo de atualização do software RIPE, 4100 registros ROA (autorização de origem de rota RPKI). O banco de dados foi restaurado apenas no dia 2 de abril, e durante todo esse tempo a verificação ficou inoperante para clientes RIPE (o problema não afetou os repositórios RPKI de outros registradores). Hoje RIPE tem novos problemas e repositório RPKI em 7 horas .
A filtragem baseada em registro também pode ser usada como solução para bloquear vazamentos (Internet Routing Registry), que define sistemas autônomos através dos quais o roteamento de prefixos especificados é permitido. Ao interagir com pequenos operadores, para reduzir o impacto de erros humanos, você pode limitar o número máximo de prefixos aceitos para sessões EBGP (a configuração de prefixo máximo).
Na maioria dos casos, os incidentes são o resultado de erros acidentais de pessoal, mas recentemente também ocorreram ataques direcionados, durante os quais os invasores comprometem a infraestrutura dos provedores. и tráfego para sites específicos através da organização de um ataque MiTM para substituir as respostas DNS.
Para dificultar a obtenção de certificados TLS durante esses ataques, a autoridade certificadora Let's Encrypt para verificação de domínio de múltiplas posições usando diferentes sub-redes. Para contornar esta verificação, um invasor precisará realizar simultaneamente o redirecionamento de rotas para vários sistemas autônomos de provedores com diferentes uplinks, o que é muito mais difícil do que redirecionar uma única rota.
Fonte: opennet.ru