Datendiode – ein unbekanntes Wesen

Ein Netzwerk zur Steuerung von Signalanlagen eines Verkehrsbetriebs wurde bislang physisch vollständig getrennt vom Rest der Welt betrieben. Das ist nun einmal die sicherste Variante. Nun wurde jedoch gefordert, die Komponenten dieses Netzes mit dem zentralen Security Monitoring zu überwachen. Es sollen also Daten aus dem physisch separaten Netz herauskommen. Aber nach wie vor dürfen unter keinen Umständen welche in das Netz hinein. Hierfür braucht es offensichtlich eine „Diode“, also ein Element das Daten nur in eine Richtung hindurchlässt.

Meine Internet-Suche nach dem Begriff förderte an prominenter Stelle ein entsprechendes Anforderungsprofil des BSI zu Tage [1]]. Datendioden braucht man wohl auch zum Schutz geheimer Informationen. Aus entsprechenden Netzen darf unter keinen Umständen Information nach außen dringen. Hinein dagegen schon. Leider konnte ich das Anforderungsprofil nicht studieren, da man für seinen Erhalt entsprechenden Bedarf gegenüber dem BSI nachweisen muss.

Zurück zu dem Produkt, das mir der Kunde zur Verfügung gestellt hatte und dessen „Sicherheit“ ich nachweisen sollte. Eine Abbildung in der Bedienungsanleitung deutet an, dass das Gerät intern aus zwei Routern besteht – als „Eingang“ und „Ausgang“ bezeichnet. Jeder Router verfügt über eine eigene serielle Konfigurationsschnittstelle (RS-232) und überdies über einige Ethernet-Ports. Beide Router sind über eine interne Schnittstelle miteinander verbunden. Diese Verbindung sei unidirektional, heißt es im Handbuch. Über Details der Realisierung schweigt es sich aus.

Immerhin beinhaltet das Handbuch ein Konfigurationsbeispiel, das ich sogleich umgesetzt habe. Demnach ist auf dem „Eingang“ eine statische Route in die Netze einzurichten, die über den „Ausgang“ zu erreichen sein sollen. Diese Route weist folgerichtig auf die IP-Adresse, die man der internen Schnittstelle des „Ausgangs“ zugewiesen hat. Überdies soll man auf der internen Schnittstelle des „Eingangs“ einen statischen ARP-Eintrag erzeugen, der die MAC-Adresse der internen Schnittstelle des „Ausgangs“ beinhaltet.

Aha, offensichtlich funktioniert auf der internen Verbindung zwischen den beiden Routern nicht einmal das Address Resolution Protocol (ARP). Wie dem auch sei, mit dem Protokollanalysator konnte ich nachweisen, dass sich Pakete vom „Eingang“ zum „Ausgang“ übertragen ließen, nicht jedoch in umgekehrter Richtung.

Natürlich habe ich sogleich den „Ausgang“ symmetrisch zum Eingang konfiguriert, also auch hier Route und ARP-Eintrag erzeugt – nichts anderes hätten Sie von mir erwartet, oder? Und trotzdem blieb die Kommunikation unidirektional. Anscheinend kann nicht einmal ein Angreifer, der volle administrative Rechte auf beiden Routern besitzt, die Übertragungsrichtung der Datendiode umkehren.

Ein Beweis dafür sind meine Experimente bis hierhin natürlich nicht. Deswegen habe ich die Datendiode aufgeschraubt und mir die Innereien angesehen: Beide Router sind identisch auf je einer Leiterplatte aufgebaut. Zwischen den Leiterplatten befindet sich ein Steckverbinder, offensichtlich die interne Schnittstelle, wie ich durch Nachverfolgen der Leiterbahnen und Vergleich mit denen der externen Ethernet-Schnittstellen herausfinden konnte.

Und siehe da: Im Gegensatz zu den externen Schnittstellen ist bei der internen nur eine Richtung beschaltet. Es handelt sich um ein Fast Ethernet (100Base-TX), bei dem das sendende Adernpaar des „Eingangs“ mit dem empfangenden des „Ausgangs“ verbunden ist. Die Gegenrichtung ist nicht beschaltet. Es funktioniert also etwa so, als wenn Sie bei einer optischen Schnittstelle zwischen zwei Switches nur eine der beiden Glasfasern aufstecken.

Was bedeutet das für die Kommunikation, die über eine Datendiode möglich ist? Ganz einfach: Es lassen sich nur Datagramme verschicken; „shoot and forget“! Sie werden niemals eine Quittung erhalten. Der Aufbau einer gesicherten Verbindung, etwa über TCP oder verschlüsselt mittels TLS, geht ins Leere. Mein Kunde wird somit nur SNMP Traps oder Syslog-Meldungen über seine Datendiode versenden können. Ein „Polling“ mittels Ping schlüge dagegen fehl.

Mit dieser Einschränkung kann mein Kunde leben. Was aber, wenn ich Daten in ein geheimes Netz senden und deren fehlerfreie Übertragung sicherstellen möchte? Dafür braucht man einen Rückkanal. Selbst hierfür gibt es bereits Ideen. Gut gefällt mir ein Vorschlag in [2], einen Rückkanal einzurichten, der ausschließlich Hash-Werte von innen nach außen übertragen kann. Um den entsprechenden „Feedback Node“ vor Kompromittierung zu schützen, würde man wiederum auf Datendioden zurückgreifen.

Halten wir fest: Dieses Konzept einer physischen Datendiode ist gegen jegliche Versuche einer Manipulation über die Administrations-Oberfläche immun. Und genau das ist ihr Vorteil gegenüber einer Firewall, bei der Sie eine Datendiode mittels eines Regelwerks emulieren.

Verweise

[1] Bundesamt für Sicherheit in der Informationstechnik, Anforderungsprofil „Datendiode zum Schutz von „GEHEIM“ eingestuften Daten“, Februar 2023, nicht abgerufen unter https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Zulassung/VS-Anforderungsprofile/Anforderungsprofile/BSI-VS-AP-0021.html

[2] Jan Klemkow, „Unidirektionale Datenverbindungen zwischen virtualisierten Gastsystemen“, Hochschule Wismar, September 2013, abgerufen unter https://klemkow.org/master.pdf