13. marca sa do pracovnej skupiny RIPE na boj proti zneužívaniu dostal návrh proti tomu zmeny.
Posledné dve roky sa v tlači ako BGP-preberania diskutovali iba konflikty typu MOAS (Multiple Origin Autonomous System). MOAS je špeciálny prípad, keď dve rôzne autonómne systémy oznamujú konfliktujúce prefixy s príslušnými číslami ASN v AS_PATH (prvé ASN v AS_PATH, ďalej v texte - origin ASN). Môžeme však uviesť aspoň
3 ďalšie typy Pilosova-Kapely Tí, ktorí hľadajú verziu TL;DR, si môžu posunúť k podnadpisu „Ideálny útok“.
Sieťový background
(aby ste lepšie chápali procesy zapojené do tohto incidentu)
Ak chcete poslať paket a máte niekoľko prefixov v routovacej tabuľke obsahujúcich cieľovú IP adresu, použijete trasu pre prefix s maximálnou dĺžkou. Ak však existuje v routovacej tabuľke niekoľko rôznych trás pre jeden prefix, vyberiete si tú najlepšiu (podľa mechanizmu výberu najlepšej cesty).
Ak chcete odoslať paket a máte v routovacej tabuľke niekoľko prefixov obsahujúcich cieľovú IP adresu, použijete smerovanie pre prefix s maximálnou dĺžkou. Ak však v routovacej tabuľke existuje niekoľko rôznych smerovaní pre jeden prefix, vyberiete si najlepšie (v súlade s mechanizmom výberu najlepšej cesty).
Existujúce prístupy k filtrovania a monitorovaniu sa snažia analyzovať trasy a prijímať rozhodnutia analýzou atribútu AS_PATH. Smerovač môže zmeniť tento atribút na akúkoľvek hodnotu počas oznamovania. Jednoduché pridanie ASN vlastníka na začiatok AS_PATH (ako origin ASN) môže byť dostatočné na obídenie súčasných mechanizmov overovania zdroja. Navyše, ak existuje trasa od napadnutého ASN k vám, vzniká možnosť vyťažiť a použiť AS_PATH tejto trasy vo vašich ďalších oznámeniach. Akékoľvek overovanie platnosti len AS_PATH pre vaše falošné oznámenia nakoniec prejde.
Ešte existuje niekoľko hodných spomenutia obmedzení. Po prvé, v prípade filtrovania prefixov vyšším poskytovateľom môže byť vaša trasa aj tak odfiltrovaná (aj s korektným AS_PATH), ak prefix nepatrí do vášho klientského kužela nastaveného u upstreamu. Po druhé - platný AS_PATH sa môže stať neplatným, ak vytvorená trasa je oznamovaná v nesprávnych smeroch a teda porušuje politiku smerovania. A nakoniec - akákoľvek trasa s prefixom porušujúcim ROA length môže byť považovaná za neplatnú.
Incident
Pred niekoľkými týždňami sme dostali sťažnosť od jedného z užívateľov. Videli sme trasy s jeho originálnym ASN a prefixmi /25, zatiaľ čo užívateľ tvrdil, že ich neoznamoval.
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||
Príklady oznámení na začiatku apríla 2019
NTT na ceste pre prefix /25 robí jeho obzvlášť podozrivým. Počas incidentu LG NTT nič nevedel o tejto trase. Takže áno, nejaký operátor vytvára celý AS_PATH pre tieto prefixy! Kontrola na iných smerovačoch umožňuje vyzdvihnúť jeden osobitný ASN: AS263444. Pozreli sme sa na iné trasy s touto autonómnou sústavou a stretli sme sa s nasledujúcou situáciou:
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||
Skúste uhádnuť, čo tu nie je v poriadku
Zdá sa, že niekto vzal prefix z trasy, rozdelil ho na dve časti a oznámil trasu s tým istým AS_PATH pre tieto 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||
Príklady trás pre jeden z párov rozdelených prefixov
Vynára sa hneď niekoľko otázok. Skutočne niekto vyskúšal v praxi tento typ zachytenia? Niekto prijal tieto trasy? Aké prefixy boli dotknuté?
Tu a začína naša séria neúspechov a ďalšie kolo sklamania v aktuálnom zdravotnom stave Internetu.
Cesta neúspechov
O všetkom poriadku. Ako môžeme určiť, ktoré smerovače prijali také prepojené trasy a ktorých prevádzka môže byť presmerovaná už dnes? Rozhodli sme sa začať s prefixmi /25, pretože „jednoducho nemôžu mať globálne rozšírenie“. Ako môžete uhádnuť — veľmi sme sa mýlili. Tento ukazovateľ sa ukázal ako príliš šumivý a trasy s takými prefixmi sa môžu objaviť aj od operátorov Tier-1. Napríklad NTT má okolo 50 takých prefixov, ktoré šíri medzi svojich klientov. Na druhej strane, tento ukazovateľ je zlý, pretože také prefixy môžu byť filtrované v prípade, že operátor nasadzuje , vo všetkých smeroch. Preto je tento prístup nevhodný na vyhľadávanie všetkých operátorov, ktorých prevádzka bola presmerovaná v dôsledku takéhoto incidentu.
Ďalším dobrým nápadom sa nám zdalo pozrieť sa na . Najmä na trasy porušujúce pravidlo maxLength príslušného ROA. Takto by sme mohli nájsť počet rôznych originálnych ASN so statusom Invalid, ktoré boli viditeľné pred touto AS. Napriek tomu existuje „malý“ problém. Priemerná hodnota (medián a moda) tohto čísla (počtu rôznych originálnych ASN) je približne 150 a aj keď odfiltrujeme malé prefixy, zostane nad 70. Táto situácia má celkom jednoduché vysvetlenie: existuje len niekoľko operátorov, ktorí už nasadili ROA filtre s politikou „resetovať Invalid trasy“ na vstupných bodoch, takže kdekoľvek vo skutočnom svete sa objaví trasa s porušením ROA, môže sa šíriť vo všetkých smeroch.
Posledné dva prístupy umožňujú nájsť operátorov, ktorí si všimli náš incident (keďže bol dostatočne veľký), ale celkovo sú nepraktické. Dobre, ale môžeme nájsť útočníka? Aké sú všeobecné znaky takej manipulácie AS_PATH? Existuje niekoľko základných predpokladov:
- Prefix nebol predtým nikde zaznamenaný;
- Origin ASN (pripomenutie: prvý ASN v AS_PATH) je platný;
- Posledný ASN v AS_PATH - to je ASN útočníka (v prípade, že jeho sused kontroluje ASN suseda na všetkých prichádzajúcich trasách);
- Útok vychádza od jedného poskytovateľa.
Ak sú všetky predpoklady správne, na všetkých nesprávnych trasách bude prezentované ASN útočníka (okrem pôvodného ASN) a tak to je "kritický" bod. Medzi skutočnými únoscami sa nachádzal aj AS263444, hoci boli aj iní. Aj keď sme vylúčili trasy incidentu z úvahy. Prečo? Kritický bod môže zostať kritický aj pre správne trasy. Môže byť výsledkom zlého prepojenia v nejakom regióne alebo obmedzení našej vlastnej viditeľnosti.
Výsledkom je: existuje spôsob, ako odhaliť útočníka, ale len za podmienky splnenia všetkých uvedených kritérií a len vtedy, keď je zachytenie dostatočne veľké na prekročenie prahov monitorovania. Ak však niektoré z týchto faktorov nie sú splnené, môžeme vyčleniť prefixy, ktoré boli postihnuté takýmto zachytením? Pre určité operátorov – áno.
Keď útočník vytvorí more specific trasu, taký prefix nie je oznamovaný skutočným vlastníkom. V prípade, ak máte od neho dynamický zoznam všetkých jeho prefixov, je možné vykonať porovnanie a nájsť skreslené more specific trasy. Tento zoznam prefixov zbierame pomocou našich BGP relácií, pretože nám odovzdávajú nielen úplný zoznam trás, ktoré operátor vidí práve teraz, ale aj zoznam všetkých prefixov, ktoré chce oznámiť svetu. Bohužiaľ, v súčasnosti existuje niekoľko desiatok používateľov Radar, ktorí poslednú časť vykonávajú nie úplne správne. Čoskoro ich upozorníme a pokúsime sa túto situáciu vyriešiť. Všetci ostatní sa môžu pripojiť k nášmu monitorovaciemu systému práve teraz.
Ak sa vrátime k pôvodnému incidentu, útočníka a rozsah distribúcie sme odhalili pomocou vyhľadávania kritických bodov. Prekvapivo, AS263444 posielal sfalšované trasy nie všetkým svojim klientom. Hoci existuje aj podivnejší 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ávny príklad pokusu o zachytenie nášho adresného priestoru
Keď boli vytvorené more specific prefixy pre naše prefixy, použil sa špeciálne vytvorený AS_PATH. Tento AS_PATH však nemohol byť prevzatý z ktoréhokoľvek z našich predchádzajúcich trás. Nemáme dokonca ani spojenie s AS6762. Pozrime sa na iné trasy v incidente: niektoré z nich mali skutočný AS_PATH, ktorý bol použitý skôr, a iné nie, aj keď vyzerajú ako skutočné. Dodatočná zmena AS_PATH nemá žiadny praktický zmysel, pretože v každom prípade bude premávka presmerovaná na útočníka, ale trasy s „zlým“ AS_PATH môžu byť filtrované ASPA alebo akýmkoľvek iným mechanizmom overovania. Tu sme rozmýšľali o motivácii únoscov. Momentálne nám chýbajú údaje na to, aby sme tvrdili, že tento incident bol plánovaným útokom. Napriek tomu — je to možné. Skúsme si predstaviť aj keď hypotetickú, ale potenciálne veľmi reálnu situáciu.
Ideálny útok
Čo máme? Predpokladajme, že ste tranzitný poskytovateľ, ktorý vysiela trasy pre svojich klientov. Ak majú vaši klienti viacnásobnú prítomnosť (multihome), dostanete len časť ich premávky. Ale čím viac premávky — tým väčší je váš príjem. Preto, ak začnete oznamovať prefixy podsietí týchto rovnakých trás so rovnakým AS_PATH, dostanete zvyšok ich premávky. V dôsledku toho aj zvyšok peňazí.
Pomôže tu ROA? Možno, áno, ak sa rozhodnete úplne vzdať používania . Okrem toho, pri tomto je veľmi neželané mať záznamy ROA s prekryvajúcimi sa prefixami. Pre niektorých operátorov sú takéto obmedzenia neprijateľné.
Pri zvažovaní iných mechanizmov zabezpečenia smerovania, v tomto prípade ASPA tiež nepomôže (pretože sa používa AS_PATH z povolenej trasy). BGPSec stále nie je optimálna možnosť kvôli nízkemu percentu prijatia a zostávajúcej možnosti downgrade útokov.
Takže máme zjavný zisk pre útočníka a nedostatok bezpečnosti. Skvelá kombinácia!
Čo treba robiť?
Očividný a najradikálnejší krok — prehodnotiť vašu aktuálnu politiku smerovania. Rozdeľte vaše adresné priestory na najmenšie kusy (bez prekrytia), ktoré chcete oznámiť. Podpíšte ROA iba pre nich, bez použitia parametra maxLength. V tomto prípade vás súčasný POV môže ochrániť pred takýmto útokom. Avšak znovu, pre niektorých operátorov sa takýto prístup nemusí javiť ako rozumný kvôli výnimočnému používaniu more specific trás. Všetky problémy súčasného stavu ROA a route objektov budú opísané v jednom z našich budúcich materiálov.
Okrem toho sa môžete pokúsiť monitorovať podobné prehliadky. Na to potrebujeme dôveryhodné informácie o vašich prefixoch. Takže, ak si nastavíte BGP session s naším zberateľom a poskytnete nám informácie o vašej viditeľnosti na internete — môžeme nájsť rozsah pre ďalšie incidenty. Pre tých, ktorí ešte nie sú pripojení k nášmu monitorovaciemu systému — na začiatok nám bude stačiť zoznam trás len s vašimi prefixmi. Ak však máte s nami nastavenú session, prosím, overte, že boli odoslané všetky vaše trasy. Bohužiaľ, je potrebné to pripomenúť, pretože niektorí operátori zabúdajú na jeden alebo dva prefixy a tým pádom vytvárajú prekážky pre naše metódy vyhľadávania. Ak všetko urobíte správne, budeme mať spoľahlivé údaje o vašich prefixoch, ktoré v budúcnosti pomôžu automaticky identifikovať a detekovať také (a iné) typy prehliadania prevádzky pre váš adresný priestor.
Ak ste v reálnom čase zistili takýto prehliadanie vašej prevádzky, môžete sa pokúsiť proti tomu zasiahnuť sami. Prvý prístup — oznámiť trasy s týmito more specific prefixami sami. V prípade nového útoku na tieto prefixy — zopakujte to.
Druhý prístup — potrestať útočníka a tých, pre ktorých je kritickým bodom (pre dobré trasy), odrezaním prístupu vašich trás k útočníkovi. To je možné dosiahnuť pridaním ASN útočníka do AS_PATH vašich starých trás a tým ich prinútiť vyhnúť sa tejto AS, využívajúc zabudovaný mechanizmus detekcie cyklov v BGP. .
Zdroj: habr.com
