Agree. It is not a problem of node red "not being safe". It is easy to blame the application and harder to accept that the root cause most likely is different. No one should publish apps/services without having a really solid understanding about security implications.
3 Likes
I don't think it makes any more sense to say Node-red is safe or unsafe than to say a hammer is safe or unsafe.
The problem as I see it is how very easy it is to make your Node-red installation vulnerable. All you have to do is tell your router to expose port 1880.
This is much more dangerous than opening port 22 because, by default, there is not even a password between the visitor and root access.
How could Node-red help to minimise this risk? Some possibilities that leap to mind:
- The "Welcome to Node-red" popup could point out the risks.
- NR could refuse connections from the internet unless the adminAuth password is set up.
- The exec node could reject commands containing "sudo" unless the adminAuth password is set up. (Are there other nodes which also expose the command line and sudo?)
- The website needs a simple and comprehensive guide to safely accessing Node-red from beyond your LAN. I think this is work in progress? But I'm hoping for something more useful to the average home enthusiast than "Employ a security professional"
2 Likes
One of the difficulties we face is trying to find the right approach that balances ease of use with the overall security. We also have to consider the many different ways Node-RED can be installed and run. We have looked at this quite a few times in the past at a high level, and never found quite the right approach.
But I think it's clear we need to do something.
I will be starting a discussion on node-red/designs Ā· Discussions Ā· GitHub later today where we can discuss the specific requirements and possible approaches.
I'm not aware of anyone working on that specifically. Lots has been written in the community on the subject - but nothing proposed and fed back into the official docs.
1 Like
A couple of other quick wins to add to the discussion.
- remove your /etc/sudoers.d/010_pi-nopasswd file - means the default user has to at least enter their password to perform admin actions (like node-red-stop and start...) and sudo apt install dodgy file.
- set your settings.js file to be owned by root rather than default user so again needs password to be re-written / edited
We could of course "force" these in the install script... but the second is no use without the first, and the first is a default Pi setting so may make Pi users go WTF ?
How can node-red identify internet connections?
I believe that a shell command could be run directly from a Function node using child_process.exec(), after requiring child_process.
If I happen to visit cnn.com, Google and Facebook know that I went there, where from and what I looked at. So maybe it's possible. Can NR's web server identify the visitor's IP address for instance?
Hmm. It's a little bit worrying.
My "suggestions" were plucked from the air in the hope and expectation that something can be done. I don't know if any of them are practical, much less acceptable to the owners/leaders.
Nobody wants Node-red to get a reputation as unsafe if something can be done to improve security.
So many good thoughts and suggestions in this thread.
I hadn't been too worried because didn't think any hacker would be too excited about my home automation, but if nothing else, it is a big hassle to rebuild the my RPi's (and not quite sure how best to do it from 1500 miles away...)
I've started looking at 'securing-node-red'; there's a lot of information there (especially for an old guy); there also appear to be a few YouTube vidoes on the subject. Are there any videos that are better than others to get me started?
Not 8880 specifically but close to that
Might be worth adding this to the security FAQ thread Dave. So we get a more definitive thread with everything in one place.
I've tried to put together stuff in the FAQ section so that at least we have things in one place. The issue is that security gets very complex very quickly. There really isn't an easy win here in my view. Trying to present an easy view of security will certainly lead more people to make mistakes.
In my view, the "simple" beginner advice is never expose the Node-RED web endpoints to the Internet until you know at least a bit about system security and can have some confidence that you can create a reasonably secure interface.
Giving more than this leads to the danger of people blaming Node-RED for security failures in the future that really have nothing to do with Node-RED. Indeed, I think we are already seeing that in threads like this.
Not really, they only know what your browser exposed to them (and possibly about a referral from another site). They will know AN IP address but what that means is open to interpretation and may not be accurate. For example, some sites think I am in Australia even though I am clearly in the UK (and not using a VPN right now).
What I mean here is that, again, things get really complex very quickly. Is it really down to Node-RED to try to cover these issues? Not in my view. Other services you run on your systems don't try to do that. It is scope creep of the highest order to try to get Node-RED to deal with these issues that should be dealt with using tried and trusted system configurations.
I think this is an awakening for many people. I've said before that Node-RED might be low-code BUT it is a general-purpose computing environment. That means it can do almost anything! That's great from a power and flexibility perspective. BUT, with great power comes great responsibility! If there is a failing in the documentation, in my view it is this, that we don't necessarily warn people that Node-RED is not a hammer, it is a 1,000 ton excavator. Allowing that to be controlled over the Internet is a recipe for disaster unless you include the appropriate controls.
Node-RED IS unsafe - in the sense that its power is as easily misused as any other powerful computer system. That doesn't make it wrong. Nor does it may it Unsafe (capital "U"). It simply makes it powerful.
As with any powerful computer system, security lies in combining a number of tools to configure controls appropriate to the risk and impact.
I've lost count of the number of times I've said in this forum and others that ANY compute system is of interest to someone or something. Between bots and many thousands of people with little money but plenty of time and an internet connection, there is money to be made. Not really for this thread for me to expand on the details of that but plenty has been written on the subject.
3 Likes
Richard Wenner has a good video, perhaps a bit dated?
Security
Hmm. It's a little bit worrying.
Rule of thumb: assume everything you install is unsecure. It is up to you to mitigate any potential security issues.
The problem in this case is the raspberry pi/os that does not require a password for sudo by default, quite a nice attack vector and an unsecured node-red is a known perfect candidate.
Security is hard. Balancing security is even harder.
As a first step I think it should really make it clear in the documentation that security should be done by the user, be it a sudo password and admin password. Also for the raspberry script: "Warning....."
The warning about the missing admin auth during startup might be more clear too, people seem to read over it ? We see NR output here regularly with the warning included.
1 Like
I don't think that knowing the visitors IP necessarily allows you to know that it is being accessed over the internet..
As most cases are likely to be enabled by setting up port forwarding rules on the router, any connections will appear to originate from the router, not the "internet"
So that suggests that it would be possible to distinguish:
My router's IP address is 192.168.1.1
Every other device on my LAN has an IP address which is similar but not equal to 192.168.1.1
Or does every connection appear to originate at the router?
@jbudd everyone's configuration may be subtly different. There will not be a one-size-fits-all solution going down that route.
1 Like
For a simple network, generally those on the local network will show the actual source pc address, but as soon as you have a slightly more complex setup (I have three subnets, for example with wifi repeaters) any from the other subnets will probably also appear to come from the router.
Ah well, it was just a naiive suggestion.
Sometimes those are the ones that trigger the discovery of a solution that wasn't otherwise apparent.
1 Like
I did but no longer
Definitely forcing a password for sudo is something that I will add to my enviroments from now on (despite that I do not expose Node-RED to the internet and never suffered any kind atack).
In regards to documentation perhaps a quick win is adding a dedicated session / icon for security in the main page. Moving the relevant session from User Guide/ Configuring Node-RED / Securing Node-RED to a place that is easier to find and notice.
3 Likes
