13. března byla pracovní skupině RIPE pro potírání zneužívání předložena zvážit BGP přepadení (hjjack) jako porušení politiky RIPE. Pokud by byl návrh přijat, internetový poskytovatel napadený přepadením provozu by měl možnost zaslat speciální žádost na odhalení útočníka. Pokud odborná skupina shromáždí dostatek potvrzujících důkazů, takový LIR, který je zdrojem BGP přepadení, by byl považován za porušitele a mohl by být zbaven statusu LIR. Byly zde i některé argumenty změně.
V tomto článku chceme ukázat příklad útoku, kdy nebyl zpochybňován pouze skutečný útočník, ale také celý seznam postižených prefixů. Navíc tento útok opět vyvolává otázky o motivech budoucích přepadení provozu tohoto typu.
Poslední dva roky byly v tisku jako BGP přepadení zdůrazňovány pouze konflikty typu MOAS (Multiple Origin Autonomous System). MOAS je specifický případ, kdy dvě různé autonomní systémy inzerují konfliktní prefixy s odpovídajícími čísly ASN v AS_PATH (první ASN v AS_PATH se dále nazývá origin ASN). Nicméně můžeme pojmenovat alespoň přepadení provozu, které umožňují útočníkovi manipulovat s atributem AS_PATH různými cíli, včetně obcházení současných přístupů k filtrování a monitorování. Známý typ útoku je poslední typ takového přepadení, ale nikoli bezvýznamný. Je velmi pravděpodobné, že právě takový útok jsme sledovali v posledních týdnech. Tato událost má vysvětlitelný charakter a dostatečně vážné důsledky.
Ti, kdo hledají verzi TL;DR, se mohou posunout k podnadpisu „Ideální útok“.
Síťové pozadí
(abyste lépe rozuměli procesům zúčastněných v tomto incidentu)
Pokud chcete odeslat paket a máte několik prefixů v tabulce směrování obsahujících cílovou IP adresu, použijete pro prefix s maximální délkou. Pokud však existuje několik různých tras pro jeden prefix v tabulce směrování, vyberete nejlepší (v souladu se mechanismem výběru nejlepší cesty).
Existující přístupy k filtrování a monitorování se snaží analyzovat trasy a přijímat rozhodnutí na základě analýzy atributu AS_PATH. Směrovač může tento atribut změnit na libovolnou hodnotu při anoncování. Jednoduché přidání ASN vlastníka na začátek AS_PATH (jako originální ASN) může být dostačující pro obcházení stávajících mechanismů ověřování zdroje. Navíc, pokud existuje trasa od napadeného ASN k vám, vzniká možnost extrahovat a použít AS_PATH této trasy ve vašich dalších anoncích. Jakékoli ověřování pouze AS_PATH pro vaše vygenerované anonce nakonec bude projít.
Existuje také několik dalších významných omezení. Za prvé, v případě filtrování prefixů vyšším poskytovatelem může být vaše trasa stále filtrována (i s platným AS_PATH), pokud prefix nepatří do vašeho zákaznického kužele, nastaveného u upstreamu. Za druhé – platný AS_PATH se může stát neplatným, pokud je vytvořená trasa anoncována nesprávnými směry a tím porušuje routingovou politiku. A nakonec – jakákoli trasa s prefixem, který porušuje ROA délku, může být považována za neplatnou.
Incident
Před několika týdny jsme obdrželi stížnost od jednoho z uživatelů. Viděli jsme trasy s jeho originálním ASN a prefixy /25, zatímco uživatel tvrdil, že je neanoncoval.
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|NEÚPLNÉ|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|NEÚPLNÉ|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|NEÚPLNÉ|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|NEÚPLNÉ|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|NEÚPLNÉ|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|NEÚPLNÉ|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|NEÚPLNÉ|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|NEÚPLNÉ|xxx|0|0||NAG||
Příklady anoncí na začátku dubna 2019
NTT na cestě pro prefix /25 činí tento obzvlášť podezřelým. Během incidentu LG NTT o této trase nevěděl. Takže ano, nějaký operátor vytváří celý AS_PATH pro tyto prefixy! Ověření na jiných směrovačích umožňuje vyzdvihnout jeden zvláš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 uhodnout, co není v pořádku
Zdá se, že někdo vzal prefix z trasy, rozdělil ho na dvě části a anoncoval trasu se stejným AS_PATH pro tyto dva prefixy.
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říklady tras pro jeden z párů rozdělených prefixů
Objevuje se několik otázek. Zkoušel někdo skutečně v praxi tento typ zachycení? Přijal někdo tyto trasy? Jaké prefixy byly ovlivněny?
Tady začíná naše řada neúspěchů a další kolo zklamání v aktuálním stavu zdraví Internetu.
Cesta neúspěchů
O všem postupně. Jak můžeme určit, které směrovače přijaly takto zachycené trasy a čí provoz může být přesměrován už dnes? Rozhodli jsme se začít s prefixy /25, protože „jednoduše nemohou mít globální dosah“. Jak můžete hádat, silně jsme se mýlili. Tato metrika se ukázala jako příliš zkreslená a trasy s takovými prefixy se mohou objevovat i u operátorů Tier-1. Například NTT má přibližně 50 takových prefixů, které šíří svým vlastním klientům. Na druhou stranu, tato metrika je špatná, protože takové prefixy mohou být filtrované, pokud operátor aplikuje , ve všech směrech. Proto taková metoda není vhodná pro hledání všech operátorů, jejichž provoz byl přesměrován v důsledku podobného incidentu.
Další dobrý nápad se nám zdál pohlédnout na . Zejména na trasy s porušením pravidla maxLength příslušného ROA. Tímto způsobem bychom mohli najít počet různých originálních ASN se statusem Invalid, které byly viditelné dané AS. Nicméně, existuje „malý“ problém. Průměr (medián a moda) tohoto čísla (počet různých originálních ASN) činí přibližně 150 a i když odfiltrujeme malé prefixy, zůstane nad 70. Taková situace má docela jednoduché vysvětlení: existuje jen několik operátorů, kteří již aplikují ROA filtry s politikou „resetovat Invalid trasy“ na vstupních bodech, takže ať už se v reálném světě objeví jakákoli trasa s porušením ROA, může se šířit ve všech směrech.
Poslední dva přístupy umožňují najít operátory, kteří viděli náš incident (protože byl dost velký), ale celkově jsou nepraktické. Dobře, ale můžeme najít útočníka? Jaké jsou obecné charakteristiky takové manipulace AS_PATH? Existuje několik základních předpokladů:
- Prefix nebyl dříve nikde zaznamenán;
- Origin ASN (připomínka: první ASN v AS_PATH) je platný;
- Poslední ASN v AS_PATH je ASN útočníka (v případě, že jeho soused kontroluje ASN souseda na všech příchozích trasách);
- Útok pochází od jednoho poskytovatele.
Pokud jsou všechny předpoklady správné, na všech nesprávných trasách bude představen ASN útočníka (kromě originálního ASN) a to je takzvaný „kritický“ bod. Mezi skutečnými únosci byl i AS263444, i když byly i další. I když jsme vyloučili trasy incidentu z úvahy. Proč? Kritický bod může zůstat kritický i pro správné trasy. Mohou být výsledkem špatné konektivity v nějakém regionu nebo omezení naší vlastní viditelnosti.
Jaký je výsledek: existuje způsob, jak detekovat útočníka, ale pouze v případě splnění všech výše zmíněných podmínek a pouze když je zachycení dostatečně velké pro překročení monitorovacího prahu. Pokud některé z těchto faktorů nejsou splněny, můžeme identifikovat prefixy, které byly tímto zachycením postiženy? Pro určité operátory – ano.
Když útočník vytvoří more specific trasu, takový prefix není oznámen skutečným vlastníkem. Pokud máte od něj dynamický seznam všech jeho prefixů, vzniká možnost provést srovnání a najít zkreslené more specific trasy. Tento seznam prefixů shromažďujeme pomocí našich BGP sezení, protože nám předávají nejen kompletní seznam tras, které jsou operátorovi aktuálně viditelné, ale také seznam všech prefixů, které chce oznámit světu. Bohužel nyní existuje několik desítek uživatelů Radar, kteří tuto poslední část neprovádějí zcela správně. V nejbližší době je budeme informovat 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, útočníka a oblast rozšíření jsme objevili pomocí hledání kritických bodů. Je překvapivé, že AS263444 rozesílal falšované trasy ne všem svým klientům. Ale existuje i podivnější aspekt.
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 o zachycení našeho adresního prostoru
Když byly vytvořeny more specific pro naše prefixy, byla použita speciálně vytvořená AS_PATH. Tento AS_PATH však nemohl být převzat z žádné z našich předchozích tras. Dokonce nemáme spojení s AS6762. Podíváme se na další trasy v incidentu: některé z nich měly skutečný AS_PATH, který byl používán dříve, a jiné ne, i když vypadaly jako skutečné. Další změna AS_PATH nemá praktický smysl, protože v každém případě bude provoz přesměrován na útočníka, ale trasy se „špatným“ AS_PATH mohou být filtrovány ASPA nebo jakýmkoli jiným mechanismem kontroly. Zde jsme se zamysleli nad motivací únosce. V současné době nám chybí data abychom mohli tvrdit, že tento incident byl plánovaným útokem. Nicméně — je to možné. Pojďme se pokusit představit si alespoň hypotetickou, ale potenciálně docela reálnou situaci.
Ideální útok
Co máme? Představme si, že jste tranzitní poskytovatel, který vysílá trasy pro své klienty. Pokud mají vaši klienti vícero přítomností (multihome), získáte pouze část jejich provozu. Ale čím více provozu, tím větší váš příjem. Proto, pokud začnete oznamovat prefixy podsítí těchto stejných tras se stejným AS_PATH, získáte zbytek jejich provozu. V důsledku toho i zbytek peněz.
Pomůže zde ROA? Možná, ano, pokud se rozhodnete zcela vzdát použití . Kromě toho je v tomto případě velmi nežádoucí mít záznamy ROA s překrývajícími se prefixy. Pro některé operátory jsou taková omezení nepřijatelná.
Při zvažování dalších mechanismů zajištění bezpečnosti routování, ASPA v tomto případě také nepomůže (protože se používá AS_PATH z povolené trasy). BGPSec stále není optimální volbou kvůli nízkému procentu přijetí a zůstávající možnosti downgrade útoků.
Takže máme jasný zisk pro útočníka a nedostatek bezpečnosti. Skvělá směs!
Co dělat?
Zřejmým a nejradikálnějším krokem je přehodnocení vaší současné politiky směrování. Rozdělte své adresní prostory na co nejmenší části (bez překryvů), které chcete oznámit. Podepište ROA jen pro ně, aniž byste používali parametr maxLength. V tomto případě vám současný POV může pomoci chránit se před podobným útokem. Opět však pro některé operátory takový přístup není rozumný kvůli výjimečnému používání more specific tras. Všechny problémy současného stavu ROA a objekty tras budou popsány v některém z našich budoucích materiálů.
Kromě toho se můžete pokusit monitorovat podobné přepady. K tomu potřebujeme spolehlivé informace o vašich prefixech. Pokud tedy nastavíte BGP seanci s naším sběračem a předáte nám informace o vaší viditelnosti na internetu, můžeme najít oblast rozšíření i pro další incidenty. Pro ty, kteří ještě nejsou připojeni k našemu monitorovacímu systému, nám zpočátku bude stačit seznam tras pouze vašich prefixů. Pokud však již máte seanci s námi, prosím, zkontrolujte, že byly odeslány všechny vaše trasy. Bohužel o tom musíme připomenout, protože část operátorů zapomíná na jeden nebo dva prefixy a tím vytváří problémy pro naše vyhledávací metody. Pokud se vše udělá správně, budou mít spolehlivé údaje o vašich prefixech, které v budoucnu pomohou automaticky identifikovat a detekovat tento (a jiné) typy přepady provozu pro vaše adresní prostory.
Pokud se v reálném čase dozvíte o takovém přepadu vašeho provozu, můžete se pokusit protivzoručit sami. Prvním přístupem je oznámit trasy s těmito more specific prefixy samostatně. V případě nového útoku na tyto prefixy zopakujte.
Druhým přístupem je potrestat útočníka a ty, pro které je kritickým bodem (pro dobré trasy), tím, že odříznete přístup vašich tras k útočníku. To lze provést přidáním ASN útočníka do AS_PATH vašich starých tras a tím je donutit vyhnout se této AS pomocí vestavěného mechanismu detekce cyklů v BGP. .
Zdroj: habr.com
