Better security by default

[knolleary]

A default install/configuration of Node-RED does not have security applied. This allows a user to get started with very little friction.

However it does result in too many insecure Node-RED instances being exposed on the internet.

We have had a number of attempts to look at this topic in the past, but none have resulted in action. We need some focussed activity to come up with an approach (or collection of approaches) that will satisfy the wide range of requirements.

We have to consider the range of usage scenarios for Node-RED and how any change in approach will impact them.

1. Raspberry Pi installed using our install script
2. Local manual install via npm
3. Docker - either official or custom image
4. Node-RED running behind a proxy that handles security (meaning NR doesn't have adminAuth set, but can be considered secure)
5. Node-RED running with adminAuth already configured
6. Embedded Node-RED which its settings passed in via code - so there is no settings.js file to look at

Some other things to consider:

1. settings.js is a JavaScript file, not a JSON file - so programmatically editing it is hard to do safely.
2. When embedded, the settings are passed in to Node-RED - there is no file to edit
3. Doing anything in the editor is potentially too late as Node-RED has to be running in order to serve it up. It also gets complicated in the embedded/hosted scenarios where security is applied outside/around Node-RED and nothing further is needed - so would be inappropriate to prompt the user to do anything.

Proposal

1. In Node-RED 4.0, we will refuse to run if adminAuth has not been set to something.

A user must either setup security, or explicitly acknowledge they do not want security by setting adminAuth to false.

This will only apply when running with a settings file - not in embedded mode where settings are passed in programmatically.

But to get to that point, we need to take action now:

1. In Node-RED 2.x/3.x
   1. if adminAuth is undefined, log a clear warning that security is not enabled. Include links to docs on setting up security. Include a warning about Node-RED 4.0 will require adminAuth to be configured to either enable or disable security.
   2. if adminAuth is false, log a warning that security is not enabled. But take false this to indicate an explicit choice to do so.
2. In Node-RED 4.0, refuse to start if adminAuth is not set - ie undefined

2. Add command to node-red admin to do more to help setup security

Right now, node-red admin can be used to generate a password hash, but the user still needs to update their settings file.

The challenge has always been that the settings file is a javascript file rather than JSON - so harder to parse and dynamically edit. Harder - but not impossible.

We should do the work to see if we can edit the file programmatically to setup adminAuth for the user.

3. Update Pi install script to prompt the user to setup security

This probably represents the largest population of regular users - especially those that may not have the depth of knowledge around securing systems. It is also where we have the most opportunity to intervene before Node-RED is run - by adding things to the install script.

• Update install script to provide a clear message around security. Done via node-red/linux-installers@033358d
• Add node-red admin init to the install script if the settings file doesn't exist. This will walk the user through configuring the system, including setting up basic admin auth.

[dceejay]

When we get to v4 - we will need a way for a scripted install to configure the admin in a valid way - either pass in user and password or set false - should this be as params to admin init ?

[dceejay]

The script now prompts the user to run admin init if the settings file does not exist. (but they can say no of course, and there is a 60s timeout, default No). Also added a --no-init command line flag that skips that for automated installs.

[jdotbdot]

In the install script, should "Allow Function nodes to load external modules" default to No?

Also in the install script
"sudo chown root:root ~/.node-red/settings.js" should be
sudo chown 0:0 ~/.node-red/settings.js" since superuser is not inevitably "root"

I'm conflicted over removing /etc/sudoers.d/010_pi-nopasswd.
System admin tasks generally need sudo; it's a shame to prevent Node-red from performing these tasks.
Simple examples from my Pi include 1) exec sudo reboot and 2) a script which calls sudo fdisk -l and sudo arp-scan to report system status.

[jdotbdot]

Well the command is in the script but commented out. I thought that might be indicative of future plans.

Incidentally the sudoers file is not /etc/sudoers.d/010_pi-nopasswd but /etc/sudoers.d/010_$USER-nopasswd since RPiOS can now be set up with a different user name. (One of their security tweeks). (at least I guess the 010_ bit remains the same with a different user)

[dceejay]

ah yeah - no - was thinking of forcing - but no - just forgot to remove that comment...
and $USER ? really - will double check that and update if necessary. Thanks

[jdotbdot]

Actually it should probably be $NODERED_USER since the script has a --nodered-user argument. Sorry, only just noticed that!

[dceejay]

Hmm - just built a new pi with default user fred.... the file is still called 010_pi-nopasswd - so I will leave it as-is.

[jdotbdot]

Gosh, so it is. My apologies for the wild goose chase.

[jdotbdot]

"The challenge has always been that the settings file is a javascript file rather than JSON - so harder to parse and dynamically edit.
We should do the work to see if we can edit the file programmatically to setup adminAuth for the user."

This isn't difficult. Will the unedited settings.js contain commented out adminAuth lines as now, or the uncommented lines (so only the hash has to change)?
In other words, will there be an option to not set up adminAuth?

[jdotbdot]

A snippet of bash to insert adminAuth section to settings.js

FILE=~/.node-red/settings.js

# In real script prompt user for password, hash it, put in $PASSWORDHASH
PASSWORDHASH='$2b$08$byDZ0u7lgK3lguZBFADoheMZRWdVstXxWN0soH5DeeTpx5XY5MrnS'  # NB contains $ - use single quotes

enableauth()
{
   awk -v HASH=${PASSWORDHASH} '{print}  # print every line except the commented out adminAuth section
   /\/\/adminAuth:/ {
      while(getline nl > 0 && (nl!~/\/\/\},/ )){ print nl }  # Print the commented out stuff
      print nl                                                                 # print the last line //},
      print "//------  added by script  ------"              # Then print the uncommented version
      print "    adminAuth: {"
      print "        type: \"credentials\","
      print "        users: [{"
      print "            username: \"admin\","
      print "            password: \""HASH"\","
      print "            permissions: \"*\""
      print "        }]"
      print "    },"
      print "//-------------------------------"
   }' $FILE > $FILE.tmp
}

if grep "^\s*adminAuth"  $FILE >/dev/null                   # Changed \s+ to \s* to find zero or more leading whitespace
then
   echo $FILE aleady has adminAuth. Not changed.
else
   cp $FILE $FILE.bak     # leave a backup copy
   enableauth
   mv $FILE.tmp $FILE   # no sanity checking
fi

[dceejay]

The node-red admin init will do that for you, if you want to do it interactively.

[TotallyInformation]

Will the unedited settings.js contain commented out adminAuth lines as now, or the uncommented lines (so only the hash has to change)?

I think that Nick/Dave indicated that it will always be present and this is, I think, best.

It would be good if the node-red log and the Editor itself provided warnings that it wasn't present, was invalid or was set to false?

[tve]

I do believe the suggestion made in the forum to refuse connections from the internet is a good one. The algorithm I would use:

• if the source IP of the connection is not RFC1918 and does not belong to the subnet of one of the host's interfaces then reject it
• if X-Forwarded-For is there, use that as source address (std header used by reverse proxies, e.g. nginx, caddy, ...)
• provide a setting to override the blockage, the setting could be a list of CIDR ranges to allow, 0.0.0.0/0 would allow all

Notes:

• Using port forwarding should only NAT the destination address, not the source.
• Running in docker will prevent enumeration of the host's interfaces, if RFC1918 is used then that's not an issue, otherwise the setting has to be used to tell the docker container what the local addresses are
• There is also X-Forwarded-Proto which would tell whether HTTPS is used, that could also factor in, e.g. could allow internet connections if HTTPS and adminAuth set

In addition, Caddy supports HTTPS with Let's Encrypt by default, you don't have to do or configure anything. Could provide a simple sample config for that. Main issue here is that it requires some form of DynamicDNS for most people. Maybe there's an NPM package that does Let's Encrypt, that could be possibly pulled into NR.

[TotallyInformation]

• if the source IP of the connection is not RFC1918 and does not belong to the subnet of one of the host's interfaces then reject it

No, I disagree with that. At least it would have to be optional. There are far too many possible network configurations to consider that. There are plenty of configurations where specific node-red instances might want to handle routable addresses.

• if X-Forwarded-For is there, use that as source address (std header used by reverse proxies, e.g. nginx, caddy, ...)

That is OK though you need to make sure that multiple (nested) proxy configurations are also handled.

• There is also X-Forwarded-Proto which would tell whether HTTPS is used, that could also factor in, e.g. could allow internet connections if HTTPS and adminAuth set

Again, there are perfectly valid situations where https would not be wanted or where it is handled elsewhere without the ability to pass on the source protocol (though that is certainly best practice).

Caddy supports HTTPS with Let's Encrypt by default, you don't have to do or configure anything. Could provide a simple sample config for that.

I completely agree that providing a set of secure by default configurations for NGINX and Caddy as a minimum would be a very good idea.

Some rework of the security FAQ and merging with some of the other security documentation to create a new security docs section would be sensible. It would also be sensible to have that section as a different repo to make it easier to update and contribute to.

Maybe there's an NPM package that does Let's Encrypt, that could be possibly pulled into NR.

Personally, I would advise against doing that. Setting up LE isn't hard but screwing up certificate-based security is easy. Leave it to the tried and trusted native tools. The acme.sh script is pretty trivial to set up and very low overhead. However, LE does require either an exposed port 80 or a txt entry adding to your DNS. So step-by-step documentation is important.

If someone does want to go down a node-red node route for supporting OS configuration changes such as LE or NGINX, it is critical that we tell people that it needs to ONLY be done on a SEPARATE INSTANCE of node-red that is carefully secured.

[jdotbdot]

• if the source IP of the connection is not RFC1918 and does not belong to the subnet of one of the host's interfaces then reject it

No, I disagree with that. At least it would have to be optional. There are far too many possible network configurations to consider that. There are plenty of configurations where specific node-red instances might want to handle routable addresses.

• if X-Forwarded-For is there, use that as source address (std header used by reverse proxies, e.g. nginx, caddy, ...)

That is OK though you need to make sure that multiple (nested) proxy configurations are also handled.

I suspect that anyone who has multiple nested proxy configurations (or even knows what it means), or has a complex network setup, will not limit their system to whatever basic security NR provides.

[tve]

• if the source IP of the connection is not RFC1918 and does not belong to the subnet of one of the host's interfaces then reject it

No, I disagree with that. At least it would have to be optional. There are far too many possible network configurations to consider that. There are plenty of configurations where specific node-red instances might want to handle routable addresses.

Did you actually read what I wrote? "provide a setting to override the blockage"...

• if X-Forwarded-For is there, use that as source address (std header used by reverse proxies, e.g. nginx, caddy, ...)

That is OK though you need to make sure that multiple (nested) proxy configurations are also handled.

That's std.
I think you're throwing out the baby with the bathwater. What I'm suggesting is to make node-red not respond to connections over the internet unless the user has configured it to do so. Same thing that basically all web development servers do (they all listen on localhost instead of 0.0.0.0 by default). The advantage of this over forcing a password to be set is that I bet most passwords will be either 'test' or 'nodered'...
Maybe the most useful thing would be to (1) force the user to change a setting to enable remote access coupled with (b) ensure the user reads a warning "if your node-red server is exposed to the internet then it will be attacked, even if you think it has nothing valuable".

[TotallyInformation]

I suspect that anyone who has multiple nested proxy configurations (or even knows what it means), or has a complex network setup, will not limit their system to whatever basic security NR provides.

This is why this stuff is hard to get right. We see lots of people in the forums who have very limited knowledge of their network setup. We cannot really make many assumptions about a users environment. We need to be cautious about not blocking use of Node-RED by making unwarranted assumptions.

[TotallyInformation]

settings.js is a JavaScript file, not a JSON file - so programmatically editing it is hard to do safely.

One change I made in my own config is to move the export and use a javascript variable then export that. While this is a tiny change, it does help people understand that the export is different from the settings object. It helps me at least, think about how to make changes and see more clearly if a mistake has been made.

It might also help if trying to change it programatically?

[TotallyInformation]

Forgot to say, I think that the install script creates a new nodered user and group and uses that in the systemd script? If it doesn't, that would be one of the best changes that could be made.

The security docs should also say that node-red should always be run under its own user/group unless you only want to use it as a desktop app.

We should also make sure that people know about how to add the node-red user/group to the appropriate groups for accessing hardware such as serial/usb ports - too often we see people running node-red as root just to get access.

And, as mentioned to TVE above, we should include some information about using a separate, secured instance of Node-RED for doing things that need to be more highly secured.

[dceejay]

sorry - you think wrong... we don't setup a new user and group. While I understand it may be more optimal it would start to cause issues re docs, as we don't do that for other platforms (eg Windows) and so on - and it would "break" existing users understanding of where files are to edit etc - and so we would need docs per platform, and maintenance thereof, and endless answers on the forum...

[TotallyInformation]

OK, but the script is specific to Linux and from a security perspective - if you are installing as a service - a new user and group should certainly be set up. That is my recommendation for an immediate boost in security for that configuration.

Obviously, users can also use Node-RED as a "desktop" style local install and in that case, the current approach is probably the best one.

[jdotbdot]

A new user and group is sensible, but where would it be installed to? /home/nodered/.node-red implies an ID you can login with?
The user id probably needs write permission for /home/pi anyway - media libraries etc.
So I'm not sure this simplifies the security issue.

I see that an exec "touch foo" makes the file -rw-r--r-- 1 pi pi 0 Oct 28 12:47 /home/pi/foo
If Node-red runs via Nginx or other proper web server does exec still run as pi?

[TotallyInformation]

Going to be doing some work with Bart around looking at NGINX configs. I already have a baseline for my own use, we are going to do something for him and possibly will then use that to look at how we might get a tool that could be used to create a parameterised set of configs. Not sure how feasible that is but worth a try.

There is also some security documentation in the uibuilder tech docs and I'm more than happy for any of that to be reused.

Bart has also started a useful diagram that we will work on and hopefully will be a useful addition to the docs at some point.

[TotallyInformation]

• Add node-red admin init to the install script if the settings file doesn't exist. This will walk the user through configuring the system, including setting up basic admin auth.

Nice one. 👍

[TotallyInformation]

I would like to add a word of caution here. I know that I often drone on about node-red security. However, I would caution against trying to get Node-RED to take on too much of the security responsibilities itself.

With the best will in the world, the more we force into Node-RED, the more people will assume that Node-RED will handle all cases. I don't believe this is sensible and it potentially takes away development resources from other areas. There are plenty of tools around to provide good security and they have been battle-tested over time.

Having said that, I think the core suggestions are sensible and useful.

[dougle03]

However, I would caution against trying to get Node-RED to take on too much of the security responsibilities itself.

I agree, but NR for the most part is aimed at code-less users, thus asking them to delve into a .js file might be a bit of stretch also, especially from the command line.
Adding some default security to NR from the get go for the most basic of user (RPi script users), by asking them questions during the script process, then storing those answers in a JSON file next to the settings.js so it can be parsed during setup/startup; especially with JSON being easier to dynamically & programatically create/edit on the fly. (Noting Nick's declared difficulties doing this to a .js file format.). And perhaps even adding in credential updating from the UI would also then be possible?
If NR is to continue to aim at coding novices (Me included), then getting basic security into place on installation must surely be a top priority, if not only to protect the users system, but to protect the reputation of NR itself on the wider security stage?
I'm honestly surprised NR has not attracted more attention from a negative security perspective before now, especially given the competence of the average user, and their aspirations to front a system that's unsafe by default onto the wan.
Is this recent rash of hacks the result of recent changes or just the hacking community learning a new vector...?

[TotallyInformation]

I agree, but NR for the most part is aimed at code-less users, thus asking them to delve into a .js file might be a bit of stretch also, especially from the command line.

Indeed, which is why, I think, there has been limited change over a long time in terms of security. It isn't easy to find the right balance. And there are so many possible user-journeys in regards to security.

Adding some default security to NR from the get go for the most basic of user (RPi script users), by asking them questions during the script process, then storing those answers in a JSON file next to the settings.js so it can be parsed during setup/startup; especially with JSON being easier to dynamically & programatically create/edit on the fly. (Noting Nick's declared difficulties doing this to a .js file format.).

And that is something I agree with - see my comments on "The Script".

If NR is to continue to aim at coding novices (Me included), then getting basic security into place on installation must surely be a top priority, if not only to protect the users system, but to protect the reputation of NR itself on the wider security stage?
I'm honestly surprised NR has not attracted more attention from a negative security perspective before now, especially given the competence of the average user, and their aspirations to front a system that's unsafe by default onto the wan.

You'll not get any argument from me - since I'm often the one in the forum reminding people to sort out their security 😁 Especially people who are clearly using Node-RED in a professional setting. One of the downsides of node-red (not its fault at all of course) is that people use it to try and overcome or work around perceived or actual limitations in their enterprise IT. This is something that is close to heart in my professional work. Analysts, data scientists, etc are people with certain skills in information management but who may be missing skills in networking and particularly security. Therefore, they do not necessarily appreciate why a network is configured how it is. The perils of "citizen programming".

Is this recent rash of hacks the result of recent changes or just the hacking community learning a new vector...?

We have only been made aware in the forum of one other targeted attack. I suspect that it is one person each time who "discovers" Node-RED and realises what it can do and how it is likely configured and used by people inexperienced with cyber security.

[tve]

       echo " ### WARNING ###"
       echo " DO NOT EXPOSE NODE-RED TO THE OPEN INTERNET WITHOUT SECURING IT FIRST"

Two of the themes I noticed in the forum thread are:

• "It doesn't have anything valuable, why would someone try to hack into it?"
• "It's just an rPi doing nothing important" : not thinking about the implications of getting a foothold in the LAN

I would add something like "Even if your Node-RED doesn't have anything valuable, (automated) attacks will happen and could provide a foothold in your local network".

[TotallyInformation]

Agree totally. And something about it providing an avenue for hackers to attack others.

[dougle03]

1. settings.js is a JavaScript file, not a JSON file - so programmatically editing it is hard to do safely.

How about adding a JSON file to handle script/ui based inputs, rather than trying to edit settings.js programmatically. AdminAuth could remain in settings, but depending on the attribute determine if the additional JSON file is needed.

[jdotbdot]

I can't see the difference between editing settings.js and editing some other json file (somethingelse.js?)

[knolleary]

@jdotbdot you can load a JSON file, parse it to a JavaScript object, change the values then write it back out as JSON.
You cannot do that so easily with a JavaScript file. That is just how it is.

[jdotbdot]

Load, parse. change, write ... Using Javascript? I can't comment because it's not my language.
However the installation script is a Bash script and I posted above a Bash function to edit settings.js. Maybe I'm missing something.

[knolleary]

The install script benefits from starting with a well-known settings file that can be treated as plain text and simple substitutions done. That is not the hard scenario. I'm looking at this with a wider context - providing a node-red admin command that can be used to setup/modify security options. So the settings.js file may not be the one from our installer, it may have been hand edited etc etc.

[dougle03]

2. When embedded, the settings are passed in to Node-RED - there is no file to edit

Would it be fair to assume users that are 'embedding' are more technically capable, and thus perhaps are not so much of a risk to security unlike novice users, who typically install via the script or Docker...?

[jdotbdot]

Although improved Node-red security in general is desirable, shouldn't that be combined with future developments to make it multi-user?

I think, at the moment, we are only trying to make the installation safer for novices, probably installing on an RPi with the script.
Anyone who installs by another method (Docker, Home Assistant, Windows, etc) can't expect the benefits offered by the "official" script.

[knolleary]

@dougle03 correct. Which is why the proposed changes are far more focused on the other types of user.