Beoordeling van de beveiliging van internetpaden

Cloudgebaseerde maildiensten worden steeds dominanter

In een artikel dat in maart 2024 werd gepubliceerd door de NOS is te lezen dat 63 procent van de ongeveer 3.800 grootste bedrijven in Nederland gebruikmaakt van de cloudgebaseerde maildiensten van Microsoft of Google. Kritieke infrastructuren (KI's) vormen hierop geen uitzondering en vele ervan, zoals ING, KPN en Schiphol, vertrouwen voor hun dagelijkse activiteiten op clouddiensten (bijvoorbeeld een maildienst). Ook SIDN en de Universiteit Twente maken gebruik van de cloudgebaseerd e-maildiensten van Microsoft.

Het probleem: beperkt inzicht in de beveiliging van paden naar clouds

Tegelijkertijd hebben KI's doorgaans beperkt inzicht in de beveiligingsstatus van de paden die hun verkeer op het internet volgt om de mailinfrastructuur van hun cloudprovider te bereiken. Een KI kan er bijvoorbeeld geen weet van hebben dat haar verkeer Autonome Systemen (AS'en) passeert die geen Route Origin Validation (ROV) gebruiken. Hierdoor is het verkeer van de KI kwetsbaar voor prefix hijacks, waardoor de cloudoperator onbereikbaar kan worden voor de KI of de vertrouwelijkheid en integriteit van de gegevens van de KI kunnen worden geschonden. Als er ook maar één AS op een pad geen gebruik maakt van ROV, dan is de KI kwetsbaar voor BGP hijacks. In BGP-jargon noemen we dit 'nevenschade'.

Wij zien routing hijacks als een risico voor de toeleveringsketen van KI's. Dit risico is reëel omdat BGP prefix hijacks heel gewoon zijn op het internet en het algemeen bekend is dat ze zijn gebruikt voor malafide doeleinden, bijvoorbeeld om betalingssystemen aan te vallen, cryptovaluta te stelen, verkeer te ontregelen en DDoS-aanvallen uit te voeren.

Onze vraag is daarom wat er nodig is om ervoor te zorgen dat KI's meer inzicht krijgen in de beveiligingsstatus van de afzonderlijke AS'en op een pad naar hun cloudprovider of andere bestemming.

Onze aanpak: de ROV-score van geldige internetpaden berekenen

We combineren BGP-routegegevens afkomstig van openbare route collectors (RouteViews en RIPE RIS) met ROV-scores om de beveiliging van een pad over het internet te beoordelen. Met Microsoft als ons voorbeeld van een cloudgebaseerde maildienst doorlopen we de volgende 4 stappen om tot zo'n beoordeling te komen:

1. Paden verzamelen

We zoeken alle BGP-aankondigingen van het AS van een KI. Voor het AS van Microsoft zoeken we BGP-aankondigingen van hun maildienst. Deze hebben als prefix 52.96.0.0/12 en hebben als bron het AS van Microsoft (AS8075). Op deze manier hebben we bezien vanuit de route collectors 2 soorten paden: van het AS van de KI naar de route collectors en van het AS van Microsoft naar de route collectors.

2. Paden plakken

We maken een ongerichte graaf van beide soorten paden, waarbij de knooppunten AS-nummers zijn en de verbindingen daartussen tupels van AS'en op het AS-pad. Het gemeenschappelijke knooppunt tussen beide paden is het AS dat routegegevens dumpt naar de route collectors en dat is het punt waarop we beide paden aan elkaar plakken.

3. Paden opschonen

We controleren of een geplakt pad geldig is, wat wil zeggen dat de prefix van het bron-AS (KI) het AS van bestemming (de cloudgebaseerde maildienst) kan bereiken en omgekeerd. Dit doen we aan de hand van het model van Gao-Rexford voor de voorwaarden voor het exporteren van routes en valley-free routing. Eerst bepalen we met behulp van AS Rank van CAIDA wat de relatie tussen AS'en op geplakte paden is: Customer to Provider (C2P), Provider to Customer (P2C) of Peer to Peer (P2P). Vervolgens selecteren we de geplakte paden die voldoen aan de voorwaarde voor het exporteren van routes: van klant-ASen vernomen routes worden geëxporteerd naar providers of peers, van providers vernomen routes worden alleen geëxporteerd naar klanten en van peers vernomen routes worden alleen geëxporteerd naar klanten. Tot slot filteren we de geplakte paden eruit die voldoen aan de voorwaarden van valley-free routing: het pad bevat maximaal één P2P-link, de P2C-link mag niet worden gevolgd door een C2P- of P2P-link en de P2P-link mag niet worden gevolgd door een C2P-link.

4. Beveiligingsscore bepalen

We gebruiken de ROV-scores die de ROVista API aan AS'en toekent om de beveiliging van een geldig internetpad te berekenen. ROVista bepaalt deze score op basis van het aantal RPKI-ongeldige prefixen dat via een AS kan worden bereikt. De ROV-score varieert van 0% tot 100%, waarbij 0% betekent dat er niet op dergelijke prefixen wordt gefilterd.

Casestudy in Nederland

We gebruiken onze methode voor het berekenen van de ROV-scores voor de paden van 4 KI's in Nederland (ING, drinkwaterbedrijf Vitens, energieleverancier Eneco en ABN-AMRO Bank) naar de maildienst van Microsoft. Figuur 1 toont voor elke KI het aantal geldige paden en hun beveiligingsstatus (in termen van ROV-scores).

Zoals te zien is in Figuur 1a, heeft AS15625 (ING) het hoogste aantal paden, misschien omdat het een multi-homed AS dat 4 upstream providers gebruikt – en meer providers betekent dat een AS op meer manieren BGP-routes krijgt. In totaal zijn er 40 paden die niet door ROV worden beschermd (0% ROV in Figuur 1a) en 20 paden die volledig door ROV worden beschermd (100% ROV) voor padlengten van 1, 2 en 3 AS-hops.

In het geval van AS56517 (Figuur 1b) zijn er in totaal 10 paden die niet door ROV worden beschermd (0% ROV) en 3 paden die volledig door ROV worden beschermd (100%), ook hier weer voor padlengten van 1, 2 en 3 AS-hops. Hieruit blijkt dat een significant aantal paden gevoelig is voor BGP-prefix hijacking, wat een risico vormt voor het e-mailverkeer van de KI omdat dit op weg naar de mailserver van Microsoft de paden met minder ROV-bescherming zou kunnen nemen.

Figuur 1. Aantal paden voor verschillende aantallen AS-hops tussen de 4 KI's en de maildienst van Microsoft.

Figuur 1 illustreert ook dat het aantal extra door ROV beschermde paden al aanzienlijk toeneemt als maar een paar upstreams ROV implementeren. Als bijvoorbeeld de upstream van AS40985 ROV zou implementeren, zouden alle 14 geldige paden naar Microsoft (1, 2 of 3 AS-hops) volledig door ROV beschermd worden in plaats van 0, zoals te zien is in Figuur 1c. Als de upstream provider van AS15916 100% ROV implementeert in plaats van rond de 62%, levert dit ABN-AMRO Bank van de 20 geldige paden 9 paden op die volledig door ROV worden beschermd. Maken deze upstreams geen gebruik van ROV, dan zijn er geen paden van AS40985 en AS15916 naar de mailinfrastructuur van Microsoft die voor 100% beschermd worden door ROV.

Coalitie van AS'en om verkeer van KI door te sturen

Tabel 1 toont het aantal unieke AS'en op geldige paden van en naar de 4 KI's die een ROV-score van 100% hebben. Er zijn bijvoorbeeld in totaal 85 verschillende geldige paden tussen AS15625 en het AS van Microsoft, waarbij 15 unieke AS'en op deze paden een ROV-score van 100% hebben. Als deze 15 AS'en een coalitie zouden vormen (bijvoorbeeld een Trust Zone), zouden ze onderling meer 100% door ROV beschermde paden hebben om verkeer uit te wisselen. Het werkelijke aantal van dit soort voor 100% door ROV beschermde paden zal echter afhangen van de overeenkomsten voor het doorsturen van verkeer die de leden van de coalitie opstellen.

We voorzien dat in de toekomst AS'en dit soort concepten ook zouden kunnen aanbieden als dienst voor klanten die meer inzicht nodig hebben in de (op ROV gebaseerde) beveiliging van de AS'en die hun verkeer verwerken (bijvoorbeeld door middel van visualisaties) en controle uit te oefenen over die paden.

Tabel 1. KI's en de unieke AS'en op geldige paden naar de maildienst van Microsoft die een ROV-score van 100% hebben.

Samenvatting en toekomstig onderzoek

Wij hebben met behulp van onze methode de ROV-scores van internetpaden van KI's in Nederland naar de maildienst van Microsoft berekend, maar de methode kan ook worden gebruikt om de ROV-beveiliging te beoordelen van paden van een willekeurig bron-AS naar een willekeurig bestemmings-AS, met of zonder een bepaalde IP-prefix. Onze casestudy laat zien dat er paden zijn die voor 100% door ROV beschermd worden en paden met minder of zelfs zonder ROV-bescherming, waardoor er een veiligheidsrisico kan ontstaan in de toeleveringsketen van operators van kritieke infrastructuren. Uit onze analyse blijkt echter ook dat het aantal volledig door ROV beschermde paden naar de maildienst van Microsoft met gemiddeld 72,5% zal toenemen als upstream providers van KI's overgaan tot volledige implementatie van ROV.

In de toekomst willen we ons onder meer gaan richten op het berekenen van de beveiligingsstatus van een pad op basis van andere beveiligingscriteria dan ROV, zoals de beschikbaarheid van DDoS-bescherming. Operators van een AS zouden deze informatie mee kunnen laten wegen bij het maken van routeringsbeslissingen tussen domeinen. We hebben onze analysecode gepubliceerd op GitHub.

Met dank aan

Dit onderzoek is uitgevoerd in het kader van het CATRIN-project, dat financiering ontving van de Nederlandse Organisatie voor Wetenschappelijk Onderzoek (NWO).

Over Shyam Krishna Khadka

Shyam Krishna Khadka is promovendus aan de Universiteit Twente. Zijn interesses liggen bij de beveiliging van de internetroutering en internetmetingen. Hij heeft bij verschillende bedrijven gewerkt, waar hij meer dan 10 jaar werkervaring in softwareontwikkeling en netwerktechnologieën heeft opgedaan.