Comment sécuriser Node-RED : une checklist pratique

Pour sécuriser Node-RED, vous devez verrouiller trois choses : qui peut ouvrir l'éditeur, comment le trafic vers celui-ci est chiffré, et comment vos flows communiquent avec les systèmes extérieurs comme un broker MQTT. Cette checklist passe en revue chaque paramètre de settings.js, avec des commandes à copier, pour obtenir une instance que vous pouvez laisser tourner sur un réseau en toute sérénité.

Pourquoi Node-RED doit être durci

Par défaut, une installation neuve de Node-RED n'a aucun login sur l'éditeur et sert du HTTP en clair sur le port 1880. Ce réglage est pratique sur un portable et dangereux partout ailleurs. Quiconque peut atteindre l'éditeur peut déployer un nœud function ou un nœud exec, et donc exécuter des commandes arbitraires sur l'hôte avec les permissions de Node-RED. Des éditeurs Node-RED exposés et sans authentification sont régulièrement repérés par des scanners sur internet : considérez l'éditeur comme une console d'administration, pas comme une page web.

Node-RED détient aussi des secrets : mots de passe de broker, jetons d'API, identifiants de base de données. Et comme il fait souvent le pont entre les réseaux OT et IT, une instance compromise peut servir de tremplin vers des zones que des attaquants ne devraient jamais atteindre.

Voici la checklist complète ; les sections suivantes détaillent chaque point.

1. Exiger un login pour l'éditeur

Générez un hash bcrypt d'un mot de passe robuste avec l'outil d'administration de Node-RED :

npx node-red admin hash-pw
# Password: ********
# $2b$08$wuAqPiKJlVN27eF5qJp.RuQYuy6ZYONW7a/UWYxDTtwKFCdB8F19y

Ajoutez ensuite adminAuth à settings.js (~/.node-red/settings.js, ou /data/settings.js sous Docker) :

adminAuth: {
    type: "credentials",
    users: [
        {
            username: "admin",
            password: "$2b$08$REPLACE_WITH_YOUR_HASH",
            permissions: "*"
        },
        {
            username: "viewer",
            password: "$2b$08$REPLACE_WITH_ANOTHER_HASH",
            permissions: "read"
        }
    ]
},

Redémarrez Node-RED : l'éditeur affiche un écran de connexion. La permission read permet de consulter les flows sans pouvoir déployer, ce qui convient aux opérateurs et aux auditeurs. Donnez à chacun son propre compte plutôt que de partager un mot de passe admin, afin de pouvoir retirer l'accès quand quelqu'un part. Pour les équipes plus grandes, adminAuth prend aussi en charge les stratégies OAuth et OpenID Connect via Passport, ce qui vous permet d'utiliser votre fournisseur d'identité existant.

2. Servir l'éditeur en HTTPS

Un login en HTTP simple transmet le jeton de session en clair sur le réseau. Activez HTTPS directement dans Node-RED ou terminez TLS sur un reverse proxy.

Directement dans settings.js :

// near the top of settings.js
const fs = require("fs");

module.exports = {
    https: {
        key: fs.readFileSync("/home/nodered/certs/privkey.pem"),
        cert: fs.readFileSync("/home/nodered/certs/fullchain.pem")
    },
    requireHttps: true,
    // ...
};

Derrière un reverse proxy comme Nginx, Caddy ou Traefik, laissez Node-RED en HTTP lié à localhost et confiez au proxy les certificats et leur renouvellement. Vérifiez que le proxy transmet les upgrades WebSocket, car l'éditeur utilise un WebSocket sur /comms pour l'état en direct et les messages de debug.

3. Définir un credential secret explicite

Node-RED chiffre les identifiants des nœuds, comme le mot de passe de votre broker MQTT, dans flows_cred.json. Si vous ne définissez pas de clé, il en génère une et l'enregistre dans un fichier d'exécution du répertoire utilisateur. Définissez la vôtre, idéalement depuis une variable d'environnement :

credentialSecret: process.env.NODE_RED_CREDENTIAL_SECRET,

Conservez ce secret dans votre gestionnaire de mots de passe ou votre coffre à secrets. Sans lui, un fichier d'identifiants chiffré est inutilisable, et c'est bien le but : quelqu'un qui copie vos fichiers de flows ne peut pas lire le mot de passe du broker. Si vous changez le secret plus tard, Node-RED rechiffre les identifiants au prochain déploiement.

4. Protéger les endpoints HTTP et les dashboards

adminAuth ne protège que l'éditeur et l'API d'administration. Les flows construits avec des nœuds http in, ainsi que les fichiers statiques, constituent une surface distincte. Ajoutez-leur une authentification basique :

httpNodeAuth: { user: "api", pass: "$2b$08$REPLACE_WITH_HASH" },
httpStaticAuth: { user: "static", pass: "$2b$08$REPLACE_WITH_HASH" },

Pour tout ce qui dépasse un mot de passe partagé, placez devant un proxy doté d'une véritable authentification, ou vérifiez un jeton dans le flow lui-même. Si vous utilisez Dashboard 2.0, examinez ses propres options d'accès et envisagez de le servir via le même proxy authentifié. Un dashboard en lecture seule peut tout de même révéler des données d'usine que vous préféreriez garder privées.

5. Limiter l'exposition réseau

La meilleure surface d'attaque est celle qui n'existe pas. Liez Node-RED à localhost et accédez-y via un VPN, un tunnel SSH ou un proxy authentifié :

uiHost: "127.0.0.1",
uiPort: process.env.PORT || 1880,

Sous Docker, publiez le port uniquement sur l'adresse de loopback, par exemple 127.0.0.1:1880:1880, comme le montre notre guide Node-RED sous Docker. Ne redirigez jamais le port 1880 d'un routeur vers internet. Si une instance tourne sur une passerelle edge, filtrez-la avec un pare-feu pour que seul le réseau d'administration puisse atteindre l'éditeur.

Pour les systèmes de production qui ne doivent jamais changer à l'exécution, vous pouvez aller plus loin et définir disableEditor: true. Les flows continuent de tourner, mais l'éditeur et l'API d'administration disparaissent ; les modifications se déploient en mettant à jour les fichiers et en redémarrant.

6. Appliquer le moindre privilège

N'exécutez pas Node-RED en root. Utilisez un utilisateur système dédié qui ne possède que le répertoire Node-RED. L'image Docker officielle s'exécute déjà avec un utilisateur non root. Supprimez ou restreignez les nœuds qui exécutent des commandes système, comme exec, si vos flows n'en ont pas besoin, grâce au paramètre nodesExcludes.

7. Contrôler les nœuds et modules installés

Chaque nœud contribué est du code qui s'exécute avec les permissions de Node-RED. N'installez que des nœuds maintenus dont vous avez réellement besoin, et examinez-les avant de les ajouter en production. Vous pouvez restreindre ce qui peut être installé depuis la palette :

externalModules: {
    palette: {
        allowInstall: true,
        allowList: ["@flowfuse/node-red-dashboard", "node-red-contrib-modbus"]
    },
    modules: {
        allowInstall: false
    }
},

Passer modules.allowInstall à false empêche les nœuds function de charger des paquets npm arbitraires à l'exécution.

8. Utiliser TLS et des identifiants uniques pour MQTT

Une instance Node-RED sécurisée ne doit pas ensuite parler en clair à son broker. Dans le nœud de configuration du broker MQTT :

1. Utilisez le port 8883 et cochez Use TLS, en laissant la vérification des certificats activée.
2. Utilisez un nom d'utilisateur, un mot de passe et un client ID dédiés à Node-RED, distincts de ceux des appareils. Sur ConnectMQ, les client IDs sont liés aux identifiants avec lesquels ils ont été émis : un identifiant d'appareil divulgué ne peut donc pas usurper votre instance Node-RED.
3. Ne publiez jamais de vraies données sur un broker public. Le serveur MQTT public gratuit est idéal pour apprendre, tester et prototyper, mais chaque topic de sa zone publique est lisible par tout le monde.

La configuration complète, y compris les fichiers CA personnalisés, se trouve dans notre guide Node-RED MQTT TLS, et nos bonnes pratiques de sécurité MQTT couvrent le côté broker.

9. Maintenir Node-RED et les nœuds à jour

Les correctifs de sécurité arrivent dans les versions de Node-RED, de Node.js et dans les mises à jour des nœuds contribués. Consultez Manage palette pour les mises à jour de nœuds, suivez les notes de version de Node-RED et passez Node.js à une branche LTS supportée. Sauvegardez d'abord votre répertoire utilisateur et testez les mises à niveau sur une copie avant la production.

10. Garder les secrets hors des flows et de git

Les identifiants ont leur place dans les champs credentials des nœuds de configuration, qui sont chiffrés, et non dans le code des nœuds function ou dans des nœuds inject. Lisez les clés d'API dans les nœuds function avec env.get() depuis des variables d'environnement. Si vous versionnez vos flows avec git, la fonctionnalité Node-RED projects chiffre le fichier d'identifiants avec une clé de projet qui n'entre jamais dans le dépôt.

La documentation officielle de sécurité Node-RED liste toutes les options citées ici. Pour une introduction plus large à la construction de flows, consultez le tutoriel Node-RED MQTT.

Connecter un Node-RED sécurisé à ConnectMQ

Un Node-RED durci mérite un broker aux mêmes standards. ConnectMQ est un broker MQTT managé avec TLS sur le port 8883 via un certificat Let's Encrypt, des client IDs liés aux identifiants émis, une isolation multi-tenant, une protection contre le flood et un blocage IP automatique après des échecs de connexion répétés. Créez un broker sur l'offre Serverless gratuite sur app.connectmq.com, sans carte bancaire, et donnez à Node-RED ses propres identifiants générés. Si vous comparez les modèles d'hébergement, lisez notre guide du broker MQTT cloud.

Questions fréquentes

Node-RED est-il sécurisé par défaut ?

Non. Une installation par défaut n'a pas de login sur l'éditeur et sert du HTTP en clair. Vous devez activer adminAuth, ajouter HTTPS et restreindre l'accès réseau avant de l'exposer au-delà de votre propre machine.

Comment définir un mot de passe pour l'éditeur Node-RED ?

Générez un hash bcrypt avec node-red admin hash-pw, ajoutez-le à la section adminAuth de settings.js et redémarrez Node-RED.

adminAuth protège-t-il mes dashboards et mes endpoints HTTP ?

Non. Il couvre l'éditeur et l'API d'administration. Utilisez httpNodeAuth, httpStaticAuth, les options propres au dashboard ou un reverse proxy avec authentification pour les endpoints des flows.

Que se passe-t-il si je perds le credential secret ?

Node-RED ne peut plus déchiffrer flows_cred.json : les identifiants stockés sont perdus. Vos flows se chargent toujours, mais vous devez ressaisir les mots de passe, comme les identifiants de votre broker MQTT.