13. marts til RIPE arbejdsgruppen mod misbrug betragte BGP-kapring (hjjack) som en overtrædelse af RIPE-politikken. Hvis forslaget blev accepteret, ville internetudbyderen, der blev angrebet af trafikaflytning, have mulighed for at sende en særlig anmodning om at afsløre angriberen. Hvis gennemgangsholdet indsamlede tilstrækkeligt bevismateriale, ville den LIR, der var kilden til BGP-aflytningen, blive betragtet som en ubuden gæst og kunne blive frataget sin LIR-status. Der var også nogle argumenter ændringer.
I denne publikation ønsker vi at vise et eksempel på et angreb, hvor der ikke kun var tale om den rigtige angriber, men også hele listen over berørte præfikser. Desuden rejser et sådant angreb igen spørgsmål om motiverne for fremtidige aflytninger af denne type trafik.
I løbet af de sidste par år er kun konflikter som MOAS (Multiple Origin Autonomous System) blevet dækket i pressen som BGP-aflytninger. MOAS er et særligt tilfælde, hvor to forskellige autonome systemer annoncerer modstridende præfikser med tilsvarende ASN'er i AS_PATH (den første ASN i AS_PATH, i det følgende benævnt oprindelses-ASN). Dog kan vi i det mindste nævne trafikaflytning, hvilket giver en hacker mulighed for at manipulere AS_PATH-attributten til forskellige formål, herunder at omgå moderne tilgange til filtrering og overvågning. Kendt angrebstype - den sidste type af sådan aflytning, men slet ikke i betydning. Det er meget muligt, at det er præcis den slags angreb, vi har set i løbet af de seneste uger. En sådan begivenhed har en forståelig karakter og ret alvorlige konsekvenser.
De, der leder efter TL;DR-versionen, kan rulle til underteksten "Perfect Attack".
Netværksbaggrund
(for at hjælpe dig med bedre at forstå de processer, der er involveret i denne hændelse)
Hvis du vil sende en pakke, og du har flere præfikser i rutetabellen, der indeholder destinations-IP-adressen, vil du bruge ruten til præfikset med den længste længde. Hvis der er flere forskellige ruter for det samme præfiks i rutetabellen, vil du vælge den bedste (i henhold til den bedste vejvalgsmekanisme).
Eksisterende filtrerings- og overvågningsmetoder forsøger at analysere ruter og træffe beslutninger ved at analysere AS_PATH-attributten. Routeren kan ændre denne egenskab til enhver værdi under annoncering. Blot at tilføje ejerens ASN i begyndelsen af AS_PATH (som oprindelses-ASN) kan være nok til at omgå mekanismerne til kontrol af nuværende oprindelse. Desuden, hvis der er en rute fra det angrebne ASN til dig, bliver det muligt at udtrække og bruge AS_PATH for denne rute i dine andre annoncer. Enhver AS_PATH-only valideringskontrol for dine udformede meddelelser vil i sidste ende bestå.
Der er stadig et par begrænsninger, der er værd at nævne. For det første, i tilfælde af præfiksfiltrering af upstream-udbyderen, kan din rute stadig blive filtreret (selv med den korrekte AS_PATH), hvis præfikset ikke tilhører din klientkegle, der er konfigureret på upstream. For det andet kan en gyldig AS_PATH blive ugyldig, hvis den oprettede rute annonceres i forkerte retninger og dermed overtræder routingpolitikken. Endelig kan enhver rute med et præfiks, der overtræder ROA-længden, blive betragtet som ugyldig.
Utilsigtet hændelse
For et par uger siden modtog vi en klage fra en af vores brugere. Vi så ruter med hans oprindelse ASN og /25 præfikser, mens brugeren hævdede, at han ikke annoncerede dem.
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||
Eksempler på annonceringer for begyndelsen af april 2019
NTT i stien til /25-præfikset gør det særligt mistænkeligt. LG NTT var uvidende om denne rute på tidspunktet for hændelsen. Så ja, en eller anden operatør opretter en hel AS_PATH for disse præfikser! Tjek på andre routere afslører en bestemt ASN: AS263444. Efter at have set på andre ruter med dette autonome system, stødte vi på følgende situation:
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||
Prøv at gætte, hvad der er galt her
Det ser ud til, at nogen tog præfikset fra ruten, delte det i to dele og annoncerede ruten med den samme AS_PATH for disse to præfikser.
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||
Eksempel på ruter for et af de opdelte præfiks-par
Der opstår flere spørgsmål på én gang. Har nogen rent faktisk prøvet denne type aflytning i praksis? Har nogen taget disse ruter? Hvilke præfikser blev påvirket?
Det er her, vores række af fiaskoer begynder og endnu en runde af skuffelse over den aktuelle tilstand af internettets helbred.
Vejen til fiasko
Første ting først. Hvordan kan vi afgøre, hvilke routere der accepterede sådanne opsnappede ruter, og hvis trafik kunne omdirigeres i dag? Vi troede, at vi ville starte med /25 præfikser, fordi de "simpelthen ikke kan have global distribution." Som du kan gætte, tog vi meget fejl. Denne metrik viste sig at være for støjende, og ruter med sådanne præfikser kan forekomme selv fra Tier-1-operatører. For eksempel har NTT omkring 50 sådanne præfikser, som den distribuerer til sine egne kunder. På den anden side er denne metrik dårlig, fordi sådanne præfikser kan filtreres fra, hvis operatøren bruger , i alle retninger. Derfor er denne metode ikke egnet til at finde alle operatører, hvis trafik blev omdirigeret som følge af en sådan hændelse.
En anden god idé, vi syntes, var at se på . Især for ruter, der overtræder maxLength-reglen for den tilsvarende ROA. På denne måde kunne vi finde antallet af forskellige oprindelses-ASN'er med status Invalid, der var synlige for en given AS. Der er dog et "lille" problem. Gennemsnittet (medianen og tilstanden) af dette tal (antallet af forskellige oprindelses-ASN'er) er omkring 150, og selvom vi filtrerer små præfikser fra, forbliver det over 70. Denne situation har en meget enkel forklaring: der er kun en få operatører, der allerede bruger ROA-filtre med en "nulstil ugyldige ruter"-politik ved indgangspunkter, så uanset hvor en rute med en ROA-overtrædelse dukker op i den virkelige verden, kan den forplante sig i alle retninger.
De sidste to tilgange giver os mulighed for at finde operatører, der så vores hændelse (da den var ret stor), men generelt er de ikke anvendelige. Okay, men kan vi finde den ubudne gæst? Hvad er de generelle træk ved denne AS_PATH-manipulation? Der er et par grundlæggende antagelser:
- Forstavelsen var ikke set nogen steder før;
- Oprindelses-ASN (påmindelse: første ASN i AS_PATH) er gyldig;
- Den sidste ASN i AS_PATH er angriberens ASN (i tilfælde af at dens nabo tjekker naboens ASN på alle indgående ruter);
- Angrebet stammer fra en enkelt udbyder.
Hvis alle antagelser er korrekte, vil alle forkerte ruter præsentere angriberens ASN (undtagen oprindelses-ASN), og dette er således et "kritisk" punkt. Blandt de sande flykaprere var AS263444, selvom der var andre. Selv når vi kasserede hændelsens ruter fra overvejelse. Hvorfor? Et kritisk punkt kan forblive kritisk selv for korrekte ruter. Det kan enten være resultatet af dårlige forbindelser i en region eller begrænsninger i vores egen synlighed.
Som et resultat er der en måde at opdage en angriber på, men kun hvis alle ovenstående betingelser er opfyldt, og kun når aflytningen er stor nok til at passere overvågningstærsklerne. Hvis nogle af disse faktorer ikke er opfyldt, kan vi så identificere de præfikser, der led af en sådan aflytning? For visse operatører - ja.
Når en angriber opretter en mere specifik rute, annonceres et sådant præfiks ikke af den sande ejer. Hvis du har en dynamisk liste over alle dens præfikser fra den, bliver det muligt at foretage en sammenligning og finde forvrængede mere specifikke ruter. Vi indsamler denne liste over præfikser ved hjælp af vores BGP-sessioner, fordi vi ikke kun får den fulde liste over ruter, der er synlige for operatøren lige nu, men også en liste over alle de præfikser, som den ønsker at reklamere for til verden. Desværre er der nu flere dusin Radar-brugere, som ikke fuldfører den sidste del korrekt. Vi giver dem besked om kort tid og prøver at løse dette problem. Alle andre kan tilslutte sig vores overvågningssystem lige nu.
Hvis vi vender tilbage til den oprindelige hændelse, blev både angriberen og distributionsområdet opdaget af os ved at søge efter kritiske punkter. Overraskende nok sendte AS263444 ikke fabrikerede ruter til alle sine kunder. Selvom der er et fremmed øjeblik.
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||
Et nyligt eksempel på et forsøg på at opsnappe vores adresseområde
Da der blev oprettet mere specifikke for vores præfikser, blev der brugt en specielt oprettet AS_PATH. Denne AS_PATH kunne dog ikke være taget fra nogen af vores tidligere ruter. Vi har ikke engang kommunikation med AS6762. Ser man på de andre ruter i hændelsen, havde nogle af dem en rigtig AS_PATH, der tidligere blev brugt, mens andre ikke havde, selvom den ligner den rigtige. Ændring af AS_PATH derudover giver ingen praktisk mening, da trafikken alligevel vil blive omdirigeret til angriberen, men ruter med en "dårlig" AS_PATH kan filtreres af ASPA eller enhver anden inspektionsmekanisme. Her tænker vi på flykaprerens motivation. Vi har i øjeblikket ikke nok information til at bekræfte, at denne hændelse var et planlagt angreb. Ikke desto mindre er det muligt. Lad os prøve at forestille os en situation, selvom den stadig er hypotetisk, men potentielt ret reel.
Perfekt angreb
Hvad har vi? Lad os sige, at du er en transitudbyder, der sender ruter for dine kunder. Hvis dine kunder har flere tilstedeværelser (multihome), vil du kun modtage en del af deres trafik. Men jo mere trafik, jo mere er din indkomst. Så hvis du begynder at annoncere undernetpræfikser for de samme ruter med den samme AS_PATH, vil du modtage resten af deres trafik. Som et resultat, resten af pengene.
Vil ROA hjælpe her? Måske ja, hvis du beslutter dig for at stoppe helt med at bruge det . Derudover er det højst uønsket at have ROA-poster med krydsende præfikser. For nogle operatører er sådanne begrænsninger uacceptable.
I betragtning af andre routingsikkerhedsmekanismer hjælper ASPA heller ikke i dette tilfælde (fordi den bruger AS_PATH fra en gyldig rute). BGPSec er stadig ikke en optimal mulighed på grund af lave adoptionsrater og den resterende mulighed for nedgraderingsangreb.
Så vi har en klar gevinst for angriberen og en mangel på sikkerhed. Fantastisk blanding!
Hvad skal jeg gøre?
Det åbenlyse og mest drastiske skridt er at gennemgå din nuværende routingpolitik. Bryd dit adresseområde op i de mindste bidder (ingen overlapninger), som du vil annoncere for. Signer kun ROA for dem, uden at bruge parameteren maxLength. I dette tilfælde kan din nuværende POV redde dig fra et sådant angreb. Men igen, for nogle operatører er denne tilgang ikke rimelig på grund af den eksklusive brug af mere specifikke ruter. Alle problemer med den nuværende tilstand af ROA og ruteobjekter vil blive beskrevet i et af vores fremtidige materialer.
Derudover kan du forsøge at overvåge sådanne aflytninger. For at gøre dette har vi brug for pålidelige oplysninger om dine præfikser. Så hvis du etablerer en BGP-session med vores indsamler og giver os oplysninger om din internetsynlighed, kan vi finde mulighederne for andre hændelser. For dem, der endnu ikke er tilsluttet vores overvågningssystem, vil en liste over ruter kun med dine præfikser være nok til at begynde med. Hvis du har en session hos os, bedes du kontrollere, at alle dine ruter er sendt. Desværre er dette værd at huske, fordi nogle operatører glemmer et præfiks eller to og dermed forstyrrer vores søgemetoder. Hvis det gøres korrekt, vil vi have pålidelige data om dine præfikser, som i fremtiden vil hjælpe os med automatisk at identificere og detektere denne (og andre) typer af trafikaflytning for dit adresseområde.
Bliver du opmærksom på en sådan aflytning af din trafik i realtid, kan du selv forsøge at modvirke det. Den første tilgang er selv at annoncere for ruter med disse mere specifikke præfikser. I tilfælde af et nyt angreb på disse præfikser, gentag.
Den anden tilgang er at straffe angriberen og dem, for hvem han er et kritisk punkt (for gode ruter) ved at afskære adgangen til dine ruter til angriberen. Dette kan gøres ved at tilføje angriberens ASN til AS_PATH af dine gamle ruter og dermed tvinge dem til at undgå det AS ved at bruge den indbyggede loop-detektionsmekanisme i BGP .
Kilde: www.habr.com