Node-Red Security

General
1

Hi,

Have read a lot here about NR and security issues when deploying in the cloud. Have read that it is good to go and also that don't do it as commercially you are going to get issues.

The security of NR in the cloud will determine if I continue to use it on this project, along with other questions I have over scalability with the single thread capabilities that could restrict scaling, could end up with ten's if not more messages a second when scaled.

I have NR on a Pi to collect data from lots of local nodes, the hub then sends data to the cloud via MQTT. I then have NR on a cloud server that services a MySQL database, access to any data is being done via a web app, so NR is a discrete service, not using dashboards or any real direct access to NR for the user.

Does this make it easier to secure, or should I be looking elsewhere or be looking at something like Stackhero, Elestio or FlowFuse?

WDL

2

I'm in the middle of writing an article about securing node-red on a pi, probably won't publish it...

The key points are:

By default the Pi user account has superuser powers.

Node-red by default gives you the same powers without a password.

Minimum precautions

  1. Do not create the default username "pi"
  2. Do not permit access to the NR editor from the Internet (ie port forwarding) - there are of course ways to do this safely.
  3. Set up adminAuth in settings.js to require a login for the editor.
  4. Encrypt your credentials file. (3 & 4 are options at the end of the installation script)
  5. Make the settings file immutable by sudo chmod +i settings.js sudo chattr +i settings.js
  6. Disallow passwordless use of sudo for the NR user. (Or restrict it to specified commands)

It's also possible to make your flows file immutable, which makes your Node-red installation effectively read-only. Obviously only for production, not development!

Edit: Deleted editor login recommendation. Without HTTPS (not straightforward!) the username and password are easily captured from network traffic.
Edit 2: Corrected command to protect settings.js

3

If we said pretty please would you publish your paper?

1 Like
4

Trouble is it's a complicated topic and there are strong divergent opinions about it.

Also I have no knowledge of Node-red on other platforms, I can't make suggestions for eg NR on Windows

5

Opinions are like, never mind. I run on pi and am hugely interested.

6

Pretty please with a cherry on top :slightly_smiling_face:

7

It's a work in progress - I already edited the suggestions above.

8

Might be worth putting up on a GitHub repo - you may get some busybodies chipping in with some suggestions. :wink:

Question - is this going to be a commercial service? Again, this can make a big difference. Also, how sensitive will the service be? Will it control critical hardware or manage sensitive or valuable data?

Without this information, we can't really give any useful guidance.

And please note, any feedback you get here is NOT PROFESSIONAL ADVICE. If in doubt, always get professional input.

Scalability is itself a slippery subject. There are many ways to scale systems like Node-RED. But 10's of messages per second would be generally trivial even on a Pi Zero. But we have to make many assumptions as we don't have a lot to go on here. Plenty has previously been written in this forum about performance and scalability though.

The mostly single-threaded nature of Node.js is actually rarely an issue to be honest. Node handles that very well indeed. On a Pi, you would be far more likely to run out of memory or CPU or I/O throughput long before you hit issues with only a single thread.

So your cloud Node-RED server is separate to the MySQL DB server? If not, you could separate them if you found that your NR hub was struggling. Also, you could both vertically and horizontally scale your NR hub if needed. Vertical scaling simply being make the virtual server bigger. Horizontal being run up multiple NR servers and group inputs to balance each instance.

The 1st 2 seem general cloud services so not sure how much that helps you other than letting someone else do some of the configuration of your server for you.

FlowFuse is different in that it is a dedicated Node-RED service. In theory, this should make your instance easier to manage and possibly more secure if you lack the knowledge in-house. I can't really comment on scalability though as I don't have enough experience with it.

Your brief description of your central hub is a common approach and generally a reasonable architecture. It certainly is a well trodden path that gives you access to the tools that could let you secure everything.

Regardless though, if you are running a commercial service - hopefully with defined SLA's - that has some value, you should at least get your end-to-end service security tested. It is commercially dangerous to believe that you or your team have the skills to ensure decent levels of security (unless you have certified security professionals working for you of course :slight_smile: ).

9

Hi TotallyInformation,

Will provide a little more information on the infrastructure of the project, will hopefully make more sense.

Have developed a bespoke RF communication stack, have created Nodes that will sit inside lights, wall switches, temp. sensors etc. and a modified Node that will either plug into the GPIO port on a Pi or into a USB port on a PC enabling two way serial communication via serial port over the RF network.

Local Mode
The Pi, has Node Red controlling the data in and out of the serial port, processes the data and maintains a MySQL database locally. It also has a web app running on it so you can login to the app run reports and push data out to the network either manually or via scheduled tasks.

The PC can be used in the same way, but is more designed for sites where you have several Pi's, as they could be spread across different buildings or on separate floors. In this case the PC will sync all the Pi databases onto a single database on the PC giving you a single pane to view all Node data across the site.

Cloud Mode
Node Red on the Pi has a switch, when activated will then maintain the data in the same way as above, but also send and receive data packets via MQTT to a Node Red flow on a cloud server, that also has a MySQL database and web app that allows remote login to view and run reports for several sites that a customer has deployed. So giving a digital twin in the nodes, on the Pi DB and cloud DB.

This way the customer has the option to run the solution on site or via the cloud for remote access and control. There could be thousands of Nodes on a site being controlled by many Pi's, it is only the Pi's that communicate to the cloud via the MQTT if set to this mode, and the customer could have many sites in different locations.

It is a commercial service is the respect that we will be providing it to customers, but it is being used as a mechanism to sell physical product, we will not be looking to charge for access to the data or web services, but may want to charge for additional services at some point in the future.

The data is not sensitive, will contain data points such as temperature history across the site, how long lights have been turned on etc. BUT, the ability to change settings in the Nodes remotely has been built in, so via the web app you could send a message to a Pi that would change how long a light stays on after presence was detected, or turn all the lights off in a group or across the whole site.

This is where the vulnerability is, am sure a customer would not be too pleased if someone started turning their lights on and off for fun. We can recover from this, if you pull the power to the Pi's, reset the Nodes they will work with retained settings as a copy of the setup is kept on net, so can run effectively run headless, would just lose data logging to the cloud until service was restored.

At the moment Node Red, web app and database is sitting on the same cloud server (have set up an Azure pay as you go server to play with) but they could sit on separate ones.

I have been writing software for many many years, but has all been PC based like CAD software etc. have little to no web based security knowledge so learning as I go along on this part, but am not naĂŻve enough to think that we do this without professional help, will be seeking the services of a good penetration tester :slightly_smiling_face:

10

Well my suggestions in this thread relate to Node-red on a home network.

Some of the suggestions might also be relevant to your product but securing a distributed system is much more complex.

11

This thread has some great ideas for securing Node-RED: HTTPS, reverse proxies, and token-based authentication are all strong approaches.

I wanted to expand upon the FlowFuse option, especially since you’re exploring ways to protect the editor and endpoints. It offers team-based access control to restrict who can edit or deploy flows, and it includes automatic HTTPS (via Let’s Encrypt) to secure connections without manual setup. It also manages environment variables securely, keeping sensitive data out of flows, and supports SSO for integrating with existing identity providers.

For those handling multiple Node-RED instances, FlowFuse provides a centralized way to monitor and secure them, which could be useful as your setup scales. It’s not meant to replace the great DIY solutions shared here, but it might simplify some of the heavy lifting.

For context I work for FlowFuse and would be happy to answer questions if you have them!

1 Like
12

Hmm, a lot to unpack there. And a reminder that we are not a free consultancy here. :wink:

I will reluctantly forego commenting about the wisdom, or otherwise, of creating bespoke comms stacks when so many good ones already exist.

We will have to disagree on that assessment I'm afraid. Though bear in mind that I'm professionally involved with tech and digital government and health services. Certainly we would most certainly consider at least some of that data sensitive in many scenarios. You should at least clearly inform your potential and actual customers about the risks.

There are risks that bad actors could tell whether there is anyone in the building. Or a bad actor could force the lights on, costing money. If heating or access control is involved, that would then certainly have to be treated as sensitive data as well.

I doubt I would have used MySQL for that. Certainly if trying to use a Pi. Not knowing the data you want to store, it is hard to be definitive about what might be best though. Postgres would probably be better as it has more flexibility, including timeseries data stores which are often more suited to IoT data.

What if I were a customer looking to implement on hundreds of sites with 10's of thousands of nodes? Seems like a commercial risk to me not to charge for the cloud service which is certainly going to cost you ongoing revenue costs. Those costs could get quite hefty. Especially if you need to set up separate cloud instances for each customer.

Indeed. Though actually, a more common scenario typically comes from accidental errors. Also, while lighting controls would cost an org some money if left on when they should be off (which could be considerable in some buildings). If you later extend the system to other controls, then things could get a LOT more serious.

You should get professional advice about both the Azure architecture AND the security. Azure, AWS, etc. It is very easy for cloud costs to get out of hand if you aren't careful. The security architecture, as also intimated, could be quite critical depending on your customers, their locality and local laws and what kind of data and controls will be involved.

Just to note that there are standards for vendors of security testing, best to look those up and make sure you get a vendor who is certified and can provide certified tests.