Het bedrijf Cloudflare rapport over het incident van gisteren, waarbij gedurende vanaf 13:34 tot 16:26 (MSK) problemen werden waargenomen met de toegang tot veel bronnen op het wereldwijde web, waaronder de infrastructuur van Cloudflare, Facebook, Akamai, Apple, Linode en Amazon AWS. Problemen in de infrastructuur van Cloudflare, die CDN-diensten biedt voor 16 miljoen websites, van 14:02 tot 16:02 (MSK). Volgens Cloudflare was er tijdens de storing ongeveer 15% van het wereldwijde verkeer verloren.
Het probleem was een route-lek via BGP, waarbij ongeveer 20.000 prefixen voor 2400 netwerken verkeerd omgebogen werden. De bron van het lek was de provider DQE Communications, die gebruik maakte van software voor voor optimalisatie van de routing. BGP Optimizer splitst IP-prefixen in kleinere delen, bijvoorbeeld van 104.20.0.0/20 naar 104.20.0.0/21 en 104.20.8.0/21, waardoor DQE Communications een groot aantal specifieke routes aan zijn kant had die meer algemene routes overschreven (d.w.z. in plaats van algemene routes naar Cloudflare werden meer gedetailleerde routes naar specifieke subnetten van Cloudflare gebruikt).
Deze specifieke routes werden aangekondigd aan een van de klanten (Allegheny Technologies, AS396531), die ook verbinding had via een andere provider. Allegheny Technologies zond de ontvangen routes door naar een andere transitprovider (Verizon, AS701). Door het ontbreken van adequate filtering van BGP-aankondigingen en limieten voor het aantal prefixen, nam Verizon deze aankondiging over en zond de ontvangen 20.000 prefixen naar de rest van het internet. De onjuiste prefixen werden vanwege hun granulariteit als meer prioritair gezien, aangezien een specifieke route een hogere prioriteit heeft dan een algemene route.
Uiteindelijk werd het verkeer voor veel grote netwerken omgeleid via Verizon naar de kleine provider DQE Communications, die niet in staat was om de toegenomen stroom te verwerken, wat leidde tot een ineenstorting (het effect is vergelijkbaar met het vervangen van een deel van een drukke snelweg door een onverharde weg).
Om soortgelijke incidenten in de toekomst te voorkomen,
:
- Gebruik van aankondigingen op basis van RPKI (BGP Origin Validation, staat alleen aankondigingen toe van netwerkeigenaren);
- Beperk het maximale aantal te ontvangen prefixen voor alle EBGP-sessies (de instelling maximum-prefix zou helpen om meteen de overdracht van 20.000 prefixen binnen één sessie te blokkeren);
- Pas filtering toe op basis van het IRR-register (Internet Routing Registry, dat AS bepaalt via welke routen de opgegeven prefixen zijn toegestaan);
- Gebruik de aanbevolen instellingen in RFC 8212 op routers om standaard blokkering (‘default deny’) toe te passen;
- Stop met het ondoordacht gebruik van BGP-optimalisaties.
Bron: opennet.ru
