I don't see this discussion, is it private?
I have finally had the time to post a proposal for what we should do here: Better security by default Ā· Discussion #81 Ā· node-red/designs Ā· GitHub
Getting the balance for the wide range of users of Node-RED is not trivial. Right now, the most exposure comes from those running self-hosted instances, typically using the install script we provide.
@dceejay has already made some initial updates to the script to help prompt the user to setup security - and some more things are coming.
In the design note I've outlined what we'll do between now and Node-RED 4.0 to make security something that cannot be ignored - an explicit choice will have to be made to run without it.
7 Likes
I have installed Buster, enabled SSH, so I can log in with phutty, don't know much linux, what I could, I have forgotten, since the system has been running without problems for several years.
But, have changed the password for PI, and created a new user, who has been given administrator rights (root or sudo I think you call it)
question is can i delete user pi?
Question 2, is there some increased security in changing the port
Question 3, VPN, my pi gets an IP from my switch (dhcp) and the switch is connected to the fiber router and out to the internet. how will it work?
Stupid questions I guess, but I don't do this every day 
The pi is still safe, not connected to the internet.
The current version of Raspberry Pi OS is Bullseye not Buster.
If you use the Raspberry Pi Imager to burn your SD card you don't even need to start off with a user "pi". You can choose a username and password and setup SSH (and Wifi) as part of the installation.
Not really.
It depends which VPN you use. You really need to read the instructions for whichever you pick.
Since you previously had it set up to access from the internet, you must know about port forwarding, the router's public IP address and that it is liable to change. So you may already be using a dynamic DNS service.
The internal IP address, issued to the Pi by your router, is not relevant.
I do believe the original suggestion is a good one, it also came to my mind when this whole thing started. 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 hosts interfaces then reject it
- if X-Forwarded-For is there, use that (I believe that's the 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
Using port forwarding should only NAT the destination address, not the source.
One thing I'm wondering is why are people exposing NR to the internet? Or more specifically, what functionality are they trying to get remotely?
Something NR could do is use separate ports by default: 1880 for the editor, 1881 for the std dashboard, 1882 for nodes (TCP/HTTP/...), for example. This way, if someone wants to be able to view the dashboard remotely they don't end up opening the whole thing. Of course, opening the dashboard isn't exactly safe either.
Your easiest and cleanest way to get safely back through a VPN is through one of the softwre defined VPNs, Tailscale, Zerotier, Cloudflare
Of all of them i find Zerotier the esiest and quickest to setup.
They have good docs on their website and provide packages for linux etc and you can install endpoints on your phone from the relevant apps store. These sort of VPN apps do not require you to open any ports etc on your firewall
Craig
2 Likes
One thing I'm wondering is why are people exposing NR to the internet? Or more specifically, what functionality are they trying to get remotely?
I suspect most of them: endpoints (eg. dashboard/http endpoint/uibuilder etc).
Of all of them i find Zerotier the esiest and quickest to setup.
Security is not easy. What if zerotier gets hacked ? Massive problem.
No it is not easy - but implementing something like this is a good step in the right direction.
I could instead tell him to implement a wireguard network without any of the fancy front end etc from Tailscale - but that is far beyond most peoples capabilities.
In my experience once you start people down the security track it is far easier to get them to take the next step and then the next etc.
The combination of implementing a decent level of password security on their Pi and within NR, implementing something like Zerotier which is only authorised for the single phone and the Pi is going to be adequate to ensure that the majority of people will be left alone.
I asume you also read the details of that theoretical exploit and the conditions that would be required for some to carry it.
Also the fact that ZT seemed to address it in a timely fashion and have released many updates since then ?
Update 2021-09-24 : Additional changes have been implemented to enable collision detection on the root servers, as well as a new release of the Zerotier clients (1.6.6) that no longer implicitly trust identities learned from root servers. Zerotier have released a blog post discussing the issues further.
Craig
1 Like
I am just trying to point out that vulnerabilities are always there. I am no fan of centralized cloud services, as those are the most interesting to hackers and if things goes wrong there, it is always at a massive scale.
Zero-tier, vpns and the like are only reachable from devices that have been setup with the requirements (which is a good thing). I don't always have these requirements available, but still want to access my systems somehow and opted for nginx proxy+ssl and authelia (2FA) instead (with my fingers crossed that those are all safe).
If i do not have my phone or laptop available to initiate a VPN from then i will go without (other than telegram notifications and the like)
I do security for a living and the one thing i drill into people is the fact that there is always someone smarter and more determined out there - it is all about minimizing the footprint as much as possible.
i personally recommend people stay away from all the self hosted stuff as there are too many moving pieces in there that the majority of people do not have time to keep on top of with security advisories etc
Craig
3 Likes
I'm not a fan of centralized cloud services and run my own wireguard VPN, but then, I'm an IT professional. I would never recommend doing something like this to someone who doesn't have a pretty intimate grasp of IP & TCP protocols. IMHO Craig's recommendation is very good and yes, "vulnerabilities are always there" but that's not a reason not to implement security. Given that evidently some NR users are exposing the admin without any security they would be infinitely better off with just about any reputable cloud VPN solution.
3 Likes
Hey Thorsten,
Via the NR dashboard you can:
- Control your garage doors when you arrive home
- Watch your camera's when you are not home
- Activate your alarm system when you forgot that.
- And so on...
And I know that there are also a lot of folks in this community that even need to access the flow editor UI remotely. For example somebody owns a company that monitors refrigerators for a large series of restaurants. They install everywhere a Raspberry, and they can control all the flows remotely.
1 Like
Strange. Adding that line did nothing for me. No change to whether the user pi needs a password when executing a sudo command.
1 Like
I did. Sort of. Didn't read far enough (missed the fine print) 
.
For the record, the fine print is this:
sudo visudo /etc/sudoers.d/010_pi-nopasswd
and change
pi ALL=(ALL) NOPASSWD: ALL
to
pi ALL=(ALL) ALL
Problem solved!
Thanks.
1 Like
This is not safe enough, as I got hacked through exactly this:
As far as I can see that attack did not get in through SSH, which is what is referenced in the text you replied to.
1 Like
I don't think i would be arguing about security with Julian !! @TotallyInformation
Thanks for coming and sharing your experience @PanicMan.
It does not seem that SSH or port 22 were abused in this hack.
I have no idea if the method of attack was the same on Openhab or HomeAssistant as on Node-red.
We think that the vulnerability (in Node-Red systems) was created when the user allowed access to the Node-red editor by opening port 1880 in their router.
The intrusion probably used Node-red to download and run one or more malicious binary files.
We don't know if the recent occurrences were the first visits by the baddies to "our" Raspberry Pies, but I downloaded one malicious shell script to look at. On the face of it, it updated cryptomining code on the computer, so maybe it was a repeat visit.
So the key things to consider are:
Don't port-forward 1880 unless you have a really good reason, the baddies have started poking at it.
Use a secure password for access to the Node-red editor (and dashboard).
Ensure that the Node-red userid does not have sudo without a password.
3 Likes
