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
