13. mars til RIPEs arbeidsgruppe mot misbruk anser BGP-kapring (hjjack) som et brudd på RIPEs retningslinjer. Dersom forslaget ble akseptert, ville internettleverandøren angrepet av trafikkavlytting ha mulighet til å sende en spesiell forespørsel om å avsløre angriperen. Hvis vurderingsteamet samlet inn tilstrekkelig støttebevis, ville LIR-en som var kilden til BGP-avskjæringen bli ansett som en inntrenger og kunne bli fratatt sin LIR-status. Det var også noen argumenter Endringer.
I denne publikasjonen ønsker vi å vise et eksempel på et angrep der ikke bare den virkelige angriperen var det aktuelle, men også hele listen over berørte prefikser. Dessuten reiser et slikt angrep igjen spørsmål om motivene for fremtidig avlytting av denne typen trafikk.
I løpet av de siste par årene har bare konflikter som MOAS (Multiple Origin Autonomous System) blitt omtalt i pressen som BGP-avlytting. MOAS er et spesialtilfelle der to forskjellige autonome systemer annonserer motstridende prefikser med tilsvarende ASN-er i AS_PATH (den første ASN i AS_PATH, heretter referert til som opprinnelses-ASN). Imidlertid kan vi nevne i det minste trafikkavskjæring, slik at en angriper kan manipulere AS_PATH-attributtet til forskjellige formål, inkludert å omgå moderne tilnærminger til filtrering og overvåking. Kjent angrepstype - den siste typen slik avlytting, men slett ikke av betydning. Det er godt mulig at dette er akkurat den typen angrep vi har sett de siste ukene. En slik hendelse har en forståelig natur og ganske alvorlige konsekvenser.
De som leter etter TL;DR-versjonen kan bla til undertittelen "Perfect Attack".
Nettverksbakgrunn
(for å hjelpe deg bedre å forstå prosessene involvert i denne hendelsen)
Hvis du vil sende en pakke og du har flere prefikser i rutetabellen som inneholder destinasjons-IP-adressen, vil du bruke ruten for prefikset med lengst lengde. Hvis det er flere forskjellige ruter for samme prefiks i rutetabellen, vil du velge den beste (i henhold til den beste veivalgsmekanismen).
Eksisterende filtrerings- og overvåkingsmetoder forsøker å analysere ruter og ta beslutninger ved å analysere AS_PATH-attributtet. Ruteren kan endre denne egenskapen til hvilken som helst verdi under reklame. Bare å legge til eierens ASN i begynnelsen av AS_PATH (som opprinnelses-ASN) kan være nok til å omgå gjeldende opprinnelseskontrollmekanismer. Dessuten, hvis det er en rute fra det angrepne ASN til deg, blir det mulig å trekke ut og bruke AS_PATH til denne ruten i dine andre annonser. Enhver AS_PATH-valideringssjekk for dine utformede kunngjøringer vil til slutt bestå.
Det er fortsatt noen få begrensninger som er verdt å nevne. For det første, i tilfelle prefiksfiltrering av oppstrømsleverandøren, kan ruten din fortsatt bli filtrert (selv med riktig AS_PATH) hvis prefikset ikke tilhører klientkjeglen din som er konfigurert på oppstrøms. For det andre kan en gyldig AS_PATH bli ugyldig hvis den opprettede ruten annonseres i feil retninger og dermed bryter retningslinjene for ruting. Til slutt kan enhver rute med et prefiks som bryter ROA-lengden anses som ugyldig.
hendelse
For noen uker siden mottok vi en klage fra en av våre brukere. Vi så ruter med hans opprinnelses-ASN og /25-prefikser, mens brukeren hevdet at han ikke annonserte 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å kunngjøringer for begynnelsen av april 2019
NTT i banen for /25-prefikset gjør det spesielt mistenkelig. LG NTT var uvitende om denne ruten på tidspunktet for hendelsen. Så ja, en eller annen operatør oppretter en hel AS_PATH for disse prefiksene! Å sjekke andre rutere avslører en bestemt ASN: AS263444. Etter å ha sett på andre ruter med dette autonome systemet, møtte vi følgende situasjon:
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 å gjette hva som er galt her
Det ser ut til at noen tok prefikset fra ruten, delte det i to deler og annonserte ruten med samme AS_PATH for de to prefiksene.
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||
Eksempelruter for et av de delte prefiksparene
Flere spørsmål dukker opp på en gang. Har noen faktisk prøvd denne typen avlytting i praksis? Har noen tatt disse rutene? Hvilke prefikser ble berørt?
Det er her vår rekke av feil begynner og nok en runde med skuffelse over den nåværende helsetilstanden til Internett.
Veien til fiasko
Første ting først. Hvordan kan vi finne ut hvilke rutere som godtok slike avlyttede ruter og hvis trafikk kan omdirigeres i dag? Vi tenkte at vi skulle starte med /25-prefikser fordi de "bare ikke kan ha global distribusjon." Som du kan gjette, tok vi veldig feil. Denne beregningen viste seg å være for støyende, og ruter med slike prefikser kan vises selv fra Tier-1-operatører. For eksempel har NTT rundt 50 slike prefikser, som de distribuerer til sine egne kunder. På den annen side er denne beregningen dårlig fordi slike prefikser kan filtreres ut hvis operatøren bruker , i alle retninger. Derfor er denne metoden ikke egnet for å finne alle operatører hvis trafikk ble omdirigert som følge av en slik hendelse.
En annen god idé vi tenkte var å se på . Spesielt for ruter som bryter maxLength-regelen til den tilsvarende ROA. På denne måten kunne vi finne antall forskjellige opprinnelses-ASN med status Ugyldig som var synlige for et gitt AS. Det er imidlertid et "lite" problem. Gjennomsnittet (median og modus) for dette tallet (antallet av forskjellige opprinnelses-ASN-er) er omtrent 150, og selv om vi filtrerer ut små prefikser, forblir det over 70. Denne tilstanden har en veldig enkel forklaring: det er bare en få operatører som allerede bruker ROA-filtre med en "tilbakestill ugyldige ruter"-policy ved inngangspunkter, slik at uansett hvor en rute med et ROA-brudd vises i den virkelige verden, kan den forplante seg i alle retninger.
De to siste tilnærmingene lar oss finne operatører som så hendelsen vår (siden den var ganske stor), men generelt er de ikke aktuelt. Ok, men kan vi finne inntrengeren? Hva er de generelle egenskapene til denne AS_PATH-manipulasjonen? Det er noen grunnleggende antakelser:
- Prefikset hadde ikke vært sett noe sted før;
- Opprinnelses-ASN (påminnelse: første ASN i AS_PATH) er gyldig;
- Den siste ASN i AS_PATH er angriperens ASN (i tilfelle naboen sjekker naboens ASN på alle innkommende ruter);
- Angrepet kommer fra en enkelt leverandør.
Hvis alle forutsetninger er korrekte, vil alle feil ruter presentere angriperens ASN (unntatt opprinnelses-ASN), og dermed er dette et "kritisk" punkt. Blant de sanne kaprerne var AS263444, selv om det var andre. Selv når vi forkastet hendelsesrutene fra vurdering. Hvorfor? Et kritisk punkt kan forbli kritisk selv for riktige ruter. Det kan enten være et resultat av dårlig tilkobling i en region eller begrensninger i vår egen synlighet.
Som et resultat er det en måte å oppdage en angriper på, men bare hvis alle vilkårene ovenfor er oppfylt og bare når avlyttingen er stor nok til å passere overvåkingsterskelene. Hvis noen av disse faktorene ikke er oppfylt, kan vi da identifisere prefiksene som led av slik avlytting? For enkelte operatører - ja.
Når en angriper oppretter en mer spesifikk rute, annonseres ikke et slikt prefiks av den sanne eieren. Hvis du har en dynamisk liste over alle prefiksene fra den, blir det mulig å foreta en sammenligning og finne forvrengte mer spesifikke ruter. Vi samler denne listen over prefikser ved å bruke BGP-øktene våre, fordi vi ikke bare får den fullstendige listen over ruter som er synlige for operatøren akkurat nå, men også en liste over alle prefiksene som den ønsker å annonsere for verden. Dessverre er det nå flere titalls Radar-brukere som ikke fullfører den siste delen riktig. Vi vil varsle dem om kort tid og prøve å løse dette problemet. Alle andre kan bli med i overvåkingssystemet vårt akkurat nå.
Hvis vi går tilbake til den opprinnelige hendelsen, ble både angriperen og distribusjonsområdet oppdaget av oss ved å søke etter kritiske punkter. Overraskende nok sendte ikke AS263444 fabrikerte ruter til alle sine klienter. Selv om det er et fremmed øyeblikk.
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 nylig eksempel på et forsøk på å avskjære adresseområdet vårt
Når mer spesifikke ble opprettet for våre prefikser, ble en spesiallaget AS_PATH brukt. Denne AS_PATH kan imidlertid ikke ha blitt tatt fra noen av våre tidligere ruter. Vi har ikke engang kommunikasjon med AS6762. Ser vi på de andre rutene i hendelsen, hadde noen av dem en ekte AS_PATH som tidligere ble brukt, mens andre ikke hadde, selv om den ser ut som den ekte. Å endre AS_PATH i tillegg gir ingen praktisk mening, siden trafikken uansett vil bli omdirigert til angriperen, men ruter med en "dårlig" AS_PATH kan filtreres av ASPA eller en hvilken som helst annen inspeksjonsmekanisme. Her tenker vi på motivasjonen til kapreren. Vi har foreløpig ikke nok informasjon til å bekrefte at denne hendelsen var et planlagt angrep. Likevel er det mulig. La oss prøve å forestille oss, selv om det fortsatt er hypotetisk, men potensielt ganske reell, en situasjon.
Perfekt angrep
Hva vi har? La oss si at du er en transportleverandør som kringkaster ruter for kundene dine. Hvis kundene dine har flere tilstedeværelser (multihome), vil du bare motta en del av trafikken deres. Men jo mer trafikk, jo mer inntekt. Så hvis du begynner å annonsere subnettprefikser for de samme rutene med samme AS_PATH, vil du motta resten av trafikken deres. Som et resultat, resten av pengene.
Vil ROA hjelpe her? Kanskje ja, hvis du bestemmer deg for å slutte å bruke den helt . I tillegg er det svært uønsket å ha ROA-poster med kryssende prefikser. For noen operatører er slike restriksjoner uakseptable.
Med tanke på andre rutingsikkerhetsmekanismer, vil ikke ASPA hjelpe i dette tilfellet heller (fordi den bruker AS_PATH fra en gyldig rute). BGPSec er fortsatt ikke et optimalt alternativ på grunn av lave adopsjonsrater og den gjenværende muligheten for nedgraderingsangrep.
Så vi har en klar gevinst for angriperen og mangel på sikkerhet. Flott blanding!
Hva skal jeg gjøre?
Det åpenbare og mest drastiske trinnet er å gjennomgå din nåværende rutingpolicy. Bryt opp adresseplassen din i de minste bitene (ingen overlappinger) som du vil annonsere. Signer ROA kun for dem, uten å bruke maxLength-parameteren. I dette tilfellet kan din nåværende POV redde deg fra et slikt angrep. Men igjen, for noen operatører er denne tilnærmingen ikke rimelig på grunn av den eksklusive bruken av mer spesifikke ruter. Alle problemer med den nåværende tilstanden til ROA og ruteobjekter vil bli beskrevet i et av våre fremtidige materialer.
I tillegg kan du prøve å overvåke slike avlyttinger. For å gjøre dette trenger vi pålitelig informasjon om prefiksene dine. Derfor, hvis du etablerer en BGP-sesjon med samleren vår og gir oss informasjon om din internettsynlighet, kan vi finne omfanget for andre hendelser. For de som ennå ikke er koblet til vårt overvåkingssystem, vil til å begynne med en liste over ruter kun med dine prefikser være nok. Hvis du har en økt med oss, vennligst sjekk at alle rutene dine er sendt. Dessverre er dette verdt å huske fordi noen operatører glemmer et prefiks eller to og dermed forstyrrer søkemetodene våre. Hvis det gjøres riktig, vil vi ha pålitelige data om prefiksene dine, som i fremtiden vil hjelpe oss å automatisk identifisere og oppdage denne (og andre) typer trafikkavlytting for adresseområdet ditt.
Blir du oppmerksom på en slik avlytting av trafikken din i sanntid, kan du prøve å motvirke det selv. Den første tilnærmingen er å annonsere ruter med disse mer spesifikke prefiksene selv. I tilfelle et nytt angrep på disse prefiksene, gjenta.
Den andre tilnærmingen er å straffe angriperen og de han er et kritisk punkt for (for gode ruter) ved å avskjære tilgangen til rutene dine til angriperen. Dette kan gjøres ved å legge til angriperens ASN til AS_PATH av dine gamle ruter og dermed tvinge dem til å unngå at AS bruker den innebygde løkkedeteksjonsmekanismen i BGP .
Kilde: www.habr.com