13 martie grupului de lucru anti-abuz RIPE considerați deturnarea BGP (hjjack) ca o încălcare a politicii RIPE. Dacă propunerea ar fi acceptată, furnizorul de internet atacat prin interceptarea traficului ar avea posibilitatea de a trimite o cerere specială pentru a demasca atacatorul. Dacă echipa de examinare a colectat suficiente dovezi justificative, LIR-ul care a fost sursa interceptării BGP ar fi considerat un intrus și ar putea fi deposedat de statutul său LIR. Au fost și câteva argumente schimbări.
În această publicație dorim să arătăm un exemplu de atac în care nu doar atacatorul real a fost în discuție, ci și întreaga listă de prefixe afectate. Mai mult, un astfel de atac ridică din nou întrebări cu privire la motivele interceptărilor viitoare ale acestui tip de trafic.
În ultimii câțiva ani, doar conflicte precum MOAS (Multiple Origin Autonomous System) au fost tratate în presă ca interceptări BGP. MOAS este un caz special în care două sisteme autonome diferite promovează prefixe conflictuale cu ASN-uri corespunzătoare în AS_PATH (primul ASN din AS_PATH, denumit în continuare ASN de origine). Cu toate acestea, putem numi cel puțin interceptarea traficului, permițând unui atacator să manipuleze atributul AS_PATH în diverse scopuri, inclusiv ocolirea abordărilor moderne de filtrare și monitorizare. Tip de atac cunoscut - ultimul tip de astfel de interceptare, dar deloc ca importanță. Este foarte posibil ca acesta să fie exact genul de atac pe care l-am văzut în ultimele săptămâni. Un astfel de eveniment are o natură de înțeles și consecințe destul de grave.
Cei care caută versiunea TL;DR pot derula la subtitrarea „Perfect Attack”.
Fundalul rețelei
(pentru a vă ajuta să înțelegeți mai bine procesele implicate în acest incident)
Dacă doriți să trimiteți un pachet și aveți mai multe prefixe în tabelul de rutare care conține adresa IP de destinație, atunci veți folosi ruta pentru prefixul cu cea mai mare lungime. Dacă există mai multe rute diferite pentru același prefix în tabelul de rutare, o veți alege pe cea mai bună (în funcție de cel mai bun mecanism de selecție a căii).
Abordările existente de filtrare și monitorizare încearcă să analizeze rutele și să ia decizii prin analiza atributului AS_PATH. Routerul poate schimba acest atribut la orice valoare în timpul reclamei. Pur și simplu adăugarea ASN-ului proprietarului la începutul lui AS_PATH (ca ASN de origine) poate fi suficientă pentru a ocoli mecanismele curente de verificare a originii. Mai mult, dacă există o rută de la ASN-ul atacat către tine, devine posibil să extragi și să folosești AS_PATH-ul acestei rute în celelalte reclame ale tale. Orice verificare de validare numai pentru AS_PATH pentru anunțurile dvs. elaborate va trece în cele din urmă.
Există încă câteva limitări care merită menționate. În primul rând, în cazul filtrării prefixului de către furnizorul din amonte, ruta dumneavoastră poate fi în continuare filtrată (chiar și cu AS_PATH corectă) dacă prefixul nu aparține conului dumneavoastră client configurat în amonte. În al doilea rând, un AS_PATH valid poate deveni invalid dacă traseul creat este anunțat în direcții incorecte și, prin urmare, încalcă politica de rutare. În cele din urmă, orice rută cu un prefix care încalcă lungimea ROA poate fi considerată nevalidă.
Incident
Acum câteva săptămâni am primit o reclamație de la unul dintre utilizatorii noștri. Am văzut rute cu prefixele sale de origine ASN și /25, în timp ce utilizatorul a susținut că nu le-a făcut publicitate.
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 pentru începutul lunii aprilie 2019
NTT în calea pentru prefixul /25 îl face deosebit de suspect. LG NTT nu cunoștea această rută la momentul incidentului. Deci da, un operator creează un întreg AS_PATH pentru aceste prefixe! Verificarea altor routere dezvăluie un anumit ASN: AS263444. După ce ne-am uitat la alte rute cu acest sistem autonom, am întâlnit 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 este în neregulă aici
Se pare că cineva a luat prefixul de pe traseu, l-a împărțit în două părți și a făcut publicitate rutei cu același AS_PATH pentru acele 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
Mai multe întrebări apar deodată. A încercat cineva în practică acest tip de interceptare? A luat cineva aceste rute? Ce prefixe au fost afectate?
Aici începe șirul nostru de eșecuri și încă o rundă de dezamăgire față de starea actuală a sănătății Internetului.
Calea eșecului
Să începem cu începutul. Cum putem determina ce routere au acceptat astfel de rute interceptate și al căror trafic ar putea fi redirecționat astăzi? Ne-am gândit să începem cu /25 prefixe pentru că „pur și simplu nu pot avea distribuție globală”. După cum puteți ghici, ne-am înșelat foarte mult. Această măsurătoare s-a dovedit a fi prea zgomotoasă și rutele cu astfel de prefixe pot apărea chiar și de la operatorii de nivel 1. De exemplu, NTT are aproximativ 50 de astfel de prefixe, pe care le distribuie propriilor clienți. Pe de altă parte, această măsurătoare este proastă, deoarece astfel de prefixe pot fi filtrate dacă operatorul le folosește , în toate direcțiile. Prin urmare, această metodă nu este potrivită pentru găsirea tuturor operatorilor al căror trafic a fost redirecționat în urma unui astfel de incident.
O altă idee bună la care ne-am gândit a fost să ne uităm . În special pentru rutele care încalcă regula maxLength a ROA corespunzătoare. În acest fel, am putea găsi numărul de ASN de origine diferită cu statut Invalid care au fost vizibile pentru un anumit AS. Cu toate acestea, există o „mică” problemă. Media (mediană și mod) acestui număr (numărul de ASN-uri de origine diferită) este de aproximativ 150 și, chiar dacă filtram prefixele mici, rămâne peste 70. Această stare de fapt are o explicație foarte simplă: există doar o puțini operatori care folosesc deja filtre ROA cu o politică de „resetare rute invalide” la punctele de intrare, astfel încât oriunde apare o rută cu o încălcare a ROA în lumea reală, aceasta se poate propaga în toate direcțiile.
Ultimele două abordări ne permit să găsim operatori care au văzut incidentul nostru (deoarece a fost destul de mare), dar în general nu sunt aplicabile. Bine, dar putem găsi intrusul? Care sunt caracteristicile generale ale acestei manipulări AS_PATH? Există câteva ipoteze de bază:
- Prefixul nu mai fusese văzut nicăieri;
- ASN de origine (memento: primul ASN din AS_PATH) este valid;
- Ultimul ASN din AS_PATH este ASN-ul atacatorului (în cazul în care vecinul său verifică ASN-ul vecinului pe toate rutele de intrare);
- Atacul provine de la un singur furnizor.
Dacă toate ipotezele sunt corecte, atunci toate rutele incorecte vor prezenta ASN-ul atacatorului (cu excepția ASN-ului de origine) și, prin urmare, acesta este un punct „critic”. Printre adevărații deturnatori a fost AS263444, deși au mai fost și alții. Chiar și atunci când am scos din considerare rutele incidente. De ce? Un punct critic poate rămâne critic chiar și pentru rutele corecte. Poate fi fie rezultatul unei conectivități slabe într-o regiune, fie al limitărilor în propria noastră vizibilitate.
Ca urmare, există o modalitate de a detecta un atacator, dar numai dacă toate condițiile de mai sus sunt îndeplinite și numai atunci când interceptarea este suficient de mare pentru a depăși pragurile de monitorizare. Dacă unii dintre acești factori nu sunt îndepliniți, atunci putem identifica prefixele care au suferit în urma unei astfel de interceptări? Pentru anumiți operatori - da.
Când un atacator creează o rută mai specifică, un astfel de prefix nu este anunțat de adevăratul proprietar. Dacă aveți o listă dinamică a tuturor prefixelor sale, atunci devine posibil să faceți o comparație și să găsiți rute mai specifice distorsionate. Colectăm această listă de prefixe folosind sesiunile noastre BGP, deoarece ni se oferă nu numai lista completă a rutelor vizibile operatorului chiar acum, ci și o listă cu toate prefixele pe care acesta dorește să le facă publicitate lumii. Din păcate, acum există câteva zeci de utilizatori Radar care nu completează corect ultima parte. Îi vom anunța în scurt timp și vom încerca să rezolvăm această problemă. Toți ceilalți se pot alătura sistemului nostru de monitorizare chiar acum.
Dacă revenim la incidentul inițial, atât atacatorul, cât și zona de distribuție au fost detectate de noi prin căutarea punctelor critice. În mod surprinzător, AS263444 nu a trimis rute fabricate tuturor clienților săi. Deși există un moment 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 încercare de a intercepta spațiul nostru de adrese
Când au fost create altele mai specifice pentru prefixele noastre, a fost folosit un AS_PATH special creat. Cu toate acestea, acest AS_PATH nu ar fi putut fi luat de pe niciunul dintre rutele noastre anterioare. Nici măcar nu avem comunicare cu AS6762. Privind celelalte rute din incident, unele dintre ele aveau un AS_PATH real care a fost folosit anterior, în timp ce altele nu, chiar dacă arată ca cel real. În plus, modificarea AS_PATH nu are niciun sens practic, deoarece traficul va fi oricum redirecționat către atacator, dar rutele cu AS_PATH „proastă” pot fi filtrate de ASPA sau de orice alt mecanism de inspecție. Aici ne gândim la motivația atacatorului. În prezent, nu avem suficiente informații pentru a confirma că acest incident a fost un atac planificat. Cu toate acestea, este posibil. Să încercăm să ne imaginăm, deși încă ipotetică, dar potențial destul de reală, o situație.
Atacul perfect
Ce avem? Să presupunem că sunteți un furnizor de transport public care difuzează rute pentru clienții dvs. Dacă clienții tăi au prezență multiplă (multihome), atunci vei primi doar o parte din traficul lor. Dar cu cât mai mult trafic, cu atât mai mult venitul tău. Deci, dacă începeți să faceți publicitate pentru prefixele de subrețea ale acestor rute cu același AS_PATH, veți primi restul traficului acestora. Drept urmare, restul banilor.
ROA va ajuta aici? Poate că da, dacă decideți să încetați complet să îl utilizați . În plus, este extrem de nedorit să existe înregistrări ROA cu prefixe care se intersectează. Pentru unii operatori, astfel de restricții sunt inacceptabile.
Având în vedere alte mecanisme de securitate de rutare, ASPA nu va ajuta nici în acest caz (pentru că folosește AS_PATH dintr-o rută validă). BGPSec încă nu este o opțiune optimă din cauza ratelor scăzute de adoptare și a posibilității rămase de atacuri de downgrade.
Deci avem un câștig clar pentru atacator și o lipsă de securitate. Super mix!
Ce ar trebui să fac?
Pasul evident și cel mai drastic este să revizuiți politica actuală de rutare. Împărțiți spațiul de adrese în cele mai mici bucăți (fără suprapuneri) pe care doriți să le faceți publicitate. Semnați ROA numai pentru ei, fără a utiliza parametrul maxLength. În acest caz, POV-ul tău actual te poate salva de un astfel de atac. Cu toate acestea, din nou, pentru unii operatori această abordare nu este rezonabilă din cauza utilizării exclusive a rutelor mai specifice. Toate problemele cu starea actuală a ROA și a obiectelor rutei vor fi descrise într-unul dintre materialele noastre viitoare.
În plus, puteți încerca să monitorizați astfel de interceptări. Pentru a face acest lucru, avem nevoie de informații fiabile despre prefixele dvs. Astfel, dacă stabiliți o sesiune BGP cu colecționarul nostru și ne furnizați informații despre vizibilitatea dvs. pe Internet, putem găsi amploarea altor incidente. Pentru cei care nu sunt încă conectați la sistemul nostru de monitorizare, pentru început, va fi suficientă o listă de rute doar cu prefixele dvs. Dacă aveți o sesiune cu noi, vă rugăm să verificați dacă toate rutele dvs. au fost trimise. Din păcate, acest lucru merită reținut deoarece unii operatori uită un prefix sau două și astfel interferează cu metodele noastre de căutare. Dacă se face corect, vom avea date fiabile despre prefixele dvs., care în viitor ne vor ajuta să identificăm și să detectăm automat acest (și alte) tipuri de interceptare a traficului pentru spațiul dvs. de adrese.
Dacă deveniți conștienți de o astfel de interceptare a traficului dvs. în timp real, puteți încerca să o contracarați singur. Prima abordare este de a face publicitate rutelor cu aceste prefixe mai specifice. În cazul unui nou atac asupra acestor prefixe, repetați.
A doua abordare este să pedepsești atacatorul și pe cei pentru care el este un punct critic (pentru rute bune) prin întreruperea accesului rutelor tale către atacator. Acest lucru se poate face prin adăugarea ASN-ului atacatorului la AS_PATH a vechilor rute și astfel forțați-i să evite acel AS folosind mecanismul de detectare a buclei încorporat în BGP .
Sursa: www.habr.com