március 13-án a RIPE visszaélések elleni munkacsoportjának tekintse a BGP-eltérítést (hjjack) a RIPE szabályzat megsértésének. A javaslat elfogadása esetén a forgalomelfogással megtámadott internetszolgáltatónak lehetősége lenne külön kérést küldeni a támadó leleplezése érdekében. Ha a vizsgálócsoport elegendő bizonyítékot gyűjt össze, a BGP-lehallgatás forrásaként szolgáló LIR-t behatolónak tekintik, és megfoszthatják LIR-státuszától. Volt néhány érv is változtatások.
Ebben a kiadványban egy olyan támadásra szeretnénk példát mutatni, ahol nemcsak a valódi támadóról volt szó, hanem az érintett előtagok teljes listájáról is. Sőt, egy ilyen támadás ismét kérdéseket vet fel az ilyen típusú forgalom jövőbeni elfogásának indítékaival kapcsolatban.
Az elmúlt néhány évben csak az olyan konfliktusokkal foglalkoztak a sajtóban, mint a MOAS (Multiple Origin Autonomous System), mint BGP-elfogás. A MOAS egy speciális eset, amikor két különböző autonóm rendszer ütköző előtagokat hirdet a megfelelő ASN-ekkel az AS_PATH-ban (az első ASN az AS_PATH-ban, a továbbiakban eredet ASN). De legalább megnevezhetjük forgalom elfogása, amely lehetővé teszi a támadók számára, hogy különféle célokra manipulálják az AS_PATH attribútumot, beleértve a szűrés és figyelés modern megközelítéseinek megkerülését. Ismert támadástípus - az ilyen elfogás utolsó típusa, de egyáltalán nem fontos. Nagyon valószínű, hogy az elmúlt hetekben pontosan ilyen támadást láthattunk. Egy ilyen eseménynek érthető természete és meglehetősen súlyos következményei vannak.
Azok, akik a TL;DR verziót keresik, a "Perfect Attack" feliratig görgethetnek.
Hálózati háttér
(hogy jobban megértse az incidenssel kapcsolatos folyamatokat)
Ha csomagot szeretne küldeni, és több előtagja van a cél IP-címét tartalmazó útválasztási táblázatban, akkor a leghosszabb előtag útvonalát fogja használni. Ha ugyanahhoz az előtaghoz több különböző útvonal is tartozik az útválasztási táblázatban, akkor a legjobbat kell kiválasztani (a legjobb útvonalválasztási mechanizmus szerint).
A meglévő szűrési és megfigyelési megközelítések az AS_PATH attribútum elemzésével kísérlik meg az útvonalak elemzését és a döntések meghozatalát. A router ezt az attribútumot bármilyen értékre módosíthatja hirdetés közben. A tulajdonos ASN-jének egyszerű hozzáadása az AS_PATH elejéhez (mint az eredeti ASN-hez) elegendő lehet az aktuális eredet-ellenőrző mechanizmusok megkerüléséhez. Ezen túlmenően, ha van egy útvonal a megtámadott ASN-től Ön felé, akkor lehetségessé válik ennek az útvonalnak az AS_PATH kinyerése és felhasználása a többi hirdetésében. A kialakított közleményeihez tartozó AS_PATH csak érvényesítési ellenőrzés végül sikeres lesz.
Még mindig van néhány korlátozás, amelyet érdemes megemlíteni. Először is, az upstream szolgáltató előtagszűrése esetén az útvonal továbbra is szűrhető (még a megfelelő AS_PATH-val is), ha az előtag nem tartozik az upstream-en konfigurált klienskúphoz. Másodszor, egy érvényes AS_PATH érvénytelenné válhat, ha a létrehozott útvonalat helytelen irányban hirdetik, és így sérti az útválasztási szabályzatot. Végül minden olyan útvonalat érvénytelennek lehet tekinteni, amelynek előtagja megsérti a ROA hosszát.
Incidens
Néhány héttel ezelőtt panaszt kaptunk egyik felhasználónktól. Láttunk útvonalakat a származási ASN és /25 előtagokkal, miközben a felhasználó azt állította, hogy nem hirdette őket.
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
Példák a 2019. április eleji bejelentésekre
A /25 előtag elérési útjában található NTT különösen gyanússá teszi. Az LG NTT nem tudott erről az útvonalról az incidens idején. Tehát igen, néhány operátor egy teljes AS_PATH-t hoz létre ezekhez az előtagokhoz! Más útválasztók ellenőrzése egy konkrét ASN-t mutat: AS263444. Miután megvizsgáltunk más útvonalakat ezzel az autonóm rendszerrel, a következő helyzettel találkoztunk:
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
Próbáld kitalálni, mi a baj itt
Úgy tűnik, hogy valaki kivette az előtagot az útvonalból, két részre osztotta, és az útvonalat ugyanazzal az AS_PATH-val hirdette meg ehhez a két előtaghoz.
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
Példaútvonalak az egyik osztott előtagpárhoz
Több kérdés is felmerül egyszerre. Valaki próbálta már ezt a fajta lehallgatást a gyakorlatban? Járta már valaki ezeket az utakat? Milyen előtagok érintettek?
Itt kezdődik a kudarcok sorozata, és egy újabb csalódás az internet jelenlegi állapota miatt.
A kudarc útja
Először is. Hogyan határozhatjuk meg, hogy mely útválasztók fogadták el az ilyen elfogott útvonalakat, és kinek a forgalmát lehetne ma átirányítani? Úgy gondoltuk, hogy a /25 előtagokkal kezdjük, mert "egyszerűen nem lehet globális eloszlásuk". Ahogy sejtheti, nagyon tévedtünk. Ez a mérőszám túl zajosnak bizonyult, és az ilyen előtagokkal rendelkező útvonalak még a Tier-1 operátoroktól is megjelenhetnek. Például az NTT körülbelül 50 ilyen előtaggal rendelkezik, amelyeket saját klienseinek terjeszt. Másrészt ez a mérőszám rossz, mert az ilyen előtagok kiszűrhetők, ha az operátor használja , minden irányban. Ezért ez a módszer nem alkalmas minden olyan szolgáltató megtalálására, akiknek a forgalmát egy ilyen esemény következtében átirányították.
Egy másik jó ötlet volt, hogy megnézzük . Különösen olyan útvonalakon, amelyek megsértik a megfelelő ROA maxLength szabályát. Így meg tudjuk találni az adott AS számára látható Invalid állapotú különböző eredetű ASN-ek számát. Van azonban egy "kis" probléma. Ennek a számnak (a különböző eredetű ASN-ek számának) átlaga (mediánja és módusa) körülbelül 150, és ha a kis előtagokat kiszűrjük is, 70 felett marad. Ennek az állapotnak nagyon egyszerű magyarázata van: csak egy néhány operátor már használ ROA-szűrőket „invalid routes” házirenddel a belépési pontokon, így bárhol megjelenik egy ROA-sértést sértő útvonal a való világban, minden irányban továbbterjedhet.
Az utolsó két megközelítés lehetővé teszi, hogy megtaláljuk azokat a kezelőket, akik látták az incidensünket (mivel az elég nagy volt), de általában nem alkalmazhatók. Oké, de megtaláljuk a betolakodót? Melyek az AS_PATH manipuláció általános jellemzői? Van néhány alapvető feltételezés:
- Az előtagot még sehol nem látták;
- Eredeti ASN (emlékeztető: első ASN az AS_PATH-ban) érvényes;
- Az AS_PATH utolsó ASN-je a támadó ASN-je (ha a szomszédja minden bejövő útvonalon ellenőrzi a szomszéd ASN-jét);
- A támadás egyetlen szolgáltatótól származik.
Ha minden feltevés helyes, akkor minden helytelen útvonal bemutatja a támadó ASN-jét (kivéve az eredeti ASN-t), és ezért ez egy "kritikus" pont. A valódi gépeltérítők között volt az AS263444, bár voltak mások is. Még akkor is, ha az incidens útvonalait figyelmen kívül hagytuk. Miért? Egy kritikus pont még a megfelelő útvonalak esetében is kritikus maradhat. Ennek oka lehet egy régió rossz kapcsolata vagy saját láthatóságunk korlátai.
Ennek eredményeként van mód a támadó észlelésére, de csak akkor, ha a fenti feltételek mindegyike teljesül, és csak akkor, ha az elfogás elég nagy ahhoz, hogy átlépje a megfigyelési küszöbértékeket. Ha e tényezők közül néhány nem teljesül, meg tudjuk-e azonosítani azokat az előtagokat, amelyek szenvedtek az ilyen lehallgatástól? Bizonyos operátorok esetében igen.
Amikor egy támadó konkrétabb útvonalat hoz létre, az ilyen előtagot a valódi tulajdonos nem hirdeti. Ha dinamikus listája van az összes előtagjáról, akkor lehetővé válik az összehasonlítás és a torz, konkrétabb útvonalak megtalálása. Ezt az előtaglistát a BGP-munkameneteink segítségével gyűjtjük össze, mert nem csak az üzemeltető számára jelenleg látható útvonalak teljes listáját kapjuk meg, hanem az összes előtag listáját is, amelyet hirdetni szeretne a világnak. Sajnos ma már több tucat Radar-felhasználó van, akik nem fejezik be megfelelően az utolsó részt. Hamarosan értesítjük őket, és megpróbáljuk megoldani a problémát. Mindenki más most csatlakozhat megfigyelő rendszerünkhöz.
Ha visszatérünk az eredeti incidenshez, akkor a támadót és a terjesztési területet is a kritikus pontok keresésével észleltük. Meglepő módon az AS263444 nem küldött kitalált útvonalakat minden ügyfelének. Bár van egy furcsább pillanat is.
BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
Egy újabb példa a címterünk elfogására tett kísérletre
Amikor konkrétabbakat hoztak létre az előtagjainkhoz, egy speciálisan létrehozott AS_PATH-t használtak. Ezt az AS_PATH-t azonban egyik korábbi útvonalunkról sem lehetett átvenni. Még az AS6762-vel sem kommunikálunk. Az incidens többi útvonalát tekintve néhányuknak valódi AS_PATH-ja volt, amelyet korábban használtak, míg másoknak nem, még ha úgy néz ki, mint az igazi. Az AS_PATH módosításának ráadásul nincs gyakorlati értelme, mivel a forgalmat úgyis átirányítják a támadóhoz, de a „rossz” AS_PATH-val rendelkező útvonalakat ASPA vagy bármely más ellenőrzési mechanizmus kiszűrheti. Itt a gépeltérítő motivációjára gondolunk. Jelenleg nincs elegendő információnk annak megerősítésére, hogy ez az incidens tervezett támadás volt. Ennek ellenére lehetséges. Próbáljunk meg elképzelni egy, bár még hipotetikus, de potenciálisan egészen valós helyzetet.
Tökéletes támadás
Amink van? Tegyük fel, hogy Ön tömegközlekedés-szolgáltató, aki útvonalakat sugároz ügyfelei számára. Ha ügyfelei többszörös jelenléttel (multihome) rendelkeznek, akkor a forgalmuk csak egy részét kapja meg. De minél nagyobb a forgalom, annál több a bevétele. Tehát ha elkezdi hirdetni ugyanazon útvonalak alhálózati előtagjait ugyanazzal az AS_PATH-val, akkor megkapja a forgalmuk többi részét. Ennek eredményeként a többi pénzt.
Segít itt a ROA? Talán igen, ha úgy dönt, hogy teljesen abbahagyja a használatát . Ezenkívül nagyon nem kívánatos, hogy a ROA rekordok metsző előtagokkal legyenek. Egyes szolgáltatók számára az ilyen korlátozások elfogadhatatlanok.
Figyelembe véve a többi útválasztási biztonsági mechanizmust, az ASPA ebben az esetben sem segít (mivel az AS_PATH-t egy érvényes útvonalból használja). A BGPSec még mindig nem optimális megoldás az alacsony elfogadási arány és a leminősítési támadások fennmaradó lehetősége miatt.
Tehát egyértelmű előnyünk van a támadó számára, és a biztonság hiánya. Remek keverék!
Mit tegyek?
A kézenfekvő és legdrasztikusabb lépés az aktuális útválasztási szabályzat felülvizsgálata. Bontsa fel címterét a hirdetni kívánt legkisebb részekre (átfedések nélkül). Csak ezekre írja alá a ROA-t, a maxLength paraméter használata nélkül. Ebben az esetben a jelenlegi POV megmentheti Önt egy ilyen támadástól. Egyes üzemeltetők számára azonban ez a megközelítés nem ésszerű, mivel kizárólag specifikusabb útvonalakat használnak. A ROA és az útvonalobjektumok jelenlegi állapotával kapcsolatos összes problémát leírjuk valamelyik jövőbeli anyagunkban.
Ezenkívül megpróbálhatja figyelemmel kísérni az ilyen elfogásokat. Ehhez megbízható információkra van szükségünk az előtagjairól. Így, ha BGP-munkamenetet hoz létre gyűjtőnkkel, és tájékoztatást ad nekünk az internetes láthatóságáról, akkor más incidensekre is lehetőség nyílik. Azok számára, akik még nem csatlakoztak felügyeleti rendszerünkhöz, kezdésként elég lesz egy útvonallista csak az Ön előtagjaival. Ha van velünk egy munkamenet, kérjük, ellenőrizze, hogy az összes útvonalat elküldte-e. Sajnos ezt érdemes megjegyezni, mert egyes operátorok elfelejtenek egy-két előtagot, és így beavatkoznak a keresési módszereinkbe. Ha helyesen csinálja, megbízható adatokkal rendelkezünk az előtagjairól, amelyek a jövőben segítenek nekünk automatikusan azonosítani és észlelni ezt (és más típusú) forgalomelfogást a címterében.
Ha a forgalom ilyen, valós idejű elhallgatását észleli, megpróbálhatja saját maga ellensúlyozni. Az első megközelítés az, hogy saját maga hirdeti az útvonalakat ezekkel a pontosabb előtagokkal. Ha új támadás éri ezeket az előtagokat, ismételje meg.
A második megközelítés az, hogy megbünteti a támadót és azokat, akik számára kritikus pont (jó útvonalak esetén), azáltal, hogy elzárja az útvonalak hozzáférését a támadóhoz. Ezt úgy teheti meg, hogy hozzáadja a támadó ASN-jét a régi útvonalak AS_PATH-jához, és így arra kényszeríti őket, hogy elkerüljék az AS-t a BGP beépített hurokészlelési mechanizmusával. .
Forrás: will.com