MQTT-Flows konfigurieren

Sicheres MQTT in einem OT-Netzwerk mit Access Gate, standardmäßiger Verweigerung auf Port 1883, identitätsbasierten Enklaven, Steuerung auf Topic-Ebene und TLS für einen Broker, der ohne Authentifizierung oder Verschlüsselung ausgeliefert wird.

MQTT ist ein schlankes Publish/Subscribe-Protokoll, das in IoT und OT für Telemetrie und Steuerungsbefehle eingesetzt wird: Clients veröffentlichen Nachrichten zu Themen (Topics) auf einem Broker, andere Clients abonnieren diese Topics. Das Protokoll ist einfach und effizient – genau darin liegt auch sein Sicherheitsproblem. Ein Broker mit Standardkonfiguration läuft häufig ohne Authentifizierung, ohne Verschlüsselung und ohne Topic-Zugriffskontrolle. Jeder, der ihn erreichen kann, kann alle Topics lesen oder einen unautorisierten Befehl an ein Steuerungs-Topic senden. Access Gate stellt Identität, Richtlinien und Verschlüsselung vor den Broker, sodass nur autorisierte Clients MQTT-Nachrichten austauschen.

Was Sie erhalten

Default-Deny auf Port 1883. Nichts erreicht den MQTT-Port des Brokers, solange keine explizite ACL-Regel dies erlaubt. Das allein beseitigt die Angriffsfläche, bei der jeder Host im Netzwerk verbinden und veröffentlichen kann.
Identitätsgebundener Zugriff. MQTT-Datenflüsse sind in der Regel Machine-to-Machine – ein Publisher sendet Telemetrie, ein Broker verteilt sie. Berechtigungen werden zwischen Assets definiert, sodass nur der autorisierte Client den Broker erreicht und kein anderer.
TLS für ein Protokoll ohne eigene Verschlüsselung. MQTT auf Port 1883 überträgt Daten im Klartext. Das Gate kapselt die Sitzung in TLS zwischen Client und Gate und leitet den Datenverkehr anschließend über das geschützte Segment an den Broker weiter. Der Datenverkehr ist damit während der Übertragung verschlüsselt, ohne dass am Broker kryptografische Änderungen erforderlich sind.

Warum der Standard-Broker exponiert ist

In diesem Beispiel läuft der Broker als Eclipse Mosquitto 2.0.18 unter Linux mit einer minimalen Lab-Konfiguration:

# /etc/mosquitto/conf.d/lab.conf
listener 1883 0.0.0.0   # MQTT on the standard port 1883, bound to all interfaces
allow_anonymous true    # no authentication: any client can connect, publish, and subscribe

In dieser Konfiguration birgt der Broker mehrere Risiken:

Keine Authentifizierung. Mit allow_anonymous true kann jeder im Netzwerk verbinden, veröffentlichen und abonnieren – ohne Benutzername oder Passwort.
Kein TLS. Datenverkehr auf Port 1883 ist unverschlüsselt: Zugangsdaten und Telemetrie sind abfangbar, und die Sitzung kann während der Übertragung manipuliert werden (MITM).
Keine Topic-ACLs. Jeder Client kann alle Topics abonnieren oder an ein Steuerungs-Topic veröffentlichen – beispielsweise um einen PLC-Sollwert zu fälschen.
Nachrichteninjektion und Replay. Gefälschte oder wiederholte Befehle an Aktoren haben in OT physische Auswirkungen.
Denial of Service. Flooding mit Retained Messages und Verbindungserschöpfung können den Broker zum Absturz bringen.
Broker-Exposition. Da 1883 an 0.0.0.0 gebunden ist, ist der Broker segmentübergreifend erreichbar, sofern das Netzwerk nicht strikt isoliert ist.

Einrichtung

Registrieren Sie den Broker als Asset und setzen Sie das Protokoll auf MQTT.

Registrierung des MQTT-Brokers als Asset
Fügen Sie den Broker einem Enclave hinzu (siehe Schutz eines Assets mit Enclaves) und fügen Sie dann eine allow-Regel für das mqtt-Protokoll hinzu, die auf den spezifischen Client beschränkt ist, der den Broker erreichen soll. Damit wird ein Enclave um die MQTT-Datenflüsse gelegt.

Ein Enclave, der die MQTT-Datenflüsse umschließt

Ab diesem Punkt ist der Broker nicht mehr offen zugänglich: Das Gate erzwingt die Identität des Clients und die Zugriffskontrollregeln für den Datenfluss.

Praxisbeispiel: Absicherung eines Client-zu-Broker-Datenflusses

Die folgenden Abbildungen zeigen, wie eine Nachricht von einem Client über das Access Gate an den Broker veröffentlicht wird. Der Enclave ist so konfiguriert, dass nur dieser Client den Broker erreichen kann – kein anderer Host im Netzwerk.

Erste Sicherheitsebene: Authentifizierung und Zugriffskontrolle hinzufügen

Vom Client aus veröffentlichen wir eine Nachricht an das Topic. Das Gate lässt den autorisierten Client durch, und der Broker empfängt die Nachricht.

Veröffentlichen einer Nachricht an den Broker

Der Broker empfängt die veröffentlichte Nachricht

Zweite Sicherheitsebene: TLS-Verschlüsselung hinzufügen

Öffnen Sie den Enclave, aktivieren Sie TLS und installieren Sie das Zertifikat auf dem Client-Gerät. Das Gate unterhält nun einen TLS-Tunnel zwischen Client und Broker, sodass derselbe Datenfluss verschlüsselt übertragen wird.

Veröffentlichen einer verschlüsselten Nachricht an den Broker

Der Broker empfängt die verschlüsselte Nachricht

Aufbau der verschlüsselten Sitzung

Es ist hilfreich, die verschlüsselte Veröffentlichung als drei Schichten zu betrachten, die der Reihe nach aufgebaut werden:

Socket (TCP). Der Client öffnet eine TCP-Verbindung zum Gate auf Port 1883. Dies ist eine zuverlässige Byte-Leitung, die alles transportiert, was in sie eingespeist wird.
TLS. Unmittelbar nach dem Öffnen des Sockets findet ein TLS-Handshake statt. Der Proxy präsentiert seine Zertifikatskette, der Client verifiziert sie anhand seines eigenen Zertifikats (hier das Access Gate-Zertifikat) und prüft, ob der Hostname mit dem SAN des Zertifikats übereinstimmt (mqtt-broker.bluelab.secure). Beide Seiten leiten dann Schlüssel ab, und alles danach ist verschlüsselt.
Nachricht (MQTT). Erst wenn TLS aktiv ist, läuft MQTT über den verschlüsselten Kanal: CONNECT, der Broker antwortet mit CONNACK (0) (akzeptiert), dann PUBLISH der Nutzdaten an das Topic plant/line1/cmd, dann DISCONNECT. Exit-Code 0 bedeutet, dass alle drei Schichten erfolgreich abgeschlossen wurden.

TCP ist die Leitung, TLS ist der verschlüsselte Umschlag um die Leitung, und MQTT ist das eigentliche Gespräch innerhalb des Umschlags. Die Aufgabe des Proxys besteht darin, alles abzuweisen, was nicht im TLS-Umschlag verpackt ist.

Hinweise und Fallstricke

Den Datenfluss nicht unterbrechen. Beobachten Sie den realen MQTT-Datenverkehr, bevor Sie Regeln durchsetzen, damit Sie wissen, welche Clients legitim veröffentlichen oder abonnieren.
Topics sind die eigentliche Angriffsfläche. Erreichbarkeit ist die erste Kontrolle, aber der Schaden in MQTT entsteht auf Topic-Ebene. Beschränken Sie Berechtigungen auf die spezifischen Clients, die ein Steuerungs-Topic besitzen, damit ein kompromittierter Sensor nicht daran veröffentlichen kann.
Zertifikat speichern. Bewahren Sie das Client-Zertifikat im Zertifikatspeicher des Geräts auf, anstatt --cafile bei jedem Befehl zu übergeben, damit der verschlüsselte Datenfluss der Standardpfad ist.
Andere OT-Protokolle. Das gleiche Modell – Default-Deny, identitätsgebunden, TLS-gekapselt – gilt für die anderen industriellen Protokolle im Netzwerk. MQTT ist ein häufiger Ausgangspunkt, aber nicht der einzige.

Zusammenfassung

Sie haben den Broker als MQTT-Asset registriert, einen Enclave um die MQTT-Datenflüsse mit einer Default-Deny-Regel gelegt, die auf den autorisierten Client beschränkt ist, und TLS aktiviert, damit ein Klartextprotokoll verschlüsselt übertragen wird – ohne den Broker zu ändern. Der Client authentifiziert sich und verschlüsselt gegenüber dem Gate, das die Richtlinien durchsetzt und den Datenverkehr über das geschützte Segment an den Broker weiterleitet.

Setzen Sie dies ein, um einen MQTT-Broker abzusichern, der ohne Authentifizierung, ohne Verschlüsselung und ohne Topic-Zugriffskontrolle ausgeliefert wird – in einer Umgebung, in der Erreichbarkeit gleichbedeutend mit Autorisierung ist und eine einzige unerwünschte Veröffentlichung einen physischen Prozess beeinflussen kann.