Compania de telecom deținută de statul rus a deturnat traficul Google, Facebook, Cloudflare și alții.

Din cauza consumului uriaș de internet ca urmare a pandemiei de coronavirus ce a făcut aproape toată planeta să stea acasă, Internetul este suprasolicitat de oamenii care fie muncesc de acasă prin videoconferințe fie își alungă plictiseala jucându-se sau având diverse activități online. Acest lucru a pus o presiune foarte mare asupra serverelor celor mai importante companii de pe planetă, iar Google și Facebook au avut parte de întreruperi în furnizarea anumitor servicii.

Campaniile publicitare de la Google au avut întârzieri chiar și de câteva zile până a începe livrarea, iar Facebook și-a furnizat la rândul său serviciile cu frâna de mână trasă. Pe lângă faptul că suprasolicitarea internetului realizată de oamenii ce stau în case au mai intervenit și entități răuvoitoare ce au pus o presiune și mai mare pe serviciile de internet.

Săptămâna trecută, traficul de internet destinat pentru mai mult de 200 dintre cele mai mari reţele de livrare conţinut (CDN) din lume şi pentru providerii de găzduire a fost redirecţionat în mod suspect prin Rostelecom, providerul de telecomunicaţii deţinut de statul rus. Incidentul a afectat mai mult de 8800 de rute de trafic şi peste 200 de reţele, durând aproximativ o oră. Printre companiile care au avut de suferit din cauza incidentului se numără giganţii Google, Facebook, Amazon, dar şi firme mari de pe piaţa de internet precum Cloudflare sau GoDaddy.

Incidentul reprezintă o deturnare clasică de tip BGP (Border Gateway Protocol). însemnând că a fost preluat controlul în mod ilegal asupra unor clase de IP-uri prin coruperea acestui BGP. Acest protocol este sistemul de facto folosit pentru a transmite traficul de internet către reţelele de internet din toată lumea. Întregul sistem este foarte fragil din cauza faptului că orice reţea participantă poate să „mintă” şi să publice un anunţ (rută BGP) susţinând că „serverele Facebook” se află în reţeaua lor, iar toate entităţile de pe internet vor lua această informaţie ca fiind legitimă şi trimite tot traficul de pe Facebook spre serverele „teroriştilor”.

Deturnările de trafic, o problemă veche nerezolvată

În trecut, înainte ca HTTPS să fie folosit la scară largă pentru a cripta traficul, deturnările de tip BGP permitea răuvoitorilor să lanseze atacuri, să intercepteze şi să altereze traficul de internet. În zilele noastre, deturnările BGP sunt încă periculoase din cauza faptului că permite răufăcătorilor să înregistreze traficul şi să încerce să îl analizeze şi decripteze mai târziu când securitatea devine mai fragilă ca urmare a progreselor în criptografie.

Aceste deturnări de trafic au fost o problemă încă din anii ’90, iar eforturile de a se concepe o securitate sporită au fost în desfăşurare vreme de mulţi ani. Cu toate acestea, progresul în adoptarea noilor protocoale de siguranţă au fost lente, iar deturnările BGP continuă să se petreacă în mod regulat. De exemplu, în noiembrie 2018, un mic ISP Nigerian a deturnat traficul ce ar fi trebuit să ajungă în reţeaua Google, iar în junie 2019 o mare parte din traficul destinat reţelelor mobile Europene a fost redirecţionat prin China Telecom, cel mai mare operator telecom din China şi care este deţinut de statul chinez.

Rușii și chinezii, cei mai mari „agresori”

Experţii au spus de multe ori că nu toate deturnările BGP sunt rău intenţionate. Majoritatea incidentelor pot fi rezultatul unor greşeli umane făcute de operatorii care tastează greşit ASN-urile (numărul sistemului autonom, acel cod prin care entităţile de internet sunt identificate) şi deturnează accidental traficul de internet destinat companiei respective.

Deşi Rostelecom nu este la prima abatere în acest sens, având câteva incidente suspecte la activ, cel mai mare „agresor” în acest domeniu este China Telecom. Cea mai importantă deturnare realizată de Rostelecom s-a petrecut în 2017 când au deturnat traficul unora dintre cele mai mari entităţi financiare din lume, precum Visa, Mastercard, HSBC şi multe altele.

Sursa articol: Zdnet.com

Admin

Admin

See author's posts