The way it is currently written, if somebody else is trying to brute force my account, it will have the added side affect of locking me out for 10 minutes. That seems like a major flaw. The offending ip address should be locked out, not just the username. To be fair, github blame says that the code was last touched 8 years ago. I guess it isn't a problem. I hadn't personally noticed until trying to hack myself and noticed the response.
p.s. it's not very hard to wire up custom middleware to dynamically block ip addresses after failed auth attempts. I just threw together a little code to make it happen.
^^^^ This has stuck in the back of my mind for the last day.
I think I have a beginner solution for this. Use an ssh tunnel. I do this all the time when setting up a service before releasing it. I just realized a user could use it as access to their editor from anywhere if they like.
connect to the ssh server on the system hosting node-red and create a tunnel
I discovered this (editor block) while playing with custom middleware but did not have enough time to actually make it work. Would you mind sharing your solution?
I am glad you mentioned that because your response got stuck in my (fore)head as well and I did not know how to respond.
I am not sure if I understand the tunnel approach. I assume, this would be in a scenario where only ssh is allowed and the "node-red server" would be behind some sort of firewall?
I have a feeling, that very often the node-red server is being exposed to the web because a beginner does not know how to configure a secure setup. And therefore the default installation should at least offer some sort of protection. Repeating myself:
Force password protection for the editor (during setup .. automatically copy the hash to settings.js)
Suggest to use other username than admin
After entering the password wrongly multiple times, the "admin" user should be blocked (this gives a good hint to the user that somebody is trying to get access). If it's only a 10 minutes block, it's only a matter of time until the "hack" is successful.
Suggest another port than 1880 (generally move away from default settings)
Well, I'd hardly call it "beginer friendly" - it is actually quite confusing to set up since you need to understand the difference between the local and the remote ports and which goes on which side of the command.
And without one of the cloud security solutions, it still requires people to open a firewall port and most would probably open the default port 22 which is serious mistake since there are now probably millions of bots that probe for that port in order to brute-force their way in.
Honestly, what we really need for people lacking experience is more good write-ups and videos showing people how to use Zero Trust, ZeroTier and NGROK securely. These are the best tools for people with minimal security knowledge I believe. They just need to be shown how to set them up sensibly.
NOTE: My log file shows scans mostly happen in the less than 9K port range. also spcifc targeted ports. So If I was going to put my ssh port out there it would mostly fall in the 20K to 50K range to just be safe.
Isn't it generally true that you can forward an external port to a different internal one - so external port 48022 to internal port 22?
So no changes needed to sshd_config, and no need to specify the port if you are connecting between two devices on the LAN.
Yes, usually the router allows you to map any incoming port to, in this case, port 22. Then in the ssh command in the client you specify the port to use.
Also disable the user root if you have one so the bot needs to guess the port, user and pwd. Also, on a pi, remove or rename the user pi
As this is an open area of the board, if I was a hacker I would be following these threads to see what people are doing and how I could change my attacks. I wish there was a way to make this type of post only available to people who are active on the forum for some length of time.
I think that there is a way but would need a minor change by a forum admin...
As far as I'm aware forum categories can be limited to specific trust levels, just like the lounge is limited to trust level 3 and above.
So.. if the security category was amended so that users had to be trust level 1 (or 2?) or above to access it, it would stop access to casual visitors (and being indexed by google bots).
Note.
Level 0 = new user
Level 1 = basic user
Level 2 = member
Level 3 = regular
Will do, but have to clean it up first. Also, it will only work for the httpAdminMiddleware and not the httpNodeMiddleware, since they apply their respective middleware differently. The httpAdmin adds the middleware before the authentication, whereas httpNode adds the middleware after. So, if using the built-in auth you would notice the admin middleware gets called everytime, but the httpNode middleware only gets called after a successful login. That inconsistency is a little tricky to work with and I may have to post that separately, or maybe I am just doing something wrong.
Perhaps we could implement dynamic ip banning and could share our findings with each other. It makes me wonder if some node-red instances that are currently hacked arent running as bots to hack other node-reds. Wouldnt it be odd if your ip ended up on the blocked list and that was the way you found out that you were compromised?
I don't think users understand the amount of random traffic that is slamming their computer/router/server/firewall before they go hosting node-red.
I've sanitized one of my UFW firewalls logs.
Whats important. SRC=[this is the bad actors IP] DPT=[this is the destination port they are trying to reach]
This was not the norm prior 2020. Sure I would get a hit every 5min ..... but now its like free penetration testing every minute or more.
Also this server has been up for a bit. It was way worse for the first few days it went up. If you lock your stuff down it will taper off to this level.
I'm blocking bad actors that slam me or port scan but the guy who pops in and does 20 or less ports every 10 min I don't block. It's no longer about stopping them all its about tapering off the traffic.
If you block every one and every thing that just happens to hit the wrong port you will wall yourself off.
Everything that hits your server is a higher risk. The more intelligent the device, the more the risk.
With the exception of cheap VPS's where you probably don't get a proper firewall, virtually all of that traffic should never of hit your server.
This is one of the major advantages of using Cloudflare Zero Trust. Cloudflare have been one of the top services for managing Internet traffic risks now for years and all that experience goes into their services and keeps stuff away from you. No low-cost home router can ever match that.
But either way, the only traffic that should ever reach an actual service should only be traffic that you want. UFW and Failtoban are then just there to control unwanted access to necessarily exposed services.
Personally, I'm not that worried about hackers following the forum and these threads. To me it is more important to educate everyone else. Of course though, I'm not about to reveal everything that I do or protect.
I agree, however when I have customers using internet services of their own and they happen to be NAT behind a web service provider that lets them and a ton of others (some of them are bad actors ) spin up droplets for preforming tasks ...... I end up with calls about how they can't access ... bla ... bla ... bla..
again its a fine line when dealing with general public service.
I am far from clear that there are any necessarily exposed services, especially for a home user of Node-red.
"I want to access my home Node-red from my office" - that's fine.
"So I opened port 1880" - yes, that works.
"Now I've been hacked" - It is inevitable that a Node-red server exposed to the internet will eventually be hacked. You could set up your own firewalls, web servers, reverse proxies, assorted three letter acronyms, but unless you know about internet security - point 2 demonstrates that you don't - you won't prevent it.
Yes, I know what you are saying. One of the reasons the big global cloud services are useful - the ability to rapidly spin up/down virtual data centres for relatively little cost.. But of course, things often come down to cost and many times people prefer the risk to the cost.
I agree with you. But I think that @meeki007 is dealing with more commercial tasks.
For home use, I can't ever imagine wanting to expose the editor to the Internet. At most, I would have a temporary service via one of the cloud vpn's but even then, I wouldn't leave it up all the time.
Having a dashboard - slightly different. I still wouldn't want that exposed without good protection - again, probably via a cloud VPN.
Personally, I don't leave anything open all the time. But then I'm mostly at home these days so don't often need much. Most things are automatic anyway and the couple of things that might need an override can be controlled in other ways. I get notified if something is wrong and I could quickly stand up a connection then.
The problem how does a new user know they need to reach level one to get security info?
At the least, IMHO there should be a security announcement topic (somewhat like the releases News topic) so that folks get a heads up concerning security issues or could read about security advice.
What is stopping a hacker from obtaining enough access rights to get at the information? Or someone who has got the details from selling that? Secrecy and security never mix well. If there is a culture where no one discloses about being hacked, then we will be the ostriches with our heads in the sands. This thread has made me aware of how a Node-RED hack might work (i.e. off-screen nodes), else I would have been unaware and perhaps already been hacked and never noticed.
On the actual topic, one thing I always do is to set the adminRoot path in the settings. That way it's not host:1880/ but host:1880/somerandomlylongpath which also needs to be known (can't be sniffed as a port number). (I was wondering why my instances hadn't been hacked and perhaps it's because all there is on port 1880 is "page not found")
And that is a typical example of security through obscurity!
