Compania Cloudflare raportul incidentului de ieri, care a cauzat între 13:34 și 16:26 (MSK), au fost probleme de acces la multe resurse din rețeaua globală, inclusiv infrastructura Cloudflare, Facebook, Akamai, Apple, Linode și Amazon AWS. Problemele în infrastructura Cloudflare, care oferă CDN pentru 16 milioane de site-uri, între 14:02 și 16:02 (MSK). Potrivit evaluării Cloudflare, în timpul întreruperii s-a înregistrat o pierdere de aproximativ 15% din traficul global.
Problema a fost o scurgere de rute prin BGP, în timpul căreia aproximativ 20.000 de prefixe pentru 2400 de rețele au fost redirecționate incorect. Sursa scurgerii a fost furnizorul DQE Communications, care a folosit software-ul pentru optimizarea rutelor. BGP Optimizer împarte prefixele IP în unități mai mici, de exemplu, împarte 104.20.0.0/20 în 104.20.0.0/21 și 104.20.8.0/21, și, ca rezultat, DQE Communications a păstrat de partea sa un număr mare de rute specifice, care redefineau rutele mai generale (adică, în loc de rutele generale către Cloudflare, au fost utilizate rute mai granularizate către subneturi specifice Cloudflare).
Aceste rute punctuale au fost anunțate unui client (Allegheny Technologies, AS396531), care avea, de asemenea, o conexiune printr-un alt furnizor. Allegheny Technologies a transmis rutele primite unei alte companii de tranzit (Verizon, AS701). Din lipsa unei filtrări adecvate a anunțurilor BGP și a limitării numărului de prefixe, Verizon a preluat acest anunț și a transmis cele 20.000 de prefixe primite pentru restul internetului. Prefixele incorecte, datorită granularității lor, au fost percepute ca fiind mai prioritare, deoarece ruta specifică are o prioritate mai mare decât cea generală.
Ca urmare, traficul pentru multe rețele mari a fost direcționat prin Verizon către un furnizor mic, DQE Communications, incapabil să gestioneze fluxul masiv, ceea ce a dus la un colaps (efectul este comparabil cu acela în care o parte dintr-o autostradă aglomerată este înlocuită cu o cale de țară).
Pentru a preveni apariția unor incidente similare în viitor,
:
- Utilizați anunțurilor pe baza RPKI (BGP Origin Validation, permite acceptarea anunțurilor doar de la proprietarii rețelei);
- Limitarea numărului maxim de prefixe acceptate pentru toate sesiunile EBGP (setarea maximum-prefix ar ajuta imediat să respingă transmiterea celor 20.000 de prefixe într-o singură sesiune);
- Aplicați filtrarea pe baza registrului IRR (Internet Routing Registry, care determină AS-urile prin care este permisă rutarea prefixelor specificate);
- Utilizați pe routere setările recomandate în RFC 8212 pentru blocarea implicită (‘default deny’);
- Opriți utilizarea nechibzuită a optimizatorilor BGP.
Sursa: opennet.ro
