Securing the settings.js file

I've recently realized that (correct me if I'm wrong) anyone with access to the device hosting Node-RED can add a new user account, with full admin privileges, without even needing to know the host device's password assuming it's already online and logged in which it would have to be to be hosting Node-RED.

I can just run node-red admin hash-pw and do a quick nano ~/.node-red/settings.js (no sudo required?!?) and paste it in as a second user, and be on my way.

Is there any way of limiting this sort of access? Yes it is unlikely, but not impossible, and in the environment I am deploying this system in, that is potentially a very bad security hole.

Anyone with physical access to the device, able to walk up to it and start typing in a shell without any challenge will be able to do pretty much anything - Node-RED would be the least of your concerns.

At a minimum you should:

  1. run Node-RED as a dedicated, non-root, user
  2. ensure the file permissions are correctly set so only that user can edit the settings file
  3. ensure that account is properly secured - someone shouldn't be able to walk up to the device and start typing in commands!

That won't address every possible route to securing an unattended device - but its the bare minimum to consider.

Of course. And all of these are addressed. However, given that the settings.js file stored in /usr/lib/node_modules/node-red/settings.js is not writable, at least not without sudo access, it would seem appropriate to also secure the settings.js file that node-red-start actually uses to configure itself on start up with the same sudo access requirement. I'm not saying that is possible to implement right now, but it feels like a security hole. At least that way someone who managed to connect to the Pi without the password wouldn't be able to do anything to the settings file without knowing the sudo password. I don't know. Maybe I'm just spewing nonsense.

If you have a device left such that someone can walk up to it and access it without any login or password, then you have bigger problems.

As a minimum, the device should be properly secured to not allow random people to login. Node-RED should be running as a password protected user - and its settings file properly secured for that user.

1 Like

If you have installed node-red as sudo, you will be running as root. Anyone with access to the node-red editor can probably hose the whole device very easily.

  1. Don't install node-red or any nodes as root - ever.
  2. If the server is used for multiple purposes, make sure that node-red runs under its own dedicated user and control access to the userDir folder both from the OS and from within the editor.
  3. If you need the extra layer, move identity management, authentication and authorisation to a different service such as LDAP or OAuth so that you are not relying on local files.

No, it is simply a recognition that the majority usage of node-red, at least in the past, was from the home automation world where consequences were less and requirements simpler.

node-red is a node.js app and security of such apps is a reasonably well documented approach.

As Nick says, if anyone can connect to your Pi's OS without a password, you may as well not bother with security at all unless you have installed it in a secure room with controlled access and disabled remote access.

Remember, the default configuration of a Pi is NOT AT ALL SECURE. Not in any way. It was designed for education use with simplicity in mind, not security. However, because it uses Linux as the OS, all of the core tools you need to be able to set it up securely are already installed or readily available.

Understanding how to make good use of user and group accounts is your starting point. Look at the standard setup for any web server for example and you will see how it should be done.

All of these points are valid. I'm not expecting Node-RED to or the Pi for that matter to be a fortress. I have employed measures to enhance both of their securities (https:// requirement, a user login, dashboard and static page locks, disabling all access methods except SSH and VNC, non-standard ports for everything, auto-updates and upgrades, and am considering adding fail2ban, different root password, secure main user password, bluetooth and wifi off etc). I've done the best I can from resources I have found online. This device is only being deployed to serve a very specific purpose, and I am being overly paranoid on purpose. Nobody will have physical access. As I said, I may just be spewing garbage -- I imagine there's some way for someone to get through SSL without a passcode and gain access that way but then (maybe?) get stumped by a password request when trying to use sudo. Yes, improbable, maybe even impossible (I do not know, I'm not a security expert), and on second thought anyone who can manage to get through SSL or VNC w/o a password can probably easily circumvent a password request on the Pi.