Március 13-án a RIPE csoportban az visszaélések ellen a BGP elfogás (hjjack) RIPE szabályszegésként való kezelésére. A javaslat elfogadása esetén a támadott internet-szolgáltató külön kérvényt nyújthatna be a támadó leleplezésére. Ha a szakértői csoport elegendő bizonyítékot gyűjt, akkor az ilyen BGP elfogást előidéző LIR megsértőnek számítana, és megfoszthatják LIR státuszától. Volt néhány érv változtatás ellen.
A következő publikációban példát szeretnénk bemutatni egy olyan támadásra, ahol nemcsak a valódi támadó, hanem az összes érintett prefix lista is kérdéses volt. Sőt, egy ilyen támadás újra felveti a kérdéseket a jövőbeli ilyen típusú forgalomelfogások indítékait illetően.
Az elmúlt néhány évben a sajtóban a BGP elfogásokat csak MOAS (Több Eredetű Autonóm Rendszer) típusú konfliktusok formájában tárgyalták. A MOAS egy különleges eset, amikor két különböző autonóm rendszer ellentmondó prefixeket hirdet meg a megfelelő ASN számokkal az AS_PATH-ban (az AS_PATH első ASN-jét a továbbiakban origin ASN-nek hívjuk). Azonban legalább is megemlíthetjük a forgalom elfogásának, amelyek lehetővé teszik a támadók számára, hogy manipulálják az AS_PATH attribútumot különböző céllal, beleértve a modern szűrési és megfigyelési megközelítések megkerülését. Az ismert támadási típus, — az ilyen típusú elfogás legújabb változata, de nem kevesebb jelentőséggel bír. Nagyon valószínű, hogy éppen egy ilyen támadás tanúi voltunk az elmúlt hetekben. Az esemény érthető, és komoly következményekkel jár.
Akik a TL;DR verziót keresik, görgessenek le a "Tökéletes támadás" alcímhez.
Hálózati háttér
(hogy jobban megértsék az adott incidensben részt vevő folyamatokat)
Ha csomagot kíván küldeni, és több prefix is szerepel az útválasztási táblában, amelyek tartalmazzák az IP-címet, akkor a maximális hosszúságú prefix útvonalát fogja használni. Ha azonban az útválasztási táblában több eltérő útvonal is létezik ugyanahhoz a prefixhez, akkor a legjobbat választja (a legjobb útvonalválasztási mechanizmus értelmében).
A létező szűrési és megfigyelési megközelítések próbálják elemezni az útvonalakat, és döntéseket hozni az AS_PATH attribútum elemzésével. A router megváltoztathatja ezt az attribútumot bármilyen értékre a hirdetés során. Elég lehet, ha a tulajdonos ASN-t az AS_PATH elejére hozzáadjuk (mint eredeti ASN), hogy megkerüljük a jelenlegi forrásellenőrzési mechanizmusokat. Továbbá, ha van egy útvonal a megtámadott ASN-tól hozzánk, lehetőség nyílik az AS_PATH eltávolítására és használatára más hirdetéseinkben. Bármilyen érvényességi ellenőrzés, amely csak az AS_PATH-ra vonatkozik a saját hirdetett útvonalainknál, végül át fog menni.
Még néhány említésre méltó korlátozás létezik. Először is, a felsőbb szolgáltató által végzett prefix szűrés esetén az útvonalad még mindig kiszűrhető (még a helyes AS_PATH esetén is), ha a prefix nem tartozik az upstream-nél beállított ügyfélkúpodhoz. Másodszor, egy érvényes AS_PATH érvénytelenné válhat, ha a létrehozott útvonalat helytelen irányokban hirdetik, így megszegve a forgalomirányítási politikát. Végül, bármilyen útvonal, amelynek prefixe megszegi a ROA hosszát, érvénytelennek tekinthető.
Incidens
Néhány héttel ezelőtt egy felhasználónktól panaszt kaptunk. Olyan útvonalakat láttunk az origin ASN-jével és /25 prefixekkel, 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|HIÁNYZIK|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|HIÁNYZIK|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|HIÁNYZIK|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|HIÁNYZIK|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|HIÁNYZIK|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|HIÁNYZIK|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|HIÁNYZIK|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|HIÁNYZIK|xxx|0|0||NAG||
Hirdetési példák 2019 áprilisának elejéről
Az NTT útvonala a /25 prefixhez különösen gyanússá teszi. Az incidens alatt az LG NTT semmit nem tudott erről az útvonalról. Szóval igen, valaki létrehoz egy teljes AS_PATH-ot ezekhez a prefixekhez! Más routereken végzett ellenőrzés lehetővé teszi egy különleges ASN kiemelését: AS263444. Más, ezzel az autonóm rendszerről származó útvonalak megvizsgálva a következő helyzetbe kerültek:
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 nem stimmel itt
Úgy tűnik, hogy valaki egy útvonal prefixét vette, kettévágta, és ugyanazzal az AS_PATH-dal hirdette ezt a két prefixet.
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||
Az egyik pár pontosan elválasztott prefix hirdetési példái
Több kérdés is felmerül. Valóban próbálta valaki ezt a fajta lehallgatást a gyakorlatban? Valaki elfogadta ezeket az útvonalakat? Milyen prefixek voltak érintve?
Itt kezdődik a kudarcaink sorozata és egy újabb csalódás a jelenlegi internetes egészségügyi állapotban.
A kudarcok útja
Mindent sorjában. Hogyan határozhatjuk meg, hogy mely routerek fogadták el ezeket a lehallgatott útvonalakat és kinek a forgalma irányítható már ma? Azt gondoltuk, hogy az /25 prefixekkel érdemes kezdeni, mert ezek "egyszerűen nem lehetnek globális eloszlásúak". Ahogy sejthető — nagyon tévedtünk. Ez a metrika túl zajos volt, és az ilyen prefixek akár Tier-1 szolgáltatóktól is megjelenhetnek. Például az NTT-nek körülbelül 50 ilyen prefixe van, amelyeket a saját ügyfeleinek terjeszt. Más részről azonban ez a metrika gyenge, mert az ilyen prefixek kiszűrhetők, ha a szolgáltató alkalmazza , minden irányba. Ezért ez a módszer nem alkalmas arra, hogy megtaláljuk az összes szolgáltatót, akinek a forgalma egy ilyen esemény következtében átirányításra került.
Egy másik jó ötletnek tűnt megnézni a . Különösen a maxLength szabályt megsértő útvonalakra. Így megtalálhatnánk azokat a különböző origin ASN-eket, amelyek Invalid státuszúak, és amelyek láthatóak voltak az adott AS számára. Azonban van egy "kis" probléma. Ennek az értéknek (a különböző origin ASN-ek számának) az átlag (medián és mód) körülbelül 150, és még ha kiszűrjük is a kis prefixeket, akkor is 70 felett marad. Ennek az állapotnak meglehetősen egyszerű magyarázata van: nagyon kevés szolgáltató alkalmaz ROA-szűrőket az "Invalid útvonalak visszavonására" a belépési pontokon, ezért bármikor, amikor a valós világban olyan útvonal jelenik meg, amely megsérti a ROA-t, az minden irányban terjedhet.
Az utolsó két megközelítés lehetővé teszi, hogy megtaláljuk azokat a szolgáltatókat, akik észlelték a mi incidensünket (mivel az elég nagy volt), de összességében nem alkalmazhatóak. Rendben, de megtalálhatjuk a támadót? Mik a AS_PATH manipulációjának általános jellemzői? Van néhány alapvető feltételezés:
- A prefix korábban sehol nem volt észlelve;
- Az Origin ASN (emlékeztető: az első ASN az AS_PATH-ban) érvényes;
- Az AS_PATH utolsó ASN-je a támadó ASN-je (ha a szomszédja ellenőrzi a szomszéd ASN-jét minden bejövő útvonalon);
- A támadás egy szolgáltatótól származik.
Ha minden feltevés helyes, akkor minden hibás útvonalon megjelenik a támadó ASN (az origin ASN kivételével), így ez „kritikus” pontnak számít. Az igazi elrablók között található az AS263444, de voltak mások is. Még amikor az incidens útvonalait kizártuk a vizsgálatból. Miért? A kritikus pont kritikus maradhat a helyes útvonalak esetén is. Ez lehet a rossz összeköttetés eredménye egy régióban, vagy a saját láthatóságunk korlátozása.
Ennek eredményeként van mód a támadó felfedezésére, de csak abban az esetben, ha minden felsorolt feltétel teljesül, és csak akkor, ha a megfigyeléshez elegendő méretű az elfogás. Ha azonban ezek közül bármelyik tényező nem teljesül, kiemelhetjük a hasonló elfogás miatt érintett prefixeket? Bizonyos szolgáltatók esetében – igen.
Amikor a támadó létrehoz egy konkrétabb útvonalat, azt a valódi tulajdonos nem hirdeti meg. Ha rendelkezésére áll egy dinamikus lista az összes prefixéről, lehetőség van összehasonlítani és megtalálni a torzított konkrétabb útvonalakat. Ezt a prefixek listáját a BGP-sessionjeink segítségével gyűjtjük, mivel nemcsak a jelenleg látható útvonalak teljes listáját kapjuk az üzemeltetőtől, hanem azt is, hogy mely prefixeket szeretné a világ felé hirdetni. Sajnos jelenleg több tucat Radar felhasználó van, aki ezt az utolsó részt nem teljesíti megfelelően. A közeljövőben értesítjük őket, és próbáljuk megoldani ezt a problémát. Mindenki más azonnal csatlakozhat a megfigyelési rendszerünkhöz.
Ha visszatérünk az eredeti eseményhez, a támadó és a terjedési terület felfedezésére a kritikus pontok keresésével került sor. Meglepetés, de az AS263444 nem mindenkinek küldött hamisított útvonalakat. Bár van egy még furcsább dolog 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||
A közelmúlt egy példája a címterületünk elfogásának kísérlete
Amikor a prefixeinkhez létrehoztuk a specifikus ‘more specific’ címkéket, akkor egy különösen létrehozott AS_PATH-ot használtunk. Azonban ezt az AS_PATH-ot nem lehetett felhasználni egyik korábbi útvonalunkban sem. Még az AS6762-höz sincs kapcsolatunk. Nézzük meg az incidens más útvonalait: egyeseknek valódi AS_PATH-juk volt, amelyet korábban használtak, másoknak viszont nem, még akkor is, ha úgy néztek ki, mint egy valódi AS_PATH. Az AS_PATH további módosítása semmilyen gyakorlati értelmet nem hordoz, hiszen a forgalmat így is a támadóhoz fogják irányítani, de a „rossz” AS_PATH-al rendelkező útvonalakat kiszűrheti az ASPA vagy bármely más ellenőrzési mechanizmus. Itt elgondolkodtunk a haszonélvező motivációján. Jelenleg nincsenek adatok arra, hogy ezt az incidenst szándékos támadásnak tekintjük, de ez lehetséges. Próbáljuk elképzelni ezt a potenciálisan reális, még ha jelenleg hipotetikus helyzetet.
Tökéletes támadás
Mit van? Tegyük fel, hogy Ön egy tranzit szolgáltató, aki útvonalakat közvetít az ügyfeleinek. Ha az ügyfelei több kapcsolattal rendelkeznek (multihome), akkor csak a forgalmuk egy részét kapja meg. De minél több a forgalom, annál nagyobb a bevétele. Tehát, ha elkezdi bejelenteni e címek alhálózatainak prefixeit ugyanazzal az AS_PATH-al, megkapja a maradék forgalmat. Ennek következményeként pedig a megmaradt pénzért.
Segít itt a ROA? Talán igen, ha teljesen lemond a használatáról . Ezen kívül rendkívül nem kívánatos, hogy átfedő prefixekkel rendelkező ROA bejegyzéseket tartson. Néhány szolgáltató számára az ilyen korlátozások elfogadhatatlanok.
Más routing biztonsági mechanizmusok figyelembevételével az ASPA sem segít (mivel a megengedett útvonal AS_PATH-ját használják). A BGPSec továbbra is nem optimális lehetőség a kis elfogadási arány és az alászállítási támadások lehetősége miatt.
Így tehát van egy egyértelmű profit a támadó számára és biztonság hiánya. Kiváló keverék!
Mit kell tenni?
Nyilvánvaló és a legradikálisabb lépés a jelenlegi útválasztási politikád felülvizsgálata. Oszd fel az IP-címtérképed a legkisebb darabokra (átfedések nélkül), amelyeket csak szeretnél bejelenteni. Csak ezekre a darabokra írd alá a ROA-t, anélkül, hogy a maxLength paramétert használnád. Ebben az esetben a jelenlegi POV megmenthet egy ilyen támadástól. Ugyanakkor, némely szolgáltató számára ez a megközelítés nem ésszerű a túl specifikus útvonalak kiemelt használata miatt. A ROA és a route objektumok jelenlegi helyzetével kapcsolatos problémákat egy későbbi anyagunkban fogjuk ismertetni.
Ezenkívül megpróbálhatunk monitorozni az ilyen jellegű átvételeket. Ehhez megbízható információra van szükségünk a prefixedről. Tehát, ha BGP munkamenetet állítasz be a gyűjtőnkkel, és átadod nekünk az internetes láthatóságod információját — meg tudjuk határozni a kiterjedés területét és más incidenseket is. Azok számára, akik még nem csatlakoztak a monitoring rendszerünkhöz — az elején elegendő egy lista az útvonalakról, amelyek csak a te prefixedről szólnak. Ha már van munkameneted velünk, kérlek, ellenőrizd, hogy minden útvonaladat elküldték-e. Sajnos ezt érdemes emlékeztetni, mivel egyes szolgáltatók elfelejtenek egy vagy két prefixedet, így zavarokat okoznak a keresési módszereinkben. Ha mindent helyesen csinálsz, megbízható adataink lesznek a prefixedről, amelyek a jövőben automatikusan segítenek az ilyen (és más) típusú forgalomátvételi támadások észlelésében az IP-térképeden.
Ha valós időben értesülsz egy ilyen forgalomeltérítésről, megpróbálhatod saját magad ellensúlyozni. Az első megközelítés az, hogy önállóan bejelented az ilyen típusú, specifikusabb prefixed útvonalait. Újabb támadás esetén ugyanezeket a prefixedet ismételd meg.
A második megközelítés az, hogy megbünteted a támadót és azokat, akik számára kritikus pontot jelentenek (a jó útvonalak esetében), azzal, hogy levágod az útvonalait a támadótól. Ezt úgy érheted el, hogy a támadó ASN-jét hozzáadod a régi útvonalak AS_PATH-jéhez, így arra kényszerítve őket, hogy elkerüljék ezt az AS-t, felhasználva a BGP beépített cikluskereső mechanizmusát. .
Forrás: habr.com
