Como Proteger o Node-RED: Um Checklist Prático

Para proteger o Node-RED, você precisa controlar três coisas: quem pode abrir o editor, como o tráfego até ele é criptografado e como seus fluxos conversam com sistemas externos, como um broker MQTT. Este checklist percorre cada configuração do settings.js, com comandos para copiar, para que você termine com uma instância segura para deixar rodando em uma rede.

Por que o Node-RED precisa de hardening

De fábrica, uma instalação nova do Node-RED não tem login no editor e serve HTTP puro na porta 1880. Esse padrão é prático em um notebook e perigoso em qualquer outro lugar. Quem conseguir acessar o editor pode implantar um function node ou um node exec, o que significa executar comandos arbitrários no host com as permissões do Node-RED. Editores Node-RED expostos e sem autenticação são encontrados regularmente por scanners na internet, então trate o editor como um console administrativo, não como uma página web.

O Node-RED também guarda segredos: senhas de broker, tokens de API, credenciais de bancos de dados. E, como costuma fazer a ponte entre redes de tecnologia operacional e de TI, uma instância comprometida pode servir de trampolim para lugares que atacantes nunca deveriam alcançar.

Aqui está o checklist completo; as seções abaixo explicam cada item.

1. Exija login no editor

Gere um hash bcrypt de uma senha forte com a ferramenta de administração do Node-RED:

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

Depois adicione o adminAuth ao settings.js (~/.node-red/settings.js, ou /data/settings.js no 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"
        }
    ]
},

Reinicie o Node-RED e o editor passa a exibir uma tela de login. A permissão read permite ver os fluxos sem fazer deploy, o que é adequado para operadores e auditores. Dê a cada pessoa a própria conta em vez de compartilhar uma senha de administrador, para poder remover o acesso quando alguém sair. Para equipes maiores, o adminAuth também suporta estratégias OAuth e OpenID Connect por meio do Passport, então você pode usar seu provedor de identidade atual.

2. Sirva o editor via HTTPS

Um login sobre HTTP puro envia o token de sessão pela rede em texto claro. Habilite o HTTPS diretamente no Node-RED ou termine o TLS em um proxy reverso.

Diretamente no settings.js:

// perto do início do 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,
    // ...
};

Atrás de um proxy reverso como Nginx, Caddy ou Traefik, mantenha o Node-RED em HTTP vinculado ao localhost e deixe o proxy cuidar dos certificados e da renovação. Garanta que o proxy encaminhe upgrades de WebSocket, porque o editor usa um WebSocket em /comms para status ao vivo e mensagens de debug.

3. Defina um credential secret explícito

O Node-RED criptografa as credenciais dos nodes, como a senha do seu broker MQTT, em flows_cred.json. Se você não definir uma chave, ele gera uma e a salva em um arquivo de runtime no diretório de usuário. Defina a sua, de preferência a partir de uma variável de ambiente:

credentialSecret: process.env.NODE_RED_CREDENTIAL_SECRET,

Guarde esse segredo no seu gerenciador de senhas ou cofre de segredos. Sem ele, um arquivo de credenciais criptografado é inútil, e é justamente essa a ideia: quem copiar seus arquivos de fluxo não consegue ler a senha do broker. Se você mudar o segredo depois, o Node-RED recriptografa as credenciais no próximo deploy.

4. Proteja endpoints HTTP e dashboards

O adminAuth protege apenas o editor e a API de administração. Fluxos montados com nodes http in e arquivos estáticos são outra superfície. Adicione autenticação básica para eles:

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

Para algo mais elaborado que uma senha compartilhada, coloque na frente um proxy com autenticação adequada ou verifique um token dentro do próprio fluxo. Se usar o Dashboard 2.0, revise as opções de acesso dele e considere servi-lo pelo mesmo proxy autenticado. Mesmo um dashboard somente leitura pode revelar dados da planta que você prefere manter privados.

5. Limite a exposição na rede

A melhor superfície de ataque é nenhuma. Vincule o Node-RED ao localhost e acesse-o por VPN, túnel SSH ou proxy autenticado:

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

No Docker, publique a porta apenas no endereço de loopback, por exemplo 127.0.0.1:1880:1880, como mostrado no nosso guia de Node-RED com Docker. Nunca encaminhe a porta 1880 de um roteador para a internet. Se uma instância rodar em um gateway de borda, coloque um firewall para que apenas a rede de gerenciamento alcance o editor.

Para sistemas de produção que nunca devem mudar em tempo de execução, você pode ir além e definir disableEditor: true. Os fluxos continuam rodando, mas o editor e a API de administração deixam de existir; implante mudanças atualizando os arquivos e reiniciando.

6. Rode com o mínimo de privilégios

Não rode o Node-RED como root. Use um usuário de sistema dedicado, dono apenas do diretório do Node-RED. A imagem Docker oficial já roda como usuário não root. Remova ou restrinja nodes que executam comandos do sistema, como o exec, se seus fluxos não precisarem deles, usando a configuração nodesExcludes.

7. Controle nodes e módulos instalados

Todo node da comunidade é código rodando com as permissões do Node-RED. Instale apenas nodes mantidos de que você realmente precisa e revise-os antes de levá-los à produção. Você pode restringir o que pode ser instalado pela paleta:

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

Definir modules.allowInstall como false impede que function nodes carreguem pacotes npm arbitrários em tempo de execução.

8. Use TLS e credenciais exclusivas para MQTT

Uma instância segura do Node-RED não deve, depois de tudo isso, conversar com o broker em texto claro. No node de configuração do broker MQTT:

1. Use a porta 8883 e marque Use TLS, deixando a verificação de certificado ativada.
2. Use username, senha e client ID dedicados ao Node-RED, separados dos dispositivos. No ConnectMQ, os client IDs ficam vinculados às credenciais com que foram emitidos, então uma credencial de dispositivo vazada não consegue se passar pela sua instância do Node-RED.
3. Nunca publique dados reais no servidor MQTT público. O servidor MQTT público (gratuito) é ideal para aprender, mas todo topic na área pública dele pode ser lido por qualquer pessoa.

A configuração completa, incluindo arquivos de CA personalizados, está no nosso guia de Node-RED MQTT com TLS, e nossas boas práticas de segurança MQTT cobrem o lado do broker.

9. Mantenha o Node-RED e os nodes atualizados

Correções de segurança chegam nas versões do Node-RED, do Node.js e nas atualizações dos nodes da comunidade. Verifique o Manage palette em busca de atualizações de nodes, acompanhe as notas de versão do Node-RED e atualize o Node.js para uma linha LTS suportada. Faça backup do seu diretório de usuário antes e teste as atualizações em uma cópia antes da produção.

10. Mantenha segredos fora dos fluxos e do git

As credenciais pertencem aos campos de credenciais dos nodes de configuração, que são criptografados, e não ao código de funções ou a nodes inject. Leia chaves de API em function nodes com env.get() a partir de variáveis de ambiente. Se você versiona fluxos com git, o recurso de projetos do Node-RED criptografa o arquivo de credenciais com uma chave de projeto que nunca entra no repositório.

A documentação oficial de segurança do Node-RED lista todas as opções citadas aqui. Para uma introdução mais ampla à criação de fluxos, veja o tutorial de MQTT no Node-RED.

Conecte o Node-RED protegido ao ConnectMQ

Um Node-RED blindado merece um broker com o mesmo padrão. O ConnectMQ é um broker MQTT gerenciado com TLS na 8883 usando certificado Let's Encrypt, client IDs vinculados às credenciais emitidas, isolamento multi-tenant, proteção contra flood e bloqueio automático de IP após repetidas falhas de login. Crie um broker no plano Serverless gratuito em app.connectmq.com, sem cartão de crédito, e dê ao Node-RED as próprias credenciais geradas. Se estiver comparando modelos de hospedagem, leia nosso guia de broker MQTT na nuvem.

Perguntas frequentes

O Node-RED é seguro por padrão?

Não. Uma instalação padrão não tem login no editor e serve HTTP puro. Você precisa habilitar o adminAuth, adicionar HTTPS e restringir o acesso à rede antes de expô-lo além da sua própria máquina.

Como defino uma senha para o editor do Node-RED?

Gere um hash bcrypt com node-red admin hash-pw, adicione-o à seção adminAuth do settings.js e reinicie o Node-RED.

O adminAuth protege meus dashboards e endpoints HTTP?

Não. Ele cobre o editor e a API de administração. Use httpNodeAuth, httpStaticAuth, as opções do próprio dashboard ou um proxy reverso com autenticação para os endpoints dos fluxos.

O que acontece se eu perder o credential secret?

O Node-RED não consegue descriptografar o flows_cred.json, então as credenciais armazenadas são perdidas. Seus fluxos continuam carregando, mas você precisa informar de novo senhas como as credenciais do seu broker MQTT.