Für ein stabiles Internet, wie Sie es hoffentlich kennen, ist es wichtig Regeln und Sicherheitsmechanismen haben. Eine Initiative, die sich eben dies auf die Fahnen geschrieben hat, ist MANRS (https://www.manrs.org).
MANRS steht für „Mutually Agreed Norms for Routing Security“, frei übersetzt “Einvernehmlich vereinbarte Normen zur Routing Sicherheit“.
Hieraus geht auch das Ziel der Initiative hervor, möglichst viele Teilnehmer sollen diese Normen umsetzen, sei es ein Internetprovider, Cloudanbieter, Streaminganbieter oder Internet Exchanges.
Um z.B. eine Domain aufrufen zu können, werden viele kleine Datenpakete durch das Internet geschickt. Diese Datenpakete müssen dafür mehrere Router passieren, diese Router sorgen dafür, dass das Datenpaket den schnellsten Weg zum Ziel findet. Um den schnellsten Weg zu finden, führt der Router einen „Routing Table“, in dem der Router alle ihm bekannten Wege zum Ziel führt. Dieser „Routing Table“ baut auf den Updates seiner Nachbarroutern auf.
Durch diesen kleinen Exkurs wird vielleicht auch deutlich, warum es wichtig ist, korrekte Daten an die Nachbarrouter zu annoncieren. Werden falsche Daten annonciert, führt der „Routing Table“ falsche Einträge. Letztendlich kann dies für Sie verschiedene Konsequenzen zur Folge haben: Ihre Daten kommen nicht am Ziel an; benötigen sehr viel länger zum Ziel; im schlimmsten Fall landen die Daten bei Kriminellen. Daher ist es wichtig, entsprechende Maßnahmen umzusetzen, um solche Probleme, so gut wie möglich, zu verhindern.
Viele dieser Punkte haben wir schon seit langem umgesetzt, wie z.B. durch die Einführung von RPKI letztes Jahr. Nun haben wir jedoch auch die letzten Maßnahmen eingeführt und vor allem aktualisiert, um alle 4 Themenkomplexe komplett zu erfüllen. Somit können wir nun verkünden, dass wir seit heute offizieller MANRS Teilnehmer sind.
Auch zukünftig werden wir natürlich die Entwicklungen beobachten und entsprechende Maßnahmen ergreifen sofern diese nötig sind. Sollten Sie Fragen haben, melden Sie sich gerne bei uns.
In der IT-Branche ist RPKI in aller Munde und auch wir haben dieses Thema in den letzten Wochen aufgegriffen. Mit der Implementierung leisten wir einen Beitrag zur Routing-Sicherheit und schützen unsere Netze gegen gewollte und ungewollte Attacken.
Ab Dienstag, den 07.01.2020, werden wir die RPKI Validation aktivieren und Routen verwerfen, die nicht korrekt vom Inhaber authorisiert sind. Laut unserem Monitoring werden dies ca. 4500 IPv4 Netze und ca. 800 IPv6 Netze sein.
Und nun nochmal genauer
Was ist eigentlich RPKI?
RPKI steht für ‚Resource Public Key Infrastructure‘ und bildet einen Baustein in der BGP Sicherheit. BGP ist die Abkürzung für ‚Border Gateway Protocol‘ und stellt das zentrale Routingprotokoll dar, um verschiedene Netzwerke miteinander zu verbinden.
Jede Organisation oder Privatperson, die selbst Prefixe (Netze) hochfahren möchte, erhält von der zuständigen RIR (Regional Internet Registry), in unserem Fall dem RIPE, eine sogenannte AS-Nummer. Generell kann nun jeder unterhalb seiner AS-Nummer (oder auch einer x-beliebigen, BGP bietet da keinen Schutz) jedes Prefix annoncieren und dies seinem BGP-Neighbor mitteilen. Ohne Sicherheitsmechanismen nimmt der BGP-Neighbor dieses Prefix in seinen Routing Table auf und teilt wiederum seinen Nachbarn mit, dass er einen Pfad zu diesem Prefix besitzt. Somit könnte der Traffic nun einen anderen Weg nehmen und nicht am eigentlichen Zielort ankommen. Mit RPKI ist es nun möglich, solche Angriffe zu einem großen Teil zu unterbinden. Wichtig hierfür ist das Signieren der eigenen Prefixe sowie das Validieren der externen Prefixe.
Signierung
RPKI setzt zum Signieren auf die Public-Key Verschlüsselung. Hierfür übernimmt das RIPE das Hosten der CA (Certification Authority) und stellt uns Zertifikate für unsere Prefixe aus. So ein Zertifikat nennt sich ROA (Route Origination Authorization) und besteht aus drei Teilen.
Origin AS – Die AS-Nummer, die das Prefix hochfahren darf
Prefix – Das zu signierende Prefix
Prefixlänge – Die Länge des Prefix, z.B. ob das Prefix nur als /24 hochgefahren werden darf oder auch als /23
Anhand der erstellten ROAs kann nun jeder Router ein Prüfung vornehmen, ob das an ihn annoncierte Prefix überhaupt annonciert werden darf.
Validierung
Die Validierung der Prefixe läuft so ab, dass zusätzliche Software, der Validator, alle ROAs von den unterschiedlichen RIRs runterlädt und lokal zusammenfasst. Der Router fragt die ROAs nun über das RTR-Protokoll vom Validator ab und führt dann eine Route Origin Validation (ROV) durch und versieht die ihm annoncierten Prefixe mit einem Status:
valid Das annoncierte Prefix wird vom korrekten AS annonciert und hat die korrekte Länge
unknown Das annoncierte Prefix hat keinen ROA oder die Verbindung zum Validator ist längere Zeit inaktiv und die lokale Datenbank damit nicht mehr up-to-date
invalid Das annoncierte Prefix wird vom falschen AS annonciert oder besitzt eine falsche Länge
Auf Basis dieser Validierung kann man auf dem Router nun festlegen, was mit den annoncierten Prefixes geschehen soll.
Wir haben unsere Router so konfiguriert, dass Prefixe mit dem Status valid und unknown angenommen werden. Prefixe mit dem Status invalid, werden vom 07.01.2020 an verworfen und nicht in den aktiven Routing Table aufgenommen.
Durch das Verwerfen von invaliden Prefixes kann es nun vorkommen, dass Clients aus diesen Netzen keinen unserer Services mehr nutzen können. Hier möchten wir nochmal betonen, dass das Problem in dem Fall nicht bei uns liegt, sondern beim Provider des Clients, da dort falsche ROAs konfiguriert sind.
Demonstrieren lässt sich dies z.B. an dem Prefix 24.38.100.0/24. Hierfür ist der folgende ROA angelegt.
Demnach darf nur das AS6128 das Netz announcen. Laut Routing Table wird das Netz jedoch von AS54004 announciert. Damit stimmt das announcierte Prefix nicht mit dem ROA überein und der Status wird auf invalid gesetzt.
Da wir mit einigen Kunden interne BGP-Sessions aufgesetzt haben und wir dort teilweise Prefixe announciert bekommen, die nicht durch einen ROA authorisiert werden können, mussten wir hierfür eine Lösung finden, da jedes an uns announcierte Prefix die Validierung durchlaufen soll, ohne Ausnahme.
Um dies zu gewährleisten, werden die announcierten Prefixes in die kundenspezifische Policy geschrieben und erhalten dort von uns den Status valid. So ist gewährleistet, dass die Prefixes vom Kunden immer valid sind und angenommen werden.
Zusätzlich versehen wir jedes Prefix mit einer Community, was uns z.B. das Monitoring der Prefixes erleichtert.
Die Zukunft
RPKI trägt einen Teil zur Sicherheit der Netzwerke bei, weitere interessante Sicherheitsmaßnahmen wie z.B. ASPA befinden sich in der Entwicklung und werden von uns aufmerksam verfolgt, um auch zukünftig unser Netzwerk, und damit auch Sie, zu schützen.
Wir hoffen, Ihnen einen kleinen Einblick in die RPKI Implementierung bei Artfiles gegeben zu haben. Sollten Sie Fragen haben, melden Sie sich gerne bei uns.