Internet Routing mit RPKI absichern
Klare Datenpfade
Veröffentlicht in Ausgabe 09/2021 - PRAXIS
Das Border-Gateway-Protokoll (BGP) ist de-facto das Standardprotokoll für den Austausch von Erreichbarkeitsinformationen zwischen autonomen Systemen (AS) im Internet. IP-Adressbereiche sind in Prefixe eingeteilt und die Erreichbarkeit jedes Adressbereichs wird vom Ursprungs-AS in Form eines BGP-Announcements an die benachbarten AS weitergeleitet. Diese AS stellen sich selbst dem AS-Pfad des Announcements voran und leiten die Informationen dann wiederum an alle benachbarten AS weiter. So traversieren Erreichbarkeitsinformationen aller Prefixe durch das Internet und werden in den Routing-Tabellen der Autonomen-Systeme-Router vorgehalten.
Die BGP-Spezifikation sieht aus historischen Gründen keine Absicherung der Erreichbarkeitsinformationen vor. Das Internet war zum Zeitpunkt seiner Entstehung so überschaubar, dass sich Administratoren noch persönlich kannten. Auch wenn das heute nicht mehr so ist, gibt es noch ein implizites Vertrauen aller AS untereinander. Das bedeutet, dass jedes AS im Grunde beliebige Informationen an seine Nachbarn weiterleiten kann, sowohl im Hinblick auf Prefixe als auch auf AS-Pfade. Der Versand falscher Informationen führt so regelmäßig zu Routinganomalien im Internet. Erst kürzlich ist die Deutsche Telekom Opfer eines Prefix-Hijacking geworden.
Routinganomalien
Die Ursache für Routinganomalien sind häufig Konfigurationsfehler einzelner AS. Einmal im Router hinterlegt, werden Informationen unmittelbar weitergeleitet und verbreiten sich zeitnah im Internet. So führt etwa ein Tippfehler bei der Eingabe des Prefixes unter Umständen zu einer internetweiten Beeinträchtigung. Die so entstehende Anomalie nennt sich heute Prefix-Hijacking.
Das Border-Gateway-Protokoll (BGP) ist de-facto das Standardprotokoll für den Austausch von Erreichbarkeitsinformationen zwischen autonomen Systemen (AS) im Internet. IP-Adressbereiche sind in Prefixe eingeteilt und die Erreichbarkeit jedes Adressbereichs wird vom Ursprungs-AS in Form eines BGP-Announcements an die benachbarten AS weitergeleitet. Diese AS stellen sich selbst dem AS-Pfad des Announcements voran und leiten die Informationen dann wiederum an alle benachbarten AS weiter. So traversieren Erreichbarkeitsinformationen aller Prefixe durch das Internet und werden in den Routing-Tabellen der Autonomen-Systeme-Router vorgehalten.
Die BGP-Spezifikation sieht aus historischen Gründen keine Absicherung der Erreichbarkeitsinformationen vor. Das Internet war zum Zeitpunkt seiner Entstehung so überschaubar, dass sich Administratoren noch persönlich kannten. Auch wenn das heute nicht mehr so ist, gibt es noch ein implizites Vertrauen aller AS untereinander. Das bedeutet, dass jedes AS im Grunde beliebige Informationen an seine Nachbarn weiterleiten kann, sowohl im Hinblick auf Prefixe als auch auf AS-Pfade. Der Versand falscher Informationen führt so regelmäßig zu Routinganomalien im Internet. Erst kürzlich ist die Deutsche Telekom Opfer eines Prefix-Hijacking geworden.
Routinganomalien
Die Ursache für Routinganomalien sind häufig Konfigurationsfehler einzelner AS. Einmal im Router hinterlegt, werden Informationen unmittelbar weitergeleitet und verbreiten sich zeitnah im Internet. So führt etwa ein Tippfehler bei der Eingabe des Prefixes unter Umständen zu einer internetweiten Beeinträchtigung. Die so entstehende Anomalie nennt sich heute Prefix-Hijacking.
Der erste dokumentierte Prefix-Hijacking-Vorfall fand bereits 1997 statt, als das AS mit der Nummer 7007 versehentlich alle damals erreichbaren Prefixe an seine Nachbarn weiterleitete, etwa 45.000 an der Zahl. Dieser Vorfall führte zu einer Diskussion über die notwendige Absicherung der Erreichbarkeitsinformationen beim Versand, zumindest für die Zuordnung eines Adressbereichs zu dem Ursprungs-AS.
Zwar gibt es bis heute, immerhin fast ein Vierteljahrhundert später, noch keine flächendeckende Umsetzung einer Absicherung, mit der Ressource-PKI (RPKI) existiert jedoch ein kryptografischer Ansatz, der vielversprechend ist und bereits von vielen großen AS implementiert wurde. Weil die Core-Router im Internet auf die Weiterleitung von Datenpaketen und nicht auf kryptografische Funktionen optimiert sind, werden diese bei der Nutzung der RPKI durch klassische Server bei der Routenauswahl unterstützt.
Ausgangspunkt der RPKI ist die auch für die Vergabe von IP-Adressen und den Betrieb der Root-DNS-Server zuständige Internet Assigned Numbers Authority (IANA). Die regionalen Internetregistrierungen (RIR) übernehmen dabei stellvertretend die Zertifizierung der Zuordnung von AS zu IP-Adressbereich. Insgesamt gibt es fünf RIR, davon ist das RIPE Network Coordination Centre [1] für den europäischen Kontinent zuständig. Um eine weltweit eindeutige AS-Nummer (ASN) zu erhalten, werden die AS-Betreiber Mitglied bei einer der RIRs, die jeweils eigene RPKI-Repositories betreiben, von denen sich die Zertifikate herunterladen lassen. Die benötigten Zertifizierungszertifikate hinterlegt jede RIR in einem Trust Anchor Locator (TAL), der von den jeweiligen Webseiten heruntergeladen werden kann, für das RIPE etwa unter [2].
Route Origin Authorization
Um die Prefixe Ihres Unternehmens-AS mit RPKI abzusichern, müssen Sie bei der zuständigen RIR eine Route Origin Authorization (ROA) beantragen. Das funktioniert im Grunde genommen so wie die Beantragung eines TLS-Zertifikats für einen Web- oder Mailserver. Dabei sind die meisten Felder selbsterklärend. Da es bisher nur eine Version der Spezifikation gibt, steht im Versionsfeld immer eine "1". Den ROA-Namen können Sie frei wählen und das Origin-AS ist die Ihnen von der RIR zugewiesene ASN. Prefix und Prefix-Length passen Sie an Ihre annoncierten Prefixe an. Mit Max-Length geben Sie optional eine maximale Länge des Prefixes an, etwa wenn Sie dieses in weitere Subnetze aufteilen und diese ebenfalls schützen möchten.
Ihr eigenes Prefix mittels RPKI zu schützen, funktioniert natürlich nur dann, wenn andere AS die Informationen auch überprüfen können. Bestenfalls soll dies direkt im Rahmen der Routenauswahl auf den Routern selbst passieren. Wie bereits angedeutet, sind die Router oft nicht dafür ausgestattet, große Mengen kryptografischer Operationen zusätzlich zum Routing der Datenpakete durchzuführen. Glücklicherweise gibt es daher mehrere Softwareprojekte, die entsprechende Dienste im eigenen AS bereitstellen können. Als Beispiel verwenden wir an dieser Stelle den vom NLnet Labs entwickelten Routinator [3].
Sie können Routinator auch verwenden, um zunächst einen Einblick in die Thematik zu erhalten, selbst wenn Sie nicht für den Betrieb eines AS verantwortlich sind. Komfortablerweise wird ein fertig vorbereiteter Docker-Container angeboten. Routinator benötigt für den Betrieb Zugriff auf die TAL der RIR. Dafür sollte bestenfalls ein Docker-Volume angelegt werden, um diesen Schritt nicht bei jedem Start erneut durchführen zu müssen. Dieses Volume erzeugen Sie mit den folgenden Kommandos und laden direkt die benötigten TAL herunter:
docker volume create routinator-volume
docker run --rm -v routinator-volume: /home/routinator/.rpki-cache/tals nlnetlabs/routinator init -f --accept-arin-rpa
Mit "--accept-arin-rpa" stimmen Sie den RPKI-Nutzungsbedingungen der amerikanischen ARIN RIR zu [4]. Wenn Sie darauf verzichten, haben Sie keinen Zugriff auf das entsprechende Repository. Um nur einen Blick auf RPKI zu riskieren, müssen Sie hier natürlich nicht zustimmen. Nachdem der Container alle wichtigen Informationen hat, starten Sie Routinator mit dem Kommando:
docker run -d --restart=unless-stopped --name routinator -p 3323:3323 -p 9556:9556 -v routinator-volume:/home/routinator/.rpki-cache/tals nlnetlabs/routinator
Nach dem Start können Sie mit Ihrem Browser die Adresse "http://localhost: 9556" öffnen und erhalten auf dem Dash-board einen Überblick, aufgeteilt nach den einzelnen RIR. Über die Validierungsfunktion oben auf der Seite können Sie nun etwa prüfen, ob Sie die Webseite unter "it-administrator.de" korrekt erreichen können oder ob der IP-Adressbereich etwa illegitimerweise auch von anderen AS angeboten wird. Geben Sie dazu als ASN 24940 und als Prefix 88.198.0.0/16 ein. Der Begriff VRP steht für Validated ROA Payload. Tatsächlich lassen sich in einem ROA nämlich mehrere Prefixe unterbringen. Jeder einzelne wird dann entsprechend validiert.
Router konfigurieren
Alle wichtigen Routerhersteller unterstützen in aktuellen Versionen die Verwendung von RPKI-Servern. Am Beispiel eines Cisco-Routers (mit IOS-Version 15.2 oder höher) demonstrieren wir, wie Sie die Verwendung von Routinator aktivieren. Dabei gehen wir davon aus, dass Sie bereits über einen für BGP-Routing eingerichteten Router verfügen. Wenn Sie die Konfiguration zunächst testen möchten, bietet sich der Graphical Network Simulator (GNS3) [5] für Ihre Versuche an. Dort können Sie IOS-Images gefahrlos auf emulierter Routerhardware laufen lassen und verschiedene Konfigurationen testen.
Die Verbindungsoptionen zu Routinator konfigurieren Sie im BGP-Konfigurationsbereich des Routers. Ersetzen Sie in den folgenden Kommandos die Werte hinter den Direktiven entsprechend Ihrer Netzwerkumgebung:
AS100-Router1(config)# router bgp 100
AS100-Router1(config-router)# bgp router-id 1.1.1.1
AS100-Router1(config-router)# rpki server 192.168.1.10
AS100-Router1(config-router)# transport tcp port 3323
AS100-Router1(config-router)# refresh-time 900
Natürlich können Sie mehrere RPKI-Server konfigurieren, wenn Sie Lastverteilung oder Ausfallsicherheit wünschen. Speichern Sie die Konfiguration und prüfen Sie anschließend mit den folgenden Befehlen den Status der RPKI-Server:
AS100-Router1# show bgp rpki server summary
AS100-Router1# show bgp rpki table ipv4
Sie sehen die konfigurierten Server und die IPv4-Adressbereiche mit den Informationen über die maximale Länge, das Origin AS und den RPKI-Server, von dem diese Information erhalten wurde. Nachdem Sie die Funktion ausreichend getestet haben, können Sie Ihre Eingangsfilter entsprechend anpassen (auch individuell für einzelne Peers oder die Routeserver eines Internetknotenpunkts) und zukünftig ungültige Announcements herausfiltern.
Beachten Sie, dass Sie Prefixe, die nicht Teil einer ROA sind, aber weiterhin erlauben, sonst entfernen Sie all die AS aus Ihrer Routingtabelle, die RPKI bisher nicht verwenden.
Fazit
Zur Absicherung von Erreichbarkeitsinformationen ist RPKI sinnvoll und prinzipiell einfach und ohne großen finanziellen Aufwand konfiguriert. Um die Nutzung weiter zu etablieren, haben Sie in diesem Artikel die notwendigen Grundlagen und Konfigurationen für Ihre Netzwerkumgebung kennengelernt. Wenn Sie selbst kein AS-Betreiber sind, überprüfen Sie die Prefixe Ihrer Dienstleister und ermuntern Sie diese zum Einsatz von RPKI.
(dr)
Link-Codes
[1] RIPE Network Coordination Centre: https://www.ripe.net/
[2] RIPE Trust Anchor Locator: https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/ripe-ncc-rpki-trust-anchor-structure/
[3] Routinator: https://www.nlnetlabs.nl/projects/rpki/routinator/
[4] ARIN RIR: https://www.arin.net/resources/manage/rpki/rpa.pdf
[5] Graphical Network Simulator: https://gns3.com/