Safely accessing Node-RED over the Internet

NOTES:

  • This is a large and complex subject. So this FAQ is likely to be a work-in-progress for some time.
  • This FAQ MUST NOT be taken as gospel or as professional advice. The information is shared in good faith but with no guarantees. Get the input of professionals and get your system regularly security tested, at least penetration tested.

Apologies, the forum won't let me have 2 new topics open at the same time, I will come back to this when time permits. In the meantime, please feel free to add suggestions for content and links to existing resources.

Overview of options

There are two main options for making Node-RED endpoints available over the Internet.

  1. A Virtual Private Network (VPN)

    There are a number of different types of VPN so I'll summarise them separately. Broadly, there are 3 types but only 2 help in this case.

    What most people think of as a VPN provides an encrypted "tunnel" over a more open network. Whatever is connected at the remote end of the tunnel appears as though they are on the local end. In other words, a VPN of this type extends your local network to a remote device or site. This has its own dangers in that you may be opening your network to a less well-managed device or site, one that may be vulnerable or be compromised which may then compromise your local network. So doing this kind of VPN right is a serious excercies and not to be undertaken lightly.

    The 2nd type of useful VPN uses a 3rd-party intermediate and a utility on a local server to facilitate limited connections between a remote device and a local device or network. These are sometimes referred to as HTTP VPN's. They create a tunnel over HTTP rather than at the lower level of the other VPN types. This makes them much easier to set up typically. However, you have to trust the 3rd-party. And, many of these services are not secure by default - they allow unencrypted traffic, something that you must NEVER allow over the Internet - no excuses.

    The 3rd type of VPN is the type that you use to obfuscate your origin on the Internet, generally to access services that are limited to a specific locality. These are not suitable for this use-case.

  2. TCP/IP direct access

    This is probably what most people think of when they think about sharing web-based services over the Internet. HTTP that underpins the web is a TCP/IP based service. If you have ever just enabled access to Node-RED over the Internet, you are in this space.

    In this case, you are allowing access from potentially billions of external devices to your local network and do a device on that network that may not be (almost certainly isn't) secure. Within 30 seconds of connecting a new network device to the Internet, it will be scanned by bots and occasionally real people who are all looking for entry to free resources. Either for the purpose of stealing information of value (like identities), stealing computing power (to allow them to go hack other people or hide their illegal activities), or simply to cause havoc for the sake of it. If bots can be bothered to access IP cameras (that have tiny amounts of processing power), they will be bothered to use your poorly secured devices. We HAVE seen instances of specific hacks on Node-RED in addition to the "normal" vulnerabilities of any device running services accessible to the Internet.

    So, you need to take some steps to at least secure what access is allowed from the Internet and you will need various tools to help with that. It is hard to get right and easy to mess up. If you are not an expert, you will need lots of time to make sure you get things reasonably secure. And even then, you should have your setup professionally tested if you are running anything of value. You will also need some ongoing processes because vulnerabilities are constantly changing. Once you have started, the only way to stop is to turn off access completely. So make sure you are prepared to keep going and have the time and resources to commit to your service (even if it is only for you and a few friends).

    Also note that this option is what you are using if you make use of a cloud-based server whether that is from a cloud service provider (Azure, AWS, etc) or from a VPS or shared server service provider. So I won't be covering that separately. Just note that you have fewer security options when working with a VPS or shared server. In the case of a VPS, you are reliant on the service provider for a main firwall (it will be a fixed, shared configuration) and on an OS-level local firewall for your specific controls - not as secure but probably good enough for most things. For a shared server, you will be dependent on what the service provider lets you do. In most cases shared servers are not suitable for running Node-RED anyway.

I will break down the three broad approaches in separate posts to this thread. Please do chip in with other comments though.

3 Likes

This topic was automatically opened after 13 hours.

So, been a very hectic year for me so not really had a chance to come back to this subject. But after a fruitful conversation with Bart, I wanted to at least jot down some notes about securing Node-RED.


To make Node-RED endpoints available over the Internet, there are 3 components we need to think about.

  1. The Node-RED nodes/flows that define web endpoints themselves (in other words, the Node-RED service).
  2. The web server that makes these endpoints available to users.
  3. The certificates and keys that enable the TLS encryption of traffic.

Each of these components need their own security. And each of these components are better treated somewhat independently from a security perspective since that gives us better security in depth.

1) The Node-RED Service

The default installation for Node-RED is not very secure. It is installed in the global root or super-admin context. This gives anyone with access to flows the potential ability to do anything to the device it is running on.

Instead, you should create a new user id specifically for Node-RED. Then install Node-RED in a way that only gives access to that user. This is the same way that other services work. Check out an installation for a web or database server as an example.

Once installed, only give that user access to the services and devices it really needs. You can use the standard OS features to do this.

2) The Web Server

Node-RED has its own, built-in web server (actually it has two). This is provided with the help of ExpressJS.

While you can certainly configure this to be reasonably secure, Node-RED focuses (rightly) on nodes and flows, not security. It is much better to use a separate web server and use that to handle security. This also gives you more security depth because the web server can (and will) now run under a different user id - your Node-RED flows will not be able to make changes to it.

Thankfully, this is pretty easy to set up and there are many tutorials. Choose your favourite web server (my preference is generally NGINX) and configure it as a "reverse proxy". As such, it sits between users and the Node-RED service and acts as an intermediary for all web (and websocket) traffic.

You can use the capabilities of the web server to handle the TLS network encyrption. This provides some security depth and removes some overheads and configuration complexity from Node-RED.

You also need to block access to Node-RED's TCP/IP port (typically 1880) from anywhere except localhost. Then all traffic to/from Node-RED has to come through the proxy. It is possible to configure Node-RED to only listen to localhost requests. Do both if you are of the "belt and braces" mindset. :slight_smile:

3) Certificate & Key management

Sometimes you will see this referred to as "Public Key Infrastructure" (PKI). The key thing to remember about certificate/key management is that:

  • The certificate is PUBLIC
  • The key is PRIVATE

You must never let the key be obtained by anyone else otherwise it is worthless. One of the reasons that Let's Encrypt keeps the validity of their certificates and keys so short is that it limits the damage should your key file be compromised. Many browsers are also starting to reject certificates with long lifespans.

Because the key is so critical, I personally prefer to manage the certificates and keys as a separate process though the Caddy web server has key management built in if you really want to go that way. The other reason for managing them separately is that it gives you much more freedom and flexibility for using things like multi-domain and wildcard certificates should you wish to. Again, though, the main reason is security depth and separation of concerns.

Let's Encrypt have the acme.sh scripts which are easily configured and create CRON scheduled jobs to automatically update your certificates and keys. Again, create a separate user id to run these. Then you can choose where the resulting files are copied to and what security to apply.


By keeping these 3 components separated, you are greatly increasing your security since compromise of 1 service doesn't necessarily mean compromise of the others. Generally, the nature of Node-RED as a code authoring service means that it is likely to have the weakest security - that isn't a failure of Node-RED, simply recognising how it is used. Having the web service and the certificate/key management as separate processes with their own security will give you the best chance at keeping your service safe and secure.

Of course, this is not the only way and there are many other things you can and should do to secure Node-RED over the Internet but these are the basics and for the majority of uses, this should be sufficient.

As always, this information is provided as-is with no guarantee that it is correct. Always get your services checked by a security professional.


One final point to make in these notes. About the use of Docker.

Using Docker to deliver the services above (all or some) is perfectly fine - if you know how to use and manage Docker. Docker containers will generally help with separation of security but that isn't a foregone conclusion. The principles I've outlined should be applied to Docker containers as well with each service separated and seprarately secured.

Certainly, though, the use of containers will generally help keep things separate and compromise in one container will be harder to spread to another.

If you don't know Docker though, you may find that it adds more overheads on both resources and management, than you really want. It certainly adds quite a lot of additional complexity.


While what I've outlined may seem complex, the complexity is in the initial setup. You only have to do that once. Then the maintenance should actually be easier.

Your web server should have been installed using your OS's package manager and so will update with everything else (including databases and node.js) so ensuring that they stay current and secure. acme.sh updates itself as it is run. Node-RED updates using npm under the user you installed it with.

Configuration, after the initial install, is also simpler since you are unlikely to ever need to change the acme.sh script and rarely change your web server configuration. Node-RED however, changes pretty rapidly, including the settings.js file. So keeping that as simple as possible makes life a lot easier.

Hope this helps - comments, as always, welcome.

3 Likes