13. marts i RIPE's arbejdsgruppe mod misbrug om at betragte BGP-hijacking som en overtrædelse af RIPE-politikken. Hvis forslaget vedtages, ville en internetudbyder, der blev angrebet ved hjælp af trafikafskæring, få mulighed for at sende en særlig anmodning for at afsløre gerningsmanden. Hvis ekspertgruppen samler tilstrækkelige beviser, ville en sådan LIR, der er kilde til BGP-hijacking, blive betragtet som en overtræder og kunne miste sin LIR-status. Der var også nogle argumenter ændringer.
I denne publikation ønsker vi at vise et eksempel på et angreb, hvor ikke kun den faktiske gerningsmand var under mistanke, men også hele listen over berørte præfikser. Desuden rejser et sådant angreb igen spørgsmål om motiverne bag fremtidige trafikafskæringer af denne art.
De sidste par år har medierne kun dækket konflikter af typen MOAS (Multiple Origin Autonomous System) som BGP-hijacking. MOAS er et særligt tilfælde, hvor to forskellige autonome systemer annoncerer konfliktende præfikser med de relevante ASN-numre i AS_PATH (den første ASN i AS_PATH, herefter kaldet origin ASN). Men vi kan nævne mindst af trafikafskæring, der gør det muligt for en gerningsmand at manipulere AS_PATH-attributten med forskellige mål, herunder for at omgå moderne metoder til filtrering og overvågning. En velkendt type angreb er den seneste type sådan afskæring, men ikke mindre betydningsfuld. Det er meget muligt, at vi har været vidne til netop et sådant angreb de seneste uger. Denne begivenhed har en forklarlig karakter og alvorlige konsekvenser.
De, der søger en TL;DR-version, kan rulle ned til underoverskriften 'Den perfekte angreb'.
Netværksbaggrund
(for at du bedre forstår de processer, der er involveret i denne hændelse)
Hvis du ønsker at sende et pakke og har flere præfikser i routingtabellen, der indeholder destinations-IP-adressen, vil du bruge ruten for præfikset med den maksimale længde. Hvis der derimod findes flere forskellige ruter for et enkelt præfiks i routingtabellen, vil du vælge den bedste (i henhold til mekanismen for valg af bedste rute).
De eksisterende metoder til filtrering og overvågning forsøger at analysere ruter og træffe beslutninger ved at analysere AS_PATH-attributten. Routeren kan ændre denne attribut til enhver værdi under annoncering. Bare det at tilføje ejerens ASN i starten af AS_PATH (som origin ASN) kan være tilstrækkeligt til at omgå de nuværende kildekontrolmekanismer. Desuden, hvis der er en rute fra det angrebne ASN til dig, opstår muligheden for at udtrække og bruge AS_PATH for denne rute i dine andre annoncer. Enhver validering, der kun kontrollerer AS_PATH for dine skrabede annoncer, vil i sidste ende blive bestået.
Der er også flere værd at nævne begrænsninger. For det første, i tilfælde af, at en overordnet udbyder filtrerer præfikser, kan din rute stadig blive filtreret (selv med et korrekt AS_PATH), hvis præfikset ikke tilhører din kundecone, der er oprettet hos upstream. For det andet – kan et gyldigt AS_PATH blive ugyldigt, hvis den oprettede rute annonceres i ukorrekte retninger, og dermed overtræder routingpolitikken. Og endelig - enhver rute med et præfiks, der overtræder ROA-længden, kan betragtes som ugyldig.
Hændelse
For et par uger siden modtog vi en klage fra en af brugerne. Vi så ruter med hans origin ASN og præfikser \/25, mens brugeren påstod, at de ikke havde annonceret 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å annoncer fra begyndelsen af april 2019
NTT's rute for præfikset \/25 gør det særligt mistænkeligt. Under hændelsen vidste LG NTT intet om denne rute. Så ja, en eller anden operatør skaber en hel AS_PATH for disse præfikser! En kontrol på andre routere fremhæver en særlig ASN: AS263444. Når vi ser på andre ruter med dette autonome system, står vi over for 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||
Forsøg at gætte, hvad der er galt her
Det ser ud til, at nogen har taget præfikset fra ruten, delt det op i to dele og annonceret 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||
Eksempler på ruter for et af parene af delte præfikser
Der opstår straks flere spørgsmål. Har nogen virkelig prøvet denne type af affangning i praksis? Har nogen accepteret disse ruter? Hvilke præfikser blev berørt?
Her begynder vores række af fiaskoer og en ny runde af skuffelse over den nuværende tilstand af internettet.
Vejen til fiasko
Lad os tage det hele i rækkefølge. Hvordan kan vi identificere hvilke routere, der har accepteret sådanne omdirigerede ruter, og hvis trafik der kan omdirigeres allerede i dag? Vi tænkte på at starte med præfikserne /25, fordi de "bare ikke kan have global udbredelse". Som du måske gætter — vi tog fejl. Denne metric viste sig at være alt for støjende, og ruter med sådanne præfikser kan dukke op selv fra Tier-1 operatører. For eksempel har NTT omkring 50 sådanne præfikser, som de distribuerer til deres egne kunder. På den anden side er denne metric dårlig, fordi sådanne præfikser kan blive filtreret, hvis operatøren anvender , i alle retninger. Derfor er denne metode ikke velegnet til at finde alle operatører, hvis trafik blev omdirigeret som følge af en sådan hændelse.
En anden god idé var at se på . Især ruter med brud på maxLength-reglen for den relevante ROA. På den måde kunne vi finde antallet af forskellige origin ASN med status Invalid, der var synlige for denne AS. Alligevel er der et "lille" problem. Gennemsnittet (medianen og moden) af dette tal (antallet af forskellige origin ASN) er omkring 150, og selv hvis vi filtrerer små præfikser, vil det forblive over 70. Denne situation har en ret simpel forklaring: Der er kun nogle få operatører, der allerede anvender ROA-filtre med politikken "droppere Invalid ruter" på indgangspunkterne, så uanset hvor i den virkelige verden en rute med brud på ROA dukker op, kan den blive distribueret i alle retninger.
De sidste to tilgange gør det muligt at finde operatører, der har set vores hændelse (da den var stor nok), men generelt er de ikke anvendelige. Godt, men kan vi finde gerningsmanden? Hvad er de generelle kendetegn ved en sådan manipulation af AS_PATH? Der er nogle grundlæggende antagelser:
- Præfikset er ikke blevet set før;
- Origin ASN (for at minde om: første ASN i AS_PATH) er gyldigt;
- Den sidste ASN i AS_PATH er angrebsmannens ASN (hvis hans nabo kontrollerer naboens ASN på alle indkommende ruter);
- Angrebet kommer fra én udbyder.
Hvis alle antagelser er rigtige, vil der på alle forkerte ruter blive præsenteret ASN for angriberen (udover origin ASN), og derfor er dette et 'kritisk' punkt. Blandt de sande hijackere var der AS263444, selvom der var andre. Selv når vi udelukkede hændelsesruterne fra overvejelserne. Hvorfor? Et kritisk punkt kan forblive kritisk selv for korrekte ruter. Det kan være et resultat af dårlig forbindelse i et bestemt område eller begrænsninger i vores egen synlighed.
Som resultat: der er en måde at opdage angriberen på, men kun under forudsætning af at alle de ovenfor nævnte betingelser er opfyldt, og kun når interceptionen er tilstrækkelig stor til at overstige overvågningsgrænserne. Hvis nogle af disse faktorer ikke overholdes, kan vi så identificere de præfikser, der er berørt af en sådan interception? For bestemte operatører – ja.
Når angriberen skaber en more specific rute, annonceres en sådan præfiks ikke af den sande ejer. I tilfælde af at du har en dynamisk liste over alle hans præfikser, åbner det muligheden for at sammenligne og finde forvrængede more specific ruter. Vi indsamler denne liste over præfikser ved hjælp af vores BGP-sessioner, da vi får præsenteret ikke kun den fulde liste over ruter, som operatøren kan se lige nu, men også en liste over alle præfikser, som han ønsker at annoncere til verden. Desværre er der i øjeblikket flere dusin Radar-brugere, der ikke udfører den sidste del korrekt. Snart vil vi informere dem og forsøge at løse dette problem. Alle andre kan dog tilslutte sig vores overvågningssystem lige nu.
Hvis vi vender tilbage til den oprindelige hændelse, blev både angriberen og distributionsområdet identificeret af os gennem søgning efter kritiske punkter. Overraskende nok sendte AS263444 ikke forfalskede ruter til alle sine kunder. Der er dog et endnu mere underligt punkt.
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 kapre vores adresseområde.
Da mere specifikke ’more specific’ blev oprettet for vores præfikser, blev der brugt en specielt oprettet AS_PATH. Dog kunne denne AS_PATH ikke være taget fra nogen af vores tidligere ruter. Vi har ikke engang forbindelse til AS6762. Lad os se på andre ruter i hændelsen: nogle af dem havde et reelt AS_PATH, som blev anvendt tidligere, mens andre ikke havde, selvom de så ud som om de var ægte. Yderligere ændring af AS_PATH giver ikke rigtig mening, da trafikken uanset hvad vil blive omdirigeret til angriberen, men ruter med 'dårlig' AS_PATH kan blive filtreret af ASPA eller en anden valideringsmekanisme. Her overvejede vi angriberens motivation. Lige nu har vi ikke nok data til at påstå, at denne hændelse var et planlagt angreb. Det er dog en mulighed. Lad os prøve at forestille os en hypotetisk, men kunne realistisk situation.
Den perfekte attack
Hvad har vi? Antag, at du er en transitudbyder, der transmitterer ruter for dine kunder. Hvis dine kunder har flere tilstedeværelser (multihome), vil du kun få en del af deres trafik. Men jo mere trafik — desto mere indtjening. Så hvis du begynder at annoncere præfikserne for disse samme ruter med det samme AS_PATH, vil du få resten af deres trafik. Som en konsekvens får du den resterende del af pengene.
Vil ROA hjælpe her? Måske, hvis du beslutter at helt opgive brugen af . Derudover er det i denne sammenhæng ekstremt uønsket at have ROA-poster med overlappende præfikser. For nogle udbydere er sådanne begrænsninger uacceptable.
Når vi overvejer andre mekanismer til sikring af ruting, vil ASPA i dette tilfælde heller ikke hjælpe (fordi AS_PATH fra en legitim rute anvendes). BGPSec er stadig ikke en optimal løsning på grund af den lave acceptprocent og den resterende mulighed for downgrade-angreb.
Således har vi en åbenlys gevinst for angriberen og mangel på sikkerhed. En fantastisk blanding!
Hvad skal der gøres?
Det mest åbenlyse og radikale skridt er at revurdere din nuværende routingpolitik. Opdel dit adresseområde i de mindste bidder (uden overlap), som du ønsker at annoncere. Underskriv ROA kun for dem uden at bruge maxLength parameteren. I dette tilfælde kan den nuværende POV redde dig fra et sådant angreb. Men igen, for nogle operatører er denne tilgang ikke fornuftig på grund af den omfattende brug af more specific ruter. Alle problemer med den nuværende tilstand af ROA og route objekter vil blive beskrevet i et af vores kommende materialer.
Derudover kan man forsøge at overvåge sådanne afskæringer. For dette har vi behov for pålidelige oplysninger om dine præfikser. Så hvis du opretter en BGP-session med vores collector og giver os oplysninger om din synlighed på internettet, kan vi finde distributionsområdet og for andre hændelser. For dem, der endnu ikke er tilsluttet vores overvågningssystem — vil en liste med ruter, som kun indeholder dine præfikser, være tilstrækkelig i starten. Hvis du allerede har en session med os, så tjek venligst, at alle dine ruter er blevet sendt. Desværre er det værd at nævne, da nogle operatører glemmer en eller to præfikser og derved forstyrrer vores metoder til at finde dem. Hvis alt gøres korrekt, vil vi have pålidelige data om dine præfikser, som i fremtiden vil hjælpe med automatisk at identificere og opdage sådanne (og andre) typer af trafikafskæringer for dit adresseområde.
Hvis du i realtid har fået kendskab til en sådan afskæring af din trafik, kan du forsøge at modvirke det selv. Den første tilgang er at annoncere ruter med disse more specific præfikser selv. Ved en ny angreb på disse præfikser, gentag.
Den anden tilgang er at straffe gerningsmanden og dem, der er kritiske for ham (for gode ruter), ved at skære adgangen til dine ruter for gerningsmanden. Dette kan gøres ved at tilføje gerningsmandens ASN i AS_PATH for dine gamle ruter og derved tvinge dem til at undgå denne AS, ved hjælp af den indbyggede mekanisme til opdagelse af cykler i BGP. .
Kilde: habr.com
