13. marca je v delovno skupino RIPE za boj proti zlorabam prispela da se BGP-preusmeritev (hijack) obravnava kot kršitev pravilnika RIPE. V primeru sprejetja predloga bi imel internetni ponudnik, ki je bil tarča preusmeritve prometa, možnost poslati posebno zahtevo za razkritje storilca. Če bi strokovna skupina zbrala dovolj potrjujočih dokazi, bi tak LIR, ki je vir BGP-preusmeritve, veljal za kršitelja in bi lahko izgubil status LIR. Predloženi so bili tudi nekateri argumenti spremembi.
V tej objavi želimo prikazati primer napada, ko ni bil pod vprašajem le pravi storilec, temveč celoten seznam prizadetih prefiksov. Še več, tak napad ponovno odpira vprašanja o motivih prihodnjih preusmeritev prometa te vrste.
V zadnjih dveh letih so se v medijih o BGP-preusmeritvah poročali le o konfliktih vrste MOAS (Multiple Origin Autonomous System). MOAS je posebna naključnost, ko dve različni avtonomni sistemi oglašujeta konfliktne prefikse z ustreznimi številkami ASN v AS_PATH (prvi ASN v AS_PATH, naprej v besedilu - origin ASN). Vendar lahko navedemo najmanj preusmeritve prometa, ki omogočajo storilcu manipulacijo z atributom AS_PATH z različnimi cilji, vključno z obvladovanjem sodobnih metod filtriranja in spremljanja. Znan tip napada je zadnji tip takšne preusmeritve, a ne po pomenu. Zelo verjetno smo prav to napad opazovali v zadnjih tednih. Tak dogodek ima razumljiv značaj in dovolj resne posledice.
Tisti, ki iščejo TL;DR različico, lahko pomaknejo do podnaslova "Popoln napad".
Omrežno ozadje
(da boste bolje razumeli procese, vključene v ta incident)
Če želite poslati paket in imate več prefiksov v usmerjevalni tabeli, ki vsebujejo IP-naslov cilja, boste uporabili pot za prefiks z največjo dolžino. Če pa v usmerjevalni tabeli obstaja več različnih poti za en prefiks, boste izbrali najboljšo (v skladu z mehanizmom izbire najboljše poti).
Obstoječi pristupi filtriranju i praćenju pokušavaju analizirati rute i donositi odluke analizirajući atribut AS_PATH. Usmjerivač može promijeniti ovaj atribut na bilo koju vrijednost prilikom oglašavanja. Jednostavno dodavanje ASN vlasnika na početak AS_PATH (kao izvorni ASN) može biti dovoljno da zaobiđe trenutne mehanizme provjere izvora. Štoviše, ako postoji ruta od napadnutog ASN do vas, postoji mogućnost da izvučete i koristite AS_PATH te rute u drugim vašim oglasima. Svaka provjera valjanosti samo AS_PATH za vaše faux oglase na kraju će biti prošla.
Postoji još nekoliko vrijednih spomena ograničenja. Prvo, u slučaju filtriranja prefiksa od strane višeg providera, vaša ruta se i dalje može filtrirati (čak i s ispravnim AS_PATH), ako prefiks ne pripada vašem klijentskom okviru postavljenom kod uzlaznog. Drugo, valjani AS_PATH može postati nevaljan ako je stvorena ruta oglašena u pogrešnim smjerovima i time krši pravilo usmjerenja. I na kraju, svaka ruta s prefiksom koja krši ROA duljinu može se smatrati nevaljanom.
Incident
Prije nekoliko tjedana primili smo pritužbu od jednog korisnika. Vidjeli smo rute s njegovim izvorom ASN i prefiksima /25, dok je korisnik tvrdio da ih nije oglašavao.
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||
Primjeri oglasa na početku travnja 2019
NTT na putu za prefiks /25 čini ga posebno sumnjivim. Tijekom incidenta LG NTT nije znao za ovu rutu. Dakle, da, neki operater stvara cijeli AS_PATH za te prefikse! Provjera na drugim usmjerivačima omogućava isticanje jednog posebnog ASN: AS263444. Gledajući druge rute s ovim autonomnim sustavom, naišli smo na sljedeću situaciju:
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||
Pokušajte pretpostaviti što ovdje nije u redu
Čini se da je netko uzeo prefiks iz rute, podijelio ga na dva dijela i oglasio rutu s istim AS_PATH za ta dva prefiksa.
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||
Primjeri ruta za jedan od parova podijeljenih prefiksa
Postavlja se nekoliko pitanja. Da li je netko zaista isprobao ovu vrstu presretanja? Je li netko prihvaćao te rute? Koji su prefiksi bili pogođeni?
Tukaj se začne naš cikel neuspehov in še ena runda razočaranja glede trenutnega stanja interneta.
Pot neuspehov
Vse po vrsti. Kako lahko ugotovimo, kateri usmerjevalniki so sprejeli take preusmerjene poti in kateri promet se lahko že danes preusmeri? Mislili smo, da začnemo s predznaki /25, saj ti 'preprosto ne morejo imeti globalne razširjenosti'. Kot lahko uganite, smo se hudo motili. Ta metrcommonka se je izkazala za preglasno in poti s takimi predznaki se lahko pojavijo tudi pri Tier-1 operaterjih. Na primer, NTT ima okoli 50 takšnih predznakov, ki jih porazdeli med svoje stranke. Po drugi strani pa je ta metrcommonka slaba, ker so takšni predznaki lahko filtrirani, če operater uporablja , v vseh smereh. Zato ta metoda ni primerna za iskanje vseh operaterjev, katerih promet je bil preusmerjen kot posledica takšnega incidenta.
Še ena dobra ideja se nam je zdela, da pogledamo na . Še posebej na poti, ki kršijo pravilo maxLength ustreznega ROA. Tako bi lahko našli število različnih izvornih ASN-jev s statusom Invalid, ki so bili vidni temu AS. Kljub temu pa obstaja 'majhna' težava. Povprečna vrednost (mediana in moda) tega števila (število različnih izvornih ASN-jev) je okoli 150 in, celo če filtriramo majhne predznake, bo ostala nad 70. Takšno stanje ima precej preprosto razlago: le nekaj operaterjev že uporablja ROA filtre s politiko 'zavrzite Invalid poti' na vhodnih točkah, zato kjerkoli v resničnem svetu nastane pot, ki krši ROA, lahko razširja v vseh smereh.
Zadnji dva pristopa omogočata iskanje operaterjev, ki so videli naš incident (ker je bil dovolj velik), vendar so na splošno neuporabni. Dobro, a lahko najdemo zlorabnika? Kakšne so splošne značilnosti take manipulacije AS_PATH? Obstaja nekaj osnovnih predpostavk:
- Predznak nikjer prej ni bil opazen;
- Izvorni ASN (opomba: prvi ASN v AS_PATH) je veljaven;
- Zadnji ASN v AS_PATH je ASN napadalca (v primeru, da njegov sosed preverja ASN soseda na vseh prihajajočih poteh);
- Napad prihaja od enega ponudnika.
Če so vse domneve pravilne, bo na vseh napačnih poteh prikazan ASN napadalca (razen izvornega ASN), kar je zato "kritična" točka. Med pravimi ugrabitelji se je izkazal tudi AS263444, čeprav je bilo še drugih. Tudi ko smo iz obravnave izločili poti incidenta. Zakaj? Kritična točka je lahko še vedno kritična tudi za pravilne poti. Lahko je rezultat slabe povezanosti v določenem območju ali omejitev naše lastne vidljivosti.
Kot rezultat: obstaja način, kako odkriti napadalca, vendar le, če so izpolnjeni vsi zgoraj navedeni pogoji in le, ko je prestrezanje dovolj obsežno, da preide preko mejnikov spremljanja. Če pa kateri od teh dejavnikov ni izpolnjen, ali lahko izpostavimo prefikse, ki so bili prizadeti s takim prestrezanjem? Za nekatere operaterje — da.
Ko napadalec ustvari bolj specifično pot, tak prefiks ne oglašuje pravi lastnik. V primeru, da imate dinamični seznam vseh njegovih prefiksov, se pojavi možnost primerjave in iskanja izkrivljenih bolj specifičnih poti. Ta seznam prefiksov zbiramo preko naših BGP sej, saj nam posredujejo ne le popoln seznam poti, ki so trenutno vidne operaterju, ampak tudi seznam vseh prefiksov, ki jih želi oglaševati svetu. Na žalost trenutno obstaja več deset uporabnikov Radar, ki zadnjega dela ne izvajajo povsem pravilno. Kmalu jih bomo obvestili in poskušali rešiti to težavo. Vse ostale pa lahko takoj pridružijo našemu sistemu spremljanja.
Če se vrnemo k prvotnemu incidentu, sta tako napadalec kot področje širjenja bila ugotovljena z našo pomočjo pri iskanju kritičnih točk. Presenetljivo je, da AS263444 ni pošiljal ponarejenih poti vsem svojim strankam. Vendar pa obstaja še bolj čuden element.
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||
Nedavni primer poskusa prestrezanja našega naslovnega prostora.
Ko se je ustvarilo more specific’e za naše prefikse, je bil uporabljen posebej ustvarjen AS_PATH. Vendar ta AS_PATH ni mogel biti vzet iz katerega koli prejšnjega ruta. Nimamo niti povezave z AS6762. Oglejmo si druge rute v incidentu: nekateri od njih so imeli pravi AS_PATH, ki je bil uporabljen prej, medtem ko drugi niso, četudi so izgledali kot pravi. Dodatna sprememba AS_PATHa nima praktičnega smisla, saj bo v vsakem primeru promet preusmerjen na napadalca, a rute z 'slabim' AS_PATHom lahko filtrirajo ASPA ali kateri koli drug mehanizem preverjanja. Tukaj smo razmišljali o motivaciji ugrabljenega. Trenutno nam primanjkuje podatkov, da bi trdili, da je bil ta incident načrtovana napad. Kljub temu — to je mogoče. Poskusimo si predstavljati vsaj hipotezno, a potencialno zelo resnično situacijo.
Popoln napad
Kaj imamo? Predpostavimo, da ste tranzitni ponudnik, ki posreduje rute za svoje stranke. Če imajo vaše stranke večkratno prisotnost (multihome), boste dobili le del njihovega prometa. A več kot je prometa — večji je vaš dohodek. Zato, če začnete napovedovati prefikse podomrežij teh istih rut, z istim AS_PATHom, boste dobili preostali del njihovega prometa. Kot posledica, tudi preostali del denarja.
Ali tu ROA pomaga? Mogoče, ja, če se odločite popolnoma opustiti njegovo uporabo . Poleg tega je pri tem močno nezaželeno imeti zapise ROA s prekrivajočimi prefiksi. Za nekatere operaterje so omejitve takšne vrste nesprejemljive.
Ob upoštevanju drugih mehanizmov za zagotavljanje varnosti usmerjanja, v tem primeru ASPA prav tako ne bo pomagal (ker se uporablja AS_PATH z dovoljenega ruta). BGPSec še vedno ni optimalna izbira zaradi nizkega odstotka sprejemanja in ostajajoče možnosti napadov downgrade.
Tako imamo očitno korist za napadalca in pomanjkanje varnosti. Odlična mešanica!
Kaj je potrebno narediti?
Najbolj očiten in radikalen korak je revizija vaše trenutne politike usmerjanja. Razdelite svoj naslovni prostor na najmajše koščke (brez prekrivanj), ki jih želite oglaševati. Podpišite ROA samo za njih, ne da bi uporabljali parameter maxLength. V tem primeru vas lahko trenutni POV reši pred tako napadom. Vendar pa za nekatere operaterje tak pristop ni smiseln zaradi izjemne uporabe bolj specifičnih usmeritev. Vse težave trenutnega stanja ROA in objektov usmerjanja bodo obravnavane v enem od naših prihodnjih materialov.
Poleg tega lahko poskušate spremljati takšne preusmeritve. Za to potrebujemo zanesljive informacije o vaših predponah. Tako, če nastavite BGP sejo z našim zbiralnikom in nam posredujete informacije o vaši vidnosti na internetu — lahko najdemo območje širjenja in za druge incidente. Za tiste, ki še niso povezani z našim sistemom spremljanja — za začetek nam bo dovolj seznam usmeritev samo z vašimi predponami. Če pa imate sejo z nami, prosimo, preverite, ali so bile poslane vse vaše usmeritve. Na žalost to velja ponoviti, saj nekateri operaterji pozabijo na eno ali dve predponi in tako ustvarijo ovire za naše metode iskanja. Če izvedemo vse pravilno, bomo imeli zanesljive podatke o vaših predponah, ki bodo v prihodnosti pomagali avtomatsko določati in zaznavati take (in druge) vrste preusmeritev prometa za vaš naslovni prostor.
Če ste v realnem času izvedeli za takšno preusmeritev vašega prometa, se lahko poskusite samostojno upreti. Prvi pristop je samostojno oglaševanje usmeritev s temi bolj specifičnimi predponami. V primeru novega napada na te predpone — ponoviti.
Drugi pristop je kaznovati napadalca in tiste, za katere je kritična točka (za dobre usmeritve), ter odrezati dostop vaših usmeritev do napadalca. To lahko storite tako, da dodate ASN napadalca v AS_PATH vaših starejših usmeritev in jih tako prisilite, da se izogibajo temu AS, s pomočjo vgrajenega mehanizma za odkrivanje ciklov v BGP. .
Izvor: habr.com
