13. března do pracovní skupiny RIPE proti zneužívání považovat BGP hijacking (hjjack) za porušení zásad RIPE. Pokud by byl návrh přijat, měl by poskytovatel internetu napadený zachycováním provozu možnost odeslat speciální požadavek na odhalení útočníka. Pokud hodnotící tým shromáždí dostatečné podpůrné důkazy, bude LIR, který byl zdrojem zachycení BGP, považován za narušitele a mohl by být zbaven svého statusu LIR. Objevily se i nějaké argumenty Změny.
V této publikaci chceme ukázat příklad útoku, kdy se jednalo nejen o skutečného útočníka, ale také o celý seznam postižených prefixů. Navíc takový útok opět vyvolává otázky po motivech budoucích odposlechů tohoto typu provozu.
Za posledních pár let byly v tisku jako odposlechy BGP popsány pouze konflikty jako MOAS (Multiple Origin Autonomous System). MOAS je speciální případ, kdy dva různé autonomní systémy inzerují konfliktní předpony s odpovídajícími ASN v AS_PATH (první ASN v AS_PATH, dále jen původní ASN). Můžeme však jmenovat alespoň zachycování provozu, což umožňuje útočníkovi manipulovat s atributem AS_PATH pro různé účely, včetně obcházení moderních přístupů k filtrování a monitorování. Známý typ útoku - poslední typ takového odposlechu, ale není vůbec důležitý. Je docela možné, že přesně takový útok jsme viděli v posledních týdnech. Taková událost má pochopitelnou povahu a docela vážné důsledky.
Ti, kteří hledají verzi TL;DR, mohou přejít na podtitul „Perfect Attack“.
Pozadí sítě
(aby vám pomohl lépe porozumět procesům souvisejícím s tímto incidentem)
Pokud chcete odeslat paket a máte ve směrovací tabulce s cílovou IP adresou více prefixů, pak použijete cestu pro prefix s nejdelší délkou. Pokud je ve směrovací tabulce několik různých cest pro stejný prefix, vyberete si tu nejlepší (podle mechanismu výběru nejlepší cesty).
Stávající přístupy filtrování a monitorování se pokoušejí analyzovat trasy a rozhodovat se pomocí analýzy atributu AS_PATH. Router může tento atribut během reklamy změnit na libovolnou hodnotu. Pouhé přidání ASN vlastníka na začátek AS_PATH (jako původní ASN) může stačit k obejití aktuálních mechanismů kontroly původu. Navíc, pokud existuje cesta z napadeného ASN k vám, bude možné extrahovat a použít AS_PATH této cesty ve vašich dalších reklamách. Jakákoli kontrola ověření pouze AS_PATH pro vaše vytvořená oznámení nakonec projde.
Stále existuje několik omezení, která stojí za zmínku. Za prvé, v případě filtrování prefixů poskytovatelem upstreamu může být vaše trasa stále filtrována (i se správnou AS_PATH), pokud prefix nepatří do vašeho klientského conu nakonfigurovaného na upstreamu. Za druhé, platná cesta AS_PATH se může stát neplatnou, pokud je vytvořená trasa inzerována v nesprávných směrech a porušuje tak zásady směrování. A konečně, každá trasa s předponou, která porušuje délku ROA, může být považována za neplatnou.
Incident
Před několika týdny jsme obdrželi stížnost od jednoho z našich uživatelů. Viděli jsme trasy s jeho původem ASN a prefixy /25, zatímco uživatel tvrdil, že je neinzeroval.
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říklady oznámení pro začátek dubna 2019
NTT v cestě pro předponu /25 je obzvláště podezřelé. Společnost LG NTT o této trase v době incidentu nevěděla. Takže ano, nějaký operátor vytvoří celou AS_PATH pro tyto předpony! Kontrola na jiných směrovačích odhalí jedno konkrétní ASN: AS263444. Když jsme se podívali na další trasy s tímto autonomním systémem, narazili jsme na následující situaci:
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||
Zkuste hádat, co je tady špatně
Zdá se, že někdo vzal předponu z trasy, rozdělil ji na dvě části a inzeroval cestu se stejnou AS_PATH pro tyto dvě předpony.
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říklad tras pro jeden z rozdělených párů prefixů
Vyvstává několik otázek najednou. Vyzkoušel někdo skutečně tento typ odposlechu v praxi? Jezdil někdo těmito cestami? Jaké předpony byly ovlivněny?
Zde začíná naše řada selhání a další kolo zklamání ze současného stavu zdraví internetu.
Cesta neúspěchu
Pěkně popořádku. Jak můžeme určit, které směrovače přijaly takto zachycené trasy a jejichž provoz by dnes mohl být přesměrován? Mysleli jsme, že začneme s předponami /25, protože „prostě nemohou mít globální distribuci“. Jak správně tušíte, velmi jsme se mýlili. Tato metrika se ukázala jako příliš hlučná a trasy s takovými předponami se mohou objevit i od operátorů úrovně 1. Například NTT má asi 50 takových prefixů, které distribuuje vlastním klientům. Na druhou stranu je tato metrika špatná, protože takové předpony lze odfiltrovat, pokud je operátor používá , v každém směru. Tato metoda tedy není vhodná pro vyhledání všech operátorů, jejichž provoz byl v důsledku takového incidentu přesměrován.
Další dobrý nápad, který jsme si mysleli, bylo podívat se . Zejména pro trasy, které porušují pravidlo maxLength odpovídající ROA. Tímto způsobem jsme mohli zjistit počet různých původních ASN se stavem Neplatné, které byly viditelné pro daný AS. Je tu však „malý“ problém. Průměr (medián a modus) tohoto čísla (počet různých výchozích ASN) je asi 150 ai když odfiltrujeme malé prefixy, zůstane nad 70. Tento stav má velmi jednoduché vysvětlení: existují pouze několik operátorů, kteří již používají filtry ROA se zásadou „resetování neplatných tras“ ve vstupních bodech, takže kdekoli se v reálném světě objeví trasa s porušením ROA, může se šířit všemi směry.
Poslední dva přístupy nám umožňují najít operátory, kteří viděli náš incident (protože byl poměrně velký), ale obecně je nelze použít. Dobře, ale můžeme najít vetřelce? Jaké jsou obecné rysy této manipulace AS_PATH? Existuje několik základních předpokladů:
- Předpona nebyla předtím nikde vidět;
- Původní ASN (připomenutí: první ASN v AS_PATH) je platné;
- Poslední ASN v AS_PATH je útočníkovo ASN (v případě, že jeho soused kontroluje sousedovo ASN na všech příchozích trasách);
- Útok pochází od jediného poskytovatele.
Pokud jsou všechny předpoklady správné, pak všechny nesprávné cesty budou prezentovat útočníkovo ASN (kromě původního ASN), a proto se jedná o „kritický“ bod. Mezi skutečnými únosci byl AS263444, i když byli i jiní. I když jsme nehodové trasy vyřadili z úvahy. Proč? Kritický bod může zůstat kritický i pro správné trasy. Může to být buď důsledkem špatné konektivity v regionu nebo omezení naší vlastní viditelnosti.
Výsledkem je, že existuje způsob, jak odhalit útočníka, ale pouze v případě, že jsou splněny všechny výše uvedené podmínky a pouze v případě, že je zachycení dostatečně velké na to, aby překročilo prahové hodnoty monitorování. Pokud některé z těchto faktorů nejsou splněny, pak můžeme identifikovat předpony, které trpěly takovým zachycením? Pro určité operátory - ano.
Když útočník vytvoří specifičtější trasu, skutečný vlastník takovou předponu neinzeruje. Pokud z něj máte dynamický seznam všech jeho prefixů, pak je možné provést srovnání a najít zkreslené konkrétnější trasy. Tento seznam prefixů shromažďujeme pomocí našich relací BGP, protože dostáváme nejen úplný seznam tras, které operátor právě vidí, ale také seznam všech prefixů, které chce propagovat světu. Bohužel je nyní několik desítek uživatelů Radaru, kteří poslední část nedokončí správně. Brzy je upozorníme a pokusíme se tento problém vyřešit. Všichni ostatní se mohou připojit k našemu monitorovacímu systému právě teď.
Pokud se vrátíme k původnímu incidentu, jak útočníka, tak distribuční oblast jsme detekovali hledáním kritických bodů. Překvapivě AS263444 neposílal vymyšlené trasy všem svým klientům. I když je tu ještě podivnější moment.
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||
Nedávný příklad pokusu zachytit náš adresní prostor
Když byly vytvořeny specifičtější pro naše prefixy, byla použita speciálně vytvořená AS_PATH. Tato AS_PATH však nemohla být převzata z žádné z našich předchozích tras. Nemáme ani komunikaci s AS6762. Když se podíváme na ostatní cesty v incidentu, některé z nich měly skutečnou AS_PATH, která byla dříve používána, zatímco jiné ne, i když to vypadá jako skutečná. Změna AS_PATH navíc nedává žádný praktický smysl, protože provoz bude stejně přesměrován na útočníka, ale cesty se „špatnou“ AS_PATH lze filtrovat pomocí ASPA nebo jiného kontrolního mechanismu. Zde přemýšlíme o motivaci únosce. V současné době nemáme dostatek informací, abychom potvrdili, že tento incident byl plánovaný útok. Přesto je to možné. Zkusme si představit, byť stále hypotetickou, ale potenciálně zcela reálnou situaci.
Perfektní útok
Co máme? Řekněme, že jste poskytovatelem tranzitních vysílacích tras pro své klienty. Pokud mají vaši klienti vícenásobnou přítomnost (multihome), budete dostávat pouze část jejich návštěvnosti. Ale čím větší provoz, tím větší příjem. Pokud tedy začnete inzerovat předpony podsítě těchto stejných tras se stejnou AS_PATH, obdržíte zbytek jejich provozu. V důsledku toho zbytek peněz.
Pomůže zde ROA? Možná ano, pokud se rozhodnete jej úplně přestat používat . Kromě toho je vysoce nežádoucí mít záznamy ROA s protínajícími se předponami. Pro některé operátory jsou taková omezení nepřijatelná.
Vzhledem k dalším mechanismům zabezpečení směrování v tomto případě nepomůže ani ASPA (protože používá AS_PATH z platné cesty). BGPSec stále není optimální volbou kvůli nízké míře přijetí a zbývající možnosti útoků na nižší verzi.
Máme tedy jasný zisk pro útočníka a nedostatek zabezpečení. Skvělý mix!
Co mám dělat?
Zřejmým a nejdrastičtějším krokem je přezkoumat vaši aktuální politiku směrování. Rozdělte svůj adresní prostor na nejmenší části (bez překrývání), které chcete inzerovat. Podepište ROA pouze pro ně, bez použití parametru maxLength. V tomto případě vás vaše aktuální POV může zachránit před takovým útokem. Pro některé operátory však tento přístup opět není rozumný kvůli výhradnímu používání specifičtějších tras. Všechny problémy se současným stavem ROA a trasovými objekty budou popsány v některém z našich budoucích materiálů.
Navíc se můžete pokusit takové odposlechy sledovat. K tomu potřebujeme spolehlivé informace o vašich prefixech. Pokud tedy navážete relaci BGP s naším sběratelem a poskytnete nám informace o vaší viditelnosti na internetu, můžeme najít prostor pro další incidenty. Pro ty, kteří ještě nejsou připojeni k našemu monitorovacímu systému, bude pro začátek stačit seznam tras pouze s vašimi prefixy. Pokud s námi máte schůzku, zkontrolujte, zda byly odeslány všechny vaše trasy. Bohužel to stojí za zapamatování, protože některé operátory zapomínají předponu nebo dvě a tím narušují naše vyhledávací metody. Pokud to uděláte správně, budeme mít spolehlivá data o vašich prefixech, která nám v budoucnu pomohou automaticky identifikovat a detekovat tento (a další) typy zachycování provozu pro váš adresní prostor.
Pokud se o takovém zachycení vašeho provozu dozvíte v reálném čase, můžete se mu pokusit čelit sami. Prvním přístupem je inzerovat trasy s těmito specifičtějšími předponami sami. V případě nového útoku na tyto prefixy opakujte.
Druhým přístupem je potrestat útočníka a ty, pro které je kritickým bodem (pro dobré cesty), odříznutím přístupu vašich cest k útočníkovi. Toho lze dosáhnout přidáním ASN útočníka do AS_PATH vašich starých tras a tím je přinutíte, aby se tomuto AS vyhnuli pomocí vestavěného mechanismu detekce smyčky v BGP. .
Zdroj: www.habr.com