Bună, numele meu este Alexander Azimov. La Yandex, dezvolt diverse sisteme de monitorizare, precum și arhitectura rețelei de transport. Dar astăzi vom vorbi despre protocolul BGP.
Acum o săptămână, Yandex a activat ROV (Route Origin Validation) la interfețele cu toți partenerii de peering, precum și punctele de schimb de trafic. Citiți mai jos despre motivul pentru care a fost făcut acest lucru și despre cum va afecta interacțiunea cu operatorii de telecomunicații.
BGP și ce este în neregulă cu el
Probabil știți că BGP a fost conceput ca un protocol de rutare interdomeniu. Cu toate acestea, pe parcurs, numărul cazurilor de utilizare a reușit să crească: astăzi, BGP, datorită numeroaselor extensii, s-a transformat într-o magistrală de mesaje, acoperind sarcini de la operator VPN până la acum la modă SD-WAN și chiar și-a găsit aplicație ca un transport pentru un controler asemănător SDN, transformând vectorul distanță BGP în ceva similar cu protocolul link-sat.
Fig. 1.
De ce a primit BGP (și continuă să primească) atât de multe utilizări? Există două motive principale:
- BGP este singurul protocol care funcționează între sisteme autonome (AS);
- BGP acceptă atribute în format TLV (tip-lungime-valoare). Da, protocolul nu este singur în asta, dar din moment ce nu există nimic care să-l înlocuiască la joncțiunile dintre operatorii de telecomunicații, se dovedește întotdeauna a fi mai profitabil să-i atașezi un alt element funcțional decât să suporti un protocol suplimentar de rutare.
Ce-i în neregulă cu el? Pe scurt, protocolul nu are încorporate mecanisme de verificare a corectitudinii informațiilor primite. Adică, BGP este un protocol de încredere a priori: dacă vrei să spui lumii că acum deții rețeaua Rostelecom, MTS sau Yandex, te rog!
Filtru bazat pe IRRDB - cel mai bun dintre cel mai rău
Se pune întrebarea: de ce mai funcționează Internetul într-o astfel de situație? Da, funcționează de cele mai multe ori, dar în același timp explodează periodic, făcând inaccesibile segmente naționale întregi. Deși activitatea hackerilor în BGP este, de asemenea, în creștere, majoritatea anomaliilor sunt încă cauzate de erori. Exemplul din acest an este în Belarus, care a făcut ca o parte semnificativă a internetului să fie inaccesabilă pentru utilizatorii MegaFon timp de o jumătate de oră. Alt exemplu - a spart una dintre cele mai mari rețele CDN din lume.
Orez. 2. Interceptarea traficului Cloudflare
Dar totuși, de ce apar astfel de anomalii o dată la șase luni și nu în fiecare zi? Deoarece transportatorii folosesc baze de date externe cu informații de rutare pentru a verifica ceea ce primesc de la vecinii BGP. Există multe astfel de baze de date, unele dintre ele sunt administrate de registratori (RIPE, APNIC, ARIN, AFRINIC), unele sunt jucători independenți (cel mai faimos este RADB) și există și un întreg set de registratori deținute de companii mari (Level3). , NTT etc.). Datorită acestor baze de date, rutarea între domenii menține stabilitatea relativă a funcționării sale.
Cu toate acestea, există nuanțe. Informațiile de rutare sunt verificate pe baza obiectelor ROUTE-OBJECTS și AS-SET. Și dacă primul implică autorizare pentru o parte a IRRDB, atunci pentru a doua clasă nu există autorizație ca clasă. Adică, oricine poate adăuga pe oricine la seturile lor și, prin urmare, poate ocoli filtrele furnizorilor din amonte. Mai mult, nu este garantată unicitatea denumirii AS-SET între diferite baze IRR, ceea ce poate duce la efecte surprinzătoare cu o pierdere bruscă a conectivității pentru operatorul de telecomunicații, care, la rândul său, nu a schimbat nimic.
O provocare suplimentară este modelul de utilizare a AS-SET. Există două puncte aici:
- Când un operator primește un client nou, îl adaugă la AS-SET, dar aproape niciodată nu îl îndepărtează;
- Filtrele în sine sunt configurate numai la interfețele cu clienții.
Drept urmare, formatul modern al filtrelor BGP constă în degradarea treptată a filtrelor la interfețele cu clienții și încrederea a priori în ceea ce vine de la partenerii de peering și furnizorii de tranzit IP.
Ce înseamnă înlocuirea filtrelor de prefix bazate pe AS-SET? Cel mai interesant lucru este că pe termen scurt - nimic. Dar apar mecanisme suplimentare care completează activitatea filtrelor bazate pe IRRDB și, în primul rând, acesta este, desigur, RPKI.
RPKI
Într-un mod simplificat, arhitectura RPKI poate fi gândită ca o bază de date distribuită ale cărei înregistrări pot fi verificate criptografic. În cazul ROA (Route Object Authorization), semnatarul este proprietarul spațiului de adrese, iar înregistrarea în sine este un triplu (prefix, asn, max_length). În esență, această intrare postulează următoarele: proprietarul spațiului de adrese $prefix a autorizat numărul AS $asn să facă publicitate prefixelor cu o lungime nu mai mare de $max_length. Iar routerele, care folosesc memoria cache RPKI, pot verifica perechea pentru conformitate prefix - primul vorbitor pe drum.
Figura 3. Arhitectura RPKI
Obiectele ROA au fost standardizate destul de mult timp, dar până de curând au rămas de fapt doar pe hârtie în jurnalul IETF. În opinia mea, motivul pentru acest lucru sună înfricoșător - marketing prost. După finalizarea standardizării, stimulentul a fost că ROA a protejat împotriva deturnării BGP - ceea ce nu era adevărat. Atacatorii pot ocoli cu ușurință filtrele bazate pe ROA inserând numărul AC corect la începutul căii. Și de îndată ce a venit această realizare, următorul pas logic a fost abandonarea utilizării ROA. Într-adevăr, de ce avem nevoie de tehnologie dacă nu funcționează?
De ce este timpul să vă răzgândiți? Pentru că acesta nu este tot adevărul. ROA nu protejează împotriva activității hackerilor în BGP, dar protejează împotriva deturnărilor accidentale de trafic, de exemplu de la scurgerile statice în BGP, care devine din ce în ce mai frecventă. De asemenea, spre deosebire de filtrele bazate pe IRR, ROV poate fi utilizat nu numai la interfețele cu clienții, ci și la interfețele cu colegii și furnizorii din amonte. Adică, odată cu introducerea RPKI, încrederea a priori dispare treptat din BGP.
Acum, verificarea rutelor bazate pe ROA este implementată treptat de jucătorii cheie: cel mai mare IX european renunță deja la rute incorecte printre operatorii Tier-1, merită evidențiat AT&T, care a activat filtre la interfețele cu partenerii săi de peering. Cei mai mari furnizori de conținut se apropie și de proiect. Și zeci de operatori de tranzit de dimensiuni medii l-au implementat deja în liniște, fără să spună nimănui despre asta. De ce toți acești operatori implementează RPKI? Răspunsul este simplu: pentru a vă proteja traficul de ieșire de greșelile altora. De aceea, Yandex este unul dintre primii din Federația Rusă care include ROV la marginea rețelei sale.
Ce se va întâmpla în continuare?
Am activat acum verificarea informațiilor de rutare la interfețele cu puncte de schimb de trafic și peeringuri private. În viitorul apropiat, verificarea va fi activată și cu furnizorii de trafic din amonte.
Ce diferență face asta pentru tine? Dacă doriți să creșteți securitatea rutării traficului între rețeaua dvs. și Yandex, vă recomandăm:
- Semnează-ți spațiul de adresă - este simplu, durează în medie 5-10 minute. Acest lucru ne va proteja conectivitatea în cazul în care cineva vă fură fără să vrea spațiul de adrese (și acest lucru se va întâmpla cu siguranță mai devreme sau mai târziu);
- Instalați unul dintre cache-urile RPKI open source (, ) și activați verificarea rutei la granița rețelei - acest lucru va dura mai mult timp, dar din nou, nu va cauza dificultăți tehnice.
Yandex sprijină, de asemenea, dezvoltarea unui sistem de filtrare bazat pe noul obiect RPKI - (Autorizare furnizor de sistem autonom). Filtrele bazate pe obiecte ASPA și ROA nu pot doar să înlocuiască AS-SET-uri „scurge”, ci și să închidă problemele atacurilor MiTM folosind BGP.
Voi vorbi în detaliu despre ASPA peste o lună la conferința Next Hop. Acolo vor vorbi și colegi de la Netflix, Facebook, Dropbox, Juniper, Mellanox și Yandex. Dacă sunteți interesat de stiva de rețea și de dezvoltarea acesteia în viitor, veniți .
Sursa: www.habr.com