Ca urmare a unui anunț BGP eronat, mai mult de 8800 de prefixe de rețea străină prin intermediul rețelei Rostelecom, ceea ce a dus la un colaps pe termen scurt a rutare, întreruperea conectivității rețelei și probleme cu accesul la unele servicii din întreaga lume. Problemă peste 200 de sisteme autonome deținute de mari companii de internet și rețele de livrare de conținut, inclusiv Akamai, Cloudflare, Digital Ocean, Amazon AWS, Hetzner, Level3, Facebook, Alibaba și Linode.
Anunțul eronat a fost făcut de Rostelecom (AS12389) pe 1 aprilie la ora 22:28 (MSK), apoi a fost preluat de furnizorul Rascom (AS20764) și mai departe de-a lungul lanțului s-a răspândit la Cogent (AS174) și Level3 (AS3356). , al cărui domeniu a acoperit aproape toți furnizorii de internet de prim nivel (). BGP a anunțat prompt Rostelecom despre problemă, astfel încât incidentul a durat aproximativ 10 minute (conform efectele au fost observate timp de aproximativ o oră).
Acesta nu este primul incident care implică o eroare din partea Rostelecom. În 2017 în 5-7 minute prin Rostelecom rețelele celor mai mari bănci și servicii financiare, inclusiv Visa și MasterCard. În ambele incidente, sursa problemei pare să fie lucrări legate de managementul traficului, de exemplu, scurgerile de rute ar putea apărea la organizarea monitorizării interne, prioritizării sau oglindirii traficului care trece prin Rostelecom pentru anumite servicii și CDN-uri (datorită creșterii încărcăturii rețelei din cauza lucrului în masă de acasă la sfârșitul Martie problema scăderii priorităţii pentru traficul serviciilor externe în favoarea resurselor interne). De exemplu, în urmă cu câțiva ani s-a făcut o încercare în Pakistan Subrețelele YouTube de pe interfața nulă au dus la apariția acestor subrețele în anunțurile BGP și la fluxul întregului trafic YouTube către Pakistan.
Interesant este că cu o zi înainte de incidentul cu Rostelecom, micul furnizor „New Reality” (AS50048) din oraș. prin Transtelecom a fost 2658 de prefixe care afectează Orange, Akamai, Rostelecom și rețelele a peste 300 de companii. Scurgerea rutei a dus la mai multe valuri de redirecționări de trafic care au durat câteva minute. La apogeu, problema a afectat până la 13.5 milioane de adrese IP. O întrerupere globală vizibilă a fost evitată datorită utilizării de către Transtelecom a restricțiilor de rută pentru fiecare client.
Incidente similare au loc pe internet și vor continua până când vor fi implementate peste tot Anunțuri BGP bazate pe RPKI (BGP Origin Validation), permițând primirea anunțurilor doar de la proprietarii rețelei. Fără autorizare, orice operator poate face reclamă la o subrețea cu informații fictive despre lungimea rutei și poate iniția tranzitul prin el însuși a unei părți din trafic din alte sisteme care nu aplică filtrarea reclamelor.
În același timp, în incidentul luat în considerare, o verificare folosind depozitul RIPE RPKI s-a dovedit a fi . Din întâmplare, cu trei ore înainte de scurgerea rutei BGP în Rostelecom, în timpul procesului de actualizare a software-ului RIPE, 4100 înregistrări ROA (Autorizarea de origine a rutei RPKI). Baza de date a fost restaurată abia pe 2 aprilie, iar în tot acest timp verificarea a fost inoperabilă pentru clienții RIPE (problema nu a afectat depozitele RPKI ale altor registratori). Astăzi, RIPE are noi probleme și depozitul RPKI în 7 ore .
Filtrarea bazată pe registru poate fi folosită și ca soluție pentru a bloca scurgerile (Internet Routing Registry), care definește sisteme autonome prin care este permisă rutarea prefixelor specificate. Când interacționați cu operatorii mici, pentru a reduce impactul erorilor umane, puteți limita numărul maxim de prefixe acceptate pentru sesiunile EBGP (setarea maxim-prefix).
În cele mai multe cazuri, incidentele sunt rezultatul unor erori accidentale ale personalului, dar recent au existat și atacuri țintite, în timpul cărora atacatorii compromit infrastructura furnizorilor. и trafic pentru site-uri specifice prin organizarea unui atac MiTM pentru a înlocui răspunsurile DNS.
Pentru a face mai dificilă obținerea certificatelor TLS în timpul unor astfel de atacuri, autoritatea de certificare Let's Encrypt la verificarea domeniului cu mai multe poziții folosind diferite subrețele. Pentru a ocoli această verificare, un atacator va trebui să realizeze simultan redirecționarea rutei pentru mai multe sisteme autonome de furnizori cu uplink-uri diferite, ceea ce este mult mai dificil decât redirecționarea unei singure rute.
Sursa: opennet.ru