13. marec delovni skupini za boj proti zlorabi RIPE menijo, da je ugrabitev BGP (hjjack) kršitev pravilnika RIPE. Če bi bil predlog sprejet, bi imel internetni ponudnik, napaden s prestrezanjem prometa, možnost poslati posebno zahtevo za razkritje napadalca. Če bi pregledovalna skupina zbrala zadostne podporne dokaze, bi LIR, ki je bil vir prestrezanja BGP, štel za vsiljivca in bi mu lahko odvzeli status LIR. Bilo je tudi nekaj argumentov spremembe.
V tej publikaciji želimo prikazati primer napada, pri katerem ni šlo samo za pravega napadalca, ampak tudi za celoten seznam prizadetih predpon. Še več, tak napad ponovno odpira vprašanja o motivih za prihodnje prestrezanje tovrstnega prometa.
V zadnjih nekaj letih so bili le konflikti, kot je MOAS (Multiple Origin Autonomous System), v tisku obravnavani kot prestrezanje BGP. MOAS je poseben primer, ko dva različna avtonomna sistema oglašujeta nasprotujoče si predpone z ustreznimi ASN-ji v AS_PATH (prvi ASN v AS_PATH, v nadaljnjem besedilu izvorni ASN). Vendar pa lahko imenujemo vsaj prestrezanje prometa, ki napadalcu omogoča manipulacijo atributa AS_PATH za različne namene, vključno z izogibanjem sodobnim pristopom k filtriranju in nadzoru. Znana vrsta napada - zadnja vrsta takega prestrezanja, vendar sploh ne po pomembnosti. Povsem mogoče je, da je prav takšen napad viden v zadnjih tednih. Takšen dogodek ima razumljivo naravo in precej resne posledice.
Tisti, ki iščejo različico TL;DR, se lahko pomaknejo do podnaslova "Perfect Attack".
Omrežno ozadje
(za lažje razumevanje procesov, vključenih v ta dogodek)
Če želite poslati paket in imate v usmerjevalni tabeli več predpon, ki vsebujejo ciljni naslov IP, boste uporabili pot za predpono z najdaljšo dolžino. Če je v usmerjevalni tabeli več različnih poti za isto predpono, boste izbrali najboljšo (glede na najboljši mehanizem izbire poti).
Obstoječi pristopi filtriranja in spremljanja poskušajo analizirati poti in sprejemati odločitve z analizo atributa AS_PATH. Usmerjevalnik lahko ta atribut med oglaševanjem spremeni v katero koli vrednost. Enostavno dodajanje lastnikovega ASN-ja na začetek AS_PATH (kot izvornega ASN-ja) je lahko dovolj, da zaobidete trenutne mehanizme preverjanja izvora. Poleg tega, če obstaja pot od napadenega ASN do vas, je mogoče ekstrahirati in uporabiti AS_PATH te poti v vaših drugih oglasih. Vsako potrditveno preverjanje samo AS_PATH za vaša oblikovana obvestila bo sčasoma uspešno.
Še vedno je nekaj omejitev, ki jih je vredno omeniti. Prvič, v primeru filtriranja predpone s strani ponudnika navzgor je vaša pot morda še vedno filtrirana (tudi s pravilno AS_PATH), če predpona ne pripada stožcu vašega odjemalca, konfiguriranega na navzgor. Drugič, veljavna AS_PATH lahko postane neveljavna, če je ustvarjena pot oglaševana v napačnih smereh in s tem krši politiko usmerjanja. Nazadnje, vsaka pot s predpono, ki krši dolžino ROA, se lahko obravnava kot neveljavna.
Nezgoda
Pred nekaj tedni smo prejeli pritožbo enega od naših uporabnikov. Videli smo poti z njegovim izvornim predponama ASN in /25, medtem ko je uporabnik trdil, da jih ni oglaševal.
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||
Primeri objav za začetek aprila 2019
NTT na poti za predpono /25 je še posebej sumljiv. LG NTT v času incidenta ni vedel za to pot. Tako da, neki operater ustvari celotno AS_PATH za te predpone! Preverjanje na drugih usmerjevalnikih razkrije en poseben ASN: AS263444. Po ogledu drugih poti s tem avtonomnim sistemom smo naleteli na naslednjo situacijo:
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||
Poskusite uganiti, kaj je tukaj narobe
Zdi se, da je nekdo vzel predpono iz poti, jo razdelil na dva dela in oglaševal pot z isto AS_PATH za ti dve predponi.
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||
Primer poti za enega od razdeljenih parov predpon
Pojavi se več vprašanj hkrati. Je kdo dejansko preizkusil to vrsto prestrezanja v praksi? Je že kdo šel po teh poteh? Katere predpone so bile prizadete?
Tu se začne naš niz neuspehov in še en krog razočaranja nad trenutnim stanjem zdravja interneta.
Pot neuspeha
Najprej najprej. Kako lahko ugotovimo, kateri usmerjevalniki so sprejeli tako prestrežene poti in čigav promet bi lahko danes preusmerili? Mislili smo, da bomo začeli s predponami /25, ker "preprosto ne morejo imeti globalne distribucije." Kot lahko ugibate, smo se zelo zmotili. Izkazalo se je, da je ta metrika preveč hrupna in poti s takimi predponami se lahko pojavijo celo pri operaterjih stopnje 1. Na primer, NTT ima približno 50 takšnih predpon, ki jih distribuira svojim strankam. Po drugi strani pa je ta metrika slaba, ker je takšne predpone mogoče filtrirati, če jih operater uporablja , v vse smeri. Zato ta metoda ni primerna za iskanje vseh operaterjev, katerih promet je bil preusmerjen zaradi takšnega incidenta.
Še ena dobra ideja, ki smo si jo zdeli ogledati . Še posebej za poti, ki kršijo pravilo maxLength ustrezne ROA. Na ta način bi lahko našli število različnih izvornih ASN s statusom Neveljaven, ki so bili vidni danemu AS. Vendar obstaja "majhen" problem. Povprečje (mediana in način) tega števila (število ASN različnih izvorov) je približno 150 in, tudi če filtriramo majhne predpone, ostane nad 70. To stanje ima zelo preprosto razlago: obstaja samo nekaj operaterjev, ki že uporabljajo filtre ROA s politiko »ponastavi neveljavne poti« na vstopnih točkah, tako da se lahko pot, kjer koli se v resničnem svetu pojavi kršitev ROA, razširi v vse smeri.
Zadnja dva pristopa nam omogočata, da najdemo operaterje, ki so videli naš incident (ker je bil precej velik), vendar na splošno nista uporabna. V redu, ampak ali lahko najdemo vsiljivca? Kakšne so splošne značilnosti te manipulacije AS_PATH? Obstaja nekaj osnovnih predpostavk:
- Predpone še ni bilo nikjer videti;
- Izvorni ASN (opomnik: prvi ASN v AS_PATH) je veljaven;
- Zadnji ASN v AS_PATH je napadalčev ASN (v primeru, da njegov sosed preveri sosedov ASN na vseh dohodnih poteh);
- Napad izvira iz enega samega ponudnika.
Če so vse predpostavke pravilne, bodo vse nepravilne poti predstavljale napadalčev ASN (razen izvornega ASN) in je zato to "kritična" točka. Med pravimi ugrabitelji je bil AS263444, čeprav so bili tudi drugi. Tudi ko smo incidentne poti izločili iz obravnave. Zakaj? Kritična točka lahko ostane kritična tudi za pravilne poti. Lahko je posledica slabe povezljivosti v regiji ali omejitev v naši prepoznavnosti.
Posledično obstaja način za odkrivanje napadalca, vendar le, če so izpolnjeni vsi zgornji pogoji in le, ko je prestrezanje dovolj veliko, da preseže nadzorne pragove. Če nekateri od teh dejavnikov niso izpolnjeni, ali lahko prepoznamo predpone, ki so bile prizadete zaradi takšnega prestrezanja? Pri določenih operaterjih - da.
Ko napadalec ustvari bolj specifično pot, pravi lastnik takšne predpone ne oglašuje. Če imate iz njega dinamičen seznam vseh njegovih predpon, potem je mogoče narediti primerjavo in poiskati izkrivljene bolj specifične poti. Ta seznam predpon zbiramo z našimi sejami BGP, ker nimamo le celotnega seznama poti, ki so trenutno vidne operaterju, ampak tudi seznam vseh predpon, ki jih želi oglaševati svetu. Na žalost je zdaj več deset uporabnikov Radarja, ki zadnjega dela ne izpolnijo pravilno. Kmalu jih bomo obvestili in poskušali rešiti to težavo. Vsi ostali se lahko pridružijo našemu sistemu spremljanja že zdaj.
Če se vrnemo k prvotnemu incidentu, smo z iskanjem kritičnih točk odkrili tako napadalca kot distribucijsko območje. Presenetljivo je, da AS263444 ni poslal izdelanih poti vsem svojim strankam. Čeprav obstaja čuden trenutek.
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 so bile za naše predpone ustvarjene bolj specifične, je bila uporabljena posebej ustvarjena AS_PATH. Vendar te AS_PATH ni bilo mogoče vzeti iz nobene od naših prejšnjih poti. Sploh nimamo komunikacije z AS6762. Če pogledamo druge poti v incidentu, so nekatere od njih imele pravi AS_PATH, ki je bil prej uporabljen, druge pa ne, čeprav je videti kot pravi. Dodatno spreminjanje AS_PATH nima nikakršnega praktičnega smisla, saj bo promet tako ali tako preusmerjen na napadalca, vendar pa lahko poti s "slabo" AS_PATH filtrirajo ASPA ali kateri koli drug inšpekcijski mehanizem. Tukaj razmišljamo o motivaciji ugrabitelja. Trenutno nimamo dovolj informacij, da bi potrdili, da je bil ta incident načrtovan napad. Kljub temu je možno. Poskusimo si predstavljati, čeprav še vedno hipotetično, a potencialno povsem realno situacijo.
Popoln napad
Kaj imamo? Recimo, da ste ponudnik prevoza, ki oddaja poti za svoje stranke. Če imajo vaše stranke večkratno prisotnost (multihome), boste prejeli le del njihovega prometa. Toda več kot je prometa, večji je vaš dohodek. Torej, če začnete oglaševati podomrežne predpone teh istih poti z istim AS_PATH, boste prejeli preostali njihov promet. Kot rezultat, preostali denar.
Bo ROA tu pomagal? Morda da, če se odločite, da ga boste popolnoma prenehali uporabljati . Poleg tega je zelo nezaželeno imeti zapise ROA s križajočimi se predponami. Za nekatere operaterje so takšne omejitve nesprejemljive.
Glede na druge varnostne mehanizme usmerjanja tudi ASPA v tem primeru ne bo pomagal (ker uporablja AS_PATH iz veljavne poti). BGPSec še vedno ni optimalna možnost zaradi nizkih stopenj sprejemanja in preostale možnosti napadov na nižjo različico.
Tako imamo očitno pridobitev za napadalca in pomanjkanje varnosti. Odlična mešanica!
Kaj naj storim?
Očiten in najbolj drastičen korak je pregled vaše trenutne politike usmerjanja. Naslovni prostor razdelite na najmanjše dele (brez prekrivanja), ki jih želite oglaševati. Podpišite ROA samo za njih, brez uporabe parametra maxLength. V tem primeru vas lahko vaš trenutni POV reši pred takšnim napadom. Vendar pa še enkrat, za nekatere operaterje ta pristop ni razumen zaradi izključne uporabe bolj specifičnih poti. Vse težave s trenutnim stanjem ROA in objektov poti bodo opisane v enem od naših prihodnjih gradiv.
Poleg tega lahko poskusite spremljati takšne prestrezanja. Za to potrebujemo zanesljive podatke o vaših predponah. Če torej vzpostavite sejo BGP z našim zbiralnikom in nam posredujete informacije o vaši internetni vidnosti, lahko najdemo prostor za druge incidente. Za tiste, ki še niste povezani z našim nadzornim sistemom, bo za začetek dovolj seznam poti samo z vašimi predponami. Če imate sejo pri nas, preverite, ali so bile vse vaše poti poslane. Na žalost si to velja zapomniti, ker nekateri operaterji pozabijo predpono ali dve in tako motijo naše metode iskanja. Če je vse opravljeno pravilno, bomo imeli zanesljive podatke o vaših predponah, ki nam bodo v prihodnosti pomagali samodejno prepoznati in zaznati to (in druge) vrste prestrezanja prometa za vaš naslovni prostor.
Če zaznate takšno prestrezanje vašega prometa v realnem času, se lahko poskusite zoperstaviti sami. Prvi pristop je, da sami oglašujete poti s temi bolj specifičnimi predponami. V primeru novega napada na te predpone ponovite.
Drugi pristop je kaznovanje napadalca in tistih, za katere je kritična točka (za dobre poti), tako da napadalcu onemogočite dostop do svojih poti. To lahko storite tako, da dodate napadalčev ASN v AS_PATH vaših starih poti in jih tako prisilite, da se izognejo temu AS z uporabo vgrajenega mehanizma za zaznavanje zank v BGP .
Vir: www.habr.com