THIS ARTICLE IS CURRENTLY IN DRAFT - it is still being developed. Please feel free to add constructive comments and corrections below.
I am going to attempt to describe the various options and configurations that you will need to think about in order to secure an instance of Node-RED. This is probably going to be a long article!
Please see my other articles Making Node-RED available over the Internet and Secure Home Automation Controls via a Telegram Bot for other ideas about the security of Node-RED in regard to use over the Internet and how to avoid having to worry about some of the issues dealt with here.
Warning and disclaimer 🔗︎
This is my best view of securing Node-RED. I’ve not been a professional developer in a long time and I am not a professional security analyst (I’m a IT technology and information security manager).
So you must not assume that this article covers every issue. You must also not assume, even if you follow every best practice, that an instance of Node-RED will be “Secure”. It may not be for many reasons.
Get your system and its infrastructure tested to destruction by professionals.
Hopefully though, this article will at least let you see the issues and have a reasonable go at making your instance of Node-RED a little more secure.
A few words and phrases that will be used along with the least technical descriptions that I can come up with.
|Encryption||Changing human readable information into something that requires a special key before it can be understood.|
|Authentication||Providing a secured identifier to a system to prove that the person accessing the system is who they claim to be.|
|Authorisation||Controlling what information a user of a system is allowed to see and what actions they are allowed to take.|
|TLS||A defined protocol for securing connections between systems and applications. In basic use, it provides a minimum level of authentication of a server (via a certificate chain of trust) and facilitates encrypted communications with that server.It also has additional mechanisms that will also provide a minimum level of trust of the client application. However, this is rarely used in Internet web applications.TLS may be used to secure many different application and system interactions, not just between a browser and a server.|
|HTTP(S)||The main web protocol that lets browsers get human readable information from web servers. HTTPS is HTTP secured with TLS (used to also allow a protocol called SSL but that is deprecated as insecure). Ideally, every connection to a server from a browser should be over HTTPS since the use of HTTP allows some pretty bad things to happen.|
The basic architecture of Node-RED 🔗︎
To help us understand what needs to be secured, here is the basic technical architecture of Node-RED. From the outside in. This is only one way to view the architecture of course, I’ve tried to keep things as simple as possible.
Your flows, Dashboard and other pages served by Node-RED
This is the “code” that you (or your users/administrators) have put together.
Node-RED is a general purpose tool and so is capable of creating web pages and various other types of connections such as websockets, TCP/UDP connections and much more.
Anything that is created at this level either must be secured by Node-RED’s settings or by your code.
The Node-RED runtime API
This is the bit of magic that makes everything work. At some point, this will be independent to the administration side but at the moment (~ v0.19) it isn’t.
The Node-RED Administration user interface
This is a web application (web page plus websocket connections) that lets you build your own applications using Node-RED. It uses various 3rd-party libraries to do some of the heavy lifting (D3, JQuery, etc.)
The Node-RED core and contributed nodes
Here is all of the clever custom code, generally tucked out of the way so you don’t need to worry about it.
ExpressJS is a library for NodeJS that does the heavy lifting of providing a web server.
Apart from the hardware, we are now at the bottom of the architecture.
No point in securing everything else unless you have secured things at this level.
In order to secure Node-RED, we have to pay some attention to all of these layers. Thankfully, the guys to created Node-RED have thought about many of the details and made it at least somewhat easier to provide a basic level of security.
Settings that you need to think about 🔗︎
Other considerations 🔗︎
NodeJS and package vulnerabilities 🔗︎
As Node-RED itself needs to have backwards compatibility with older versions of NodeJS, it may be forced to use packages (AKA modules or libraries) that are now out-of-date. Similarly, nodes that you rely on may not get updated as regularly as needed to stay ahead of vulnerabilities.
NodeJS itself is very rapidly changing and unless you are updating it regularly (e.g. weekly) it may also have outstanding vulnerabilities.
To mitigate these issues, you need to:
- Update NodeJS weekly or daily in sensitive installations. You will also want a set of regression tests - test that are run after every update - if you want users to be able to rely on rapid update cycles.
npmitself may have vulnerabilities and may need to be updated out of cycle from NodeJS.
- Regularly run
npm auditon both the location you install Node-RED (global by default) and the location where you install contributed nodes. Update nodes regularly or consider the impact of nodes that have dependencies failing audits. Note that
npm auditis only available on newer versions of npm.