Egy hibás BGP bejelentés következtében több mint 8800 külföldi hálózati előtag a Rostelecom hálózaton keresztül, ami az útválasztás rövid távú összeomlásához, a hálózati kapcsolat megszakadásához és egyes szolgáltatásokhoz való hozzáférési problémákhoz vezetett szerte a világon. Probléma több mint 200 autonóm rendszer a nagy internetes cégek és tartalomszolgáltató hálózatok tulajdonában, köztük az Akamai, a Cloudflare, a Digital Ocean, az Amazon AWS, a Hetzner, a Level3, a Facebook, az Alibaba és a Linode.
A téves bejelentést a Rostelecom (AS12389) tette április 1-jén 22:28-kor (MSK), majd a Rascom (AS20764) szolgáltató vette át, majd a láncon tovább terjedt a Cogent (AS174) és a Level3 (AS3356) felé. , melynek területe szinte az összes internetszolgáltató első szintű (). A BGP azonnal értesítette a Rostelecomot a problémáról, így az incidens körülbelül 10 percig tartott (a a hatás körülbelül egy órán keresztül volt megfigyelhető).
Nem ez az első olyan incidens, amely hibával járt a Rostelecom oldalán. 2017-ben 5-7 percen belül a Rostelecomon keresztül a legnagyobb bankok és pénzügyi szolgáltatások hálózatai, köztük a Visa és a MasterCard. Mindkét esetben úgy tűnik, hogy a probléma forrása forgalomirányítással kapcsolatos munkák, például útvonalak kiszivárogtatása fordulhat elő a Rostelecomon áthaladó forgalom belső megfigyelésének, priorizálásának vagy tükrözésének megszervezésekor bizonyos szolgáltatások és CDN-ek esetében (a hálózati terhelés növekedése miatt a tömeges otthoni munkavégzés végén március a külföldi szolgáltatások forgalmi prioritásának csökkentése a hazai források javára). Például néhány évvel ezelőtt Pakisztánban történt egy kísérlet A null felületen lévő YouTube-alhálózatok miatt ezek az alhálózatok megjelentek a BGP-bejelentésekben, és az összes YouTube-forgalom Pakisztánba áramlott.
Érdekes, hogy egy nappal az incidens előtt a Rostelecom, a kis szolgáltató „New Reality” (AS50048) a városból. a Transtelecomon keresztül volt 2658 előtag, amely az Orange, Akamai, Rostelecom és több mint 300 vállalat hálózatát érinti. Az útvonal szivárgása több, több percig tartó forgalomátirányítási hullámot eredményezett. A probléma csúcspontján 13.5 millió IP-címet érintett. Az észrevehető globális fennakadás elkerülhető, köszönhetően annak, hogy a Transtelecom minden egyes ügyfél esetében útvonalkorlátozást alkalmazott.
Hasonló események történnek az interneten és mindaddig folytatódni fog, amíg mindenhol meg nem valósulnak BGP közlemények RPKI (BGP Origin Validation) alapúak, lehetővé téve a közlemények fogadását csak a hálózattulajdonosoktól. Jogosultság nélkül bármely üzemeltető hirdethet egy alhálózatot fiktív információkkal az útvonal hosszáról, és kezdeményezheti a forgalom egy részének átszállítását magán keresztül, olyan más rendszerekről, amelyek nem alkalmaznak hirdetésszűrést.
Ugyanakkor a vizsgált incidensben a RIPE RPKI adattárat használó ellenőrzés kiderült, hogy . Véletlenül három órával a BGP útvonal kiszivárgása előtt a Rostelecomban, a RIPE szoftver frissítése közben, 4100 ROA rekord (RPKI Route Origin Authorization). Az adatbázis csak április 2-án állt helyre, és az ellenőrzés mindvégig nem működött a RIPE kliensek számára (a probléma nem érintette más regisztrátorok RPKI tárházát). Ma a RIPE új problémákkal és RPKI tárolóval rendelkezik 7 órán belül .
A rendszerleíró adatbázis alapú szűrés is használható megoldásként a szivárgások blokkolására (Internet Routing Registry), amely olyan autonóm rendszereket határoz meg, amelyeken keresztül megengedett a megadott előtagok irányítása. Amikor kis operátorokkal dolgozik, az emberi hibák hatásának csökkentése érdekében korlátozhatja az EBGP-munkamenetek elfogadott előtagjainak maximális számát (a maximális előtag beállítás).
A legtöbb esetben az incidensek véletlenszerű személyzeti hibák következményei, de az utóbbi időben célzott támadások is előfordulnak, amelyek során a támadók veszélyeztetik a szolgáltatók infrastruktúráját. и forgalom számára adott helyekre egy MiTM-támadás megszervezésével a DNS-válaszok helyettesítésére.
Az ilyen támadások során a TLS-tanúsítványok beszerzésének megnehezítésére a Let's Encrypt tanúsítványszolgáltató többpozíciós tartományellenőrzésre különböző alhálózatok használatával. Ennek az ellenőrzésnek a megkerüléséhez a támadónak egyszerre kell elérnie az útvonal-átirányítást több, különböző felfelé irányuló kapcsolattal rendelkező szolgáltató autonóm rendszeréhez, ami sokkal nehezebb, mint egyetlen útvonal átirányítása.
Forrás: opennet.ru