MQTT-Penetrationstest: Eine praxisnahe Methodik für Ihre eigenen Broker

Ein MQTT-Penetrationstest ist ein strukturierter Weg, Schwachstellen in Ihrem eigenen Broker und Ihren Clients zu finden, bevor es jemand anderes tut. Dieser Leitfaden liefert Ihnen eine wiederholbare Methodik, von Abgrenzung und Aufklärung über Authentifizierung, Autorisierung, TLS bis zu Prüfungen der Ressourcenlimits, und endet mit einer Härtungs-Checkliste, die Sie direkt an Ihr Team weitergeben können. Alles hier ist für Systeme gedacht, die Ihnen gehören oder für die Sie eine schriftliche Testerlaubnis haben.

Zuerst die Spielregeln

Einen Broker zu testen, der Ihnen nicht gehört, gilt in den meisten Rechtsordnungen als unbefugter Zugriff, ganz gleich, ob er „ohnehin offen war". Bevor Sie auch nur ein Paket senden:

• Holen Sie eine schriftliche Autorisierung des Systemeigentümers ein, mit Hosts, Ports, Zeitraum und erlaubten Techniken.
• Legen Sie fest, was außerhalb des Umfangs liegt, zum Beispiel Produktionsgeräte, die physische Anlagen ansteuern, Broker von Drittanbietern und öffentliche MQTT-Broker.
• Bevorzugen Sie eine Staging-Kopie. Ein Broker mit identischer Konfiguration, aber ohne angeschlossene Anlagen, erlaubt es Ihnen, Schreibzugriffe gefahrlos zu testen.
• Vereinbaren Sie Abbruchbedingungen. Wenn ein Test Instabilität verursacht, brechen Sie ab und melden Sie es.

In Werken mit laufender Produktion stimmen Sie Testfenster zudem mit Betriebsleitung und Instandhaltung ab, etwa auf einen geplanten Stillstand. Viele Unternehmen im DACH-Raum verankern solche Tests in ihrem Sicherheitsprogramm nach IEC 62443 oder in den Risikomanagementmaßnahmen, die NIS2 von betroffenen Einrichtungen verlangt.

Bei einem verwalteten MQTT-Broker gilt zusätzlich die Acceptable Use Policy des Anbieters. Testen Sie die Konfiguration und das Client-Verhalten Ihres eigenen Mandanten, nicht die gemeinsame Infrastruktur des Anbieters, und führen Sie niemals Last- oder Fuzzing-Kampagnen gegen einen gemeinsam genutzten Cluster oder einen öffentlichen Broker wie broker.connectmq.com durch. Dessen Limits pro Client sorgen dafür, dass er für alle nutzbar bleibt.

Die Methodik im Überblick

Phase 2: Aufklärung Ihres Brokers

Erfassen Sie zuerst alle Wege, auf denen ein Client den Broker erreichen kann. Teams sichern 8883 oft sorgfältig ab und vergessen einen WebSocket-Listener oder einen alten unverschlüsselten Listener.

# MQTT-relevante Ports auf Ihrem eigenen Host auflisten
nmap -Pn -p 1883,8883,8083,8084,9001 your-broker.example.com

# Den TLS-Endpunkt untersuchen
openssl s_client -connect your-broker.example.com:8883 -servername your-broker.example.com </dev/null

Halten Sie für jeden Listener fest: Protokoll (TCP, TLS, WS, WSS), ob er aus dem Internet erreichbar ist, Subject und Ablaufdatum des Zertifikats und welche MQTT-Versionen er akzeptiert. Stellt der Broker $SYS-Topics bereit, prüfen Sie, was diese einem gewöhnlichen authentifizierten Client verraten. Versionsstrings und Client-Zahlen sind für Angreifer nützlich und werden von Geräten selten gebraucht.

Phase 3: Authentifizierungstests

Authentifizierungstests beantworten eine einzige Frage: Kann sich jemand verbinden, der das nicht können sollte? Führen Sie jeden Test mit einem Bezeichner durch, der den Versuch in den Logs leicht auffindbar macht.

1. Anonyme Verbindung. Ohne Benutzernamen verbinden. Erwartet: Ablehnung mit dem Grund „not authorised".
2. Falsches Passwort. Erwartet: Ablehnung. Wiederholen Sie den Versuch einige Male und bestätigen Sie, dass wiederholte Fehlversuche erkannt oder gedrosselt werden.
3. Gültige Zugangsdaten, falsche Client ID. Bindet Ihr Broker Client IDs an Zugangsdaten, sollte eine Abweichung abgelehnt werden.
4. Doppelte Client ID. Zweimal mit derselben ID verbinden und die Session-Übernahme beobachten. Stellen Sie sicher, dass Ihre Geräte damit umgehen können und dass ein Angreifer, der nur eine Client ID kennt, keine Session übernehmen kann.
5. Widerrufene Zugangsdaten. Eine Testidentität widerrufen und bestätigen, dass sie sich weder verbinden noch neu verbinden kann.

Ein kleines Python-Skript macht diese Prüfungen wiederholbar:

import time
import paho.mqtt.client as mqtt

HOST, PORT = "your-broker.example.com", 8883

CASES = [
    ("anonymous", None, None, "pt-anon-01"),
    ("wrong-password", "YOUR_USERNAME", "not-the-password", "YOUR_CLIENT_ID"),
    ("valid", "YOUR_USERNAME", "YOUR_PASSWORD", "YOUR_CLIENT_ID"),
    ("valid-wrong-id", "YOUR_USERNAME", "YOUR_PASSWORD", "pt-other-id"),
]

def try_connect(name, user, pwd, cid):
    result = {}
    client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=cid,
                         protocol=mqtt.MQTTv5)
    client.tls_set()  # Serverzertifikat mit den System-CAs prüfen
    if user:
        client.username_pw_set(user, pwd)

    def on_connect(c, userdata, flags, reason_code, properties):
        result["rc"] = str(reason_code)
        c.disconnect()

    client.on_connect = on_connect
    try:
        client.connect(HOST, PORT, keepalive=10)
        client.loop_start()
        time.sleep(5)  # auf CONNACK warten
        client.loop_stop()
    except Exception as exc:
        result["rc"] = f"exception: {exc}"
    print(f"{name:16} -> {result.get('rc', 'no response')}")

for case in CASES:
    try_connect(*case)

Nur der Fall valid sollte Success melden. Alle anderen sollten mit einem eindeutigen Reason Code abgelehnt werden.

Phase 4: Autorisierungstests

Authentifizierung beweist, wer ein Client ist; Autorisierung entscheidet, was er tun darf. Erstellen Sie eine Matrix aus Rollen (Sensor, Gateway, Dashboard, Admin-Dienst) und Topic-Mustern und testen Sie jede Zelle mit einer echten Verbindung.

Arbeiten Sie mit einem Unified Namespace (UNS) nach ISA-95, leiten Sie die Matrix direkt aus dessen Hierarchie ab: Das Gateway einer Linie darf nur unter seinem eigenen Teilbaum publizieren, etwa acme/werk-stuttgart/montage/linie-1/#, und darf weder benachbarte Linien noch andere Werke erreichen. Testen Sie gezielt diese Grenzen zwischen Linien, Bereichen und Standorten.

Achten Sie darauf, wie sich Ablehnungen zeigen. In MQTT 5 liefert eine abgelehnte Subscription einen SUBACK-Reason-Code wie 0x87 (not authorised), und ein abgelehnter QoS-1-Publish liefert ein PUBACK mit Reason Code. In MQTT 3.1.1 wird ein abgelehnter Publish meist stillschweigend verworfen, Sie müssen also mit einem zweiten, privilegierten Subscriber prüfen, dass die Nachricht nie angekommen ist. Für selbst betriebene Broker erklärt der Leitfaden zur MQTT ACL, wie sich diese Regeln ausdrücken lassen. Bietet der Broker keine Regeln pro Topic, ist die entsprechende Maßnahme ein eigener Broker oder Mandant pro Vertrauenszone.

Phase 5: Tests der Transportsicherheit

Prüfen Sie beide Seiten von TLS:

• Serverseite: nur moderne Protokollversionen (TLS 1.2 und 1.3), ein Zertifikat einer vertrauenswürdigen CA, das zum Hostnamen passt, und kein unverschlüsselter Listener, der aus dem Internet erreichbar ist.
• Clientseite: Geräte müssen ein falsches Zertifikat ablehnen. Richten Sie ein Testgerät auf einen Staging-Host mit selbst signiertem oder nicht passendem Zertifikat und bestätigen Sie, dass die Verbindung fehlschlägt. Ein Client, der sich trotzdem verbindet, ist gegenüber einem aktiven Angreifer praktisch unverschlüsselt.

Der Artikel zur MQTT-TLS-Konfiguration beschreibt die korrekten Client-Einstellungen, und die Analyse von MQTT-Traffic mit Wireshark ist ein guter Weg, um nachzuweisen, dass Payloads auf der Leitung nicht mehr sichtbar sind.

Phase 6: Robustheit und Limits (nur Staging)

Robustheitstests prüfen, wie sich Broker und Clients bei zu vielen oder fehlerhaften Eingaben verhalten. Führen Sie sie nur auf einem Staging-Broker unter Ihrer Kontrolle durch, niemals auf gemeinsam genutzter oder produktiver Infrastruktur.

• Übergroße Payloads: Eine Nachricht publizieren, die größer ist als Ihr konfiguriertes Maximum. Erwartet wird eine Ablehnung, kein Absturz.
• Ratenlimits: Schneller publizieren, als Ihre Richtlinie erlaubt, und bestätigen, dass der Broker drosselt oder trennt. In den ConnectMQ-Plänen wird das Überschreiten einer Quota mit dem MQTT-5-Reason-Code 0x97 (quota exceeded) signalisiert, den Ihre Clients sauber behandeln sollten.
• Verbindungsfluten: Viele Verbindungen von einer Quelle öffnen und prüfen, dass Limits pro Client oder pro IP greifen.
• Protokoll-Fuzzing: Werkzeuge, die MQTT-Pakete verändern, können Parsing-Fehler aufdecken. Halten Sie diese Tests auf einem isolierten Broker in Ihrer Testumgebung und melden Sie Abstürze dem Broker-Hersteller.

Hintergründe zum Entwurf dieser Limits finden Sie unter MQTT-Rate-Limiting und DoS-Schutz.

Phase 7: Review von Clients und Geräten

Viele Befunde aus der Praxis liegen auf dem Gerät statt auf dem Broker:

• Zugangsdaten fest in der Firmware oder in ein Repository eingecheckt.
• Ein gemeinsames Passwort für alle Geräte einer Flotte.
• Debug-Topics, die Konfiguration oder Geheimnisse veröffentlichen.
• Befehls-Topics, die Payloads ohne Validierung ausführen.
• TLS-Prüfung deaktiviert, „damit es funktioniert".

Gehen Sie davon aus, dass jedes Gerät von einem Angreifer ausgelesen und untersucht werden kann. Jedes sollte eindeutige Zugangsdaten haben, die sich einzeln widerrufen lassen.

Härtungs-Checkliste aus Ihren Befunden

Überführen Sie Befunde in Ergebnisse, die das Team überprüfen kann:

1. Jeder Listener verlangt Authentifizierung; anonymer Zugriff existiert nur dort, wo er beabsichtigt und dokumentiert ist.
2. Aus dem Internet sind nur TLS-Listener mit gültigem Zertifikat erreichbar.
3. Jedes Gerät und jeder Dienst hat eindeutige, widerrufbare Zugangsdaten.
4. Jede Identität kann nur auf die Topics publizieren und nur die Topics abonnieren, die sie braucht.
5. Clients lehnen ungültige Zertifikate ab.
6. Limits für Nachrichtengröße, Rate und Verbindungen sind konfiguriert, und Clients gehen mit Ablehnungen um.
7. Wiederholte fehlgeschlagene Logins werden gedrosselt oder gesperrt.
8. Die Broker-Software wird planmäßig gepatcht.
9. Retained- und Debug-Topics enthalten keine Geheimnisse.
10. Erneute Tests sind nach größeren Änderungen eingeplant.

Mehrere Punkte dieser Liste übernimmt die Plattform, wenn Sie einen verwalteten MQTT-Broker nutzen. Bei ConnectMQ verlangen private Broker generierte Zugangsdaten, Client IDs sind an diese Zugangsdaten gebunden, TLS nutzt ein Let's-Encrypt-Zertifikat, Mandanten sind isoliert, und Flood Protection sowie IP-Sperre nach wiederholten fehlgeschlagenen Logins sind integriert. Ihr Testaufwand kann sich dann auf Client-Verhalten und Topic-Design konzentrieren. Der Artikel Best Practices für MQTT-Sicherheit ist eine gute Ergänzung für die clientseitigen Punkte.

Testen Sie gegen einen Broker unter Ihrer Kontrolle

Am sichersten üben Sie diese Methodik auf einem Broker, der Ihnen gehört. Erstellen Sie unter app.connectmq.com einen privaten ConnectMQ-Broker im kostenlosen Serverless-Plan (ohne Kreditkarte), führen Sie die Authentifizierungs- und TLS-Prüfungen mit Ihren eigenen Zugangsdaten durch, und halten Sie Last- und Fuzzing-Tests auf einem lokalen Staging-Broker. Für schnelle Experimente ohne sensible Daten können Sie weiterhin den kostenlosen öffentlichen MQTT-Broker im Rahmen seiner Limits nutzen.

Häufig gestellte Fragen

Darf ich einen öffentlichen MQTT-Broker einem Penetrationstest unterziehen?

Nicht ohne die ausdrückliche Erlaubnis des Betreibers. Öffentliche MQTT-Broker sind gemeinsam genutzte Dienste, und Last- oder Fuzzing-Tests verschlechtern sie für alle. Testen Sie Ihre eigenen Broker oder eine lokale Staging-Kopie.

Welche Werkzeuge werden für MQTT-Sicherheitstests häufig verwendet?

Netzwerkscanner zum Auffinden von Listenern, openssl s_client für TLS-Prüfungen, mosquitto_pub und mosquitto_sub für schnelle Tests sowie skriptgesteuerte Clients wie paho-mqtt für wiederholbare Authentifizierungs- und Autorisierungsmatrizen.

Wie oft sollten wir unser MQTT-Setup erneut testen?

Nach jeder wesentlichen Änderung an Listenern, Zugangsdaten, Topic-Struktur oder Firmware und ansonsten in regelmäßigen Abständen. Wenn Sie die Authentifizierungs- und Autorisierungsprüfungen automatisieren, werden häufige Wiederholungstests günstig.

Was ist der häufigste Befund?

Geteilte oder fest einprogrammierte Zugangsdaten auf Geräten und deaktivierte TLS-Prüfung auf Clients sind häufige Befunde, ebenso Listener, die anonyme Verbindungen akzeptieren.