That is not enough. You need to check your logs, CRON, systemd, etc and check for active background scripts (though a reboot should get rid of those unless they've been attached to CRON or systemd jobs.
You must also change all passwords on the server and related services. You might also need to check other devices on the network, specifically your router.
Only really useful if you are running file sharing from the server. Of very limited use otherwise.
Firewalls, proxy services, log monitoring and, of course, solid, offline backups should be the primary focus. LAN segmentation is good for the truly paranoid. To do that you can use an internal router (ideal) or your existing broadband router (though they are more susceptible to hacking as well).
AV for Linux is the usual commercial suspects plus ClamAV.
A good approach is to have a monitor that checks for changes to key files and sends an alert for any changes. I used to run something that at least checked for changes to /etc when I was running VPS's - can't remember what that was called but it is certainly a useful tool, not sure but I think it could be configured to watch for other changes too.
That typically helps with Wi-Fi, not so much with compromises of existing devices.
You should be using fixed IP's anyway for most things. Though personally, I do that through MAC address mapping in DHCP on the Router.
One thing you can consider is having Node-RED/MQTT instances that are externally accessible running on a separate device on its own network segment. This is a poor-man's implementation of a DMZ and isn't hard to do though it does obviously require some planning and implementation. Ideally, you set that server up so that changes are only ever pushed from a more secure server so it is immediately obvious if something else makes a change. Also, that server should have no direct information on anything in the more secure area of the network.
To be honest though, all of that is cast into shadow by using something like Cloudflare Zero Trust or a similar service. Because in those cases, you never expose anything inbound through your router. There is a service that reaches out which is much more secure.
OK. It has been a quiet night. Cleaned and fixed etc. Figured out that if you access Node-Red from outside on the IP address, then you have accesses to all flows and can destroy etc. This is probably what happened. Have now fixed login to Node-Red and changed all passwords.
This was completely useless from a Linux angle.
Trying to get a firewall into my Debian 11. The idea is to only allow my IOTs and my second router access to the server. Tried now to get the whole thing up for 6 hours without success.
Very mysterious with IPTABLES and NFTTABLES.... (Actually don't understand government funds being spent on using Linux) Tried REDHAT once in the 90's but gave up, soon to here too!
The Linux department I know of is twice the size of the Windows department and the Linux people seem significantly busier.
Can you give me tips on firewall that works, allow only some MAC addresses access and can be installed and works on Debian 11.
Have tried Firewalld, (Everything just becomes a mass of red code mass and cannot be configured). UFW was missing IPTABLES and I didn't find any sensible description on how to fix this.
Big sigh.
When I want to securely access my Node-red from anywhere away from home I use Zerotier.
It's described towards the end of the thread All flows gone after fresh install
Setup an account at zerotier.com and create a virtual network.
Install Zerotier on your Node-red computer and any device you want to access it from.
So my Node-red is on a Rspberry Pi at 192.168.1.11
If I take my laptop to the pub I can connect to it using IP address 192.168.192.11. It looks like a local IP but in fact it's a secure, encrypted connection between the laptop and Pi.
No jiggery-pokery with the router, no port forwarding!
As you already know, I have a bad grasp of this
I only have one router in the summer house that a couple of IOTs are connected to. Know their MAC addresses but cannot install VPN or similar as far as I know on these. Probably neither does Zerotier.
I would prefer to avoid external services, expensive, disappearing suddenly.
Am I getting it wrong!?
I have now started making a couple of apps for my N-R data so that I don't have to go directly to the server and look.
The idea is that you add an entry that ALLOWs your dev/admin PC to access the server (or you will be paying it a visit and resetting it!), add entries that ALLOW the MAC addresses and then DROP everything else.
Oh, I probably should have said
Install Zerotier on your Node-red computer and any device you want to access it from over the internet.
You don't have to install it on any other device in your network besides the Node-red machine.
Zerotier is free for personal use. I guess there's always a risk of free services being withdrawn.
I would prefer to avoid external services
Well before I used zerotier I had PiVPN on my Raspberry Pi. No external service required but it's not as straightforward to setup.
I was forced to migrate when I switched to broadband over the mobile phone network.
I don't know if I understood you correctly. I have the admin pc and the N-R, MQTT server in the same room. So there is no problem there. It is that I have to open a port for an external Google service provider and my summer house. I have the MAC addresses in the summer house and nothing really happens there except mice gnawing... I therefore wish to be able to only allow certain MAC addresses access to the Debian 11 server.
That sounds really interesting. I'll have to look into that further.
Found out I have an external service that needs to have a port to the Internet: Node-RED Google Assistant Bridge, https://googlehome.hardill.me.uk/
All my lights and so on works over this service. If so, how do I resolve this?
Why does everything have to be so complicated
The IPTABLES firewall can protect traffic going out (which you probably don't want to touch) and coming in (which you do).
So any traffic that ORIGINATES from outside the server, has to be explicitly allowed so that everything else can be denied.
You (probably) don't want anything from Google to originate a connection to the server so don't allow that.
You DO need to add a specific connection from your dev PC whether in the same room or not otherwise you will have to connect a screen and keyboard to the server and will only be able to access it that way - probably not what you want. You are probably safe enough allowing this either via MAC address or via IP address. There are pros and cons for each and it depends on the configuration of the PC and your router. MAC address is probably simpler for now.
You do then need to explicitly allow the mac addresses of your IoT devices assuming you want them to be able to originate new connections to the server. Which you most likely do since MQTT will want that.
Beyond that, you simply add 1 final rule to the ruleset which is DENY ALL. Rules in firewalls (you probably already know this) operate in a strict top-down hierarchy and the first matching rule wins. So your allows will need to be above the deny.
If in doubt and you have a spare Pi or can stand up a virtual server, practice on those if you want just to get a feel. If you need to "practice" on the actual server, make sure you have a screen and keyboard to hand in case you mess it up completely. We've all been there I can assure you.
As I previously wrote, it seemed like a good solution, UFW. But it didn't work in Debian 11 and nobody seems to understand why on the Internet. Very messy and boring with all these different variants of Linux.
Thanks for the tip though
Yes that's exactly what I thought but apparently there is no solution for Debian 11. It doesn't use IPTABLES for the firewall but NFTTABLES which seems new and there is no good reading online. As I wrote before, I have tried two good firewalls and neither worked although the installation seemed very straight forward. Problems arose and no one knew a solution.
Just checking that you realise that means that node-red must be able to access the internet (which it needs to be able to do anyway to install nodes and so on), it does not mean that you have to open any ports in your router.
What is it that you want to do that needed you to open the port?
Just prepping my server to upgrade from Debian 10 to 11.
On 10, looks like iptables is already mapped over anyway. So possibly you can still use iptables commands?
Not clear whether that needs an inbound connection? Or does it create an outbound connection from Node-RED to googlehome.hardill.me.uk or direct to Google?
If it does need an inbound connection, again does that connect from Google or from googlehome.hardill.me.uk.
To do that you can use an internal router (ideal) or your existing broadband router (though they are more susceptible to hacking as well).
Indeed, Firewall configs in general can be a bit of a black art all in themselves.
