Hei, jeg heter Alexander Azimov. Hos Yandex utvikler jeg ulike overvåkingssystemer, samt transportnettverksarkitektur. Men i dag skal vi snakke om BGP-protokollen.
For en uke siden aktiverte Yandex ROV (Route Origin Validation) ved grensesnittene med alle peering-partnere, samt trafikkutvekslingspunkter. Les nedenfor om hvorfor dette ble gjort og hvordan det vil påvirke samhandlingen med teleoperatørene.
BGP og hva er galt med det
Du vet sikkert at BGP ble designet som en ruteprotokoll mellom domene. Men underveis klarte antallet brukstilfeller å vokse: i dag har BGP, takket være en rekke utvidelser, blitt til en meldingsbuss som dekker oppgaver fra operatør VPN til det nå fasjonable SD-WAN, og har til og med funnet applikasjon som en transport for en SDN-lignende kontroller, som gjør avstandsvektor BGP til noe som ligner på link sat-protokollen.
Fig. 1.
Hvorfor har BGP mottatt (og fortsetter å motta) så mange bruksområder? Det er to hovedårsaker:
- BGP er den eneste protokollen som fungerer mellom autonome systemer (AS);
- BGP støtter attributter i TLV-format (type-length-value). Ja, protokollen er ikke alene om dette, men siden det ikke er noe å erstatte den i knutepunktene mellom teleoperatørene, viser det seg alltid å være mer lønnsomt å knytte et annet funksjonelt element til den enn å støtte en ekstra rutingprotokoll.
Hva er galt med ham? Kort fortalt har ikke protokollen innebygde mekanismer for å kontrollere riktigheten av den mottatte informasjonen. Det vil si at BGP er en a priori tillitsprotokoll: hvis du vil fortelle verden at du nå eier nettverket til Rostelecom, MTS eller Yandex, vær så snill!
IRRDB-basert filter - det beste av det verste
Spørsmålet oppstår: hvorfor fungerer Internett fortsatt i en slik situasjon? Ja, det fungerer mesteparten av tiden, men samtidig eksploderer det med jevne mellomrom, og gjør hele nasjonale segmenter utilgjengelige. Selv om hackeraktiviteten i BGP også er på vei oppover, er de fleste anomalier fortsatt forårsaket av feil. Årets eksempel er i Hviterussland, som gjorde en betydelig del av Internett utilgjengelig for MegaFon-brukere i en halvtime. Et annet eksempel - brøt et av de største CDN-nettverkene i verden.
Ris. 2. Cloudflare trafikkavlytting
Men likevel, hvorfor oppstår slike anomalier en gang hver sjette måned, og ikke hver dag? Fordi transportører bruker eksterne databaser med rutinginformasjon for å bekrefte hva de mottar fra BGP-naboer. Det er mange slike databaser, noen av dem administreres av registrarer (RIPE, APNIC, ARIN, AFRINIC), noen er uavhengige aktører (den mest kjente er RADB), og det er også et helt sett med registrarer eid av store selskaper (Level3 , NTT, etc.). Det er takket være disse databasene at ruting mellom domener opprettholder den relative stabiliteten til driften.
Det er imidlertid nyanser. Rutinginformasjon kontrolleres basert på ROUTE-OBJECTS og AS-SET objekter. Og hvis den første innebærer autorisasjon for en del av IRRDB, er det ingen autorisasjon for den andre klassen. Det vil si at hvem som helst kan legge til hvem som helst i settene sine og dermed omgå filtrene til oppstrømsleverandører. Dessuten er det unike med AS-SET-navngivningen mellom forskjellige IRR-baser garantert, noe som kan føre til overraskende effekter med et plutselig tap av tilkobling for teleoperatøren, som på sin side ikke endret noe.
En ekstra utfordring er bruksmønsteret til AS-SET. Det er to punkter her:
- Når en operatør får en ny klient, legger den den til AS-SET, men fjerner den nesten aldri;
- Filtrene i seg selv konfigureres kun ved grensesnittene med klienter.
Som et resultat består det moderne formatet av BGP-filtre av gradvis nedbrytende filtre ved grensesnittene med klienter og a priori tillit til det som kommer fra peering-partnere og IP-transportleverandører.
Hva er å erstatte prefiksfiltre basert på AS-SET? Det mest interessante er at på kort sikt - ingenting. Men det dukker opp flere mekanismer som utfyller arbeidet til IRRDB-baserte filtre, og først av alt er dette selvfølgelig RPKI.
RPKI
På en forenklet måte kan RPKI-arkitekturen betraktes som en distribuert database hvis poster kan verifiseres kryptografisk. Når det gjelder ROA (Route Object Authorization), er underskriveren eieren av adresseområdet, og selve posten er en trippel (prefiks, asn, max_length). I hovedsak postulerer denne oppføringen følgende: eieren av $prefix-adresseområdet har autorisert AS-nummeret $asn til å annonsere prefikser med en lengde som ikke er større enn $max_length. Og rutere, som bruker RPKI-cachen, er i stand til å sjekke paret for samsvar prefiks - første høyttaler på vei.
Figur 3. RPKI-arkitektur
ROA-objekter har vært standardisert ganske lenge, men inntil nylig forble de faktisk bare på papir i IETF-tidsskriftet. Etter min mening høres årsaken til dette skummelt ut – dårlig markedsføring. Etter at standardiseringen var fullført, var insentivet at ROA beskyttet mot BGP-kapring – noe som ikke var sant. Angripere kan enkelt omgå ROA-baserte filtre ved å sette inn riktig AC-nummer på begynnelsen av banen. Og så snart denne erkjennelsen kom, var det neste logiske trinnet å forlate bruken av ROA. Og egentlig, hvorfor trenger vi teknologi hvis den ikke fungerer?
Hvorfor er det på tide å ombestemme seg? For dette er ikke hele sannheten. ROA beskytter ikke mot hackeraktivitet i BGP, men beskytter mot utilsiktede trafikkkapringer, for eksempel fra statiske lekkasjer i BGP, som blir mer vanlig. I motsetning til IRR-baserte filtre, kan ROV brukes ikke bare ved grensesnittet med klienter, men også ved grensesnittet med jevnaldrende og oppstrømsleverandører. Det vil si at sammen med introduksjonen av RPKI, forsvinner a priori-tilliten gradvis fra BGP.
Nå blir kontroll av ruter basert på ROA gradvis implementert av nøkkelaktører: den største europeiske IX forkaster allerede feil ruter; blant Tier-1-operatører er det verdt å fremheve AT&T, som har aktivert filtre i grensesnittene med sine peering-partnere. De største innholdsleverandørene nærmer seg også prosjektet. Og dusinvis av mellomstore transittoperatører har allerede i det stille implementert det, uten å fortelle noen om det. Hvorfor implementerer alle disse operatørene RPKI? Svaret er enkelt: å beskytte utgående trafikk fra andres feil. Det er grunnen til at Yandex er en av de første i den russiske føderasjonen som inkluderer ROV i utkanten av nettverket.
Hva vil skje videre?
Vi har nå aktivert kontroll av ruteinformasjon i grensesnittene med trafikkutvekslingspunkter og private peeringer. I nær fremtid vil verifisering også bli aktivert hos oppstrøms trafikkleverandører.
Hvilken forskjell gjør dette for deg? Hvis du vil øke sikkerheten for trafikkruting mellom nettverket og Yandex, anbefaler vi:
- Signer adressefeltet ditt – det er enkelt, tar 5-10 minutter i gjennomsnitt. Dette vil beskytte tilkoblingen vår i tilfelle noen uforvarende stjeler adresseplassen din (og dette vil definitivt skje før eller siden);
- Installer en av open source RPKI cachene (, ) og aktiver rutesjekking ved nettverksgrensen - dette vil ta mer tid, men igjen vil det ikke forårsake noen tekniske problemer.
Yandex støtter også utviklingen av et filtreringssystem basert på det nye RPKI-objektet - (Autonomous System Provider Authorization). Filtre basert på ASPA- og ROA-objekter kan ikke bare erstatte "lekke" AS-SET-er, men også lukke problemene med MiTM-angrep ved å bruke BGP.
Jeg vil snakke i detalj om ASPA om en måned på Next Hop-konferansen. Kolleger fra Netflix, Facebook, Dropbox, Juniper, Mellanox og Yandex vil også snakke der. Hvis du er interessert i nettverksstakken og dens utvikling i fremtiden, kom .
Kilde: www.habr.com