13 mars till RIPEs arbetsgrupp mot missbruk betrakta BGP-kapning (hjjack) som ett brott mot RIPE-policyn. Om förslaget accepterades skulle den internetleverantör som attackerades av trafikavlyssning ha möjlighet att skicka en särskild begäran om att avslöja angriparen. Om granskningsteamet samlade in tillräckligt med stödjande bevis skulle LIR som var källan till BGP-avlyssningen anses vara en inkräktare och kan fråntas sin LIR-status. Det fanns också några argument ändringar.
I den här publikationen vill vi visa ett exempel på en attack där inte bara den verkliga angriparen var i fråga, utan även hela listan över påverkade prefix. Dessutom väcker en sådan attack återigen frågor om motiven för framtida avlyssningar av denna typ av trafik.
Under de senaste åren har endast konflikter som MOAS (Multiple Origin Autonomous System) behandlats i pressen som BGP-avlyssningar. MOAS är ett specialfall där två olika autonoma system annonserar motstridiga prefix med motsvarande ASN i AS_PATH (den första ASN i AS_PATH, nedan kallad ursprungs-ASN). Vi kan dock nämna åtminstone trafikavlyssning, vilket gör att en angripare kan manipulera AS_PATH-attributet för olika ändamål, inklusive att kringgå moderna metoder för filtrering och övervakning. Känd attacktyp - den sista typen av sådan avlyssning, men inte alls i betydelse. Det är fullt möjligt att det är precis den sortens attack vi har sett under de senaste veckorna. En sådan händelse har en förståelig natur och ganska allvarliga konsekvenser.
De som letar efter TL;DR-versionen kan rulla till undertexten "Perfect Attack".
Nätverksbakgrund
(för att hjälpa dig att bättre förstå processerna som är involverade i denna incident)
Om du vill skicka ett paket och du har flera prefix i routingtabellen som innehåller destinationens IP-adress, kommer du att använda rutten för prefixet med den längsta längden. Om det finns flera olika rutter för samma prefix i rutttabellen kommer du att välja den bästa (enligt den bästa vägvalsmekanismen).
Befintliga filtrerings- och övervakningsmetoder försöker analysera rutter och fatta beslut genom att analysera AS_PATH-attributet. Routern kan ändra detta attribut till valfritt värde under reklam. Att helt enkelt lägga till ägarens ASN i början av AS_PATH (som ursprungs-ASN) kan vara tillräckligt för att kringgå mekanismer för aktuell ursprungskontroll. Dessutom, om det finns en rutt från det attackerade ASN till dig, blir det möjligt att extrahera och använda AS_PATH för denna rutt i dina andra annonser. Alla AS_PATH-valideringskontroller för dina skapade meddelanden kommer så småningom att passera.
Det finns fortfarande några begränsningar värda att nämna. För det första, i händelse av prefixfiltrering av uppströmsleverantören, kan din rutt fortfarande filtreras (även med rätt AS_PATH) om prefixet inte tillhör din klientkon som konfigurerats vid uppströms. För det andra kan en giltig AS_PATH bli ogiltig om den skapade rutten annonseras i felaktiga riktningar och därmed bryter mot ruttpolicyn. Slutligen kan varje rutt med ett prefix som bryter mot ROA-längden anses vara ogiltig.
incident
För några veckor sedan fick vi ett klagomål från en av våra användare. Vi såg rutter med hans ursprung ASN och /25 prefix, medan användaren hävdade att han inte annonserade 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||
Exempel på tillkännagivanden för början av april 2019
NTT i sökvägen för prefixet /25 gör det särskilt misstänkt. LG NTT var omedveten om denna rutt vid tidpunkten för händelsen. Så ja, någon operatör skapar en hel AS_PATH för dessa prefix! Att kolla på andra routrar avslöjar ett särskilt ASN: AS263444. Efter att ha tittat på andra rutter med detta autonoma system, stötte vi på följande 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||
Försök gissa vad som är fel här
Det verkar som om någon tog prefixet från rutten, delade upp det i två delar och annonserade rutten med samma AS_PATH för dessa två prefix.
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||
Exempel på rutter för ett av de delade prefixparen
Flera frågor uppstår samtidigt. Har någon prövat denna typ av avlyssning i praktiken? Har någon tagit dessa vägar? Vilka prefix påverkades?
Det är här vår rad misslyckanden börjar och ännu en runda av besvikelse över det nuvarande tillståndet för Internets hälsa.
Misslyckandets väg
Först till kvarn. Hur kan vi avgöra vilka routrar som accepterade sådana avlyssnade rutter och vems trafik som skulle kunna dirigeras om idag? Vi tänkte att vi skulle börja med /25-prefix eftersom de "helt enkelt inte kan ha global distribution." Som ni kan gissa hade vi väldigt fel. Detta mått visade sig vara för bullrigt och rutter med sådana prefix kan visas även från Tier-1-operatörer. NTT har till exempel ett 50-tal sådana prefix som de distribuerar till sina egna kunder. Å andra sidan är detta mått dåligt eftersom sådana prefix kan filtreras bort om operatören använder , i alla riktningar. Därför är den här metoden inte lämplig för att hitta alla operatörer vars trafik omdirigerades till följd av en sådan incident.
En annan bra idé vi tyckte var att titta på . Speciellt för rutter som bryter mot maxLength-regeln för motsvarande ROA. På så sätt kunde vi hitta antalet olika ursprungs-ASN med status Invalid som var synliga för ett givet AS. Det finns dock ett "litet" problem. Genomsnittet (median och läge) för detta nummer (antalet ASN:er med olika ursprung) är cirka 150 och även om vi filtrerar bort små prefix förblir det över 70. Detta tillstånd har en mycket enkel förklaring: det finns bara en få operatörer som redan använder ROA-filter med en policy för "återställ ogiltiga rutter" vid ingångspunkter, så att varhelst en rutt med en ROA-överträdelse dyker upp i den verkliga världen kan den spridas i alla riktningar.
De två sista tillvägagångssätten tillåter oss att hitta de operatörer som såg vår incident (eftersom den var ganska stor), men i allmänhet är de inte tillämpliga. Okej, men kan vi hitta inkräktaren? Vilka är de allmänna egenskaperna för denna AS_PATH-manipulation? Det finns några grundläggande antaganden:
- Prefixet hade inte setts någonstans tidigare;
- Ursprungs-ASN (påminnelse: första ASN i AS_PATH) är giltigt;
- Det sista ASN i AS_PATH är angriparens ASN (i fall dess granne kontrollerar grannens ASN på alla inkommande rutter);
- Attacken kommer från en enda leverantör.
Om alla antaganden är korrekta kommer alla felaktiga rutter att presentera angriparens ASN (förutom ursprungs-ASN) och därför är detta en "kritisk" punkt. Bland de sanna kaparna fanns AS263444, även om det fanns andra. Även när vi kasserade incidentvägarna från hänsyn. Varför? En kritisk punkt kan förbli kritisk även för korrekta rutter. Det kan antingen vara resultatet av dålig anslutning i en region eller begränsningar i vår egen synlighet.
Som ett resultat finns det ett sätt att upptäcka en angripare, men bara om alla ovanstående villkor är uppfyllda och endast när avlyssningen är tillräckligt stor för att passera övervakningströsklarna. Om några av dessa faktorer inte är uppfyllda, kan vi då identifiera prefixen som led av sådan avlyssning? För vissa operatörer - ja.
När en angripare skapar en mer specifik rutt, annonseras inte ett sådant prefix av den verkliga ägaren. Om du har en dynamisk lista över alla dess prefix från den, blir det möjligt att göra en jämförelse och hitta förvrängda mer specifika rutter. Vi samlar in den här listan med prefix med hjälp av våra BGP-sessioner, eftersom vi får inte bara den fullständiga listan över rutter som är synliga för operatören just nu, utan också en lista över alla prefix som den vill marknadsföra för världen. Tyvärr finns det nu flera dussin Radaranvändare som inte slutför den sista delen korrekt. Vi kommer att meddela dem inom kort och försöka lösa problemet. Alla andra kan gå med i vårt övervakningssystem just nu.
Om vi återgår till den ursprungliga incidenten upptäcktes både angriparen och distributionsområdet av oss genom att leta efter kritiska punkter. Överraskande nog skickade inte AS263444 tillverkade rutter till alla sina kunder. Även om det finns ett främmande ögonblick.
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||
Ett färskt exempel på ett försök att fånga upp vårt adressutrymme
När mer specifika skapades för våra prefix användes en speciellt skapad AS_PATH. Denna AS_PATH kunde dock inte ha tagits från någon av våra tidigare rutter. Vi har inte ens kommunikation med AS6762. Om man tittar på de andra rutterna i händelsen hade några av dem en riktig AS_PATH som tidigare användes, medan andra inte hade det, även om den ser ut som den riktiga. Att ändra AS_PATH dessutom är inte praktiskt meningsfullt, eftersom trafiken kommer att omdirigeras till angriparen ändå, men rutter med en "dålig" AS_PATH kan filtreras av ASPA eller någon annan inspektionsmekanism. Här funderar vi på kaparens motivation. Vi har för närvarande inte tillräckligt med information för att bekräfta att händelsen var en planerad attack. Ändå är det möjligt. Låt oss försöka föreställa oss, om än fortfarande hypotetisk, men potentiellt ganska verklig, en situation.
Perfekt attack
Det vi har? Låt oss säga att du är en transitleverantör som sänder rutter för dina kunder. Om dina kunder har flera närvaro (multihome), kommer du bara att få en del av deras trafik. Men ju mer trafik, desto mer inkomst. Så om du börjar annonsera undernätsprefix för samma rutter med samma AS_PATH kommer du att få resten av deras trafik. Som ett resultat, resten av pengarna.
Kommer ROA att hjälpa här? Kanske ja, om du bestämmer dig för att sluta använda den helt . Dessutom är det högst oönskat att ha ROA-poster med korsande prefix. För vissa operatörer är sådana begränsningar oacceptabla.
Med tanke på andra routingsäkerhetsmekanismer kommer ASPA inte att hjälpa i det här fallet heller (eftersom den använder AS_PATH från en giltig rutt). BGPSec är fortfarande inte ett optimalt alternativ på grund av låga adoptionshastigheter och den återstående möjligheten till nedgraderingsattacker.
Så vi har en klar vinst för angriparen och bristande säkerhet. Jättebra mix!
Vad ska jag göra?
Det uppenbara och mest drastiska steget är att se över din nuvarande routingpolicy. Dela upp ditt adressutrymme i de minsta bitar (inga överlappningar) som du vill marknadsföra. Signera ROA endast för dem, utan att använda parametern maxLength. I det här fallet kan din nuvarande POV rädda dig från en sådan attack. Men återigen, för vissa operatörer är detta tillvägagångssätt inte rimligt på grund av den exklusiva användningen av mer specifika rutter. Alla problem med nuvarande tillstånd för ROA och ruttobjekt kommer att beskrivas i ett av våra framtida material.
Dessutom kan du försöka övervaka sådana avlyssningar. För att göra detta behöver vi tillförlitlig information om dina prefix. Om du upprättar en BGP-session med vår samlare och förser oss med information om din synlighet på Internet, kan vi alltså hitta utrymmet för andra incidenter. För de som ännu inte är anslutna till vårt övervakningssystem räcker det till att börja med en lista med rutter endast med dina prefix. Om du har en session med oss, kontrollera att alla dina rutter har skickats. Tyvärr är detta värt att komma ihåg eftersom vissa operatörer glömmer ett prefix eller två och därmed stör våra sökmetoder. Om det görs på rätt sätt kommer vi att ha tillförlitlig information om dina prefix, vilket i framtiden kommer att hjälpa oss att automatiskt identifiera och upptäcka denna (och andra) typer av trafikavlyssning för ditt adressutrymme.
Om du blir medveten om en sådan avlyssning av din trafik i realtid kan du själv försöka motverka det. Det första tillvägagångssättet är att själv annonsera rutter med dessa mer specifika prefix. I händelse av en ny attack på dessa prefix, upprepa.
Det andra tillvägagångssättet är att straffa angriparen och de för vilka han är en kritisk punkt (för bra rutter) genom att avbryta åtkomsten av dina rutter till angriparen. Detta kan göras genom att lägga till angriparens ASN till AS_PATH för dina gamla rutter och på så sätt tvinga dem att undvika att AS använder den inbyggda loop-detekteringsmekanismen i BGP .
Källa: will.com