13. Mäerz un der RIPE Anti-Mëssbrauch Aarbechtsgrupp betruecht BGP kaping (hjjack) als Violatioun vun RIPE Politik. Wann d'Propositioun ugeholl gëtt, hätt den Internet-Provider, deen duerch Traffic-Interceptioun attackéiert gëtt, d'Méiglechkeet eng speziell Ufro ze schécken fir den Ugräifer z'exposéieren. Wann d'Iwwerpréiwungsteam genuch ënnerstëtzend Beweiser gesammelt huet, géif de LIR, deen d'Quell vun der BGP-Interceptioun war, als Andréngen ugesi ginn a kéint vu sengem LIR-Status entlooss ginn. Et goufen och Argumenter Ännerungen.
An dëser Verëffentlechung wëlle mir e Beispill vun engem Attack weisen, wou net nëmmen de richtegen Ugräifer a Fro war, awer och déi ganz Lëscht vun de betraffene Präfixe. Desweideren stellt esou en Attentat nach eng Kéier d'Froen op d'Motiver fir zukünfteg Interceptiounen vun dëser Zort Verkéier.
An de leschte Joren sinn nëmmen Konflikter wéi MOAS (Multiple Origin Autonomous System) an der Press als BGP-Interceptiounen ofgedeckt ginn. MOAS ass e spezielle Fall wou zwee verschidden autonom Systemer konfliktend Präfixe mat entspriechenden ASNen an AS_PATH annoncéieren (den éischten ASN an AS_PATH, heino als Origin ASN bezeechent). Mir kënnen awer op d'mannst nennen Traffic Offangen, wat en Ugräifer erlaabt den AS_PATH Attribut fir verschidden Zwecker ze manipuléieren, dorënner modern Approche fir ze filteren an ze iwwerwaachen. Bekannt Attack Typ - déi lescht Zort vun esou Interceptioun, awer guer net an der Wichtegkeet. Et ass ganz méiglech datt dëst genau d'Aart vun Attack ass, déi mir an de leschte Wochen gesinn hunn. Esou en Event huet eng verständlech Natur an zimlech sérieux Konsequenzen.
Déi, déi no der TL;DR Versioun sichen, kënnen op den "Perfect Attack" Ënnertitel scrollen.
Reseau Hannergrond
(fir Iech ze hëllefen d'Prozesser déi an dësem Tëschefall involvéiert sinn besser ze verstoen)
Wann Dir e Paket wëllt schécken an Dir hutt verschidde Präfixe an der Routing-Tabelle mat der Destinatioun IP Adress, da benotzt Dir de Wee fir de Präfix mat der längster Längt. Wann et e puer verschidde routes fir déi selwecht Präfix am Routing Dësch, Dir wäert déi bescht wielen (no déi bescht Wee Auswiel Mechanismus).
Bestehend Filter- an Iwwerwaachungs Approche probéieren d'Strecken ze analyséieren an Entscheedungen ze treffen andeems Dir den AS_PATH Attribut analyséiert. De Router kann dësen Attribut op all Wäert während der Annonce änneren. Einfach den ASN vum Besëtzer um Ufank vun AS_PATH (als Origin ASN) bäizefügen kann genuch sinn fir den aktuellen Hierkonftprüfungsmechanismen ëmzegoen. Ausserdeem, wann et e Wee vum attackéierten ASN fir Iech ass, gëtt et méiglech den AS_PATH vun dësem Wee an Ären anere Reklammen ze extrahieren an ze benotzen. All AS_PATH-nëmmen Validatiounscheck fir Är erstallt Ukënnegung wäert schlussendlech passéieren.
Et ginn nach e puer Aschränkungen ze ernimmen. Als éischt, am Fall vu Präfixfilterung vum Upstream-Provider, kann Äre Wee nach ëmmer gefiltert ginn (och mam korrekten AS_PATH) wann de Präfix net zu Ärem Clientkegel gehéiert, deen am Upstream konfiguréiert ass. Zweetens, e gëltege AS_PATH kann ongëlteg ginn wann de geschafe Wee a falsch Richtungen ugekënnegt gëtt an domat d'Routing Politik verletzt. Schlussendlech kann all Wee mat engem Präfix, deen d'ROA-Längt verletzt, als ongëlteg ugesi ginn.
Tëschefall
Virun e puer Woche krute mir eng Plainte vun engem vun eise Benotzer. Mir gesinn routes mat sengem Urspronk ASN an /25 Präfix, iwwerdeems de Benotzer behaapt, datt hien net Reklamm hinnen.
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||
Beispiller vun Ukënnegung fir Ufank Abrëll 2019
NTT am Wee fir de /25 Präfix mécht et besonnesch verdächteg. LG NTT war net bewosst vun dëser Streck zu der Zäit vum Tëschefall. Also jo, e puer Bedreiwer erstellt e ganze AS_PATH fir dës Präfixe! Iwwerpréift op aner Router weist e bestëmmten ASN: AS263444. Nodeems mir aner Strecken mat dësem autonome System gekuckt hunn, hu mir déi folgend Situatioun begéint:
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||
Probéiert ze roden wat hei falsch ass
Et schéngt, datt een de Präfix vun der Streck geholl huet, en an zwee Deeler opgedeelt huet an de Wee mam selwechten AS_PATH fir déi zwee Präfixe ugekënnegt huet.
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||
Beispill routes fir ee vun de Split Präfix Puer
Verschidde Froen stellen sech op eemol. Huet iergendeen dës Zort vun Offangen an der Praxis wierklech probéiert? Huet iergendeen dës Strecken geholl? Wéi eng Präfixe ware betraff?
Dëst ass wou eis String vu Feeler ufänkt an nach eng Kéier Enttäuschung mam aktuellen Zoustand vun der Gesondheet vum Internet.
De Wee vum Echec
Éischt Saachen éischt. Wéi kënne mir bestëmmen wéi eng Router esou ofgefaangen Strecken akzeptéiert hunn a wéi en Traffic haut kéint ëmgeleet ginn? Mir hu geduecht datt mir mat /25 Präfixe ufänken well se "einfach keng global Verdeelung kënnen hunn." Wéi Dir kënnt roden, ware mir ganz falsch. Dës Metrik huet sech als ze laut erausgestallt a Strecken mat sou Präfixe kënne souguer vu Tier-1 Betreiber erscheinen. Zum Beispill, NTT huet ongeféier 50 esou Präfixe, déi et un seng eege Clienten verdeelt. Op der anerer Säit ass dës Metrik schlecht well sou Präfixe kënne gefiltert ginn wann de Bedreiwer benotzt , an all Richtungen. Dofir ass dës Method net gëeegent fir all Betreiber ze fannen, deenen hire Verkéier als Resultat vun esou engem Tëschefall ëmgeleet gouf.
Eng aner gutt Iddi, déi mir geduecht hunn, war ze kucken . Besonnesch fir Strecken déi d'maxLength Regel vun der entspriechender ROA verletzen. Dës Aart a Weis konnt mir d'Zuel vun verschidden Origine ASNs mat Status Invalid fannen dass zu engem bestëmmte AS siichtbar waren. Allerdéngs gëtt et e "klenge" Problem. Den Duerchschnëtt (Median a Modus) vun dëser Zuel (d'Zuel vu verschiddenen Originnen ASNs) ass ongeféier 150 an, och wa mir kleng Präfixe filteren, bleift se iwwer 70. Dësen Zoustand huet eng ganz einfach Erklärung: et gëtt nëmmen eng puer Opérateuren déi schonn ROA- Filtere mat enger "Reset Invalid routes" Politik op Entrée Punkten benotzen, sou datt egal wou eng Streck mat enger ROA Violatioun schéngt an der real Welt, et kann an all Richtungen propagéieren.
Déi lescht zwou Approche erlaben eis Betreiber ze fannen déi eisen Tëschefall gesinn hunn (well et zimlech grouss war), awer allgemeng sinn se net applicabel. Okay, awer kënne mir den Andréngen fannen? Wat sinn d'allgemeng Fonctiounen vun dëser AS_PATH Manipulatioun? Et ginn e puer grondleeënd Viraussetzungen:
- De Präfix war néierens virdru gesi ginn;
- Origin ASN (Erënnerung: éischt ASN an AS_PATH) ass valabel;
- Déi lescht ASN am AS_PATH ass den ASN vum Ugräifer (am Fall datt säin Noper den ASN vum Noper op all erakommen Strecken iwwerpréift);
- D'Attack staamt vun engem eenzege Provider.
Wann all Viraussetzunge richteg sinn, da presentéieren all falsch Strecken den ASN vum Ugräifer (ausser den Hierkonft ASN) an dofir ass dëst e "kriteschen" Punkt. Ënnert de richtege Kaper war AS263444, obwuel et anerer waren. Och wa mir den Tëschefall routes aus Iwwerleeung verworf. Firwat? E kritesche Punkt kann kritesch bleiwen och fir richteg Strecken. Et kann entweder d'Resultat vun enger schlechter Konnektivitéit an enger Regioun sinn oder Aschränkungen an eiser eegener Visibilitéit.
Als Resultat gëtt et e Wee fir en Ugräifer z'entdecken, awer nëmmen wann all déi uewe genannte Konditioune erfëllt sinn an nëmmen wann d'Interceptioun grouss genuch ass fir d'Iwwerwaachungsschwellen ze passéieren. Wann e puer vun dëse Faktoren net erfëllt sinn, da kënne mir d'Präfixe identifizéieren, déi aus esou Offangen leiden? Fir bestëmmte Bedreiwer - jo.
Wann en Ugräifer e méi spezifesche Wee erstellt, gëtt sou e Präfix net vum richtege Besëtzer ugekënnegt. Wann Dir eng dynamesch Lëscht vun all seng Präfixe vun et hunn, da gëtt et méiglech e Verglach ze maachen an verzerrt méi spezifesch routes fannen. Mir sammelen dës Lëscht vu Präfixe mat eise BGP Sessiounen, well mir kréien net nëmmen déi komplett Lëscht vu routes, déi dem Bedreiwer elo siichtbar sinn, awer och eng Lëscht vun all de Präfixe, déi e wëll op d'Welt reklaméieren. Leider ginn et elo e puer Dosen Radar Benotzer déi de leschten Deel net richteg ausfëllen. Mir informéieren hinnen kuerz a probéieren dëst Thema ze léisen. Jiddereen aneren kann elo bei eisem Iwwerwaachungssystem bäitrieden.
Wa mir zréck op den ursprénglechen Tëschefall, souwuel den Ugräifer wéi och d'Verdeelungsberäich goufe vun eis entdeckt andeems mir no kritesche Punkte sichen. Iwwerraschend huet AS263444 net fabrizéierte Strecken un all seng Clienten geschéckt. Obwuel et e frieme Moment ass.
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||
E rezent Beispill vun engem Versuch eis Adressraum z'ënnerscheeden
Wann méi spezifesch fir eis Präfixe erstallt goufen, gouf e speziell erstallt AS_PATH benotzt. Wéi och ëmmer, dësen AS_PATH konnt net vun enger vun eise fréiere Strecken geholl ginn. Mir hunn net mol Kommunikatioun mat AS6762. Wann Dir op déi aner Strecken am Tëschefall kuckt, hunn e puer vun hinnen e richtegen AS_PATH dee virdru benotzt gouf, anerer hunn net, och wann et ausgesäit wéi déi richteg. D'Ännerung vun AS_PATH zousätzlech mécht kee praktesche Sënn, well de Traffic souwisou un den Ugräifer ëmgeleet gëtt, awer Strecken mat engem "schlechten" AS_PATH kënnen duerch ASPA oder all aner Inspektiounsmechanismus gefiltert ginn. Hei denken mir iwwer d'Motivatioun vum Kaper. Mir hunn de Moment net genuch Informatioun fir ze bestätegen datt dësen Tëschefall e geplangten Attack war. Trotzdem ass et méiglech. Loosst eis probéieren eng Situatioun virzestellen, obwuel nach ëmmer hypothetesch, awer potenziell ganz reell.
Perfekt Attack
Wat hu mir? Loosst eis soen datt Dir en Transitprovider sidd deen routes fir Är Clienten ausstrahlt. Wann Är Clienten méi Präsenz hunn (Multihome), da kritt Dir nëmmen en Deel vun hirem Traffic. Mä de méi Verkéier, der méi Är Akommes. Also wann Dir Subnet Präfixe vun deene selwechte Strecken mat der selwechter AS_PATH Reklamm ufänkt, kritt Dir de Rescht vun hirem Traffic. Als Resultat, de Rescht vun de Suen.
Wäert ROA hei hëllefen? Vläicht jo, wann Dir decidéiert et komplett ze benotzen . Zousätzlech ass et héich onerwënscht ROA-Records mat intersecting Präfixe ze hunn. Fir e puer Betreiber sinn esou Restriktiounen inakzeptabel.
Wann Dir aner Routing-Sécherheetsmechanismen berécksiichtegt, hëlleft ASPA och an dësem Fall net (well et AS_PATH vun enger valabeler Streck benotzt). BGPSec ass nach ëmmer net eng optimal Optioun wéinst nidderegen Adoptiounsraten an déi verbleiwen Méiglechkeet vun Downgrade Attacken.
Also hu mir e klore Gewënn fir den Ugräifer an e Manktem u Sécherheet. Flott Mëschung!
Wat maachen?
Déi offensichtlech an drasteschste Schrëtt ass Är aktuell Routing Politik ze iwwerpréiwen. Break Är Adressraum an déi klengst Stécker (keng Iwwerlappungen) déi Dir wëllt annoncéieren. Zeechen ROA nëmme fir si, ouni de maxLength Parameter ze benotzen. An dësem Fall kann Är aktuell POV Iech vun esou engem Attack retten. Wéi och ëmmer, fir e puer Betreiber ass dës Approche net raisonnabel wéinst der exklusiver Notzung vu méi spezifesche Strecken. All Problemer mam aktuellen Zoustand vun ROA a Streck Objete wäert an engem vun eisen zukünfteg Material beschriwwe ginn.
Zousätzlech kënnt Dir probéieren esou Interceptiounen ze iwwerwaachen. Fir dëst ze maachen, brauche mir zouverlässeg Informatioun iwwer Är Präfixe. Also, wann Dir eng BGP Sessioun mat eisem Sammler opstellt an eis Informatioun iwwer Är Internet Visibilitéit gitt, kënne mir de Spillraum fir aner Tëschefäll fannen. Fir déi, déi nach net un eisem Iwwerwachungssystem verbonne sinn, fir unzefänken, ass eng Lëscht vu Strecken nëmme mat Äre Präfixe genuch. Wann Dir eng Sessioun mat eis hutt, kontrolléiert weg datt all Är Strecken geschéckt goufen. Leider ass et derwäert ze erënneren, well verschidde Betreiber e Präfix oder zwee vergiessen an domat eis Sichmethoden stéieren. Wann et richteg gemaach gëtt, hu mir zouverlässeg Donnéeën iwwer Är Präfixe, déi eis an Zukunft hëllefen, automatesch dës (an aner) Zorte vu Traffic-Interceptioun fir Är Adressraum z'identifizéieren an z'entdecken.
Wann Dir an Echtzäit esou eng Offange vun Ärem Traffic bewosst sidd, kënnt Dir probéieren et selwer entgéintzewierken. Déi éischt Approche ass fir Routen mat dëse méi spezifesche Präfixe selwer annoncéieren. Am Fall vun enger neier Attack op dës Präfixe, widderhuelen.
Déi zweet Approche ass den Ugräifer an déi fir déi hien e kritesche Punkt ass (fir gutt Strecken) ze bestrofen andeems Dir den Zougang vun Äre Strecken zum Ugräifer ofschneiden. Dëst kann gemaach ginn andeems den ASN vum Ugräifer op den AS_PATH vun Ären alen Strecken bäigefüügt gëtt a se doduerch forcéiere fir datt AS den agebaute Loop Detectiounsmechanismus am BGP benotzt. .
Source: will.com