Safely accessing Node-RED over the Internet

FAQs
1

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.

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.

Reference Material

8 Likes
3

This topic was automatically opened after 13 hours.

4

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
5

Following another set of compromised Node-RED servers that were open to the Internet, I realised that there might be some useful advice missing from the above.

There is an additonal level of security that you can apply and indeed, really should, if you need to expose a Node-RED service endpoint (e.g. a web page or API) to the Internet.

That is that you should consider having a separate instance of Node-RED on a non-standard IP port, preferably on a separate server (a Raspberry Pi might be sufficient).

A separate instance would be configured to do as little as possible itself other than handle incoming data from an instance (or MQTT or other disaggregating service) that is not exposed to the Internet and present the required endpoint(s). You could also allow data to cross over to the more secure instance - BUT, make sure that BOTH instances validate any input since ALL input across the Internet (and indeed any user input anyway) MUST be carefully validated before use.

For any static configuration on the Internet-facing instance, ideally you should periodically check against a known good config (you must run the check from something that isn't accessible from the Internet of course).

Using a separate service for this is ideal because it allows you to create physical separation not possible when running on a single server. It also allows you to minimise the attack surface by removing all unnecessary services and locking the device down carefully. Data should never be mastered on the Internet-facing server and configurations should be pushed from a non-Internet facing source so that even if the internet-facing server is compromised, it can fairly safely be reset.

This is an example of a "DMZ" approach (De-Militarised Zone) that is required in all enterprise, commercial and regulated deployments. In the case of a full DMZ, the externally-facing server(s) would have a separate LAN and router/firewall between them and the more secure internal networks. This can be simulated in a low-cost setup by using a VLAN (if your router/switch supports it) or at least using a local server firewall (e.g. IPTABLES, UFW, etc) on the internal server.

6

Install node red on any platform as usual, then install remoteit client and add TCP service to client.
Connect node red via remoteit dashboard.

7

Recently I came across another solution, which is free, secure and solid: Cloudflare zero trust tunnels (you do need a creditcard to register and a domain name). The end result is that you can keep all ports closed on your router and run a cloudflare daemon (or docker container - how it runs here) that establishes a tunnel.

Whatever you present over the tunnel is upgraded to https/tls traffic with valid certs for each endpoint.
You can ssh/smb/etc over the tunnel and cloudflare can even provide a webbased terminal (did not test this yet).

Security can be setup with passwordless auth (ie: via email) or oauth2 (many providers are integrated), yubi key etc. and you can configure that you require multiple (at least one). The setup is quite sophisticated.

I followed this tutorial (youtube).

Works fantastic.

5 Likes
8

Yes, been using that for a while now. It is more complex to set up than some of the other tools but it is flexible and secure. And you get 50 user accounts even on the free tier which is amazing.

Interestingly, Microsoft have also done a deal with Cloudflare to build a "VPN Lite" feature into Microsoft Edge browser. I also use Cloudflare free tiers for handling all my DNS and as a proxy to any web services since that provides additional protection and monitoring.

9

Please edit your answer and add this sentence:
- only Free when: max 1 user & Personal usage !

Took me +5 minutes unnecessarily to realise: min 10$/month/user

1 Like
10

You may add enhancement to the list:

A strong Proxy, which

  • can handle certificate renewal by itself
  • protects the whole PC, allowing ONLY the necessary ports
  • forwards ports (hiding the real service)
  • very easy to install and configure (2 lines in a JSON)
  • completely free and OpenSource
  • very stable & Fast!
  • runs on ALL platforms.

Maybe a BasicAuth over https can be enabled too... ?

11

As for self-managed VPN, I've found this:
https://www.softether.org/

  • Free, FOSS
  • on all platforms can be installed and everything can connect
    etc.

What I like is the very easy GUI management of it and the huge, easy to understand networking manual to it.

1 Like
12

The problem of vpn is you need i fix ip address that mean you need to pay for the fix ip !

13

Can you not use a free domain name provider such as duckdns?

14

Not so. Some types of VPN need a fixed public IP but certainly not all. But in any case, it is generally best to avoid a VPN unless you really know what you are doing. Much better to use a service such as CloudFlare Zero Trust.

15

SoftEther is different.

  • it can penetrate through all kinds of NAT / Firewall, etc.
  • it has a free "IP forwarder network", if you do not have a public IP, not even a dynamic one.
  • it has a very easy graphical interface where you can active a complete lists of graphically well explained features with just 1 Checkbox click.

If you have a public IP (even a daily or hourly changing one) than no FIX IP is needed.

Thanks for the tip ! Since I'm paying ca. 100EUR/y for my DynDns account, I was always asking myself:

  • Is there no free, stable alternative for that?
16

I used to use duckdns and pivpn but that doesn't work since I switched to mobile broadband.

Now I use Zerotier which is much easier to setup and needs no maintenance when my IP changes.
All connections are outgoing so there are no open ports.

1 Like
17

Can you actually change the dns resolver on dyn/duckdns (i mean, the purpose is the dns).

I have tried zerotier/vpn's etc. Problem with all of those is that you cannot access your devices from/via other sources, only the ones you have setup. npm proxy manager with authelia work(ed) nicely, but cloudflare zero trust, is more convenient and easier to setup. One caveat is that cloudflare could theoretically sniff your traffic, but hides your public ip, zerotier is e2e encrypted but does not hide your public ip.

18

Hey @bakman2 - not sure exactly what you are asking ?

What do you mean by change the DNS resolver for DuckDNS ?

When you say you can not access your devices do you mean you must have the client etc installed to access the VPN ?

Craig

19

Hi @PizzaProgram
Thanks for your remark.
indeed it's paid app with few good feature.
Like easy install, launch and remotly configure services with app.
Cloudflare is totaly web based with manual process.
Unlike cloudflare zero trust tunnels; we need to follow few extra scripts. (Cloudflare is wayyy cheaper than remoteit - i agree)
Both are excellent application, user may find what is best for him.
Regards,
Sudarshan

20

I think I should jump in on this. In the EU the FritzBox internet Modems are very popular and it is very easy to set up VPN on FritzBox. It is very secure and a good solution if you want to give private access to your network from outside. Benefit and drawback, everyone with the VPN network keys installed on his/here device has access to your whole network, if you do not implement extra security in your network.

For me that is fine, me, my wife and my daughter have a very secure access to our home from everywhere in the world, we can control our smart home system (Loxone), start video recording and access everything else. For me the most secure and most painless solution - if you know what you do, as always :grinning:

And on iOS it is simple to install VPN on demand, so whenever I access my home network, VPN is startet automatically within seconds.

21

Thanks for the input Max. VPN's are a solution that people often reach for and they certainly work though they can be hard to set up on some hardware.

The major disadvantage of a VPN is, as you mention, the fact that each remote device has access to your home network. That means that the network becomes only as secure as the weakest device security. This is especially problematic in certain countries where abuse of networks and even of devices (e.g. left in hotel rooms or passing through borders) is endemic. This is not a theoretical risk, I've seen examples in the real-world (hint: even before the war with Ukraine, I would never have left any device unattended in a Moscow hotel room. Certainly never leave devices on standby in hotel rooms, always turn them off completely).

Anyway, yes, VPN's can be a good choice if your router is easy to set up. But just be aware of the security risks.

I still like the idea of having a not always on solution that I can turn on remotely via a different channel such as Telegram and then turn off again when not needed. This can, of course, work with a number of the solutions outlined though it may be somewhat harder to be able to make a dynamic change to a router's VPN service than it would be to stop/start a server service such as Cloudflare Zero Trust, NGROK, etc. Those services can also be restricted to specific servers and so could fairly easily be ring-fenced from the rest of your home network. Whether it is worth the trouble is, of course, only something that each individual can decide.