A empresa Cloudflare relatório sobre o incidente de ontem, que resultou em de 13:34 a 16:26 (MSK) foram observados problemas de acesso a muitos recursos na rede global, incluindo a infraestrutura da Cloudflare, Facebook, Akamai, Apple, Linode e Amazon AWS. Os problemas na infraestrutura da Cloudflare, que fornece CDN para 16 milhões de sites, de 14:02 a 16:02 (MSK). Segundo a Cloudflare, durante a falha, foi registrada uma perda de aproximadamente 15% do tráfego global.
O problema estava vazamento de rotas através do BGP, durante o qual cerca de 20 mil prefixos para 2400 redes foram redirecionados incorretamente. A fonte do vazamento foi o provedor DQE Communications, que utilizou o software para otimizar o roteamento. O BGP Optimizer divide prefixos IP em partes menores, por exemplo, divide 104.20.0.0/20 em 104.20.0.0/21 e 104.20.8.0/21, e, como resultado, a DQE Communications manteve um grande número de rotas específicas do lado dela, redefinindo rotas mais gerais (ou seja, em vez de usar rotas gerais para a Cloudflare, foram utilizadas rotas mais granulares para sub-redes específicas da Cloudflare).
Essas rotas específicas foram anunciadas a um de seus clientes (Allegheny Technologies, AS396531), que também tinha conectividade através de outro provedor. A Allegheny Technologies retransmitiu as rotas recebidas para outro provedor de trânsito (Verizon, AS701). Devido à falta de filtragem adequada dos anúncios BGP e à limitação do número de prefixos, a Verizon captou esse anúncio e retransmitiu os 20 mil prefixos recebidos para o restante da internet. Os prefixos incorretos, devido à sua granularidade, foram considerados como mais prioritários, pois uma rota específica tem prioridade mais alta do que uma rota geral.
Como resultado, o tráfego para muitas grandes redes passou a ser direcionado pela Verizon para o pequeno provedor DQE Communications, incapaz de lidar com o fluxo elevado, o que levou ao colapso (o efeito é comparável ao que aconteceria se uma parte de uma autoestrada congestionada fosse substituída por uma estrada de terra).
Para evitar a ocorrência de incidentes semelhantes no futuro,
:
- Usar dos anúncios com base no RPKI (Validação de Origem BGP, que permite a aceitação de anúncios apenas de proprietários de rede);
- Limitar o número máximo de prefixos aceitos para todas as sessões EBGP (a configuração maximum-prefix ajudaria a descartar imediatamente a transmissão de 20 mil prefixos em uma única sessão);
- Aplicar filtragem com base no registro IRR (Internet Routing Registry, que define os AS pelos quais a roteação de prefixos específicos é permitida);
- Utilizar nas routers as configurações recomendadas no RFC 8212 para bloqueio por padrão (‘default deny’);
- Interromper o uso imprudente de otimizadores BGP.
Fonte: opennet.ru
