Den 13 mars kom ett förslag till RIPE:s arbetsgrupp för att bekämpa missbruk mot detta ändringar.
Under de senaste åren har medierna belyst endast konflikter av typen MOAS (Multiple Origin Autonomous System) som BGP-avlyssningar. MOAS är ett specialfall där två olika autonoma system annonserar konfliktande prefix med motsvarande ASN-nummer i AS_PATH (den första ASN i AS_PATH, här kallad origin ASN). Men vi kan nämna åtminstone
tre ytterligare typer Pilosova-Kapela De som letar efter en TL;DR-version kan scrolla ner till rubriken "Den perfekta attacken".
Nätverksbakgrund
(för att du ska förstå processerna involverade i denna incident bättre)
Om du vill skicka ett paket och har flera prefix i routingtabellen som innehåller måladressen kommer du att använda rutten för prefixet med längsta längd. Om det finns flera olika rutter för ett och samma prefix i routingtabellen, väljer du den bästa (enligt mekanismen för val av bästa väg).
Если вы хотите отправить пакет и у вас есть несколько префиксов в таблице маршрутизации, содержащих IP-адрес назначения, то вы будете использовать маршрут для префикса с максимальной длиной. Если же в таблице маршрутизации существует несколько разных маршрутов для одного префикса, вы выберете лучший (в соответствии с механизмом выбора лучшего пути).
Befintliga metoder för filtrering och övervakning försöker analysera rutter och fatta beslut genom att analysera AS_PATH-attributet. En router kan ändra detta attribut till vilket värde som helst under annonsering. Att helt enkelt lägga till ägarens ASN i början av AS_PATH (som origin ASN) kan vara tillräckligt för att kringgå nuvarande källkontrollmekanismer. Dessutom, om det finns en rutt från det angripna ASN till dig, finns det möjlighet att extrahera och använda AS_PATH för denna rutt i dina andra annonseringar. All validering enbart baserat på AS_PATH för dina skapade annonser kommer så småningom att godkännas.
Det finns fortfarande flera anmärkningsvärda begränsningar. För det första kan din rutt fortfarande filtreras av en överordnad leverantör i händelse av prefixfiltrering (även med korrekt AS_PATH), om prefixet inte tillhör din klientkonus som är inställd hos upstream. För det andra kan ett giltigt AS_PATH bli ogiltigt om den skapade rutten annonseras i fel riktningar och därigenom bryter mot routingpolicyn. Och slutligen — vilken rutt som helst med ett prefix som bryter mot ROA-längden kan betraktas som ogiltig.
Incident
För några veckor sedan fick vi en klagan från en av användarna. Vi såg rutter med hans origin ASN och prefix /25, medan användaren påstod att de inte hade annonserats.
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å annonser i början av april 2019
NTT på väg för prefixet /25 gör det särskilt misstänkt. Under incidenten visste LG NTT ingenting om denna rutt. Så ja, någon operatör skapar en hel AS_PATH för dessa prefix! Att kontrollera på andra routrar gör det möjligt att lyfta fram en särskild ASN: AS263444. När vi tittade 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 att någon har tagit ett prefix från en rutt, delat det i två delar och annonserat en rutt 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 paren av delade prefix
Flera frågor uppstår genast. Har någon verkligen prövat denna typ av avlyssning i praktiken? Har någon accepterat dessa rutter? Vilka prefix har påverkats?
Här börjar vår rad av missöden och ytterligare en omgång av besvikelse över det nuvarande tillståndet för Internet.
Missöksvägen
Låt oss ta det steg för steg. Hur kan vi avgöra vilka routrar som accepterade sådana avlyssnade rutter och vilken trafik som kan vara omdirigerad redan idag? Vi funderade på att börja med prefix /25, eftersom de "inte kan ha global spridning". Som ni kanske gissar – vi hade fel. Denna metrisk visade sig vara alltför brusig och rutter med sådana prefix kan förekomma även från Tier-1-operatörer. Till exempel har NTT omkring 50 sådana prefix som de sprider bland sina kunder. Å andra sidan är denna metrisk dålig, eftersom sådana prefix kan filtreras bort om operatören tillämpar , i alla riktningar. Därför passar inte denna metod för att hitta alla operatörer vars trafik har omdirigerats som ett resultat av en sådan incident.
En annan bra idé verkade vara att titta på . Särskilt på rutter som bryter mot maxLength-regeln för den aktuella ROA. På så sätt skulle vi kunna hitta antalet olika origin ASN med status ogiltig, som var synliga för denna AS. Det finns dock ett "litet" problem. Medelvärdet (median och modus) för detta tal (antal olika origin ASN) är omkring 150 och, även om vi filtrerar bort små prefix, kommer det fortfarande att vara över 70. Denna situation har en ganska enkel förklaring: det finns bara några få operatörer som redan tillämpar ROA-filter med en policy att "avvisa ogiltiga rutter" vid ingångspunkterna, därför, varhelst i den verkliga världen en rutt som bryter mot ROA dyker upp, kan den spridas i alla riktningar.
De senaste två tillvägagångssätten gör det möjligt att hitta operatörer som såg vår incident (eftersom den var tillräckligt stor), men i allmänhet är de inte tillämpliga. Bra, men kan vi hitta gärningspersonen? Vilka är de gemensamma egenskaperna för en sådan manipulation av AS_PATH? Det finns några grundläggande antaganden:
- Prefixet har aldrig tidigare setts;
- Origin ASN (påminnelse: den första ASN i AS_PATH) är giltig;
- Den sista ASN i AS_PATH är angriparens ASN (om dess granne kontrollerar granne-NSN för alla inkommande rutter);
- Attacken kommer från en enda leverantör.
Om alla antaganden är korrekta kommer det att finnas en ASN för angriparen (förutom origin ASN) i alla felaktiga rutter, vilket därmed utgör en "kritisk" punkt. Bland de verkliga hijackers finns även AS263444, även om det fanns andra. Även när vi uteslöt incidentens rutter från bedömningen. Varför? Den kritiska punkten kan förbli kritisk även för korrekta rutter. Den kan vara antingen resultatet av dålig sammanlänkning i ett visst område, eller begränsningar av vår egen synlighet.
Som ett resultat: det finns en metod för att upptäcka angriparen, men endast om alla ovanstående villkor är uppfyllda och endast när avlyssningen är tillräckligt stor för att nå övervakningströsklarna. Om några av dessa faktorer inte respektive så kan vi identifiera de prefix som drabbats av sådan avlyssning? För vissa operatörer - ja.
När en angripare skapar en mer specifik rutt, annonseras inte det prefixet av den verkliga ägaren. Om du har en dynamisk lista över alla hans prefix, ges möjlighet att göra en jämförelse och hitta förvrängda mer specifika rutter. Vi samlar in denna lista över prefix genom våra BGP-sessioner, eftersom vi får inte bara den fullständiga listan över rutter som operatören ser just nu, utan också en lista över alla prefix som han vill annonsera till världen. Tyvärr finns det för närvarande flera dussin Radar-användare som inte slutför den sista delen korrekt. Vi kommer snart att informera dem och försöka lösa detta problem. Alla andra kan ansluta till vårt övervakningssystem just nu.
Återigen till den ursprungliga incidenten, så upptäckte vi både angriparen och spridningsområdet genom att söka efter kritiska punkter. Förvånande nog skickade AS263444 falska rutter till inte alla sina kunder. Även om det finns en än mer märklig 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||
Ett nyligt exempel på ett försök att avlyssna vårt adressutrymme.
När more specific-prefixes skapades för våra prefix användes en speciellt skapad AS_PATH. Emellertid kunde denna AS_PATH inte hämtas från någon av våra tidigare rutter. Vi har inte ens någon kontakt med AS6762. Vi ser på andra rutter i incidenten: några av dem hade en verklig AS_PATH som användes tidigare, medan andra inte hade det, även om de såg ut som riktiga. Ytterligare ändringar av AS_PATH har ingen praktisk betydelse, eftersom trafiken ändå kommer att dirigeras till angriparen, men rutter med "dålig" AS_PATH kan filtreras bort av ASPA eller något annat kontrollmekanism. Här började vi fundera på angriparens motivation. Just nu har vi inte tillräckligt med data för att påstå att denna incident var en planerad attack. Ändå är det möjligt. Låt oss försöka föreställa oss även om det är hypotetiskt, men en potentiellt helt verklig situation.
Den perfekta attacken
Vad har vi? Anta att du är en transitleverantör som sänder rutter för sina kunder. Om dina kunder har fler än en anslutning (multihome) kommer du bara att få en del av deras trafik. Men ju mer trafik du får — desto mer intäkter. Så, om du börjar annonsera prefix på subnät av dessa rutter med samma AS_PATH, kommer du att få resten av deras trafik. Som ett resultat kommer den återstående delen av pengarna.
Kommer ROA att hjälpa här? Kanske, om du bestämmer dig för att helt avstå från att använda . Dessutom är det ytterst oönskat att ha ROA-poster med överlappande prefix. För vissa operatörer är sådana begränsningar oacceptabla.
När man överväger andra mekanismer för säkerhet inom routing kommer ASPA inte heller att hjälpa i detta fall (eftersom AS_PATH används från en accepterad rutt). BGPSec är fortfarande inte optimalt på grund av den låga acceptansgraden och den kvarvarande möjligheten för downgrade-attacker.
Således har vi en tydlig vinst för angriparen och brist på säkerhet. En utmärkt blandning!
Vad bör göras?
Ett uppenbart och radikalt steg är att se över din nuvarande routingpolicy. Dela upp ditt adressutrymme i de minsta bitarna (utan överlappningar) som du vill annonsera. Signera ROA endast för dem, utan att använda maxLength-parametern. I det här fallet kan den nuvarande POV skydda dig från en sådan attack. Men ånyo, för vissa operatörer är en sådan strategi irrationell på grund av det exkluderande användandet av more specific-rutter. Alla problem med det nuvarande tillståndet av ROA och routningsobjekt kommer att beskrivas i ett av våra kommande material.
Förutom detta kan man försöka övervaka sådana avlyssningar. För detta behöver vi tillförlitlig information om dina prefix. Om du ställer in en BGP-session med vår samlare och skickar oss information om din internetsynlighet — kan vi finna spridningsområdet och för andra incidenter. För dem som ännu inte är anslutna till vårt övervakningssystem — räcker det i början med en lista över rutter med endast dina prefix. Om du redan har en session med oss, kontrollera att alla dina rutter har skickats. Tyvärr måste detta påminnas om, eftersom vissa operatörer glömmer ett eller två prefix och därmed skapar störningar i våra metoder för att söka. Om allt görs korrekt, kommer vi att ha tillförlitliga data om dina prefix som i framtiden hjälper till att automatiskt identifiera och upptäcka sådana (och andra) typer av trafikavlyssning för ditt adressutrymme.
Om du i realtid får vetskap om en sådan avlyssning av din trafik, kan du försöka motverka detta själv. Första tillvägagångssättet är att annonsera rutter med dessa more specific-prefix på egen hand. I händelse av en ny attack mot dessa prefix — upprepa.
Det andra tillvägagångssättet är att straffa gärningspersonen och de som är kritiska för dem (för goda rutter) genom att avskära tillgången för dina rutter till gärningspersonen. Detta kan göras genom att lägga till gärningspersonens ASN i AS_PATH för dina gamla rutter och därmed tvinga dem att undvika denna AS, med hjälp av den inbyggda cykelupptäcktsmekanismen i BGP. .
Källa: habr.com
