Hallo, mijn naam is Alexander Azimov. Bij Yandex ontwikkel ik verschillende monitoringsystemen, evenals de architectuur van transportnetwerken. Maar vandaag zullen we het hebben over het BGP-protocol.
Een week geleden schakelde Yandex ROV (Route Origin Validation) in op de interfaces met alle peering-partners, evenals op verkeersuitwisselingspunten. Lees hieronder waarom dit is gedaan en welke invloed dit heeft op de interactie met telecomoperatoren.
BGP en wat er mis mee is
U weet waarschijnlijk dat BGP is ontworpen als een routeringsprotocol tussen domeinen. Gaandeweg is het aantal gebruiksscenario's echter gegroeid: vandaag de dag is BGP, dankzij talrijke uitbreidingen, veranderd in een berichtenbus, die taken dekt van operator VPN tot het nu modieuze SD-WAN, en heeft het zelfs toepassing gevonden als een transport voor een SDN-achtige controller, waardoor afstandsvector BGP wordt omgezet in iets dat lijkt op het links sat-protocol.
Fig. 1.
Waarom is BGP zo vaak gebruikt (en blijft het nog steeds ontvangen)? Er zijn twee belangrijke redenen:
- BGP is het enige protocol dat werkt tussen autonome systemen (AS);
- BGP ondersteunt attributen in TLV-indeling (type-lengte-waarde). Ja, het protocol staat hierin niet alleen, maar omdat er niets ter vervanging is op de kruispunten tussen telecomoperatoren, blijkt het altijd voordeliger om er nog een functioneel element aan te koppelen dan een extra routeringsprotocol te ondersteunen.
Wat is er mis met hem? Kortom, het protocol heeft geen ingebouwde mechanismen om de juistheid van de ontvangen informatie te controleren. Dat wil zeggen, BGP is een a priori vertrouwensprotocol: als je de wereld wilt vertellen dat je nu eigenaar bent van het netwerk van Rostelecom, MTS of Yandex, alsjeblieft!
IRRDB-gebaseerd filter - het beste van het slechtste
De vraag rijst: waarom werkt internet in een dergelijke situatie nog? Ja, het werkt meestal, maar explodeert tegelijkertijd periodiek, waardoor hele nationale segmenten ontoegankelijk worden. Hoewel de activiteit van hackers in BGP ook toeneemt, worden de meeste afwijkingen nog steeds veroorzaakt door bugs. Het voorbeeld van dit jaar is in Wit-Rusland, waardoor een aanzienlijk deel van het internet een half uur lang ontoegankelijk was voor MegaFon-gebruikers. Een ander voorbeeld - brak een van de grootste CDN-netwerken ter wereld.
Rijst. 2. Onderschepping van Cloudflare-verkeer
Maar toch: waarom komen dergelijke afwijkingen eens in de zes maanden voor, en niet elke dag? Omdat vervoerders externe databases met routeringsinformatie gebruiken om te verifiëren wat ze van BGP-buren ontvangen. Er zijn veel van dergelijke databases, sommige worden beheerd door registrars (RIPE, APNIC, ARIN, AFRINIC), sommige zijn onafhankelijke spelers (de bekendste is RADB), en er is ook een hele reeks registrars die eigendom zijn van grote bedrijven (Level3 , NTT, enz.). Het is dankzij deze databases dat routering tussen domeinen de relatieve stabiliteit van de werking ervan handhaaft.
Er zijn echter nuances. Routeringsinformatie wordt gecontroleerd op basis van ROUTE-OBJECTS en AS-SET-objecten. En als de eerste autorisatie impliceert voor een deel van de IRRDB, dan is er voor de tweede klasse geen autorisatie als klasse. Dat wil zeggen dat iedereen iedereen aan zijn sets kan toevoegen en daarmee de filters van upstream-providers kan omzeilen. Bovendien is de uniciteit van de AS-SET-naamgeving tussen verschillende IRR-bases niet gegarandeerd, wat tot verrassende effecten kan leiden met een plotseling verlies van connectiviteit voor de telecomoperator, die op zijn beurt niets heeft veranderd.
Een extra uitdaging is het gebruikspatroon van AS-SET. Er zijn hier twee punten:
- Wanneer een operator een nieuwe client krijgt, voegt hij deze toe aan zijn AS-SET, maar verwijdert deze vrijwel nooit;
- De filters zelf worden alleen geconfigureerd op de interfaces met clients.
Als gevolg hiervan bestaat het moderne formaat van BGP-filters uit geleidelijk degraderende filters op de interfaces met klanten en a priori vertrouwen in wat afkomstig is van peeringpartners en IP-transitproviders.
Wat vervangt prefixfilters op basis van AS-SET? Het meest interessante is dat er op de korte termijn niets is. Maar er ontstaan steeds meer mechanismen die het werk van op IRRDB gebaseerde filters aanvullen, en in de eerste plaats is dit natuurlijk RPKI.
RPKI
Op een vereenvoudigde manier kan de RPKI-architectuur worden gezien als een gedistribueerde database waarvan de records cryptografisch kunnen worden geverifieerd. In het geval van ROA (Route Object Authorization) is de ondertekenaar de eigenaar van de adresruimte en is het record zelf een triple (prefix, asn, max_length). In wezen postuleert deze invoer het volgende: de eigenaar van de adresruimte $prefix heeft het AS-nummer $asn geautoriseerd om voorvoegsels te adverteren met een lengte die niet groter is dan $max_length. En routers kunnen met behulp van de RPKI-cache het paar controleren op naleving voorvoegsel - eerste spreker onderweg.
Figuur 3. RPKI-architectuur
ROA-objecten zijn al geruime tijd gestandaardiseerd, maar bleven tot voor kort eigenlijk alleen op papier in het IETF-tijdschrift staan. Naar mijn mening klinkt de reden hiervoor eng: slechte marketing. Nadat de standaardisatie was voltooid, was de prikkel dat ROA beschermde tegen BGP-kaping - wat niet waar was. Aanvallers kunnen op ROA gebaseerde filters eenvoudig omzeilen door het juiste AC-nummer aan het begin van het pad in te voeren. En zodra dit besef kwam, was de volgende logische stap om af te zien van het gebruik van ROA. En echt, waarom hebben we technologie nodig als het niet werkt?
Waarom is het tijd om van gedachten te veranderen? Omdat dit niet de hele waarheid is. ROA beschermt niet tegen hackeractiviteit in BGP, maar beschermt tegen onbedoelde verkeerskapingen, bijvoorbeeld door statische lekken in BGP, wat steeds vaker voorkomt. Bovendien kan ROV, in tegenstelling tot op IRR gebaseerde filters, niet alleen worden gebruikt op de interfaces met klanten, maar ook op de interfaces met peers en upstream-providers. Dat wil zeggen dat, samen met de introductie van RPKI, het a priori vertrouwen geleidelijk verdwijnt uit BGP.
Nu wordt het controleren van routes op basis van ROA geleidelijk door de belangrijkste spelers geïmplementeerd: de grootste Europese IX negeert onjuiste routes al; onder Tier-1-operatoren is het de moeite waard om AT&T te benadrukken, dat filters heeft ingeschakeld op de interfaces met zijn peering-partners. Ook de grootste contentaanbieders benaderen het project. En tientallen middelgrote vervoersbedrijven hebben het al stilletjes geïmplementeerd, zonder er iemand over te vertellen. Waarom implementeren al deze operators RPKI? Het antwoord is simpel: om uw uitgaande verkeer te beschermen tegen de fouten van anderen. Daarom is Yandex een van de eersten in de Russische Federatie die ROV aan de rand van zijn netwerk opneemt.
Wat gebeurt er daarna?
We hebben nu het controleren van routeringsinformatie op de interfaces met verkeersuitwisselingspunten en privé-peerings mogelijk gemaakt. In de nabije toekomst zal verificatie ook mogelijk worden gemaakt bij upstream verkeersaanbieders.
Welk verschil maakt dit voor jou? Als u de beveiliging van de verkeersroutering tussen uw netwerk en Yandex wilt vergroten, raden we u aan:
- Onderteken uw adresruimte - het is eenvoudig, het duurt gemiddeld 5-10 minuten. Dit beschermt onze connectiviteit in het geval dat iemand onbewust uw adresruimte steelt (en dit zal vroeg of laat zeker gebeuren);
- Installeer een van de open source RPKI-caches (, ) en routecontrole aan de netwerkgrens inschakelen - dit zal meer tijd in beslag nemen, maar nogmaals, het zal geen technische problemen veroorzaken.
Yandex ondersteunt ook de ontwikkeling van een filtersysteem gebaseerd op het nieuwe RPKI-object - (autorisatie van autonome systeemaanbieder). Filters op basis van ASPA- en ROA-objecten kunnen niet alleen ‘lekkende’ AS-SETs vervangen, maar ook de problemen van MiTM-aanvallen met behulp van BGP oplossen.
Over ASPA zal ik over een maand uitgebreid praten op de Next Hop-conferentie. Ook collega's van Netflix, Facebook, Dropbox, Juniper, Mellanox en Yandex zullen daar spreken. Als je geïnteresseerd bent in de netwerkstack en de ontwikkeling ervan in de toekomst, kom dan .
Bron: www.habr.com