Seite 2: Sicherheit fürs Protokoll

Inhaltsverzeichnis

Durch die Publish-Subscribe-Architektur besitzt MQTT kaum Angriffsvektoren beim Senden von Daten an einen bestimmten Client, da Clients die TCP-Verbindung zum Broker stets selbst initiieren und kein Öffnen der Verbindungen von außen möglich ist. Dadurch entstehen keine Risiken beim Einsatz einer Netzwerkadressübersetzung (NAT), wie es beispielsweise häufig in lokalen Netzwerken der Fall ist. Geräte müssen -- und sollten(!) -- nicht über das Internet adressierbar sein. Brute-Force- und Denial-of-Service-Attacken auf einzelne Geräte sind schwierig durchzuführen, da sich die Geräte nicht von außen ansprechen lassen.

MQTT sollte immer in Verbindung mit TLS eingesetzt werden, damit die komplette Kommunikation verschlüsselt stattfindet. Dadurch lassen sich Man-In-The-Middle-Attacken weitgehend vermeiden, also Angriffe, bei denen ein Mittelsmann Daten mitlesen oder sogar manipulieren kann. Der MQTT-Client muss dazu das Serverzertifikat überprüfen und sicherstellen, dass es zum gewünschten MQTT-Broker passt und vertrauenswürdig ist. Der Mechanismus ist derselbe wie bei HTTPS.

Beim initialen Verbindungsaufbau zu einem MQTT-Broker kann ein Client optional sowohl einen Benutzernamen als auch ein Passwort zur Authentifizierung verwenden. Diese beiden Parameter sind die Grundlage für eine einfache Authentifizierung auf Credentials-Basis, aber auch für komplexere Authentifizierungsmethoden wie OAuth 2.0. Je nach Funktionsumfang des MQTT-Brokers lassen sich unterschiedliche Authentifizierungsmethoden verwenden.

Saubere Anmeldung der Clients

Authentifizierung bezeichnet die Prüfung der vom Client angegebenen Zugangsdaten am Broker. Damit lässt sich feststellen, ob der MQTT-Client tatsächlich derjenige ist, für den er sich ausgibt. Falls beispielsweise ein Passwort nicht zu dem angegebenen Benutzernamen passen sollte, lehnt der Broker die Verbindung ab.

MQTT-Sessions beginnen immer mit dem Verbindungsaufbau eines Clients und dem dazugehörigen initialen MQTT CONNECT-Paket. Neben Eigenschaften wie dem eindeutigen Client Identifier kann es optional Benutzername und Passwort enthalten. Im einfachsten Fall sendet der Client einen Benutzernamen und das zugehörige Passwort im Klartext. Im besten Fall hat der Broker das Passwort nicht im Klartext vorliegen, sondern nur den kryptographischen Hash des Passworts – SHA-512 ist beispielsweise ein geeigneter Algorithmus. Damit kann der Broker den Hash des im Klartext übertragenen Passworts selbst berechnen und mit den bekannten Credentials abgleichen. Noch besser ist freilich, wenn der MQTT-Client sein Passwort nur als Hash überträgt und der MQTT-Broker niemals mit dem Originalpasswort im Klartext in Berührung kommt.

Ein Grundprinzip für IoT-Geräte sollte sein, dass jedes individuelle Zugangsdaten bekommt, damit Administratoren einzelne Zugänge bei Bedarf sperren können. In professionellen MQTT-Installationen erfolgt die Verwaltung der Credentials daher üblicherweise zentral. Daher benötigt der MQTT-Broker oft eine Integration mit Fremdsystemen wie Datenbanken, LDAP-Verzeichnissen oder Microservices. Professionelle Broker bieten üblicherweise ein Plug-in-System an, das die Integration mit wenig Aufwand ermöglicht.

Einige MQTT-Broker verwenden neben dem Benutzernamen und dem Passwort andere Eigenschaften für die Authentifizierung. Bei dem in Deutschland entwickeltem MQTT-Broker HiveMQ gibt es folgende zusätzlichen Attribute:

• Client Identifier
• IP-Adresse des Clients
• X509-Clientzertifikat, falls vorhanden

Eine Authentifizierung, die nur auf Benutzername und Passwort setzt, ist in vielen Fällen nicht geeignet. Der zweite Teil des Artikels wird daher die Verwendung weiterer Methoden wie OAuth 2.0 Tokens oder X509-Clientzertifikate behandeln.

Die richtigen Rechte

Neben der Authentifizierung ist die Autorisierung ein wichtiges Konzept für die Absicherung von MQTT. Autorisierung bezeichnet das Einräumen spezieller Rechte und klärt die Frage danach, was ein bestimmter Client darf. Die erfolgreiche Authentifizierung eines MQTT-Clients bedeutet nicht zwangsläufig, dass er die Berechtigung besitzt, sämtliche Aktionen auszuführen. Ganz konkret schränken Entwickler bei MQTT üblicherweise ein, für welche Topics ein Client Nachrichten senden und welche Topics er abonnieren kann.

Ohne diese Autorisierung könnte ein bösartiger Client Nachrichten von allen Topics abonnieren und damit unberechtigterweise Daten mitlesen, die nicht für ihn bestimmt sind. Außerdem könnte ein solcher Client selbst Nachrichten mit beliebigen Topics senden. Deshalb gehört zu einer sauberen Anwendung mit MQTT unbedingt die Absicherung mit Autorisierungsmechanismen.

MQTT-Broker für den geschäftskritischen Einsatz bieten üblicherweise feingranulare Berechtigungsmechanismen an. HiveMQ bietet beispielsweise Methoden die folgenden Eigenschaften einzuschränken:

• Darf ein Client auf einem bestimmten Topic eine Retained Message versenden?
• Welches QoS-Level darf der Client senden oder abonnieren?
• Welche Topics darf der Client benutzen?
• Darf der Client auf einem bestimmten Topic abonnieren, senden oder gar beides?

Dabei ist das Erstellen sowohl von Blacklists als auch von Whitelists möglich. Letztere sind aus Sicherheitsperspektive der bessere Ansatz, weil Administratoren dabei jede einzelne Aktion explizit freigegeben müssen, womit sie Fehler beziehungsweise Löcher in den Regeln vermeiden.

Zusätzlich sollten Nutzer für jeden MQTT-Client Einschränkungen konfigurieren, beispielsweise die maximale Nachrichtengröße, die ein Client senden darf, und die maximale Bandbreite für einen MQTT-Sender. Damit lässt sich sicherstellen, dass keine einzelnen MQTT-Clients durch Softwarefehler oder bösartige Absicht versuchen, Denial-of-Service-Attacken auf dem Broker auszuführen, und bei Erfolg den gesamten MQTT-Service gefährden.