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.
Invalid Prefixes (Stand: 13.12.2019)
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.
Der bei ARIN angelegte ROA
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.
Routing Status beim RIPEstat (https://stat.ripe.net/24.38.100.0%2F24#tabId=routing)
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.
BGP Communities
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.
Artfiles hat eine US Niederlassung gegründet. Einige Kunden haben sich besorgt geäußert, dass diese Erweiterung unseres Geschäftes Artfiles in irgendeiner Weise unter Einfluss der US amerikanischen Behörden und vor allem natürlich Geheimdienste bringt.
Das Wichtigste vorab: Selbstverständlich wird Artfiles auch in Zukunft keine Kundendaten (weder die Daten der Kunden, noch Daten “über die Kunden”) in die USA transferieren, außer dies ist ausdrücklich vom jeweiligen Kunden so gewünscht.
Deutsche Kunden werden wie bisher ausschließlich in Deutschland auf deutschen Servern gehostet.
Zu grundsätzlichen Fragen des Datenschutzes aber nun ein Gastbeitrag unseres Anwalts und Datenschutzbeauftragten Dr. Martin Bahr (www.dr-bahr.com):
Die Gründung einer US-Tochtergesellschaft ist datenschutzrechtlich unbedenklich
Zunächst ist es wichtig sich in Erinnerung zu rufen, dass beide Gesellschaften rechtlich vollkommen autonome juristische Personen sind. Die Artfiles New Media GmbH ist eine deutsche GmbH, die Artfiles LLC eine nach US-Recht gegründete Limited Liability Company. Aus datenschutzrechtlicher Sicht ist die jeweils andere Gesellschaft somit ein vollkommen fremdes Unternehmen. Ohne ausdrückliche Zustimmung des Kunden dürfen keinerlei personenbezogene Daten zwischen den Unternehmen ausgetauscht werden.
Nun könnte man auf die Idee kommen, dass es den amerikanischen Behörden gleichwohl doch irgendwie gelingen könnte, über die Artfiles LLC auf die Daten der Artfiles New Media GmbH Zugriff zu nehmen. Eine solche theoretische Möglichkeit scheitert jedoch von vornherein an einem wichtigen Umstand: Die deutsche GmbH ist die Muttergesellschaft und die LLC ist zu 100% die Tochtergesellschaft.
Dies bedeutet nichts anderes, als dass alleinige Gesellschafterin der amerikanischen Firma die deutsche GmbH ist. Das US-Unternehmen liegt damit wirtschaftlich vollständig in deutschen Händen. Die deutsche GmbH bestimmt als Gesellschafterin die Marschroute. Die Tochter ist somit vollkommen abhängig von ihrer Mutter.
Aufgrund dieser Abhängigkeit stehen der Artfiles LLC keinerlei rechtlichen Möglichkeiten zu, Zugriff auf die deutsche GmbH zu nehmen. Ordnet z.B. eine amerikanische Behörde gegenüber der LLC eine Maßnahme an, so kann dies weder unmittelbar noch mittelbar die Muttergesellschaft treffen.
Die Eröffnung einer Tochtergesellschaft im Ausland, die zu 100% in den Händen der Mutter liegt, ist also aus datenschutzrechtlicher Hinsicht absolut unbedenklich. Dadurch wird auch nicht der NSA oder sonstigen US-Geheimorganisationen die Tür zu den Daten deutscher User geöffnet.
Ein einfacher Blick auf die Praxis zeigt auch diesen Umstand: Denn zahlreiche deutsche und europäische Unternehmen besitzen eigenständige Tochtergesellschaften, ohne dass dies von den Datenschutzbehörden in Europa jemals kritisiert wurde.
Was es aber zu beachten gilt
Grundsätzlich werden sämtliche Daten der Artfiles-Kunden in Deutschland von der deutschen GmbH gehostet. Nur wenn der Kunde dies ausdrücklich verlangt, kann er wahlweise mit der US-Tochtergesellschaft den Vertrag schließen und/oder seine Daten in US-Rechenzentren hosten lassen.
In beiden Fällen gilt es dabei zu beachten: Sobald der Kunde freiwillig und bewusst einen Berührungspunkt mit den USA setzt, gilt das zuvor Gesagte nicht mehr. Wählt ein Kunde nämlich das Hosting seiner Daten in den USA, so muss ihm klar sein, dass die dortigen Behörden somit faktisch Zugriff auf seine Informationen haben, z.B. im Rahmen einer Beschlagnahme vor Ort.
Gleiches gilt im Falle eines Vertragsschlusses mit der Artfiles LLC. Auch hier liegen standardmäßig sämtliche Daten auf US-Servern. Einzige Ausnahme: Wenn ein Kunde einen Vertragsschluss mit der Artfiles LLC wünscht, seine Daten aber in den Deutschland hosten will. Ein solcher Fall dürfte in der Praxis zwar eher selten vorkommen, soll hier aber gleichwohl nicht unberücksichtigt bleiben: Auch hier muss der Kunde damit rechnen, dass letzten Endes sämtliche Informationen ebenfalls bei den US-Behörden landen. Die Informationen zu seiner Person speichert die Artfiles LLC ohnehin aufgrund des Vertragsverhältnisses vor Ort in den USA. Hierauf haben die dortigen Ermittler unmittelbaren Zugriff. Die anderen Daten liegen zwar im Ausland und sind damit zunächst nicht unmittelbar greifbar. Wie zahlreiche Beispiele aus den letzten Jahren jedoch zeigen, ist dies aber nur von kurzer Dauer. Im Rahmen der Amtshilfe bzw. durch andere Maßnahmen gelingt es den US-Behörden idR. auch auf diese Datensätze zuzugreifen.
Lange Rede, kurzer Sinn: Wer jeden (theoretischen) Zugriff auf seine Daten durch US-Ämter vermeiden will, sollte weiterhin bei der deutschen Artfiles New Media GmbH bleiben und auch in Deutschland hosten. Durch die Gründung der US-Tochter entsteht keinerlei Datenschutzproblem.
Rechtsanwalt Dr. Bahr ist TÜV-zertifizierter Datenschutzbeauftragter und berät Artfiles seit mehr als 10 Jahren.
Der Heartbleed Bug wird zurecht von vielen als der „GAU des Internets” bezeichnet. Hierdurch wurden alle verschlüsselten Verbindungen, die von dem Bug betroffen waren, plötzlich unsicher. Betroffene Webserver müssen als unsicher gelten bis das Problem behoben ist. Technische Details zum Bug gibt es bei Heise und auch XKCD hat es wieder einmal mit einem anschaulichen Comic gut auf den Punkt gebracht.
In jüngster Zeit sehen wir vermehrt, wie Angriffe und sogenannte DDOS-Attacken („Distributed Denial of Service”, etwa: verteilte Attacken) auf unserer Kunden zunehmen, die zum Beispiel WordPress oder Joomla installiert haben. Unsere Serverüberwachung ist in der Lage, solche Angriffe häufig schon zu erkennen, bevor der Kunde dies bemerkt, sodass wir hier Gegenmaßnahmen ergreifen können, wie zum Beispiel das Aussperren dieser Angreifer. Dennoch kann nicht immer jede Attacke verhindert werden und nicht jeder Angriff wird erkannt, zumal wenn dieser mit hoher krimineller Energie abläuft.
In den letzten Wochen wurden wir von unseren Kunden öfter nach der Sicherheit von E-Mails gefragt und was wir bei Artfiles dafür unternehmen, dass Dritte hier keinen Zugang bekommen. Das können wir zum Glück relativ eindeutig und klar beantworten: Wir setzen alles technisch Mögliche ein, um den Transport und die Speicherung der E-Mails sicher zu gestalten. Am einfachsten lässt sich das erklären, wenn man einmal den Transport einer E-Mail von Ihrem Computer zum Empfänger betrachtet.
