Dobrý den, jmenuji se Alexander Azimov. V Yandexu vyvíjím různé monitorovací systémy a také architekturu transportní sítě. Dnes si ale povíme něco o protokolu BGP.
Před týdnem Yandex povolil ROV (Route Origin Validation) na rozhraních se všemi partnerskými partnery a také na výměnných bodech provozu. Níže si přečtěte, proč k tomu došlo a jak to ovlivní interakci s telekomunikačními operátory.
BGP a co je na něm špatného
Pravděpodobně víte, že BGP byl navržen jako mezidoménový směrovací protokol. Postupem času se však počet případů použití dařilo narůstat: dnes se BGP díky četným rozšířením proměnilo ve sběrnici zpráv, pokrývající úkoly od operátorské VPN po dnes módní SD-WAN, a dokonce našel uplatnění jako přenos pro řadič podobný SDN, měnící vzdálenostní vektorový BGP na něco podobného, jako je protokol Links sat.
Obr. 1.
Proč BGP získal (a nadále přijímá) tolik použití? Existují dva hlavní důvody:
- BGP je jediný protokol, který funguje mezi autonomními systémy (AS);
- BGP podporuje atributy ve formátu TLV (type-length-value). Ano, protokol v tom není sám, ale protože jej na spojích mezi telekomunikačními operátory není čím nahradit, vždy se ukáže jako výhodnější připojit k němu další funkční prvek než podporovat další směrovací protokol.
Co je s ním? Protokol zkrátka nemá vestavěné mechanismy pro kontrolu správnosti přijatých informací. To znamená, že BGP je a priori důvěryhodný protokol: pokud chcete světu sdělit, že nyní vlastníte síť Rostelecom, MTS nebo Yandex, prosím!
Filtr na bázi IRRDB – nejlepší z nejhorších
Nabízí se otázka: proč v takové situaci stále funguje internet? Ano, většinou to funguje, ale zároveň to periodicky exploduje a znepřístupní celé národní segmenty. Přestože aktivita hackerů v BGP je také na vzestupu, většinu anomálií stále způsobují chyby. Letošním příkladem je v Bělorusku, což uživatelům MegaFonu na půl hodiny znepřístupnilo značnou část internetu. Další příklad - rozbil jednu z největších sítí CDN na světě.
Rýže. 2. Zachycování provozu Cloudflare
Ale přesto, proč se takové anomálie vyskytují jednou za šest měsíců a ne každý den? Protože operátoři používají externí databáze směrovacích informací k ověření toho, co dostávají od sousedů BGP. Takových databází je mnoho, některé z nich spravují registrátoři (RIPE, APNIC, ARIN, AFRINIC), některé jsou nezávislými hráči (nejznámější je RADB) a existuje také celá řada registrátorů vlastněných velkými společnostmi (Level3 , NTT atd.). Právě díky těmto databázím si mezidoménové směrování udržuje relativní stabilitu svého provozu.
Existují však nuance. Informace o směrování jsou kontrolovány na základě objektů ROUTE-OBJECTS a AS-SET. A pokud první znamená autorizaci pro část IRRDB, pak pro druhou třídu neexistuje žádná autorizace jako třída. To znamená, že kdokoli může přidat kohokoli do svých sad a obejít tak filtry upstream poskytovatelů. Navíc není zaručena jedinečnost pojmenování AS-SET mezi různými IRR bázemi, což může vést k překvapivým efektům s náhlou ztrátou konektivity pro telekomunikačního operátora, který ze své strany nic nezměnil.
Další výzvou je způsob použití AS-SET. Jsou zde dva body:
- Když operátor získá nového klienta, přidá ho do svého AS-SET, ale téměř nikdy jej neodebere;
- Samotné filtry se konfigurují pouze na rozhraních s klienty.
Výsledkem je, že moderní formát BGP filtrů spočívá v postupné degradaci filtrů na rozhraní s klienty a apriorní důvěře v to, co přichází od peeringových partnerů a poskytovatelů IP tranzitu.
Co nahrazuje filtry prefixů založené na AS-SET? Nejzajímavější je, že z krátkodobého hlediska - nic. Ale objevují se další mechanismy, které doplňují práci filtrů na bázi IRRDB, a v první řadě je to samozřejmě RPKI.
RPKI
Zjednodušeně lze architekturu RPKI chápat jako distribuovanou databázi, jejíž záznamy lze kryptograficky ověřovat. V případě ROA (Route Object Authorization) je podepisující vlastník adresního prostoru a samotný záznam je trojitý (prefix, asn, max_length). Tento záznam v podstatě postuluje následující: vlastník adresního prostoru $prefix autorizoval číslo AS $asn k inzerci prefixů s délkou ne větší než $max_length. A routery využívající mezipaměť RPKI jsou schopny zkontrolovat, zda je pár kompatibilní předpona - první řečník na cestě.
Obrázek 3. Architektura RPKI
Objekty ROA byly standardizovány poměrně dlouho, ale donedávna zůstávaly vlastně jen na papíře v časopise IETF. Důvod toho zní podle mě děsivě – špatný marketing. Po dokončení standardizace bylo motivací to, že ROA chránila před únosem BGP – což nebyla pravda. Útočníci mohou snadno obejít filtry založené na ROA vložením správného čísla AC na začátek cesty. A jakmile toto uvědomění přišlo, dalším logickým krokem bylo opustit používání ROA. A opravdu, proč potřebujeme technologii, když nefunguje?
Proč je čas změnit názor? Protože to není celá pravda. ROA nechrání před aktivitou hackerů v BGP, ale chrání před náhodnými dopravními únosy, například ze statických úniků v BGP, které jsou stále častější. Na rozdíl od filtrů založených na IRR lze také ROV použít nejen na rozhraních s klienty, ale také na rozhraních s peer a upstream poskytovateli. To znamená, že spolu se zavedením RPKI se z BGP postupně vytrácí apriorní důvěra.
Nyní je kontrola tras na bázi ROA postupně implementována klíčovými hráči: největší evropský IX již zahazuje nesprávné trasy, z operátorů Tier-1 stojí za vyzdvihnutí společnost AT&T, která povolila filtry na rozhraních se svými peeringovými partnery. K projektu přistupují i největší poskytovatelé obsahu. A desítky středně velkých tranzitních operátorů to již v tichosti zavedly, aniž by o tom komukoli řekli. Proč všichni tito operátoři implementují RPKI? Odpověď je jednoduchá: chránit svůj odchozí provoz před chybami jiných lidí. To je důvod, proč Yandex jako jeden z prvních v Ruské federaci zahrnul ROV na okraj své sítě.
Co se stane příště?
Nyní jsme povolili kontrolu směrovacích informací na rozhraních s body výměny provozu a soukromých peeringů. V blízké budoucnosti bude ověření umožněno také u poskytovatelů upstreamového provozu.
Jaký to pro vás znamená rozdíl? Pokud chcete zvýšit zabezpečení směrování provozu mezi vaší sítí a Yandexem, doporučujeme:
- Podepište svůj adresní prostor - je to jednoduché, v průměru to trvá 5-10 minut. To ochrání naši konektivitu pro případ, že by vám někdo nevědomky ukradl adresní prostor (a to se dříve nebo později určitě stane);
- Nainstalujte jednu z open source mezipaměti RPKI (, ) a povolit kontrolu trasy na hranici sítě - zabere to více času, ale opět to nezpůsobí žádné technické potíže.
Yandex také podporuje vývoj filtrovacího systému založeného na novém objektu RPKI - (Autonomous System Provider Authorization). Filtry založené na objektech ASPA a ROA mohou nejen nahradit „děravé“ AS-SETy, ale také uzavřít problémy s MiTM útoky pomocí BGP.
O ASPA budu podrobně mluvit za měsíc na konferenci Next Hop. Vystoupí tam i kolegové z Netflixu, Facebooku, Dropboxu, Juniperu, Mellanoxu a Yandexu. Pokud vás zajímá síťový stack a jeho vývoj do budoucna, přijďte .
Zdroj: www.habr.com