Pe 13 martie, în grupul de lucru RIPE pentru combaterea abuzurilor de a trata interceptarea BGP (hijack) ca o încălcare a politicii RIPE. Dacă propunerea este acceptată, furnizorul de internet, atacat prin interceptarea traficului, ar avea posibilitatea de a trimite o cerere specială pentru a expune atacatorul. Dacă grupul de experți adună suficiente dovezi concludente, astfel de LIR-uri, care sunt sursa interceptării BGP, ar fi considerate infractori și ar putea fi privite de statutul de LIR. Au fost și unele argumente schimbări.
În această publicație dorim să arătăm un exemplu de atac, când nu doar adevăratul infractor a fost pus la îndoială, ci și întreaga listă de prefixe afectate. Mai mult, un astfel de atac ridică din nou întrebări privind motivele viitoarelor interceptări de trafic de acest tip.
În ultimii câțiva ani, în presă, ca interceptări BGP au fost raportate doar conflictele de tip MOAS (Multiple Origin Autonomous System). MOAS este un caz particular în care două sisteme autonome diferite anunță prefixe în conflict cu numere ASN corespunzătoare în AS_PATH (primul ASN în AS_PATH, denumit în continuare – ASN origin). Totuși, putem numi cel puțin de interceptare a traficului care permit atacatorului să manipuleze atributul AS_PATH cu diferite scopuri, inclusiv pentru a ocoli abordările moderne de filtrare și monitorizare. Un tip cunoscut de atac este ultimul tip de astfel de interceptare, dar nu mai puțin semnificativ. Este posibil ca exact un astfel de atac să fi fost observat în ultimele săptămâni. Un astfel de eveniment are un caracter explicabil și consecințe destul de grave.
Cei care caută o versiune TL;DR pot derula până la subtitlul „Atacul perfect”.
Contextul rețelei
(pentru a înțelege mai bine procesele implicate în acest incident)
Dacă doriți să trimiteți un pachet și aveți mai multe prefixe în tabela de rutare care conțin adresa IP destinată, veți utiliza ruta pentru prefixul cu cea mai mare lungime. Dacă însă în tabela de rutare există mai multe rute diferite pentru un singur prefix, veți alege cea mai bună (în conformitate cu mecanismul de selecție a celei mai bune căi).
Abordările existente pentru filtrare și monitorizare încearcă să analizeze rutele și să ia decizii analizând atributul AS_PATH. Routerul poate schimba acest atribut la orice valoare în timpul anunțului. Adăugarea simplă a ASN-ului proprietar la începutul AS_PATH (ca ASN de origine) poate fi suficientă pentru a ocoli mecanismele actuale de verificare a sursei. Mai mult, dacă există o rută de la ASN-ul atacat către dumneavoastră, apare posibilitatea de a extrage și folosi AS_PATH-ul acestei rute în alte anunțuri ale dumneavoastră. Orice verificare a validității doar pe baza AS_PATH-ului pentru anunțurile dumneavoastră modificate va fi, în cele din urmă, trecută.
Există, de asemenea, câteva limitări demne de menționat. În primul rând, în cazul filtrării prefixelor de către furnizorul superior, ruta dumneavoastră poate fi în continuare filtrată (chiar cu un AS_PATH corect), dacă prefixul nu aparține conurilor clienților dumneavoastră, configurate la upstream. Al doilea - un AS_PATH valid poate deveni invalid, dacă ruta creată este anunțată în direcții incorecte și, astfel, încalcă politica de rutare. Și în final - orice rută cu un prefix care încalcă lungimea ROA poate fi considerată invalidă.
Incident
Acum câteva săptămâni, am primit o plângere de la unul dintre utilizatori. Am văzut rute cu ASN-ul său de origine și prefixe /25, în timp ce utilizatorul susținea că nu le-a anunțat.
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||
Exemple de anunțuri de la începutul lunii aprilie 2019
NTT în rută pentru prefixul /25 face ca acesta să fie deosebit de suspect. În timpul incidentului, LG NTT nu știa nimic despre această rută. Așadar, da, un operator a creat un întreg AS_PATH pentru aceste prefixe! Verificarea pe alte routere permite evidențierea unui ASN deosebit: AS263444. Privind alte rute cu acest sistem autonom, ne-am confruntat cu următoarea situație:
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||
Încercați să ghiciți ce nu este în regulă aici
Se pare că cineva a preluat un prefix din rută, l-a împărțit în două părți și a anunțat ruta cu același AS_PATH pentru aceste două prefixe.
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||
Exemple de rute pentru una dintre perechile de prefixe împărțite
Întreabă-te mai multe întrebări. A încercat cineva în practică acest tip de interceptare? A acceptat cineva aceste rute? Ce prefixe au fost afectate?
Aici începe seria noastră de eșecuri și încă un rând de dezamăgire în starea actuală de sănătate a Internetului.
Calea eșecurilor
Să o luăm pe rând. Cum putem determina ce routere au acceptat astfel de rute interceptate și ce trafic poate fi redirecționat deja astăzi? Ne-am gândit să începem cu prefixele /25, pentru că acestea "pur și simplu nu pot avea o răspândire globală". După cum vă puteți imagina, ne-am înșelat grav. Această metrică s-a dovedit a fi prea zgomotoasă, iar rutele cu astfel de prefixe pot apărea chiar și de la operatori Tier-1. De exemplu, NTT are aproximativ 50 de astfel de prefixe pe care le distribuie printre clienții săi. Pe de altă parte, această metrică este slabă, deoarece astfel de prefixe pot fi filtrate în cazul în care operatorul aplică , în toate direcțiile. Prin urmare, această metodă nu este potrivită pentru a găsi toți operatorii ale căror trafic a fost redirecționat ca urmare a unui astfel de incident.
O altă idee bună ni s-a părut să ne uităm la . În special la rutele care încalcă regula maxLength a ROA corespunzătoare. Astfel, am putea determina numărul diferitelor ASN origin cu statut Invalid, care au fost văzute de acest AS. Cu toate acestea, există o "mică" problemă. Media (mediana și moda) acestui număr (numărul diferitelor ASN origin) este de aproximativ 150 și, chiar dacă filtrăm prefixele mici, va rămâne peste 70. Această situație are o explicație destul de simplă: există doar câțiva operatori care aplică deja filtre ROA cu politica „resetare a rutelor Invalid” la punctele de intrare, așa că, oriunde în lumea reală ar apărea o rută care încalcă ROA, aceasta poate fi răspândită în toate direcțiile.
Ultimele două abordări permit găsirea operatorilor care au observat incidentul nostru (deoarece acesta a fost destul de mare), dar în general ele nu sunt aplicabile. Bine, dar putem găsi atacatorul? Care sunt trăsăturile comune ale unei astfel de manipulări AS_PATH? Există câteva presupuneri de bază:
- Prefixul nu a fost observat anterior;
- ASN origin (amintire: primul ASN în AS_PATH) este valid;
- Ultimul ASN din AS_PATH este ASN-ul atacatorului (în cazul în care vecinul său verifică ASN-ul vecinului la toate rutele de intrare);
- Atacul provine de un singur furnizor.
Dacă toate presupunerile sunt corecte, atunci pe toate rutele incorecte va apărea ASN-ul atacatorului (cu excepția ASN-ului de origine) și, astfel, aceasta reprezintă un «punct critic». Printre adevărații atacatori s-a numărat și AS263444, deși au fost și altele. Chiar și atunci când am exclus rutele incidente din considerație. De ce? Punctul critic poate rămâne critic chiar și pentru rutele corecte. Poate fi rezultatul unei conectivități slabe într-o anumită regiune sau al restricțiilor de vizibilitate ale noastre.
Ca rezultat: există o modalitate de a detecta atacatorul, dar doar dacă se respectă toate condițiile enumerate mai sus și doar când interceptarea este suficient de mare pentru a depăși pragurile de monitorizare. Dacă însă unele dintre aceste condiții nu sunt respectate, putem evidenția prefixele afectate de o astfel de interceptare? Pentru anumite operatori — da.
Când atacatorul creează o rută mai specifică, acest prefix nu este anunțat de adevăratul proprietar. În cazul în care aveți de la el o listă dinamică cu toate prefixele sale, atunci apare posibilitatea de a efectua o comparație și de a găsi rutele mai specifice distorsionate. Colectăm această listă de prefixe prin intermediul sesiunilor noastre BGP, deoarece ni se transmite nu doar lista completă de rute vizibile operatorului în momentul de față, ci și lista tuturor prefixelor pe care dorește să le anunțe în lume. Din păcate, în prezent există câteva zeci de utilizatori Radar care nu îndeplinesc această ultimă parte în mod corect. În curând, vom informa aceștia și vom încerca să soluționăm această problemă. Toți ceilalți pot să se alăture sistemului nostru de monitorizare chiar acum.
Revenind la incidentul inițial, atât atacatorul, cât și domeniul de desfășurare au fost detectate de noi prin intermediul căutării punctelor critice. Este surprinzător, dar AS263444 a difuzat rute fabricate nu tuturor clienților săi. Deși există și un aspect mai ciudat.
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||
Un exemplu recent de tentativă de interceptare a spațiului nostru de adrese
Când au fost create more specific pentru prefivele noastre, a fost folosit un AS_PATH creat special. Totuși, acest AS_PATH nu putea fi extras din niciunul dintre rutele noastre anterioare. Nu avem nici măcar o legătură cu AS6762. Să ne uităm la alte rute în incident: unele dintre ele aveau un AS_PATH real, folosit anterior, iar altele nu, chiar dacă păreau a fi reale. O modificare suplimentară a AS_PATH nu are niciun sens practic, deoarece în orice caz traficul va fi redirecționat către atacator, dar rutele cu AS_PATH „proastă” pot fi filtrate de ASPA sau orice alt mecanism de verificare. Aici ne-am gândit la motivația răpitorului. În prezent, ne lipsesc datele pentru a susține că acest incident a fost un atac planificat. Cu toate acestea, este posibil. Să încercăm să ne imaginăm o situație ipotetică, dar posibil realistă.
Atacul ideal
Ce avem? Să presupunem că ești un furnizor de tranzit care transmite rute pentru clienții tăi. Dacă clienții tăi au o prezență multiplă (multihome), vei obține doar o parte din traficul lor. Dar cu cât mai mult trafic — cu atât venitul tău va fi mai mare. Așadar, dacă începi să anunți prefivele subrețelelor acestor rute cu același AS_PATH, vei obține restul traficului lor. Ca urmare, restul banilor.
Va ajuta aici ROA? Posibil, da, dacă decizi să renunți complet la utilizare . În plus,în acest caz, este extrem de nedorit să ai înregistrări ROA cu prefive care se suprapun. Pentru unii operatori, astfel de restricții sunt inacceptabile.
Privind alte mecanisme de securitate a rutării, în acest caz ASPA de asemenea nu va ajuta (deoarece se folosește AS_PATH de la o rută validă). BGPSec nu este în continuare o opțiune optimă din cauza ratei scăzute de adoptare și a rămânerii posibilei atacuri de downgrade.
Astfel, avem un profit evident pentru atacator și o lipsă de securitate. O combinație excelentă!
Ce trebuie să facem?
Pasul cel mai evident și radical este revizuirea politicii actuale de rutare. Fragmentați spațiul dumneavoastră de adrese în cele mai mici bucăți (fără suprapuneri) pe care doriți să le anunțați. Semnați ROA doar pentru acestea, fără a folosi parametrul maxLength. În acest caz, POV-ul actual v-ar putea salva de un asemenea atac. Totuși, din nou, pentru unii operatori, o astfel de abordare nu este rațională din cauza utilizării excepționale a rutelor more specific. Toate problemele legate de starea actuală a ROA și a obiectelor de rutare vor fi descrise într-unul dintre materialele noastre viitoare.
În plus, puteți încerca să monitorizați astfel de interceptări. Pentru aceasta, avem nevoie de informații de încredere despre prefixele dumneavoastră. Astfel, dacă stabiliți o sesiune BGP cu colectorul nostru și ne transmiteți informații despre vizibilitatea dumneavoastră în Internet — putem identifica zona de răspândire și pentru alte incidente. Pentru cei care nu sunt încă conectați la sistemul nostru de monitorizare — la început, ne va ajunge o listă de rute doar cu prefixele dumneavoastră. Dacă aveți deja o sesiune cu noi, vă rugăm să verificați că toate rutele dumneavoastră au fost trimise. Din păcate, trebuie să amintim acest lucru, deoarece unele operatori uită un sau două prefixe și, astfel, creează interferențe pentru metodele noastre de căutare. Dacă totul este făcut corect, atunci vom avea date de încredere despre prefixele dumneavoastră, care în viitor vor ajuta la identificarea și detectarea automată a acestor tipuri (și altor) interceptări de trafic pentru spațiul dumneavoastră de adrese.
Dacă ați aflat în timp real despre o astfel de interceptare a traficului dumneavoastră, puteți încerca să contracarați singuri. Prima abordare este să anunțați rutele cu aceste prefixe more specific singuri. În cazul unei noi atacări asupra acestor prefixe — repetați.
A doua abordare este să pedepsiți atacatorul și pe cei pentru care acesta este un punct critic (pentru rutele bune), tăind accesul rutelor dumneavoastră către atacator. Acest lucru poate fi realizat adăugând ASN-ul atacatorului în AS_PATH-ul rutelor dumneavoastră mai vechi și, astfel, forțându-i să evite această AS, folosind mecanismul încorporat de detectare a ciclurilor în BGP. .
Sursa: habr.com
