BGP marsruutide leke põhjustas massilise ühenduse katkemise internetis

Cloudflare avalikustasin eile õnnetuse raport, mille tagajärjel esinesid juurdepääsuprobleemid paljudele globaalsetele ressurssidele, sealhulgas Cloudflare'i, Facebooki, Akamai, Apple'i, Linode'i ja Amazon AWS-i infrastruktuurile, kolme tunni vältel kell 13:34 kuni 16:26 (MSK). Probleemid Cloudflare'i infrastruktuuris, mis pakub CDN-i 16 miljonile veebisaidile, ilmnesid kell 14:02 kuni 16:02 (MSK). Cloudflare'i hindangul registreeriti rikke ajal umbes 15% globaalsetest andmevoogudest.

Probleem oli põhjustatud BGP kaudu toimunud marsruutide lekke tõttu, mille käigus suunati vale suunas umbes 20 000 eelistust 2400 võrgust. Lekke allikaks oli teenusepakkuja DQE Communications, kes kasutas tarkvara BGP Optimizer marsruutimise optimeerimiseks. BGP Optimizer jagab IP-eelistusi väiksemateks, näiteks jagab 104.20.0.0/20 kaheks 104.20.0.0/21 ja 104.20.8.0/21, mistõttu hoidis DQE Communications enda süsteemis suurt hulka spetsiifilisi marsruute, mis ületavad üldised marsruudid (st Cloudflare'i üldiste marsruutide asemel kasutati konkreetsetele Cloudflare'i alamsüsteemidele suunatud detailsemaid marsruute).

Needlike punktite marsruudid said teadaüksi ühele kliendile (Allegheny Technologies, AS396531), kes oli samuti ühendatud veel ühe teenusepakkuja kaudu. Allegheny Technologies edastas saadud marsruudid teisele ülemisteenusepakkujale (Verizon, AS701). Adekaatsete BGP-sõnumite filtreerimise puudumise ning prefiksite arvu piirangu tõttu, Verizon võttis selle sõnumi üles ja edastas saadud 20 tuhat prefiksi ülejäänud internetile. Vale prefiksid nende granulaarsuse tõttu tõlgendati kõrgemate prioriteetidena, kuna konkreetne marsruut omab kõrgemat prioriteeti kui üldine.

Kokkuvõttes suunati liiklus paljude suurte võrkude kaudu Verizon'i väikesele teenusepakkujale DQE Communications, kes ei suutnud taluda suurenenud voogu, mis viis kokkuvarisemiseni (efekt on võrreldav sellega, kui osa koormatud kiirteest asendatakse taluteedega).

Sarnaste intsidentide ennetamiseks tulevikus
soovitatud:

• Kasutage verifitseerimine sõnumite põhjal RPKI (BGP päritolu valideerimine, lubab sõnumite vastuvõttu ainult võrgu omanike poolt);
• Piirata maksimaalne lubatud EBGPi seansside prefiksite arv (maximum-prefix seadistamine aitaks kohe kõrvaldada 20 000 prefiksi edastamise ühe seansi jooksul);
• Rakendada IRR (Internet Routing Registry) registripõhist filtreerimist (määrab AS-id, mille kaudu on lubatud antud prefiksite marsruutimine);
• Kasutada marsruuteritel RFC 8212 soovitatud seadeid, et vaikimisi blokeerida (‘default deny’);
• Lõpetada mõtlematu BGP optimeerijate kasutamine.

Allikas: opennet.ru