Allt Àr vÀldigt dÄligt eller en ny typ av trafikavlyssning

Den 13 mars kom ett förslag till RIPE:s arbetsgrupp för att bekÀmpa missbruk om att övervÀga BGP-avlyssning (hjjack) som ett brott mot RIPE:s policy. Om förslaget antas skulle internetleverantören, som drabbades av trafikavlyssning, fÄ möjlighet att skicka in en sÀrskild begÀran för att avslöja förövaren. Om expertgruppen samlar tillrÀckliga bevis skulle en sÄdan LIR, som Àr kÀllan till BGP-avlyssningen, betraktas som en övertrÀdare och kunna förlora sin LIR-status. Det fanns Àven vissa argument mot detta I denna publikation vill vi visa ett exempel pÄ en attack dÀr inte bara den verkliga förövaren var ifrÄgasatt, utan ocksÄ hela listan över drabbade prefix. Dessutom vÀcker en sÄdan attack Äter frÄgor om motiv för framtida trafikavlyssningar av detta slag. À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 av trafikavlyssning som gör det möjligt för förövaren att manipulera AS_PATH-attributet med olika mÄl, inklusive att kringgÄ moderna metoder för filtrering och övervakning. En kÀnd typ av attack Pilosova-Kapela Àr den senaste typen av avlyssning, men inte mindre betydelsefull. Det Àr fullt möjligt att det Àr en sÄdan attack vi har observerat de senaste veckorna. En sÄdan hÀndelse har en förklarlig karaktÀr och allvarliga konsekvenser. 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).

Om du vill skicka ett paket och har flera prefix i routingtabellen som innehÄller destinations-IP-adressen, kommer du att anvÀnda rutten för prefixet med den lÀngsta lÀngden. Om det finns flera olika rutter för ett och samma prefix i routingtabellen vÀljer du den bÀsta (enligt mekanismen för att vÀlja den bÀsta vÀgen).

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 filtrering av smĂ„ prefix, 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Ä POV. 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 maxLength. 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. för ditt eget bÀsta.

KĂ€lla: habr.com

Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar đŸ”„ Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar | ProHoster