Test d'intrusion MQTT : une méthodologie pratique pour vos propres brokers

Le test d'intrusion MQTT est une manière structurée de trouver les faiblesses de votre propre broker et de vos clients avant que quelqu'un d'autre ne le fasse. Ce guide vous donne une méthodologie reproductible, du cadrage et de la reconnaissance jusqu'aux contrôles d'authentification, d'autorisation, de TLS et de limites de ressources, et se termine par une checklist de durcissement à transmettre à l'équipe. Tout ce qui suit est destiné aux systèmes qui vous appartiennent ou que vous êtes autorisé par écrit à tester.

Les règles d'engagement d'abord

Tester un broker qui ne vous appartient pas constitue un accès non autorisé dans la plupart des juridictions, même s'il « était ouvert de toute façon ». Avant d'envoyer le moindre paquet :

• Obtenez une autorisation écrite du propriétaire du système, précisant les hôtes, les ports, les dates et les techniques permises.
• Définissez ce qui est hors périmètre, par exemple les appareils de production qui actionnent des équipements physiques, les brokers tiers et les brokers de test publics.
• Privilégiez une copie de préproduction. Un broker doté de la même configuration mais sans équipement réel vous permet de tester l'accès en écriture sans risque.
• Convenez de conditions d'arrêt. Si un test provoque une instabilité, arrêtez et faites un rapport.

Sur un broker MQTT managé, la politique d'utilisation acceptable du fournisseur s'applique aussi. Testez la configuration de votre propre tenant et le comportement de vos clients, pas l'infrastructure partagée du fournisseur, et ne lancez jamais de campagnes de charge ou de fuzzing contre un cluster partagé ou contre le serveur MQTT public gratuit broker.connectmq.com. Ses limites par client existent pour qu'il reste utilisable par tous.

La méthodologie en un coup d'œil

Phase 2 : reconnaissance de votre broker

Commencez par recenser toutes les façons dont un client peut joindre le broker. Les équipes sécurisent souvent soigneusement le 8883 et oublient un listener WebSocket ou un ancien listener en clair.

# Lister les ports liés à MQTT sur votre propre hôte
nmap -Pn -p 1883,8883,8083,8084,9001 your-broker.example.com

# Inspecter l'endpoint TLS
openssl s_client -connect your-broker.example.com:8883 -servername your-broker.example.com </dev/null

Notez pour chaque listener : le protocole (TCP, TLS, WS, WSS), s'il est joignable depuis Internet, le sujet et l'expiration du certificat, et les versions de MQTT acceptées. Si le broker expose des topics $SYS, vérifiez ce qu'ils révèlent à un client authentifié ordinaire. Les chaînes de version et le nombre de clients sont utiles à un attaquant et rarement nécessaires aux appareils.

Phase 3 : tests d'authentification

Les tests d'authentification répondent à une seule question : quelqu'un qui ne devrait pas pouvoir se connecter le peut-il ? Effectuez chaque test avec un identifiant qui permet de retrouver facilement la tentative dans les journaux.

1. Connexion anonyme. Connectez-vous sans nom d'utilisateur. Attendu : refus avec un motif « not authorised ».
2. Mauvais mot de passe. Attendu : refus. Répétez quelques fois et vérifiez que les échecs répétés sont détectés ou ralentis.
3. Identifiants valides, mauvais client ID. Si votre broker lie les client IDs aux identifiants, une incohérence doit être refusée.
4. Client ID en double. Connectez-vous deux fois avec le même ID et observez la reprise de session. Assurez-vous que vos appareils la gèrent et qu'un attaquant ne disposant que d'un client ID ne peut pas s'emparer d'une session.
5. Identifiants révoqués. Révoquez une identité de test et vérifiez qu'elle ne peut plus se connecter ni se reconnecter.

Un petit script Python rend ces contrôles reproductibles :

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()  # vérifier le certificat du serveur avec les CA du système
    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)  # attendre le CONNACK
        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)

Seul le cas valid doit indiquer Success. Tous les autres doivent être refusés avec un reason code explicite.

Phase 4 : tests d'autorisation

L'authentification prouve qui est un client ; l'autorisation décide de ce qu'il peut faire. Construisez une matrice croisant les rôles (capteur, passerelle, tableau de bord, service d'administration) et les modèles de topics, puis testez chaque case avec une vraie connexion.

Faites attention à la manière dont les refus se manifestent. En MQTT 5, un abonnement refusé renvoie un reason code SUBACK comme 0x87 (not authorised), et une publication QoS 1 refusée renvoie un PUBACK avec un reason code. En MQTT 3.1.1, une publication refusée est généralement ignorée silencieusement ; vous devez donc vérifier avec un second abonné privilégié que le message n'est jamais arrivé. Sur les brokers auto-hébergés, le guide sur les ACL MQTT explique comment exprimer ces règles. Lorsque le broker ne propose pas de règles par topic, le contrôle équivalent consiste à utiliser des brokers ou des tenants distincts par zone de confiance.

Phase 5 : tests de sécurité du transport

Contrôlez les deux côtés de TLS :

• Côté serveur : uniquement des versions modernes du protocole (TLS 1.2 et 1.3), un certificat émis par une autorité de confiance correspondant au nom d'hôte, et aucun listener en clair joignable depuis Internet.
• Côté client : les appareils doivent rejeter un mauvais certificat. Dirigez un appareil de test vers un hôte de préproduction doté d'un certificat auto-signé ou ne correspondant pas, et vérifiez que la connexion échoue. Un client qui se connecte malgré tout est en pratique non chiffré face à un attaquant actif.

L'article sur la configuration TLS de MQTT détaille les bons réglages côté client, et l'analyse du trafic MQTT avec Wireshark est un bon moyen de prouver que les payloads ne sont plus visibles sur le réseau.

Phase 6 : robustesse et limites (préproduction uniquement)

Les tests de robustesse vérifient le comportement du broker et de vos clients face à des entrées trop nombreuses ou malformées. Ne les exécutez que sur un broker de préproduction que vous contrôlez, jamais sur une infrastructure partagée ou de production.

• Payloads surdimensionnés : publiez un message plus grand que votre maximum configuré. Attendez-vous à un refus, pas à un plantage.
• Limites de débit : publiez plus vite que ne l'autorise votre politique et vérifiez que le broker ralentit ou déconnecte. Sur les offres ConnectMQ, le dépassement d'un quota est signalé par le reason code MQTT 5 0x97 (quota exceeded), que vos clients doivent gérer proprement.
• Floods de connexions : ouvrez de nombreuses connexions depuis une même source et vérifiez que les limites s'appliquent par client ou par IP.
• Fuzzing du protocole : les outils qui altèrent les paquets MQTT peuvent révéler des bugs d'analyse. Cantonnez-les à un broker de test isolé et signalez les plantages à l'éditeur du broker.

Pour le contexte sur la conception de ces limites, consultez limitation de débit MQTT et protection contre les DoS.

Phase 7 : revue des clients et des appareils

De nombreux constats concrets se situent sur l'appareil plutôt que sur le broker :

• Des identifiants codés en dur dans le firmware ou commités dans un dépôt.
• Un mot de passe unique partagé par tous les appareils d'un parc.
• Des topics de débogage qui publient la configuration ou des secrets.
• Des topics de commande qui exécutent des payloads sans validation.
• Une vérification TLS désactivée « pour que ça marche ».

Considérez chaque appareil comme potentiellement extrait et examiné par un attaquant. Chacun doit disposer d'identifiants uniques révocables individuellement.

Checklist de durcissement tirée de vos constats

Transformez les constats en résultats que l'équipe peut vérifier :

1. Chaque listener exige une authentification ; l'accès anonyme n'existe que là où il est intentionnel et documenté.
2. Seuls les listeners TLS sont joignables depuis Internet, avec un certificat valide.
3. Chaque appareil et service dispose d'identifiants uniques et révocables.
4. Chaque identité ne peut publier et s'abonner que sur les topics dont elle a besoin.
5. Les clients rejettent les certificats invalides.
6. Les limites de taille des messages, de débit et de connexions sont configurées, et les clients gèrent les refus.
7. Les échecs de connexion répétés sont ralentis ou bloqués.
8. Le logiciel du broker est mis à jour selon un calendrier.
9. Les topics retenus et de débogage ne contiennent aucun secret.
10. Un nouveau test est planifié après chaque changement majeur.

Plusieurs éléments de cette liste sont pris en charge par la plateforme lorsque vous utilisez un broker MQTT managé. Sur ConnectMQ, les brokers privés exigent des identifiants générés, les client IDs sont liés à ces identifiants, TLS utilise un certificat Let's Encrypt, les tenants sont isolés, et la protection contre le flooding ainsi que le blocage d'IP après des échecs de connexion répétés sont intégrés. Vos efforts de test peuvent alors se concentrer sur le comportement des clients et la conception des topics. L'article bonnes pratiques de sécurité MQTT complète bien les éléments côté client.

Testez sur un broker que vous contrôlez

La manière la plus sûre de mettre en pratique cette méthodologie est de le faire sur un broker qui vous appartient. Créez un broker ConnectMQ privé sur l'offre gratuite Serverless sur app.connectmq.com (sans carte bancaire), exécutez les contrôles d'authentification et de TLS avec vos propres identifiants, et gardez les tests de charge et de fuzzing sur un broker de préproduction local. Pour des expériences rapides et non sensibles, vous pouvez toujours utiliser le serveur MQTT public gratuit, dans le respect de ses limites.

Questions fréquentes

Puis-je réaliser un test d'intrusion sur un broker MQTT public ?

Pas sans l'autorisation explicite de l'opérateur. Les brokers de test publics sont des services partagés, et les tests de charge ou de fuzzing les dégradent pour tout le monde. Testez vos propres brokers ou une copie de préproduction locale.

Quels outils utilise-t-on couramment pour tester la sécurité MQTT ?

Des scanners réseau pour découvrir les listeners, openssl s_client pour les contrôles TLS, mosquitto_pub et mosquitto_sub pour les tests rapides, et des clients scriptés comme paho-mqtt pour des matrices d'authentification et d'autorisation reproductibles.

À quelle fréquence faut-il retester notre installation MQTT ?

Après chaque changement significatif des listeners, des identifiants, de la structure des topics ou du firmware, et selon un calendrier régulier le reste du temps. Automatiser les contrôles d'authentification et d'autorisation rend les tests fréquents peu coûteux.

Quel est le constat le plus courant ?

Les identifiants partagés ou codés en dur sur les appareils et la vérification TLS désactivée sur les clients sont des constats fréquents, tout comme les listeners qui acceptent des connexions anonymes.