Sveiki, mano vardas Aleksandras Azimovas. „Yandex“ kuriu įvairias stebėjimo sistemas, taip pat transporto tinklo architektūrą. Bet šiandien kalbėsime apie BGP protokolą.
Prieš savaitę „Yandex“ įjungė ROV (Maršruto kilmės patvirtinimą) sąsajose su visais partneriais, taip pat srauto mainų taškais. Skaitykite toliau, kodėl tai buvo padaryta ir kaip tai paveiks sąveiką su telekomunikacijų operatoriais.
BGP ir kas su juo negerai
Tikriausiai žinote, kad BGP buvo sukurtas kaip tarpdomeninis maršruto parinkimo protokolas. Tačiau pakeliui naudojimo atvejų skaičius išaugo: šiandien BGP dėl daugybės plėtinių virto pranešimų magistrale, apimančia užduotis nuo operatoriaus VPN iki dabar madingo SD-WAN ir netgi rado pritaikymą kaip SDN tipo valdiklio transportavimas, paverčiantis atstumo vektorių BGP į kažką panašaus į nuorodų sat protokolą.
Pav. 1.
Kodėl BGP gavo (ir tebegauna) tiek daug naudojimo būdų? Yra dvi pagrindinės priežastys:
- BGP yra vienintelis protokolas, veikiantis tarp autonominių sistemų (AS);
- BGP palaiko atributus TLV (tipas-ilgis-reikšmė) formatu. Taip, protokolas čia nėra vienas, tačiau kadangi telekomunikacijų operatorių sankryžose jo nėra kuo pakeisti, visada apsimoka prie jo pritvirtinti kitą funkcinį elementą nei palaikyti papildomą maršruto parinkimo protokolą.
Kas su juo blogai? Trumpai tariant, protokole nėra įmontuotų gautos informacijos teisingumo tikrinimo mechanizmų. Tai yra, BGP yra a priori pasitikėjimo protokolas: jei norite pasakyti pasauliui, kad dabar jums priklauso Rostelecom, MTS ar Yandex tinklas, prašau!
IRRDB pagrįstas filtras – geriausias iš blogiausių
Kyla klausimas: kodėl internetas vis dar veikia tokioje situacijoje? Taip, jis veikia didžiąją laiko dalį, bet tuo pat metu periodiškai sprogsta, todėl ištisi nacionaliniai segmentai tampa neprieinami. Nors įsilaužėlių aktyvumas BGP taip pat auga, daugumą anomalijų vis dar sukelia klaidos. Šių metų pavyzdys Baltarusijoje, dėl kurios nemaža interneto dalis pusvalandžiui buvo nepasiekiama „MegaFon“ vartotojams. Kitas pavyzdys - sulaužė vieną didžiausių CDN tinklų pasaulyje.
Ryžiai. 2. Cloudflare eismo perėmimas
Bet vis dėlto, kodėl tokios anomalijos pasitaiko kartą per pusmetį, o ne kasdien? Nes vežėjai naudoja išorines maršruto informacijos duomenų bazes, kad patikrintų, ką jie gauna iš BGP kaimynų. Tokių duomenų bazių yra daug, kai kurias iš jų valdo registratoriai (RIPE, APNIC, ARIN, AFRINIC), dalis yra nepriklausomi žaidėjai (garsiausias yra RADB), taip pat yra visas aibė registratorių, priklausančių didelėms įmonėms (3 lygis). , NTT ir kt.). Būtent šių duomenų bazių dėka tarpdomeninis maršrutas palaiko santykinį savo veikimo stabilumą.
Tačiau yra niuansų. Maršruto informacija tikrinama pagal ROUTE-OBJECTS ir AS-SET objektus. Ir jei pirmasis reiškia leidimą daliai IRRDB, tada antrajai klasei nėra jokios klasės. Tai reiškia, kad kiekvienas gali pridėti bet ką prie savo rinkinių ir taip apeiti tiekėjų filtrus. Be to, AS-SET pavadinimų tarp skirtingų IRR bazių unikalumas nėra garantuotas, o tai gali sukelti netikėtų padarinių, staiga nutrūkus ryšiui telekomunikacijų operatoriui, kuris, savo ruožtu, nieko nepakeitė.
Papildomas iššūkis yra AS-SET naudojimo modelis. Čia yra du punktai:
- Kai operatorius gauna naują klientą, jis prideda jį prie savo AS-SET, bet beveik niekada jo nepašalina;
- Patys filtrai konfigūruojami tik sąsajose su klientais.
Dėl to šiuolaikinį BGP filtrų formatą sudaro laipsniškai blogėjantys filtrai sąsajose su klientais ir a priori pasitikėjimas tuo, kas gaunama iš tarpusavio partnerių ir IP perdavimo paslaugų teikėjų.
Kas pakeičia priešdėlių filtrus, pagrįstus AS-SET? Įdomiausia, kad trumpuoju laikotarpiu – nieko. Tačiau atsiranda papildomų mechanizmų, kurie papildo IRRDB pagrįstų filtrų darbą, ir visų pirma tai, žinoma, yra RPKI.
RPKI
Supaprastintai RPKI architektūra gali būti laikoma paskirstyta duomenų baze, kurios įrašus galima patikrinti kriptografiškai. ROA (Route Object Authorization) atveju pasirašantis asmuo yra adreso erdvės savininkas, o pats įrašas yra trigubas (priešdėlis, asn, max_length). Iš esmės šis įrašas teigia: $prefix adresų erdvės savininkas įgaliojo AS numerį $asn reklamuoti priešdėlius, kurių ilgis ne didesnis nei $max_length. Ir maršrutizatoriai, naudodami RPKI talpyklą, gali patikrinti poros atitiktį priešdėlis – pirmasis kalbėtojas pakeliui.
3 pav. RPKI architektūra
ROA objektai buvo standartizuoti gana ilgą laiką, tačiau iki šiol jie iš tikrųjų liko tik popieriuje IETF žurnale. Mano nuomone, to priežastis skamba baisiai – bloga rinkodara. Pasibaigus standartizavimui, paskata buvo ta, kad ROA apsaugojo nuo BGP užgrobimo – tai nebuvo tiesa. Užpuolikai gali lengvai apeiti ROA pagrįstus filtrus, įterpdami teisingą kintamosios srovės numerį kelio pradžioje. Ir kai tik šis supratimas atėjo, kitas logiškas žingsnis buvo atsisakyti ROA. Iš tiesų, kam mums reikalingos technologijos, jei jos neveikia?
Kodėl laikas persigalvoti? Nes tai ne visa tiesa. ROA neapsaugo nuo įsilaužėlių veiklos BGP, bet apsaugo nuo atsitiktinių eismo užgrobimų, pavyzdžiui, dėl statinio BGP nuotėkio, kuris tampa vis dažnesnis. Be to, skirtingai nuo IRR pagrįstų filtrų, ROV gali būti naudojamas ne tik sąsajose su klientais, bet ir sąsajose su bendraamžiais ir tiekėjais. Tai yra, kartu su RPKI įdiegimu, a priori pasitikėjimas palaipsniui nyksta iš BGP.
Dabar maršrutų tikrinimą pagal ROA pamažu diegia pagrindiniai žaidėjai: didžiausias Europos IX jau atmeta neteisingus maršrutus tarp Tier-1 operatorių, verta išskirti AT&T, kuri įjungė filtrus sąsajose su savo partneriais. Prie projekto artėja ir didžiausi turinio tiekėjai. Ir dešimtys vidutinio dydžio tranzito operatorių jau tyliai tai įdiegė, niekam apie tai nepranešę. Kodėl visi šie operatoriai diegia RPKI? Atsakymas paprastas: apsaugoti savo išeinantį srautą nuo kitų žmonių klaidų. Štai kodėl „Yandex“ viena pirmųjų Rusijos Federacijoje įtraukė ROV į savo tinklo pakraštį.
Kas bus toliau?
Dabar įgalinome tikrinti maršruto informaciją sąsajose su srauto mainų taškais ir privačiais bendravimu. Netolimoje ateityje patvirtinimas taip pat bus įjungtas su srauto tiekėjais.
Koks tau skirtumas? Jei norite padidinti srauto nukreipimo tarp tinklo ir „Yandex“ saugumą, rekomenduojame:
- Pasirašykite savo adreso erdvę - tai paprasta, vidutiniškai trunka 5-10 minučių. Tai apsaugos mūsų ryšį tuo atveju, jei kas nors netyčia pavogtų jūsų adreso erdvę (ir tai tikrai įvyks anksčiau ar vėliau);
- Įdiekite vieną iš atvirojo kodo RPKI talpyklų (, ) ir įjungti maršruto patikrą ties tinklo riba – tai užtruks daugiau laiko, bet vėlgi, tai nesukels jokių techninių sunkumų.
„Yandex“ taip pat palaiko filtravimo sistemos, pagrįstos naujuoju RPKI objektu, kūrimą - (Autonominio sistemos teikėjo autorizacija). Filtrai, pagrįsti ASPA ir ROA objektais, gali ne tik pakeisti „nesandarius“ AS-SET, bet ir pašalinti „MiTM“ atakų problemas naudojant BGP.
Išsamiai apie ASPA kalbėsiu po mėnesio „Next Hop“ konferencijoje. Ten taip pat pasisakys kolegos iš „Netflix“, „Facebook“, „Dropbox“, „Juniper“, „Mellanox“ ir „Yandex“. Jei jus domina tinklo stackas ir jo plėtra ateityje, ateik .
Šaltinis: www.habr.com