Protecting Node-RED from itself

[TotallyInformation]

Because Node-RED is a general-purpose computing tool, it has the capabilities to make changes to the underlying Operating System environment.

So if you want your instance of Node-RED to be "safe", especially in production and customer environments, it is important to prevent Node-RED from making changes to its own environment.

Here are the things you should certainly do as a minimum if you need a secure environment:

• Protect settings.js

  While you cannot prevent it from changing certain things (flows, persisted variables, etc) if you want to allow flow edits to still work, you can and should ensure that the user-id running Node-RED does NOT have access to make changes to settings.js. Since it is that file that contains most of Node-RED's security configuration.

• Protect certificate and key files

  Node-RED should only have read-only access to these. And even that is a security risk since the private keys are supposed to be private. This is one of the reasons I don't recommend using Node-RED's built-in https capability. Instead you should use a reverse proxy such as NGINX to provide https and prevent Node-RED from having any access to the keys.

• No Internet access to the Editor

  Unless you REALLY know what you are doing, NEVER allow the Node-RED Editor (the admin web interface) to be directly accessed from the Internet. The forum has many examples of hacked Node-RED instances because people don't follow this rule.

  If you want to make the Editor remotely accessible but you aren't familiar with good security practice, use an indirect method such as Cloudflare Zero Trust, ZeroTier, or NGROK for example. Using one of those tools makes it much easier to have robust and secure access without needing to understand too many of the security details.

These things are more dependent on how secure you need your environment to be:

• Managing the node palette

  Do you want to allow flow Editors to install/update/delete nodes using the palette manager? If not, make sure that its node_modules folder cannot be amended by the user id running Node-RED and also turn off the palette manager.

• Host filing system

  Any reasonably secure installation should limit which parts of the Filing System Node-RED has read and write access to. Good practice would say that it should only be given even read access to its own userDir folder (~/.node-red on a default install). Of course, as already mentioned, some level of write access is required for that folder or at least certain files and sub-folders.

  Protect the rest of the Filing System from Node-RED access and just give specific access when required for specific purposes.

• Limit network access from flows

  While it is convenient for flow editors to have Internet and other network access from Node-RED, you should consider whether it is really needed, especially if you have turned off management of the palette. Unrestricted network access might allow an editor to exfiltrate data from across your network.

  This is especially important in a multi-customer environment where you need to ensure that one instance of Node-RED has no access to any other instances and no access to other parts of the network. Consider containerising your instances in this case or using something like FlowForge.

I expect that there are more ideas that people can, and should, add to this thread, this is just a quick brain-dump.

And, as always, please remember that this information is provided with no warrantee or guarantee. It is friendly advice not professional advice. Always have your security checked by professionals.