Më 13 mars, grupi punues RIPE mbi abuzimet për të shqyrtuar BGP-përvetësimin (hjjack) si një shkelje të politikës RIPE. Nëse propozimi miratohet, ofruesi i internetit, i cili sulmohet përmes përvetësimit të trafik, do të kishte mundësinë të dërgonte një kërkesë të veçantë për të ekspozuar keqbërësin. Nëse grupi ekspert i mbledh prova të mjaftueshme konfirmuese, atëherë një LIR i tillë, që është burimi i BGP-përvetësimit, do të konsiderohej shkelës dhe mund të humbiste statusin LIR. Kishin edhe disa argumente ndryshime.
Në këtë botim ne dëshirojmë të tregojmë një shembull të një sulmi, kur jo vetëm keqbërësi i vërtetë ishte nën dyshim, por edhe lista e plotë e prefikseve të dëmtuara. Më shumë se kaq, një sulm i tillë e rris pyetjen mbi motivet e përvetësimeve të ardhshme të trafikut të këtij lloji.
Dy vitet e fundit, nĂ« shtyp vetĂ«m konfliktet e tipit MOAS (Sistem Autonom me OrigjinĂ« tĂ« ShumĂ«fishtĂ«) janĂ« pĂ«rmendur si BGP-pĂ«rvetĂ«sime. MOAS Ă«shtĂ« njĂ« rast i veçantĂ«, kur dy sisteme autonome tĂ« ndryshme shpallin prefikse nĂ« konflikt me numrat pĂ«rkatĂ«s ASN nĂ« AS_PATH (ASN i parĂ« nĂ« AS_PATH, duke vazhduar mĂ« tej - ASN origjinĂ«). MegjithatĂ«, ne mund tĂ« pĂ«rmendim tĂ« paktĂ«n tĂ« pĂ«rvetĂ«simit tĂ« trafikut, qĂ« lejojnĂ« keqbĂ«rĂ«sit tĂ« manipulojnĂ« atributin AS_PATH pĂ«r qĂ«llime tĂ« ndryshme, pĂ«rfshirĂ« pĂ«r tĂ« anashkaluar qasjet moderne pĂ«r filtrimin dhe monitorimin. NjĂ« tip i njohur sulmi - Ă«shtĂ« tipi i fundit i kĂ«tij pĂ«rvetĂ«simi, por aspak mĂ« i parĂ«ndĂ«sishĂ«m. ĂshtĂ« mjaft e mundshme qĂ« saktĂ«sisht njĂ« sulm tĂ« tillĂ« ne e kemi vĂ«zhguar gjatĂ« javĂ«ve tĂ« fundit. NjĂ« ngjarje e tillĂ« ka njĂ« karakter tĂ« shpjegueshĂ«m dhe pasojat e saj janĂ« mjaft serioze.
Ata që kërkojnë një version TL;DR, mund të rrokullisen deri te nënkryetari "Sulmi ideal".
Sfonda e rrjetit
(në mënyrë që të kuptoni më mirë proceset që janë angazhuar në këtë incident)
Nëse dëshironi të dërgoni një paketë dhe keni disa prefikse në tabelën e routing-ut, që përmbajnë adresën IP të destinacionit, do të përdorni rrugën për prefikstin me gjatësi maksimale. Nëse në tabelën e routing-ut ekzistojnë disa rrugë të ndryshme për një prefiks, do të zgjidhni atë më të mirën (sipas mekanizmit të zgjedhjes së rrugës më të mirë).
QasjetĂ« ekzistuese pĂ«r filtrimin dhe monitorimin pĂ«rpiqen tĂ« analizojnĂ« rrugĂ«t dhe tĂ« marrin vendime duke analizuar atributin AS_PATH. RuterĂ«t mund ta ndryshojnĂ« kĂ«tĂ« atribut nĂ« çdo vlerĂ« gjatĂ« njoftimit. Thjesht shtimi i ASN e pronarit nĂ« fillim tĂ« AS_PATH (si ASN origjinal) mund tĂ« jetĂ« e mjaftueshme pĂ«r tĂ« kaluar mekanizmat aktualĂ« tĂ« verifikimit tĂ« burimit. PĂ«r mĂ« tepĂ«r, nĂ«se ekziston njĂ« rrugĂ« nga ASN e sulmuar deri te ju, ka mundĂ«si tĂ« nxirret dhe tĂ« pĂ«rdoret AS_PATH i kĂ«saj rruge nĂ« njoftimet tuaja tĂ« tjera. Ădo verifikim i vĂ«rtetĂ«sisĂ« vetĂ«m i AS_PATH pĂ«r njoftimet tuaja tĂ« mbushura pĂ«rfundimisht do tĂ« pĂ«rfundonte me sukses.
EkzistojnĂ« gjithashtu disa kufizime tĂ« tjera qĂ« meritojnĂ« pĂ«rmendje. SĂ« pari, nĂ« rastin e filtrimit tĂ« prefikseve nga ofruesi mĂ« i lartĂ«, rruga juaj mund tĂ« filtrohet pĂ«r çdo arsye (madje edhe me AS_PATH tĂ« saktĂ«), nĂ«se prefiksi nuk i takon konusit tuaj tĂ« klientĂ«ve tĂ« vendosur te ofruesi upstream. E dyta â njĂ« AS_PATH i vlefshĂ«m mund tĂ« bĂ«het i pavlefshĂ«m, nĂ«se rruga e krijuar njoftohet nĂ« drejtime tĂ« papĂ«rshtatshme dhe, kĂ«shtu, shkel politikĂ«n e rrugĂ«timit. Dhe e fundit â çdo rrugĂ« me njĂ« prefiks qĂ« shkel gjatĂ«si tĂ« ROA mund tĂ« konsiderohet e pavlefshme.
Incidenti
Disa javë më parë, morëm një ankesë nga një nga përdoruesit. Pashë rrugët me ASN e saj origjinal dhe prefikse /25, ndërsa përdoruesi pohonte se ato nuk ishin njoftuar nga ana e tij.
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||
Shembuj të njoftimeve në fillim të prillit 2019
NTT duke udhëtuar për prefiksin /25 e bën atë veçanërisht të dyshimtë. Gjatë incidentit LG NTT nuk dinte asgjë për këtë rrugë. Kështu që, po, ndonjë operator po krijon një AS_PATH të plotë për këto prefikse! Verifikimi në ruterët e tjerë lejon të veçohet një ASN e veçantë: AS263444. Duke parë rrugët e tjera me këtë sistem autonom, hasëm situatën e mëposhtme:
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||
Provoni të keni parasysh se çfarë nuk shkon këtu
Duket se dikush ka marrë prefiksin nga rruga, e ka ndarë në dy pjesë dhe ka njoftuar një rrugë me të njëjtin AS_PATH për këto dy prefikse.
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||
Shembuj të rrugëve për një nga çiftet e prefikseve të ndara
Krijohet menjĂ«herĂ« njĂ« numĂ«r pyetjesh. A ka kush provuar nĂ« praktikĂ« kĂ«tĂ« lloj zaptimi? A ka ndonjĂ« qĂ« ka pranuar kĂ«to rrugĂ«? ĂfarĂ« prefikse janĂ« prekur?
Këtu fillon seria jonë e dështimeve dhe një raund tjetër zhgënjimi në gjendjen aktuale të shëndetit të Internetit.
Rruga e dështimeve
Të gjitha në radhë. Si mund të përcaktojmë se cilat routera po pranojnë këto rrugë të kapura dhe cilat trafik mund të redirigjohet që sot? Ne menduam të fillojmë me prefiksat /25, sepse ato "thjesht nuk mund të kenë shpërndarje globale". Siç mund ta imagjinoni - ne ishim shumë në gabim. Kjo metrikë rezultoi shumë e zhurmshme dhe rrugët me këto prefikse mund të shfaqen madje edhe nga operatorët Tier-1. Për shembull, NTT ka rreth 50 nga këto prefikse që ai i shpërndan midis klientëve të tij. Nga ana tjetër, kjo metrikë është e dobët, sepse këto prefikse mund të filtrohen në rast se operatori aplikon , në të gjitha drejtimet. Prandaj, ky metod nuk është i përshtatshëm për të gjetur të gjithë operatorët, të cilët trafikuan rezultatin e ngjarjeve të tilla.
Një ide tjetër e mirë na duket të shikojmë në . Sidomos në rrugët që shkelin rregullin maxLength të ROA përkatës. Në këtë mënyrë, mund të gjejmë numrin e ASN-ve origjinale të ndryshme me status Invalid, që ishin të dukshme për këtë AS. Megjithatë, ka një "problem të vogël". Vlera mesatare (mediana dhe moda) e këtij numri (numri i ASN-ve origjinale të ndryshme) është rreth 150 dhe, edhe nëse ne filtrojmë prefikset e vogla, ajo do të mbetet mbi 70. Kjo situatë ka një shpjegim të thjeshtë: ka vetëm disa operatorë që tashmë aplikojnë filtra ROA me politikën "të ridrejtojnë rrugët Invalid" në pikët hyrëse, prandaj, kudo që një rrugë me shkelje ROA shfaqet në botën reale, ajo mund të shpërndahet në të gjitha drejtimet.
Dy qasjet e fundit lejojnë të gjejmë operatorët që panë incidentin tonë (duke qenë se ai ishte mjaft i madh), por përgjithësisht ato janë të papërshtatshme. Mirë, por a mund të gjejmë autorin? Cilat janë karakteristikat e përgjithshme të një manovrimi të tillë të AS_PATH? Ka disa supozime themelore:
- Prefiksi kurrë nuk është vërejtur më parë;
- ASN origjinal (kujtesa: ASN-i parë në AS_PATH) është valid;
- ASN-i i fundit në AS_PATH është ASN-i i sulmuesit (në rast se fqinj i kontrollon ASN-in e fqinjit në të gjitha rrugët hyrëse);
- Sulmi vjen nga një ofrues i vetëm.
Nëse të gjitha supozimet janë të sakta, atëherë në të gjitha rrugët e gabuara do të paraqitet ASN i sulmuesit (përveç ASN origjinal) dhe, kështu, kjo është një "pikë kritike". Mes grabitësve të vërtetë ishte edhe AS263444, megjithëse kishte edhe të tjerë. Edhe kur e hodhëm poshtë rrugët e incidentit nga shqyrtimi. Pse? Pika kritike mund të mbetet kritike edhe për rrugët e sakta. Ajo mund të jetë ose rezultat i lidhshmërisë së dobët në ndonjë rajon, ose kufizimeve të shikueshmërisë sonë.
Si rezultat: ka njĂ« mĂ«nyrĂ« pĂ«r tĂ« zbuluar sulmuesin, por vetĂ«m nĂ« rast se pĂ«rputhen tĂ« gjitha kushtet e mĂ«sipĂ«rme dhe vetĂ«m kur kapja Ă«shtĂ« mjaft e madhe pĂ«r tĂ« kaluar pragjet e monitorimit. NĂ«se disa nga kĂ«to faktorĂ« nuk respektohen, a mund tĂ« identifikojmĂ« prefixet e prekur nga njĂ« kapje tĂ« tillĂ«? PĂ«r disa operatorĂ« â po.
Kur sulmuesi krijon një rrugë më specifike, ky prefix nuk shpallet nga pronari i vërtetë. Në rast se ju keni një listë dinamike të të gjitha prefixeve të tij, atëherë krijohet mundësia për të bërë një krahasim dhe për të gjetur rrugët e deformuara më specifike. Ne mbledhim këtë listë prefixesh përmes BGP sesioneve tona, pasi na jepet jo vetëm lista e plotë e rrugëve, të dukshme për operatorin tani, por edhe lista e të gjitha prefixeve që ai dëshiron të shpallë në botë. Fatkeqësisht, tani ka disa dhjetëra përdorues Radar, të cilët këtë pjesë të fundit nuk e realizojnë plotësisht siç duhet. Së shpejti do t'i njoftojmë ata dhe do të përpiqemi të zgjidhim këtë problem. Të tjerët mund të bashkohen me sistemin tonë të monitorimit tani.
Nëse kthehemi në incidentin fillestar, si sulmuesi ashtu edhe zona e shpërndarjes u identifikuan nga ne duke kërkuar pika kritike. Befas, por AS263444 po shpërndante rrugë të falsifikuara vetëm për disa nga klientët e tij. Megjithatë, ka edhe një pikë më të çuditshme.
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||
Një shembull i fundit i përpjekjes për të kapur hapësirën tonë adresore
Kur u krijuan more specificâĂ«t pĂ«r prefiksat tanĂ«, u pĂ«rdor njĂ« AS_PATH i krijuar posaçërisht. MegjithatĂ«, ky AS_PATH nuk mund tĂ« merrej nga asnjĂ« nga rrugĂ«t tona tĂ« mĂ«parshme. Ne madje nuk kemi lidhje me AS6762. Po shikojmĂ« rrugĂ« tĂ« tjera nĂ« incident: disa prej tyre patĂ«n njĂ« AS_PATH tĂ« vĂ«rtetĂ«, i cili u pĂ«rdor mĂ« parĂ«, ndĂ«rsa tĂ« tjerĂ«t jo, edhe nĂ«se duken si tĂ« tillĂ«. NjĂ« ndryshim tjetĂ«r nĂ« AS_PATH nuk ka asnjĂ« kuptim praktik, pasi nĂ« çdo rast trafiku do tĂ« redirektohet te sulmuesi, por rrugĂ«t me AS_PATH tĂ« 'keq' mund tĂ« filtrohen nga ASPA ose ndonjĂ« mekanizĂ«m tjetĂ«r verifikimi. KĂ«tu, ne po mendojmĂ« pĂ«r motivin e grabitĂ«sit. Tani na mungojnĂ« tĂ« dhĂ«nat pĂ«r tĂ« pretenduar se ky incident ishte njĂ« sulm i planifikuar. MegjithatĂ«, Ă«shtĂ« e mundur. Le tĂ« pĂ«rpiqemi tĂ« imagjinomĂ« njĂ« situatĂ«, ndonĂ«se hipotetike, por potencialisht shumĂ« reale.
Sulmi ideal
ĂfarĂ« kemi? Supozoni se jeni njĂ« ofrues transit, qĂ« transmeton rrugĂ«t pĂ«r klientĂ«t e tij. NĂ«se klientĂ«t tuaj kanĂ« njĂ« prani multiple (multihome), atĂ«herĂ« do tĂ« merrni vetĂ«m njĂ« pjesĂ« tĂ« trafikut tĂ« tyre. Por sa mĂ« shumĂ« trafik â aq mĂ« shumĂ« tĂ« ardhura pĂ«r ju. Prandaj, nĂ«se filloni tĂ« shpallni prefikset e nĂ«nrrugĂ«ve tĂ« kĂ«tyre rrugĂ«ve me tĂ« njĂ«jtin AS_PATH, do tĂ« merrni pjesĂ«n tjetĂ«r tĂ« trafikut tĂ« tyre. Si pasojĂ«, do tĂ« merrni edhe pjesĂ«n tjetĂ«r tĂ« parave.
A do të ndihmojë këtu ROA? Ndoshta, po, nëse vendosni të tërhiqeni plotësisht nga përdorimi . Për më tepër, në këtë rast është jashtëzakonisht e papërshtatshme të keni regjistrime ROA me prefikse të mbivendosura. Për disa operatorë, këto kufizime janë të papranueshme.
Duke shqyrtuar mekanizmat e tjerë për sigurimin e sigurisë së rrugëve, në këtë rast ASPA gjithashtu nuk do të ndihmojë (sepse përdoret AS_PATH nga rruga e lejueshme). BGPSec ende nuk është një opsion optimal për shkak të përqindjes së ulët të pranimit dhe mundësisë së mbetjeve të sulmeve downgrade.
Prandaj, ne kemi një fitim të qartë për sulmuesin dhe mungesë sigurie. Një përzierje e shkëlqyer!
ĂfarĂ« duhet tĂ« bĂ«jmĂ«?
Hapi i dukshëm dhe më radikal është rishikimi i politikës tuaj aktuale të rrugëzimit. Ndaloni hapësirën tuaj të adresave në copëza sa më të vogla (pa përputhje) që dëshironi të shpallni. Nënshkruani ROA vetëm për to, pa përdorur parametrin maxLength. Në këtë rast, POV aktual mund t'ju shpëtojë nga një sulm të tillë. Megjithatë, përsëri, për disa operatëra ky qasje nuk është e arsyeshme për shkak të përdorimit të jashtëzakonshëm të rrugëve më specifike. Të gjitha problemet e aktualizuara të ROA dhe objekteve të rrugës do të përshkruhen në një nga materialet tona të ardhshme.
Përveç kësaj, mund të përpiqeni të monitoroni interceptimet e tilla. Për këtë, na nevojitet informacion i besueshëm për prefiksat tuaja. Kështu, nëse vendosni një sesion BGP me kolektorin tonë dhe na dërgoni informacionin tuaj mbi dukshmërinë në internet - ne mund të gjejmë fushën e shpërndarjes dhe për incidente të tjera. Për ata që ende nuk janë të lidhur me sistemin tonë të monitorimit - fillimisht na mjafton një listë rrugësh me vetëm prefiksat tuaj. Nëse keni një sesion me ne, ju lutemi kontrolloni që të gjitha rrugët tuaja janë dërguar. Fatkeqësisht, kjo duhet përmendur, pasi disa operatëra harrojnë një ose dy prefikse dhe kështu krijojnë pengesa për metodat tona të kërkimit. Nëse bëhet siç duhet, do të kemi të dhëna të besueshme mbi prefiksat tuaja, të cilat në të ardhmen do të ndihmojnë për të identifikuar në mënyrë automatike dhe për të zbuluar këtë (dhe lloje të tjera) të interceptimit të trafikëve për hapësirën tuaj të adresave.
Nëse e kuptoni në kohë reale një interceptim të tillë të trafikës tuaj, mund të provoni të kundërshtoni vetë. Qasja e parë është të shpallni rrugët me këto prefikse më specifike vetë. Në rast të një sulmi të ri ndaj këtyre prefikseve - përsërisni.
Qasja e dytë është të ndëshkoni agresorin dhe ata për të cilët ai është një pikë e rëndësishme (për rrugët e mira), duke e prerë aksesin e rrugëve tuaja tek agresori. Kjo mund të bëhet duke e shtuar ASN e agresorit në AS_PATH e rrugëve tuaja të vjetra duke e detyruar ata të shmangin këtë AS, duke përdorur mekanizmin e ndërtuar për zbulesën e cikleve në BGP. .
Burimi: habr.com
