MANRS+: Onderzoek naar de haalbaarheid van conformiteitstoetsing voor routeringsbeveiliging

Routeringsbeveiliging via MANRS

Routering op het internet is gebaseerd op het Border Gateway Protocol (BGP), waarmee autonome systemen (AS'en) informatie uitwisselen over welke IP-adressen via welke routes bereikbaar zijn. BGP beschikt echter niet over een mechanisme om de integriteit van routeringsinformatie te valideren en is daardoor kwetsbaar voor verschillende soorten aanvallen, bijvoorbeeld routekapingen. Deze aanvallen doen zich in de praktijk veelvuldig voor en kunnen ertoe leiden dat internetdiensten, zoals de DNS-infrastructuur voor .nl, onbereikbaar worden.

Om het internet minder kwetsbaar te maken voor deze bedreigingen, adviseert MANRS (Mutually Agreed Norms for Routing Security) AS-beheerders een aantal maatregelen te nemen om de routering te beveiligen, variërend van het filteren van BGP-aankondigingen tot het implementeren en aan de community beschikbaar stellen van opensource monitoringtools. De MANRS-community noemt deze maatregelen Actions en meet via de MANRS Observatory voortdurend of ze correct worden toegepast.

MANRS is sinds de oprichting in 2014 uitgegroeid tot de standaard voor goede praktijken op het gebied van routeringsbeveiliging en er nemen op dit moment wereldwijd meer dan 1.200 AS-beheerders aan deel. Bij SIDN zijn we sinds 2018 aangesloten bij MANRS, omdat we een veilig routeringssysteem essentieel vinden voor zowel het .nl-ecosysteem als het internet als geheel. Andere Nederlandse deelnemers zijn onder meer KPN, VodafoneZiggo, TransIP, BIT en SURF. MANRS wordt beheerd door de Global Cyber Alliance (GCA).

MANRS+: MANRS naar een hoger niveau tillen

De MANRS+-werkgroep, eveneens onder beheer van GCA, heeft MANRS+ onlangs goedgekeurd. MANRS+ is een uitbreiding op MANRS die (1) aanvullende maatregelen definieert en (2) tot doel heeft de conformiteit met MANRS met een hoge mate van zekerheid te valideren via metingen en audits. MANRS+ is opgezet om te voldoen aan de vraag van zakelijke klanten naar betere routeringsbeveiliging, zodat ze bijvoorbeeld hun communicatieketen beter kunnen beschermen en connectiviteitsproviders kunnen selecteren die de beveiliging van routers actief beheren (door MANRS+ te ondersteunen).

MANRS+ richt zich op AS'en die optreden als connectiviteitsproviders (CP-AS'en) en hun rol binnen BGP. Een CP-AS kan 3 soorten BGP-relaties hebben: met peers, met transitproviders en met klanten. Een CP-AS biedt zijn klanten connectiviteit door hun (legitieme) routes door te sturen naar zijn peers en transitproviders, en omgekeerd.

MANRS+ vereist dat CP-AS'en verschillende soorten beveiligingsmaatregelen (zogeheten security controls) implementeren, bijvoorbeeld op het gebied van routeringsbeveiliging, mitigatie van DDoS-aanvallen en bescherming tegen spoofing. Daarnaast definieert MANRS+ richtlijnen voor het valideren of CP-AS'en deze maatregelen correct hebben geïmplementeerd, evenals een aantal auditniveaus (Self-declared, Audited of Measured). In totaal gaat het om 21 beveiligingsmaatregelen.

Probleem: MANRS+-conformiteit betrouwbaar meten

Een aanzienlijk probleem is dat het lastig is om betrouwbaar te meten in hoeverre toekomstige MANRS+-deelnemers de maatregelen voor het filteren van BGP-berichten correct implementeren. Daarbij gaat het in het bijzonder om de volgende maatregelen:

• Route Origin Validation (MANRS+ Routing Security Control ID RS-01)

• Prefix Filtering of Customers (RS-02)

• Control a set of customer ASes (RS-03)

• Filtering of bogons (RS-06)

Het is lastig om deze maatregelen betrouwbaar te controleren, omdat zich op het pad tussen de meetinfrastructuur en een CP-AS geen andere AS'en mogen bevinden. Die zouden namelijk de testresultaten beïnvloeden, waardoor met minder zekerheid kan worden vastgesteld of correcte filtering te danken is aan het CP-AS in kwestie, of aan een ander AS op het pad. Daarom is het noodzakelijk om een BGP-sessie op te zetten met het CP-AS dat wordt getoetst.

GCA benaderde ons met de vraag of wij hen konden helpen, gezien onze ervaring met internetmetingen. Daarop hebben we in samenwerking met GCA dit onderzoek uitgevoerd. Het controleren van de correcte implementatie van de overige 17 MANRS+-maatregelen viel buiten de scope van ons project.

Ontwerp van ons MANRS+-meetsysteem

Om het hierboven beschreven probleem op te lossen, ontwikkelden we een nieuwe methodologie waarmee met een hoge mate van zekerheid kan worden vastgesteld of toekomstige MANRS+-deelnemers de 4 filterende beveiligingsmaatregelen RS-01, RS-02, RS-03 en RS-06 hebben geïmplementeerd. Figuur 1 laat een globaal overzicht van ons meetsysteem zien. De broncode is voor iedereen toegankelijk via GitHub.

Figuur 1: Globaal overzicht van ons MANRS+-meetsysteem: de BGP-peeringrelaties tussen het MANRS+-peer-AS, MANRS+-klant-AS en CP-AS.

Om te meten in hoeverre een CP-AS filters heeft geconfigureerd, zet ons systeem 2 directe peeringsessies met het CP-AS op: een sessie waarin het MANRS+-peer-AS de rol van peer-AS uitvoert (de linkerpijl in Figuur 1), en een sessie waarin het MANRS+-klant-AS de rol van klant-AS uitvoert (de rechterpijl). Wij hebben voor ogen dat in de toekomst zowel het klant-AS als het peer-AS zullen worden beheerd door een 'MANRS+-auditor', een nieuwe zakelijke rol in het routeringsecosysteem waar we later in deze blog dieper op ingaan.

Met behulp van de 2 peeringsessies maakt ons systeem het mogelijk om een uiteenlopende reeks tests uit te voeren om te controleren hoe het CP-AS omgaat met aankondigingen. Concreet houdt dit in dat we prefixen adverteren vanuit het MANRS+-klant-AS en monitoren welke aankondigingen worden ontvangen door het MANRS+-peer-AS. Als het peer-AS routes ontvangt die volgens de MANRS+-filtermaatregelen zouden moeten worden geweigerd, wijst dit op onjuiste filtering en configuratie van de router van het CP-AS. We gebruiken prefixen die nergens anders op het internet in gebruik zijn, om mogelijke schade te voorkomen als het CP-AS onze testaankondigingen per ongeluk zou lekken naar het internet.

Het getoetste CP-AS hoeft niet via een directe fysieke verbinding op de meetinfrastructuur te zijn aangesloten. Ook zonder zo'n verbinding kunnen het MANRS+-klant-AS en het MANRS+-peer-AS directe BGP-sessies met het CP-AS opzetten. De BGP-berichten worden in dat geval transparant doorgestuurd via meerdere onderliggende netwerken (BGP-multihop).

Toetsing van de MANRS+-maatregelen voor routeringsbeveiliging

Test voor RS-01: ons systeem controleert of Route Origin Validation (ROV) correct is geconfigureerd door routeaankondigingen met een ongeldige Route Origin Authorization (ROA) naar het CP-AS te sturen. Als het CP-AS ROV implementeert, behoren deze BGP-aankondigingen te worden verworpen en zullen we ze niet terugzien bij het peer-AS. Met behulp van ROA-objecten kunnen AS-beheerders cryptografisch aantonen dat ze het recht hebben om een IP-adresblok (een prefix) te gebruiken en te adverteren. ROA-objecten worden opgeslagen in de Resource Public Key Infrastructure (RPKI), een gedecentraliseerde database waarvan het vertrouwen is verankerd in de 5 Regional Internet Registries (RIR's).

Test voor RS-02 en RS-03: ons systeem injecteert routeaankondigingen in het CP-AS die, op basis van informatie uit de Internet Routing Registries (IRR) en andere openbare bronnen, niet zouden mogen worden geadverteerd naar het peer-AS. Zo zouden bijvoorbeeld aankondigingen voor een prefix die het klant-AS volgens de IRR niet mag adverteren door het CP-AS moeten worden verworpen. De IRR bestaat uit meerdere gedistribueerde databases voor routeringsbeleid, die informatie bevatten zoals welke AS'en welke prefixen mogen adverteren, contactpersonen en IP-adresblokken. In tegenstelling tot de RPKI is de integriteit van gegevens in IRR-databases niet cryptografisch gewaarborgd.

Test voor RS-06: we meten of bogon-prefixaankondigingen correct worden gefilterd door te adverteren naar het CP-AS. Het CP-AS behoort dat soort aankondigingen te filteren en niet te adverteren naar het peer-AS. Een bogon-aankondiging betreft een prefix die niet bedoeld is voor routering op het publieke internet. Voorbeelden hiervan zijn de private IPv4- en IPv6-adresblokken.

Opzet van ons prototype

Om de haalbaarheid van onze aanpak te toetsen, ontwikkelden we in ons lab bij SIDN een prototype van ons meetsysteem. Dit deden we met behulp van containerlab, een tool voor het orkestreren van netwerklabs op basis van containers. Het verschil met tools als docker-compose is dat er met containerlab gemakkelijk koppelingen tussen containers kunnen worden geconfigureerd, waardoor het beter aansluit bij onze opzet. In ons prototype gebruiken we 3 containers om een topologie te configureren die de relaties simuleert tussen de 3 AS'en in figuur 1: het CP-AS, het MANRS+-klant-AS en het MANRS+-peer-AS.

Voor de routers in onze 3 gesimuleerde AS'en gebruiken we de BIRD-softwarerouter. Deze router is goed onderhouden en open source. Daardoor is hij toegankelijk voor iedereen die zelf met ons prototype aan de slag wil. Om RPKI-gegevens te valideren en beschikbaar te stellen aan het CP-AS, draaien we een instantie van Routinator als validerende cache.

Naast de routers voor onze 3 lokale AS'en bevat onze topologie ook een lokale IRR en een lokale RPKI (omwille van de eenvoud niet weergegeven in figuur 1). Door lokaal een IRR en RPKI te draaien, kunnen we eenvoudig gegevens manipuleren om de testcases voor de verschillende maatregelen te demonstreren. We gebruiken Krill en rsync om een lokale publicatieserver op te zetten en IRRd, Postgres en Redis voor het draaien van een lokale IRR.

Resultaat: we kunnen MANRS+-maatregelen voor routeringsbeveiliging betrouwbaar meten

Ons prototype was in staat om betrouwbaar vast te stellen dat 4 MANRS+-maatregelen voor routeringsbeveiliging door het CP-AS waren geïmplementeerd. We kwamen tot deze conclusie door onze testscripts uit te voeren voor verschillende testcases (RS-01, RS-02, RS-03 en RS-06, wat nauwkeurige en reproduceerbare resultaten opleverde.

Naar onze mening biedt ons systeem daarom een solide uitgangspunt voor een toekomstige 'MANRS+-auditor'. Deze nieuwe zakelijke rol, zoals wij die voor ons zien, is verantwoordelijk voor het controleren van de MANRS+-conformiteit van CP-AS'en door zowel het klant-AS als het peer-AS te draaien (zie figuur 1).

Uitbreidingen en overwegingen voor een toekomstige MANRS+-auditor

Dit neemt niet weg dat we een toekomstige MANRS+-auditor aanbevelen om ons ontwerp en prototype zorgvuldig te evalueren, aangezien ons project een haalbaarheidsonderzoek betrof. Wij voorzien bijvoorbeeld de volgende uitbreidingen:

Testplanning: ons systeem heeft een uitbreiding nodig waarmee objecten in de RPKI en in een IRR-database vóór het uitvoeren van tests eerst automatisch worden bijgewerkt. Wanneer het klant-AS bijvoorbeeld een prefix adverteert die door het CP-AS zou moeten worden verworpen op basis van een ROV-ongeldig filter (RS-01), is het noodzakelijk dat het systeem eerst de bijbehorende ROA bijwerkt en de geadverteerde prefix deel uitmaakt van een geldige AS-set in de IRR. Op die manier kunnen we er zeker van zijn dat het CP-AS het prefix verwerpt vanwege ROV en niet vanwege ongeldige informatie in de IRR. Een ander voorbeeld is dat het systeem CP-AS'en voldoende tijd moet geven om hun filters bij te werken. Wijzigingen in de RPKI kunnen er bijvoorbeeld een uur of langer over doen om zich te verspreiden. Filters die gebaseerd zijn op informatie in de IRR kunnen zelfs nog langzamer zijn (bijvoorbeeld 24 uur in het geval van NTT). Daarna kan de MANRS+-auditor het prefix adverteren naar de CP-AS'en. Op het internet worden BGP-updates doorgaans binnen 2 minuten verspreid, waardoor de test na uiterlijk 2 minuten moet worden beëindigd.

Controle van meerdere CP-AS'en: ons systeem heeft een uitbreiding nodig waarmee de MANRS+-auditor meerdere CP-AS'en parallel kan controleren. Dit betekent dat het systeem in staat moet zijn om dezelfde prefixen gelijktijdig naar meerdere CP's te adverteren en meerdere binnenkomende aankondigingen bij het MANRS+-peer-AS te monitoren, bijvoorbeeld met behulp van het BGP Monitoring Protocol. Op die manier kan de MANRS+-auditor de conformiteit van meerdere CP's gelijktijdig toetsen zonder dat daar extra middelen voor nodig zijn.

Beperking van onbedoelde routeverspreiding: Een mislukte test betekent dat het CP-AS de toepasselijke maatregelen niet heeft geïmplementeerd, waardoor zich mogelijk ongeldige aankondigingen over het internet verspreiden. Om dit te voorkomen, moet de MANRS+-auditor 3 tegenmaatregelen nemen. Ten eerste moet het MANRS+-klant-AS de ongeldige aankondiging intrekken zodra deze is waargenomen bij het MANRS+-peer-AS. Ten tweede kan een CP-AS zijn klanten toestaan om de verspreiding van hun prefixen te beïnvloeden via BGP-community's. In dat geval moeten de aankondigingen van het klant-AS BGP-community's bevatten die het CP-AS instrueren om de prefixen uitsluitend langs het pad naar het MANRS+-peer-AS te verspreiden. Ten derde, als een CP-AS testprefixen verder verspreidt, kunnen deze de aandacht trekken van andere netwerkoperators en onderzoekers. In het belang van transparantie moet MANRS+ daarom de middelen die bij de tests zijn gebruikt openbaar documenteren.

Onafhankelijke validatie van resultaten: De tests die door MANRS+ worden uitgevoerd, zijn gebaseerd op vertrouwen. Het is mogelijk dat een CP aankondigingen en peeringrelaties met het MANRS+-klant-AS en het MANRS+-peer-AS anders behandelt dan de rest van zijn peeringsessies. Aanvullende monitoring, vergelijkbaar met de huidige metingen binnen MANRS, kan worden ingezet om onafhankelijk te controleren op de verspreiding van ongeldige routes.

Een gedetailleerdere bespreking van deze en andere uitbreidingen vind je in ons openbare rapport voor de MANRS+-werkgroep.

Volgende stappen voor MANRS+ en onze testomgeving

Als volgende stap willen we onze aanpak testen bij meerdere operationele CP-AS'en op het internet. Daarnaast gaan we op zoek naar een organisatie die de rol van MANRS+-auditor op zich kan nemen. GCA zal hierbij het voortouw nemen. Ter ondersteuning geven wij een presentatie over ons prototypesysteem tijdens de komende bijeenkomst van de MANRS-community op 11 november.

We zijn benieuwd naar je feedback!

Aangezien dit ons eerste project is op het gebied van het toetsen van de routeringsbeveiliging, horen we graag wat je ervan vindt. Voel je vrij om ons een e-mail te sturen.