Unable to secure Node-RED

Hi,

I am just starting with Node-RED and probably my question is too basic, but after hours in Internet I cannot secure my access to Node-RED page.

It is Node-RED v0.19.4 and I am running it in a Raspberry Pi.

I modified the file: /usr/lib/node_modules/node-red/settings.js as described in
https://nodered.org/docs/security,

This part:

adminAuth: {
type: "credentials",
    users: [{
        username: "admin",
        password: "$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN.",
        permissions: "*"
    }]
},

I replaced it with my own username and password hash.

After rebooting the Pi, the page does not ask for username and password.

What am I missing?

Thank you so much

Javier

Wrong file I am afraid. That is the master file that is picked up when you start node red the first time. You need to edit the file in your node red working directory. Assuming you have not changed the default user name this will be .node-red/settings.js

You can confirm where it is by restarting node red then running the command node-red-log and you will see the startup log which tells you where settings.js is as well as other useful information.

Colin,
Thank you so much for your swift response.
I knew it was a basic question, but I am a beginner.
Now it is solved thanks to your contribution.
Best regards

Please don't forget to think through the other security issues as well.

For example, no point in adding password security if you haven't also added a certificate so that you have to access Node-RED's servers via https instead of http.

As some have found out to their cost recently, security Node-RED for the Internet (if that is what you are doing) can be quite involved. It is all too easy to get wrong I'm afraid.

Let's keep it in perspective. It is worth password securing your instance even over http as that will prevent casual access by things scanning for unsecured Node-RED instances. That would have been enough to prevent the recent malware attack.

Good point.

Though I'm not sure it would have stopped the attacks actually since it looks like the attacker may, at least in some cases, had access to the server itself and therefore could most likely have changed the settings file anyway.

The problem with just setting the user credentials is that it is all too easy to do that early on and then forget about the rest when you move forward with a project. Let's try to get people to think about security holistically from the outset, it is, realistically, the only way to continue to improve IoT security.

Design and build with security in mind.

I am not aware of a single instance of that. The recent issue was triggered by blindly attempting to post the attack flow to port 1880. Something that a simple password would have prevented.

Hello gentlemen,

having been attacked as mentionned i made a clean up and reinstall today. Removing nodered, node.js, npm and other files and directories.

I modified /usr/lib/node_modules/node-red/settings.js as Talud08 did.
I AM asked a login and password now.
But : I do not have any settings.js in .node-red/ directory.

So i did as said: start NR, then use node-red-log . It does not display any different path.
(i copied the result below for info)

So when i read all above Colin's answer is a bit confusing.

So is it mine or his' installation that is weird ?

Am i missing something ?

edit> sorry for the bold text , don't know how to get rid of it.

Thanks for your help in getting us understanding all this.

ยงยงยงยงยงยงยงยงยงยงยงยงยงยงยงยงยงยง

node-red-start

Start Node-RED

Once Node-RED has started, point a browser at http://192.168.0.18:1880
On Pi Node-RED works better with the Firefox or Chrome browser

Use node-red-stop to stop Node-RED
Use node-red-start to start Node-RED again
Use node-red-log to view the recent log output
Use sudo systemctl enable nodered.service to autostart Node-RED at every boot
Use sudo systemctl disable nodered.service to disable autostart on boot

To find more nodes and example flows - go to http://flows.nodered.org

Starting as a systemd service.

pi@raspberrypi:~ $ node-red-log

pi : TTY=unknown ; PWD=/home/pi ; USER=root ; COMMAND=/sbin/modprobe w1-gpio pullup=1
pam_unix(sudo:session): session opened for user root by (uid=0)
pam_unix(sudo:session): session closed for user root
pi : TTY=unknown ; PWD=/home/pi ; USER=root ; COMMAND=/sbin/modprobe w1-therm strong_pullup=1
pam_unix(sudo:session): session opened for user root by (uid=0)
pam_unix(sudo:session): session closed for user root
pi : TTY=unknown ; PWD=/home/pi ; USER=root ; COMMAND=/sbin/modprobe w1-gpio pullup=1
pam_unix(sudo:session): session opened for user root by (uid=0)
pam_unix(sudo:session): session closed for user root
pi : TTY=unknown ; PWD=/home/pi ; USER=root ; COMMAND=/sbin/modprobe w1-therm strong_pullup=1
pam_unix(sudo:session): session opened for user root by (uid=0)
pam_unix(sudo:session): session closed for user root
pi : TTY=unknown ; PWD=/home/pi ; USER=root ; COMMAND=/sbin/modprobe w1-gpio pullup=1
pam_unix(sudo:session): session opened for user root by (uid=0)
pam_unix(sudo:session): session closed for user root
pi : TTY=unknown ; PWD=/home/pi ; USER=root ; COMMAND=/sbin/modprobe w1-therm strong_pullup=1
pam_unix(sudo:session): session opened for user root by (uid=0)
pam_unix(sudo:session): session closed for user root
Stopping Node-RED graphical event wiring tool...
14 Oct 21:32:57 - [info] Stopping flows
14 Oct 21:32:57 - [info] [mqtt-broker:4ab6a67.cae7ad8] Disconnected from broker: mqtt://192.168.0.18:1883
14 Oct 21:32:57 - [info] Stopped flows
Stopped Node-RED graphical event wiring tool.
Starting Node-RED graphical event wiring tool...
Started Node-RED graphical event wiring tool.
14 Oct 21:36:17 - [info]
Welcome to Node-RED

14 Oct 21:36:17 - [info] Node-RED version: v0.19.4
14 Oct 21:36:17 - [info] Node.js version: v4.8.7
14 Oct 21:36:17 - [info] Linux 4.9.35-v7+ arm LE
14 Oct 21:36:18 - [info] Loading palette nodes
14 Oct 21:36:23 - [info] Dashboard version 2.9.8 started at /ui

14 Oct 21:36:18 - [info] Loading palette nodes
14 Oct 21:36:23 - [info] Dashboard version 2.9.8 started at /ui
14 Oct 21:36:24 - [info] Settings file : /usr/lib/node_modules/node-red/settings.js
14 Oct 21:36:24 - [info] Context store : 'default' [module=memory]
14 Oct 21:36:24 - [info] User directory : /home/pi/.node-red
14 Oct 21:36:24 - [warn] Projects disabled : editorTheme.projects.enabled=false
14 Oct 21:36:24 - [info] Flows file : /home/pi/.node-red/flows_raspberrypi.json
14 Oct 21:36:24 - [info] Server now running at http://127.0.0.1:xxxx/
14 Oct 21:36:24 - [warn]

Your flow credentials file is encrypted using a system-generated key.
If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.
You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.

14 Oct 21:36:25 - [info] Starting flows
Stopping Node-RED graphical event wiring tool...
14 Oct 21:36:30 - [info] Started flows
14 Oct 21:36:30 - [info] [debug:9e1905d4.5afd2] conn etablieundefined
14 Oct 21:36:31 - [info] Stopping flows
14 Oct 21:36:31 - [info] Stopped flows
Stopped Node-RED graphical event wiring tool.
^Cpi@raspberrypi:~/.node-red pi@raspberrypi:~ node-red-stop

Stop Node-RED

Use node-red-start to start Node-RED again

You are using an old version of node.js - you should upgrade it to at lease version 8.x and test again.

I'm assuming your using a Pi??
You could use the NR Upgrade Script - https://nodered.org/docs/hardware/raspberrypi to install the correct versions automatically.

Hi,

When sharing log output it's best to put 3 backticks ` on a newline before and after. That formats it properly.

In the very old days of NR, we didn't have the .node-red directory ... we just used the install directory. Because of that, NR checks the modified time of the settings file in the install directory and uses that if it has been changed.

Copy the file from the /usr/lib directory to ~/.node-red and all should be well.

Whether or not that is the case, if there are attackers who know Node-RED, the next step is to combine attacks. What is the point in giving people less than the full picture?

The only way to reduce the insecurities in systems is to design with security in mind from the outset. This is especially true of IoT systems which currently have an appaling record for security.

As a community, we can be part of the problem or we can promote solutions.

Hopefully, as we explain the issues and mitigations to each other, we can continue to improve the messages and methods.

I totally agree. I had held off writing my reply a few times over the last couple of weeks, for not wanting to give the impression that HTTPS wasn't important. But nor do I want users to not bother doing anything because HTTPS can be hard to setup properly. There is a balance here - the more we can do to make HTTPS trivial to setup, the better. In the meantime, users need to do as much as they can for themselves.

There absolutely is a balance, I fully agree. And I'll be the first to admit that I can sometimes come down on the opposite extreme :slight_smile: - nature of the job I'm afraid. Either way, the debate is good. We've allowed ourselves too much leeway when building home systems and we need to mature the whole thing a little.

In regard to the HTTPS/TLS thing, you know that I previously created a script to help create self-signed certificates.

Of course, that is no longer sufficient thanks to the way that browsers are evolving. So over the weekend, I spent some time finally working out the best way to get Let's Encrypt working in a way that is easily used by multiple services.

Previously, you couldn't do that without exposing some part of your internal network to the Internet. However, you can now do it - with some caveats.

Anyway, I'll be posting a blog post soon about how to get and update a Let's Encrypt wildcard certificate, how to give all of your internal services names and how to add the certificate & key to your services to turn on encrypted communications.

1 Like

i managed to do what Nick said (i.e. moving settings.js).

Login and password woks also.
Changed the port.

no i'm ready for the TLS stuff... not easy to undestand.
Thanks all for the help.

Hi TotallyInformation,

As the question of security has come up a lot recently I am keen to explore the various ways to secure Node Red and with regards to the Let's Encrypt route am I correct in understanding that in order for an SSL certificate to be issued you need to have a DNS pointing at your IP address? If this is the case am I correct in further assuming that you will need a static IP address issued by your ISP otherwise on the loss of the IP address the SSL will become redundant?

Hi, I need to find time to publish my blog post that explains all of this. But in summary, LE has moved on a little. Previously you had to expose an end point in your network in order to get a cert. Now, if you have a suitable DNS provider with a supported API, the LE client can dynamically create a temporary DNS entry that LE validates instead of the end point.

Also, the old method required a DNS name entry with a valid public IP address - the endpoint. Now, your public domain name is still needed but you can point it at an invalid IP address - I used 10.10.10.10 I think - so you don't expose anything about your private network.

Couple that with LE's new-ish wildcard domain support and you can create a cert that will work across multiple internal services. Only the main domain needs to be valid - eg. sample.com - then you can use something like pi.sample.com internally.

So to answer your question directly. No, you don't need to point the DNS at a valid IP address (as long as you are using a supported DNS provider - I register my domains with a decent provider then reassign the name servers to Cloudflare but you can now register via Cloudflare directly). And no, you don't need a static IP address since you just use a dummy address.