Brokers MQTT exposés sur Internet : les risques du port 1883 ouvert

Les brokers MQTT exposés sont des serveurs qui acceptent des connexions depuis n'importe où sur Internet, souvent sur le port 1883 en clair et sans authentification. Cet article explique ce qu'un attaquant ou un simple curieux peut voir et faire sur un tel broker, comment vérifier si l'un de vos brokers est exposé et comment y remédier. Vous terminerez avec une courte checklist d'audit et une règle claire sur la place des données de test et des données de production.

Pourquoi des brokers MQTT exposés continuent d'apparaître

MQTT a été conçu pour être simple. L'installation par défaut d'un broker écoute généralement sur le port TCP 1883, et certaines configurations anciennes ou orientées développement autorisent d'emblée les connexions anonymes. C'est parfait sur un ordinateur portable et dangereux sur une VM cloud dotée d'une adresse IP publique.

Les chercheurs en sécurité et les moteurs de recherche qui indexent les services connectés à Internet ont signalé à plusieurs reprises un grand nombre de brokers qui répondent sur le port 1883 et acceptent une connexion sans identifiants. Le scénario est généralement le même :

• Un développeur lance Mosquitto ou un autre broker sur une VM pour faire fonctionner un prototype.
• Le pare-feu cloud ou le groupe de sécurité est ouvert sur le 1883 « temporairement » pour que les appareils sur le terrain puissent le joindre.
• L'accès anonyme reste activé parce que les appareils n'ont jamais reçu d'identifiants.
• Le prototype devient discrètement la production.

Aucune de ces étapes ne semble risquée isolément. Ensemble, elles créent un bus de messages que n'importe qui peut lire et écrire.

Ce qu'un broker ouvert expose

Pour comprendre le risque, rappelez-vous ce que fait un broker MQTT : il achemine chaque message publié vers chaque abonné correspondant. Si n'importe qui peut se connecter, n'importe qui peut devenir abonné, et le wildcard multiniveau # correspond à tous les topics que gère le broker.

Le volet écriture est souvent sous-estimé. Si un relais connecté s'abonne à home/garage/door/set et que le broker accepte les publications anonymes, la porte est contrôlée par quiconque trouve le broker. En milieu industriel, le même schéma touche les consignes et les commandes machine. C'est pourquoi la sécurité MQTT concerne autant l'autorisation que le chiffrement.

Des fuites d'informations sans la moindre attaque

Nul besoin d'intention malveillante pour que des dégâts surviennent. Une arborescence de topics comme acme/plant2/line4/press7/fault renseigne un concurrent sur l'agencement de votre usine. Les retained messages peuvent contenir des versions de firmware, ce qui aide quiconque cherche des appareils présentant des bugs connus. Les topics de débogage transportent souvent des traces d'appels, des adresses IP ou des dumps complets de configuration. L'hypothèse prudente est que tout ce qui est publié sur un broker ouvert est public.

Comment vérifier si votre propre broker est exposé

Ne testez que des brokers qui vous appartiennent ou que vous êtes explicitement autorisé à tester. L'objectif est de confirmer votre propre configuration depuis l'extérieur, comme la verrait un scanner Internet.

Effectuez ces vérifications depuis un réseau extérieur à votre réseau d'entreprise ou cloud, par exemple un partage de connexion mobile :

# 1. Le port MQTT en clair est-il joignable depuis Internet ?
nc -vz your-broker.example.com 1883

# 2. Accepte-t-il une connexion anonyme ? (uniquement sur votre propre broker)
mosquitto_sub -h your-broker.example.com -p 1883 -i audit-anon-check -t 'audit/probe' -W 5 -v

# 3. Le port TLS présente-t-il un certificat valide ?
openssl s_client -connect your-broker.example.com:8883 -servername your-broker.example.com </dev/null | head -20

Interprétez les résultats ainsi :

1. Si nc indique que le port est ouvert alors que vous ne vouliez pas proposer MQTT en clair publiquement, fermez-le au niveau du pare-feu.
2. Si mosquitto_sub se connecte et attend au lieu d'échouer avec « not authorised », l'accès anonyme est activé. Désactivez-le.
3. Si le certificat est auto-signé, expiré ou ne correspond pas au nom d'hôte, les clients échouent ou, pire, ont été configurés pour ignorer la vérification.

Examinez aussi directement la configuration de votre broker. Dans Mosquitto 2.x, par exemple, un listener sans allow_anonymous false ni fichier de mots de passe ou plugin d'authentification est un signal d'alarme. Vérifiez chaque listener, y compris les listeners WebSocket sur des ports comme 8083 et 9001, souvent oubliés.

Comment corriger un broker MQTT exposé

Suivez ces étapes dans l'ordre. Les trois premières éliminent l'essentiel du risque en un après-midi.

1. Exiger l'authentification sur chaque listener. Émettez un nom d'utilisateur et un mot de passe uniques, ou un certificat client, par appareil ou par service. Des identifiants partagés rendent la révocation impossible. Le guide sur l'authentification MQTT par nom d'utilisateur et mot de passe couvre la mise en place concrète.
2. Fermer le port 1883 à Internet. Réservez MQTT en clair à localhost ou à un réseau privé, et n'exposez que TLS sur 8883 (ainsi que les WebSockets sécurisés si des navigateurs doivent y accéder).
3. Activer TLS avec un certificat émis par une autorité de confiance. Les clients doivent vérifier le certificat du serveur et le nom d'hôte. Consultez la configuration TLS de MQTT pour les réglages côté client et côté broker.
4. Restreindre ce que chaque identité peut publier et lire. Sur un broker auto-hébergé, utilisez des ACL pour qu'un capteur de température ne puisse ni s'abonner à # ni publier des commandes. Le guide des ACL MQTT présente les modèles courants.
5. Retirer les données sensibles des payloads et des topics retenus. Effacez les retained messages dont vous n'avez plus besoin en publiant un retained message vide sur le topic.
6. Appliquer des limites. Plafonnez le nombre de connexions, la taille des messages et leur débit pour qu'un seul client ne puisse pas épuiser le broker.
7. Mettre à jour et surveiller. Maintenez la version du broker à jour et surveillez les échecs de connexion répétés.

Si cette liste ressemble à un travail continu plutôt qu'à une correction ponctuelle, c'est parce que c'en est un. C'est l'une des principales raisons pour lesquelles les équipes passent à un broker MQTT managé au lieu d'exploiter elles-mêmes un serveur exposé à Internet.

Brokers de test publics et brokers privés

Il existe une distinction importante entre un broker exposé par accident et un broker délibérément public. Un broker de test public est conçu pour être ouvert : n'importe qui peut se connecter, n'importe qui peut s'abonner, et chacun sait que les données sont visibles. C'est un outil d'apprentissage et d'expérimentation rapide.

ConnectMQ exploite ainsi le serveur MQTT public gratuit broker.connectmq.com. Il accepte les clients anonymes avec n'importe quel client ID unique et non vide, et applique des limites prudentes par client, comme 64 Ko par message, 10 messages par seconde et 10 abonnements. Il est donc idéal pour essayer du code :

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'

La règle est simple : le serveur MQTT public gratuit est réservé aux tests et aux prototypes, jamais aux données de production. Ne publiez jamais de vraies données clients, d'identifiants, de localisations ou de commandes d'équipements réels sur un broker public, quel qu'il soit. Utilisez un préfixe de topic unique comme connectmq/demo/<random-id>/ pour que vos expériences n'entrent pas en collision avec celles des autres.

Lorsque votre projet dépasse le stade de l'expérimentation, il lui faut un broker privé avec authentification et TLS. Sur ConnectMQ, en créer un vous fournit des identifiants générés, et les client IDs sont liés à ces identifiants ; un client ID divulgué ne suffit donc pas à lui seul pour se connecter.

Ce que change un broker MQTT managé

Passer à un broker MQTT managé ne vous rend pas automatiquement sûr, mais cela supprime les causes d'exposition les plus courantes. Sur un broker privé ConnectMQ :

• Les connexions exigent le nom d'utilisateur et le mot de passe générés dans le portail.
• TLS est disponible sur le port 8883 et les WebSockets sécurisés sur le 8084, avec un certificat Let's Encrypt, si bien que les clients peuvent vérifier le serveur sans fichiers d'autorité de certification personnalisés.
• Les tenants sont isolés les uns des autres dans le cluster multi-tenant.
• Les quotas par offre, la protection contre le flooding et le blocage d'IP après des échecs de connexion répétés limitent les abus.

Votre part reste la vôtre : protégez les identifiants sur les appareils, utilisez TLS en production et concevez des topics qui ne laissent pas fuiter d'informations. Pour un panorama complet des options, le guide du broker MQTT cloud compare les modèles de déploiement, et l'article bonnes pratiques de sécurité MQTT traite en profondeur le côté client.

Checklist d'audit rapide

Utilisez cette liste pour chaque broker que vous exploitez :

1. Aucun listener n'accepte de connexions anonymes, sauf s'il est intentionnellement public.
2. Le port 1883 n'est pas joignable depuis Internet ; TLS est imposé sur les endpoints publics.
3. Chaque appareil ou service possède ses propres identifiants, et vous savez comment les révoquer.
4. Les clients vérifient le certificat du serveur et le nom d'hôte.
5. Aucun secret, aucune donnée personnelle ni aucun topic de commande n'est publié sur des brokers de test publics.
6. Les retained messages ne contiennent rien que vous ne voudriez pas voir lu par un inconnu.
7. Les limites de connexions, de taille et de débit sont configurées.
8. Les échecs de connexion sont visibles et les échecs répétés sont bloqués.

Démarrer avec un broker ConnectMQ privé

Si votre prototype tourne aujourd'hui sur un broker ouvert, la solution la plus rapide est de le migrer vers un broker privé. Créez un broker sur l'offre gratuite Serverless sur app.connectmq.com, sans carte bancaire, copiez les identifiants générés et basculez vos clients sur mqtts:// sur le port 8883. Votre code de test continue de fonctionner sur le serveur MQTT public gratuit broker.connectmq.com tandis que les données de production restent privées.

Questions fréquentes

Le port 1883 est-il toujours non sécurisé ?

Le port 1883 transporte MQTT sans chiffrement ; les identifiants et les payloads circulent donc en clair. C'est acceptable sur localhost ou sur un réseau isolé, mais les endpoints exposés à Internet doivent utiliser TLS sur 8883.

Comment savoir si des inconnus lisent mon broker ?

Sans authentification, vous ne pouvez pas le savoir de façon fiable, car n'importe quel client peut s'abonner à # en silence. Considérez un broker anonyme exposé à Internet comme déjà compromis et faites la rotation de tous les secrets qui y ont transité.

Puis-je utiliser broker.connectmq.com pour mon projet en toute sécurité ?

Oui pour l'apprentissage et les tests avec des données non sensibles. Comme il est public par conception, tout ce qui y est publié peut être lu par d'autres ; les systèmes de production doivent donc utiliser un broker privé avec identifiants.

Désactiver l'accès anonyme arrête-t-il toutes les attaques ?

Non, mais cela élimine la plus facile. Combinez l'authentification avec TLS, une autorisation par client, des limites et des mises à jour régulières pour une protection réelle.