Offen erreichbare MQTT-Broker im Internet: Die Risiken von Port 1883

Offen erreichbare MQTT-Broker sind Server, die Verbindungen von überall aus dem Internet annehmen, oft auf dem unverschlüsselten Port 1883 und ohne Authentifizierung. Dieser Artikel erklärt, was ein Angreifer oder ein neugieriger Fremder auf einem solchen Broker sehen und tun kann, wie Sie prüfen, ob einer Ihrer eigenen Broker offen erreichbar ist, und wie Sie das beheben. Am Ende haben Sie eine kurze Audit-Checkliste und eine klare Regel dafür, wohin Test- und Produktionsdaten gehören.

Warum immer wieder offen erreichbare MQTT-Broker auftauchen

MQTT wurde auf Einfachheit ausgelegt. Eine Standardinstallation eines Brokers lauscht typischerweise auf TCP-Port 1883, und manche älteren oder auf Entwicklung ausgerichteten Konfigurationen erlauben von Haus aus anonyme Verbindungen. Auf einem Laptop ist das perfekt, auf einer Cloud-VM mit öffentlicher IP-Adresse gefährlich.

Sicherheitsforscher und Suchmaschinen, die mit dem Internet verbundene Dienste indexieren, haben wiederholt große Zahlen von Brokern gemeldet, die auf Port 1883 antworten und eine Verbindung ohne Zugangsdaten akzeptieren. Das Muster dahinter ist meist dasselbe:

• Ein Entwickler startet Mosquitto oder einen anderen Broker auf einer VM, um einen Prototyp zum Laufen zu bringen.
• Die Cloud-Firewall oder Security Group wird „vorübergehend" für 1883 geöffnet, damit Feldgeräte den Broker erreichen.
• Der anonyme Zugriff bleibt aktiv, weil die Geräte nie Zugangsdaten erhalten haben.
• Der Prototyp wird stillschweigend zur Produktion.

Keiner dieser Schritte wirkt für sich genommen riskant. Zusammen entsteht ein Nachrichtenbus, den jeder lesen und beschreiben kann.

Was ein offener Broker preisgibt

Um das Risiko zu verstehen, erinnern Sie sich daran, was ein MQTT-Broker tut: Er leitet jede veröffentlichte Nachricht an jeden passenden Subscriber weiter. Wenn sich jeder verbinden kann, kann jeder zum Subscriber werden, und die mehrstufige Wildcard # passt auf jedes Topic, das der Broker verarbeitet.

Die Schreibseite wird oft unterschätzt. Wenn ein smartes Relais home/garage/door/set abonniert und der Broker anonyme Publisher akzeptiert, steuert das Tor, wer auch immer den Broker findet. In industriellen Umgebungen betrifft dasselbe Muster Sollwerte und Maschinenbefehle; für OT-Netze fordern IEC 62443 und die Umsetzung von NIS2 deshalb eine strikte Kontrolle darüber, wer worauf zugreifen darf. Deshalb geht es bei MQTT-Sicherheit ebenso um Autorisierung wie um Verschlüsselung.

Informationslecks ganz ohne Angriff

Für einen Schaden braucht es keine böse Absicht. Ein Topic-Baum wie acme/plant2/line4/press7/fault verrät einem Wettbewerber den Aufbau Ihres Werks. Gerade ein sauber nach ISA-95 strukturierter Unified Namespace (UNS), etwa acme/werk-stuttgart/presswerk/linie-4/presse-7/stoerung, ist auf einem offenen Broker eine vollständige Landkarte Ihrer Produktion. Retained Messages können Firmware-Versionen enthalten, was jedem hilft, der nach Geräten mit bekannten Fehlern sucht. Debug-Topics enthalten oft Stack Traces, IP-Adressen oder vollständige Konfigurations-Dumps. Die sichere Annahme lautet: Alles, was auf einem offenen Broker veröffentlicht wird, ist öffentlich.

So prüfen Sie, ob Ihr eigener Broker offen erreichbar ist

Testen Sie nur Broker, die Ihnen gehören oder für die Sie ausdrücklich zum Testen autorisiert sind. Ziel ist es, Ihre eigene Konfiguration von außen zu bestätigen, so wie ein Internet-Scanner sie sehen würde.

Führen Sie diese Prüfungen aus einem Netz außerhalb Ihres Unternehmens- oder Cloud-Netzes durch, etwa über einen mobilen Hotspot:

# 1. Ist der unverschlüsselte MQTT-Port aus dem Internet erreichbar?
nc -vz your-broker.example.com 1883

# 2. Akzeptiert er eine anonyme Verbindung? (nur Ihr eigener Broker)
mosquitto_sub -h your-broker.example.com -p 1883 -i audit-anon-check -t 'audit/probe' -W 5 -v

# 3. Liefert der TLS-Port ein gültiges Zertifikat?
openssl s_client -connect your-broker.example.com:8883 -servername your-broker.example.com </dev/null | head -20

So deuten Sie die Ergebnisse:

1. Meldet nc den Port als offen und wollten Sie kein unverschlüsseltes MQTT öffentlich anbieten, schließen Sie ihn an der Firewall.
2. Verbindet sich mosquitto_sub und wartet, statt mit „not authorised" abzubrechen, ist anonymer Zugriff aktiviert. Deaktivieren Sie ihn.
3. Ist das Zertifikat selbst signiert, abgelaufen oder passt es nicht zum Hostnamen, scheitern die Clients entweder, oder, schlimmer noch, sie wurden so konfiguriert, dass sie die Prüfung überspringen.

Prüfen Sie außerdem direkt die Konfiguration Ihres Brokers. In Mosquitto 2.x ist beispielsweise ein Listener ohne allow_anonymous false und ohne Passwort- oder Auth-Plugin ein Warnsignal. Prüfen Sie jeden Listener, auch WebSocket-Listener auf Ports wie 8083 und 9001, die häufig vergessen werden.

So beheben Sie einen offen erreichbaren MQTT-Broker

Gehen Sie diese Schritte der Reihe nach durch. Die ersten drei beseitigen den Großteil des Risikos an einem Nachmittag.

1. Authentifizierung auf jedem Listener verlangen. Stellen Sie pro Gerät oder Dienst einen eindeutigen Benutzernamen und ein Passwort oder ein Client-Zertifikat aus. Geteilte Zugangsdaten machen einen Widerruf unmöglich. Der Leitfaden zur MQTT-Authentifizierung mit Benutzername und Passwort beschreibt die praktische Einrichtung.
2. Port 1883 zum Internet hin schließen. Halten Sie unverschlüsseltes MQTT auf localhost oder einem privaten Netz und stellen Sie nur TLS auf 8883 bereit (sowie sichere WebSockets, falls Browser Zugriff brauchen).
3. TLS mit einem Zertifikat einer vertrauenswürdigen CA aktivieren. Clients sollten Serverzertifikat und Hostnamen prüfen. Client- und Broker-Einstellungen finden Sie unter MQTT-TLS-Konfiguration.
4. Einschränken, was jede Identität publizieren und abonnieren darf. Nutzen Sie auf einem selbst betriebenen Broker ACLs, damit ein Temperatursensor weder # abonnieren noch Befehle publizieren kann. Der MQTT-ACL-Leitfaden zeigt gängige Muster.
5. Sensible Daten aus Payloads und Retained-Topics entfernen. Löschen Sie nicht mehr benötigte Retained Messages, indem Sie eine leere Retained Message auf das Topic publizieren.
6. Limits setzen. Begrenzen Sie Verbindungen, Nachrichtengröße und Nachrichtenrate, damit ein einzelner Client den Broker nicht erschöpfen kann.
7. Patchen und überwachen. Halten Sie die Broker-Version aktuell und achten Sie auf wiederholte fehlgeschlagene Logins.

Wenn diese Liste eher nach einer Daueraufgabe als nach einer einmaligen Korrektur klingt, liegt das daran, dass sie genau das ist. Es ist einer der Hauptgründe, warum Teams auf einen verwalteten MQTT-Broker umsteigen, statt selbst einen aus dem Internet erreichbaren Server zu betreiben.

Öffentliche MQTT-Broker und private Broker

Es gibt einen wichtigen Unterschied zwischen einem versehentlich offen erreichbaren Broker und einem bewusst öffentlichen. Ein öffentlicher MQTT-Broker für Tests ist darauf ausgelegt, offen zu sein: Jeder kann sich verbinden, jeder kann abonnieren, und allen ist klar, dass die Daten sichtbar sind. Er ist ein Werkzeug zum Lernen und für schnelle Experimente.

ConnectMQ betreibt einen solchen Broker unter broker.connectmq.com. Er akzeptiert anonyme Clients mit jeder nicht leeren, eindeutigen Client ID und wendet konservative Limits pro Client an, etwa 64 KB pro Nachricht, 10 Nachrichten pro Sekunde und 10 Subscriptions. Damit ist er ideal, um Code auszuprobieren:

mosquitto_sub -h broker.connectmq.com -p 1883 -i demo-sub-7f3a -t 'connectmq/demo/7f3a/#' -v
mosquitto_pub -h broker.connectmq.com -p 1883 -i demo-pub-7f3a -t 'connectmq/demo/7f3a/hello' -m 'test message'

Die Regel ist einfach: Der öffentliche MQTT-Broker ist ausschließlich für Testdaten gedacht. Veröffentlichen Sie niemals echte Kundendaten, Zugangsdaten, Standorte oder Steuerbefehle für reale Anlagen auf einem öffentlichen Broker. Verwenden Sie ein eindeutiges Topic-Präfix wie connectmq/demo/<random-id>/, damit Ihre Experimente nicht mit denen anderer kollidieren.

Sobald Ihr Projekt über Experimente hinausgeht, braucht es einen privaten Broker mit Authentifizierung und TLS. Wenn Sie bei ConnectMQ einen erstellen, erhalten Sie generierte Zugangsdaten, und Client IDs sind an diese Zugangsdaten gebunden, sodass eine geleakte Client ID allein für eine Verbindung nicht ausreicht.

Was ein verwalteter MQTT-Broker ändert

Der Wechsel zu einem verwalteten MQTT-Broker macht Sie nicht automatisch sicher, beseitigt aber die häufigsten Ursachen für Exposition. Auf einem privaten ConnectMQ-Broker gilt:

• Verbindungen erfordern den im Portal generierten Benutzernamen und das Passwort.
• TLS ist auf Port 8883 und sichere WebSockets auf 8084 mit einem Let's-Encrypt-Zertifikat verfügbar, sodass Clients den Server ohne eigene CA-Dateien prüfen können.
• Mandanten sind im Multi-Tenant-Cluster voneinander isoliert.
• Quotas pro Plan, Flood Protection und IP-Sperre nach wiederholten fehlgeschlagenen Logins begrenzen Missbrauch.

Ihre Seite bleibt in Ihrer Verantwortung: Schützen Sie Zugangsdaten auf Geräten, nutzen Sie TLS in Produktion und entwerfen Sie Topics so, dass sie keine Informationen preisgeben. Einen vollständigen Überblick über die Optionen gibt der Leitfaden zum Cloud-MQTT-Broker, der Bereitstellungsmodelle vergleicht, und der Artikel Best Practices für MQTT-Sicherheit behandelt die Client-Seite ausführlich.

Kurze Audit-Checkliste

Nutzen Sie diese Liste für jeden Broker, den Sie betreiben:

1. Kein Listener akzeptiert anonyme Verbindungen, sofern er nicht bewusst öffentlich ist.
2. Port 1883 ist aus dem Internet nicht erreichbar; auf öffentlichen Endpunkten wird TLS erzwungen.
3. Jedes Gerät und jeder Dienst hat eigene Zugangsdaten, und Sie wissen, wie Sie sie widerrufen.
4. Clients prüfen Serverzertifikat und Hostnamen.
5. Auf öffentlichen MQTT-Brokern werden keine Geheimnisse, personenbezogenen Daten oder Steuer-Topics veröffentlicht.
6. Retained Messages enthalten nichts, was ein Fremder nicht lesen sollte.
7. Limits für Verbindungen, Größe und Rate sind konfiguriert.
8. Fehlgeschlagene Logins sind sichtbar, und wiederholte Fehlversuche werden gesperrt.

Starten Sie mit einem privaten ConnectMQ-Broker

Wenn Ihr Prototyp heute auf einem offenen Broker läuft, ist der schnellste Weg, ihn auf einen privaten Broker umzuziehen. Erstellen Sie unter app.connectmq.com einen Broker im kostenlosen Serverless-Plan, ganz ohne Kreditkarte, kopieren Sie die generierten Zugangsdaten und stellen Sie Ihre Clients auf mqtts:// auf Port 8883 um. Ihr Testcode funktioniert weiterhin auf broker.connectmq.com, während Produktionsdaten privat bleiben.

Häufig gestellte Fragen

Ist Port 1883 immer unsicher?

Port 1883 überträgt unverschlüsseltes MQTT, Zugangsdaten und Payloads gehen also im Klartext über die Leitung. Auf localhost oder in einem isolierten Netz ist das vertretbar, aus dem Internet erreichbare Endpunkte sollten jedoch TLS auf 8883 verwenden.

Woran erkenne ich, ob Fremde meinen Broker mitlesen?

Ohne Authentifizierung können Sie das nicht zuverlässig feststellen, weil jeder Client # unbemerkt abonnieren kann. Betrachten Sie einen anonymen, aus dem Internet erreichbaren Broker als bereits offengelegt und rotieren Sie alle Geheimnisse, die über ihn gelaufen sind.

Kann ich broker.connectmq.com sicher für mein Projekt nutzen?

Zum Lernen und Testen mit nicht sensiblen Daten ja. Da er bewusst öffentlich ist, kann alles, was dort veröffentlicht wird, von anderen gelesen werden; Produktivsysteme sollten daher einen privaten Broker mit Zugangsdaten nutzen.

Stoppt das Deaktivieren des anonymen Zugriffs alle Angriffe?

Nein, aber es beseitigt den einfachsten. Für echten Schutz kombinieren Sie Authentifizierung mit TLS, Autorisierung pro Client, Limits und regelmäßigem Patchen.