I created this repository to share my insights on setting up (free) security for a Node-RED system, more particular based on Tailscale.
After a lot of Node-RED systems had been hacked in 2023-2024, I decided to improve my own Node-RED security setup. I especially wanted to get rid of my old port-forwarding setup, since most of the hacked Node-RED systems had a similar setup like mine. We will discuss further on why port-forwarding should be avoided!
This tutorial only teaches you the basics of Tailscale. Afterwards I recommend you to have a look at the Tailscale documentation (see here) for more details. They also offer some video tutorials on YouTube.
Please read the disclaimer at the bottom of this readme page, before you get started!
Thanks to Julian Knight who devoted a part of his life helping users to keep their Node-RED systems secure. He teached me a lot about security, and was so kind to review this tutorial! Have a look at his website which contains lots of useful articles.
Pull-requests are very welcome, to help improving the information in this tutorial. That is the only way we can help each other to improve our Node-RED security. See the contributing guide how to make changes yourself.
Issues can be used e.g. to mention if a part of the documentation is not correct or incomplete. But when you have a Tailscale issue with your setup, post it directly in the Tailscale repo or create a discussion in the Node-RED Discourse forum (where you can mention me to get my attention). But DON'T post such issues in this repo, because I don't have the time to troubleshoot individual use cases!!!
Obviously when you would use Node-RED only offline, you could minimize the risk of malicious users accessing your system. However there are a number of nice use cases, that will only work by connecting Node-RED to the internet:
- View the Node-RED dashboard remotely, to keep an eye on your house while not being at home.
- Pass speech commands to a Google Home device, which will send them (via the Google Action servers) to the endpoint of the node-red-contrib-google-smarthome node.
- And so on...
The following articles provice technical details about some of the terminology used in this repository. It is NOT required to read this, because it is rather heavy technical information. But it will give you some background information about how stuff works behind the scenes.
- Basics of https: explains why you need a private key and public key for https (see here).
- Basics of (LetsEncrypt) certificates: explains why you need to create a (LetsEncrypt) certificate from your public key (see here).
To setup a secure network connection to your Node-RED system (flow editor, dashboard, local endpoints, ...) from the internet, it is higly advised to use a trusted third-party networking service. Such a service is used between Node-RED and the internet, to handle all the complex security stuff:
You could also prefer to install your own reverse-proxy software locally to achieve a similar result, but that has some disadvantages:
- Setup a reverse-proxy (e.g. Caddy, Nginx, ...) is quite complex.
- Maintaining your setup continiously is a must (e.g. install security patches as soon as vulnerabilities are being reported).
- Setup of access control is a must, to reduce the number of devices that can access your system.
- And so on ...
Such a reverse-proxy setup would become a tough nut to crack for a lot of Node-RED users. Let the security experts from the third-party service do their job, while you have have time to do fun stuff with Node-RED meanwhile ;-)
I had a look at several third-party services, but at the end I decided that Tailscale was the best solution for my use case. You can look here for a comparison of Tailscale with some other services.
Tailscale allows you to create a virtual private network (VPN) between all your devices, as long as you have a Tailscale agent installed on all those devices. In contradiction to a normal VPN, Tailscale offers a peer-to-peer mesh network which is called a tailnet. In other words instead of transferring all the data through a central server cluster (like most VPN services do), the data is communicated directly between devices in your tailnet. Such direct connections between your devices offer multiple advantages:
- The data can be exchanged very fast via such connections.
- There are no traffic volume limitations, which is useful when transferring lots of data (e.g. video footage from IP cameras). Only for public funnels, there is a traffic limitation.
- The tailnet will continue working, even when the Tailscale servers would become temporarily unaccessible. Except if you use their relay or funnel service.
When you want to access your Node-RED dashboard (running on a Raspberry Pi) from your smartphone, you need to install a Tailscale agent both on your Raspberry Pi and your smartphone. Once you have added both devices (i.e. Tailscale agents) in your Tailscale account, they become part of your own tailnet. As a result both devices can communicate directly to each other via their Tailscale agents. This means you can navigate with your smartphone browser to the (virtual!) hostname of your Raspberry Pi, to see your Node-RED dashboard:
You can read here why port forwarding should be avoided, and how Tailscale can work without port forwarding.
This tutorial describes in detail how to get started with Tailscale. The information is split into separate pages, to keep this readme compact and readable.
- Optionally you might read about the Tailscale relay servers. These servers will be used to connect two Tailscale agents, in case a direct connections cannot be setup: see here.
- Optionally you might read about the Tailscale control servers, which distribute your tailnet information from your account to all your Tailscale agents: see here.
- Setup your own tailnet, by creating a Tailscale account, and install a Tailscale agent on ALL your devices (which need to be added to your tailnet): see here.
- Specify a (virtual) logical hostname for each device within your tailnet (both for easy access and https), i.e. setup DNS in your tailnet: see here.
- Configure Node-RED to allow it to be accessed from the tailnet, using plain http connections within your tailnet: see here.
- Optionally you might read about how reverse proxies work, to understand better the sub-path routing that we are going to use: see here.
- Serve Node-RED as a local service via https, based on LetsEncrypt certificates: see here.
- Setup a public tunnel (called funnel) to allow third-party services to access Node-RED, for example for Google Assistant: see here.
- Make some other local services available within your tailnet, to make sure you can access them even when you are not at home: see here.
- Finally specify which devices are allowed to communicate with each other (within your tailnet), using Access Control Lists (ACL): see here.
There is a lot of stuff involved, so troubleshooting isn't always easy. I have created a list of tips from my own experience: see here.
Tailscale offers some other nice stuff, not directly related to Node-RED. But might be interesting anyway:
- Get access to your Synology NAS even when you are not at home (see their tutorial). Please note that their youtube video contains some extra stuff (e.g. to select their LetsEncrypt certificate in the NAS), which is not described in the text below the video. After you have setup this, you can:
- Access the web interface of your NAS via
https:\\<your_virtual_nas_device>.<your_tailnet>.ts.net - Explore the NAS filesystem in your favorite file explorer software via
\\<your_virtual_nas_device>.<your_tailnet>.ts.net\DATA.
- Access the web interface of your NAS via
It is important to note that while I try to strive for accuracy, I’m not an expert in this field. The information provided in this repository is intended to be a helpful guide, but it’s not exhaustive or infallible. While this information can enhance your system’s security, there is no guarantee for complete protection against all potential threats.
It’s also worth noting that this documentation is public, and could be read by anyone, including potential hackers. This means that there’s no “security by obscurity” - the security measures outlined here are based on their inherent strength, not their secrecy.
Please be aware that I cannot be held responsible in any way if your system is compromised. This holds true even if the information I’ve shared is incomplete or incorrect. Implementing security measures and maintaining the security of your system is a complex task that ultimately lies with you.