Hello, a nevem Alexander Azimov. A Yandexnél különféle felügyeleti rendszereket, valamint közlekedési hálózati architektúrát fejlesztek. De ma a BGP protokollról fogunk beszélni.
Egy héttel ezelőtt a Yandex engedélyezte a ROV-t (Route Origin Validation) az összes társkereső partnerrel, valamint a forgalomcsere pontokon. Olvassa el az alábbiakban arról, hogy miért történt ez, és hogyan befolyásolja a távközlési szolgáltatókkal való interakciót.
BGP és mi a baj vele
Valószínűleg tudja, hogy a BGP-t tartományok közötti útválasztási protokollnak tervezték. Útközben azonban a felhasználási esetek száma nőtt: mára a BGP a számos bővítménynek köszönhetően üzenetbuszgá alakult, amely a kezelői VPN-től a mostanában divatos SD-WAN-ig terjedő feladatokat fedi le, sőt, mára alkalmazásra is talált. egy SDN-szerű vezérlő átvitele, amely a BGP távolságvektort a links sat protokollhoz hasonlóvá alakítja.
Fig. 1.
Miért kapott (és kap továbbra is) olyan sok felhasználást a BGP? Ennek két fő oka van:
- A BGP az egyetlen protokoll, amely autonóm rendszerek (AS) között működik;
- A BGP támogatja az attribútumokat TLV (type-length-value) formátumban. Igen, ebben nincs egyedül a protokoll, de mivel a távközlési szolgáltatók csomópontjainál nincs mit pótolni, mindig kifizetődőbb egy másik funkcionális elemet csatolni hozzá, mint egy további útválasztási protokollt támogatni.
Mi a gond vele? Röviden, a protokoll nem rendelkezik beépített mechanizmusokkal a kapott információ helyességének ellenőrzésére. Vagyis a BGP egy a priori bizalmi protokoll: ha el akarja mondani a világnak, hogy most Ön a Rostelecom, az MTS vagy a Yandex hálózata, kérem!
IRRDB alapú szűrő - a legjobb a legrosszabbból
Felmerül a kérdés: miért működik még ilyen helyzetben az internet? Igen, az idő nagy részében működik, ugyanakkor időnként felrobban, így egész nemzeti szegmensek elérhetetlenek. Bár a hackerek aktivitása a BGP-ben is növekszik, a legtöbb anomáliát még mindig a hibák okozzák. Az idei példa az Fehéroroszországban, amely fél órára elérhetetlenné tette az internet jelentős részét a MegaFon felhasználók számára. Egy másik példa - feltörte a világ egyik legnagyobb CDN-hálózatát.
Rizs. 2. Cloudflare forgalom elfogása
De mégis, miért fordulnak elő ilyen anomáliák félévente egyszer, és nem minden nap? Mivel a szolgáltatók az útválasztási információk külső adatbázisait használják annak ellenőrzésére, hogy mit kapnak a BGP-szomszédoktól. Számos ilyen adatbázis létezik, egy részüket regisztrátorok kezelik (RIPE, APNIC, ARIN, AFRINIC), vannak független szereplők (a leghíresebb a RADB), és van egy egész sor nagyvállalati tulajdonú regisztrátor (3. szint). , NTT stb.). Ezeknek az adatbázisoknak köszönhető, hogy a tartományok közötti útválasztás megőrzi működésének viszonylagos stabilitását.
Vannak azonban árnyalatok. Az útválasztási információk ellenőrzése ROUTE-OBJECTS és AS-SET objektumok alapján történik. És ha az első az IRRDB egy részének engedélyezését jelenti, akkor a második osztály esetében nincs osztályként való felhatalmazás. Vagyis bárki bárkit hozzáadhat a készleteihez, és ezzel megkerülheti az upstream szolgáltatók szűrőit. Ráadásul az AS-SET elnevezésének egyedisége a különböző IRR-bázisok között nem garantált, ami meglepő hatásokhoz vezethet a kapcsolat hirtelen elvesztésével a távközlési szolgáltató számára, aki a maga részéről semmit sem változtatott.
További kihívást jelent az AS-SET használati mintája. Itt két pont van:
- Amikor egy operátor új klienst kap, hozzáadja az AS-SET-hez, de szinte soha nem távolítja el;
- Maguk a szűrők csak a kliensekkel való interfészeken vannak konfigurálva.
Ennek eredményeként a BGP-szűrők modern formátuma fokozatosan leépülő szűrőkből áll a kliensekkel való interfészeken, és eleve bizalommal abban, ami a társ-partnerektől és az IP-átviteli szolgáltatóktól származik.
Mi helyettesíti az AS-SET-en alapuló előtagszűrőket? A legérdekesebb dolog az, hogy rövid távon - semmi. De további mechanizmusok jelennek meg, amelyek kiegészítik az IRRDB-alapú szűrők munkáját, és mindenekelőtt ez természetesen az RPKI.
RPKI
Leegyszerűsítve az RPKI architektúra egy elosztott adatbázisnak tekinthető, amelynek rekordjai kriptográfiailag ellenőrizhetők. ROA (Route Object Authorization) esetén az aláíró a címtér tulajdonosa, maga a rekord pedig tripla (előtag, asn, max_length). Ez a bejegyzés lényegében a következőket feltételezi: a $prefix címtér tulajdonosa felhatalmazta a $asn AS-számot a $max_length-nél nem hosszabb előtagok hirdetésére. Az RPKI gyorsítótárat használó útválasztók pedig képesek ellenőrizni a pár megfelelőségét előtag – az első felszólaló az úton.
3. ábra RPKI architektúra
A ROA objektumokat meglehetősen régóta szabványosították, de egészen a közelmúltig valójában csak papíron maradtak az IETF folyóiratban. Véleményem szerint ennek oka ijesztően hangzik – rossz marketing. A szabványosítás befejezése után az ösztönzés az volt, hogy a ROA védett a BGP-eltérítés ellen – ami nem volt igaz. A támadók könnyen megkerülhetik a ROA-alapú szűrőket, ha beillesztik a megfelelő AC számot az útvonal elejére. És amint ez a felismerés megérkezett, a következő logikus lépés a ROA használatának elhagyása volt. És tényleg, miért van szükségünk a technológiára, ha nem működik?
Miért van itt az ideje, hogy meggondolja magát? Mert ez nem a teljes igazság. A ROA nem véd a hackertevékenység ellen a BGP-ben, hanem véd a véletlen forgalmi eltérítések ellen, például a BGP statikus szivárgásai miatt, ami egyre gyakoribb. Ezenkívül az IRR-alapú szűrőkkel ellentétben a ROV nem csak a kliensekkel, hanem a társ- és upstream szolgáltatókkal való interfészeken is használható. Vagyis az RPKI bevezetésével az a priori bizalom fokozatosan eltűnik a BGP-ből.
A ROA-n alapuló útvonal-ellenőrzést most fokozatosan bevezetik a kulcsszereplők: a legnagyobb európai IX már elveti a hibás útvonalakat, a Tier-1 üzemeltetők közül érdemes kiemelni az AT&T-t, amely a peering partnerekkel való interfészeken engedélyezte a szűrőket. A legnagyobb tartalomszolgáltatók is közelednek a projekthez. És több tucat közepes méretű tranzit szolgáltató már csendben bevezette, anélkül, hogy bárkinek is szólt volna róla. Miért valósítják meg mindezek az operátorok az RPKI-t? A válasz egyszerű: megvédeni a kimenő forgalmat mások hibáitól. Ez az oka annak, hogy a Yandex az elsők között az Orosz Föderációban, amely a ROV-t a hálózatának szélére helyezi.
Mi fog ezután történni?
Mostantól engedélyeztük az útválasztási információk ellenőrzését a forgalmi cserepontok és a privát társviszony-létesítési interfészeken. A közeljövőben az ellenőrzést az upstream forgalmi szolgáltatóknál is engedélyezni fogják.
Milyen különbséget jelent ez számodra? Ha növelni szeretné a hálózat és a Yandex közötti forgalomirányítás biztonságát, javasoljuk:
- Írja alá a címterét - egyszerű, átlagosan 5-10 percet vesz igénybe. Ez megvédi kapcsolatunkat arra az esetre, ha valaki akaratlanul is ellopná a címterét (és ez előbb-utóbb biztosan megtörténik);
- Telepítse az egyik nyílt forráskódú RPKI gyorsítótárat (, ) és engedélyezze az útvonal-ellenőrzést a hálózat határán - ez több időt vesz igénybe, de ismét nem okoz technikai nehézségeket.
A Yandex támogatja az új RPKI objektumon alapuló szűrőrendszer fejlesztését is - (Autonóm rendszerszolgáltatói jogosultság). Az ASPA és ROA objektumokra épülő szűrők nemcsak a „szivárgó” AS-SET-eket helyettesíthetik, hanem a BGP-t használó MiTM-támadások problémáit is lezárhatják.
Az ASPA-ról egy hónap múlva, a Next Hop konferencián fogok részletesen beszélni. Ott felszólalnak a Netflix, a Facebook, a Dropbox, a Juniper, a Mellanox és a Yandex kollégái is. Ha érdekel a hálózati stack és annak fejlesztése a jövőben, gyere el .
Forrás: will.com