Homelab

1. Don’t bother with disabling icmp. You’ll use it way more then it’s worth disabling, and something like nmap -Pn -p- X.X.X.0/24 will find all your servers anyways (same can be said for ssh and port 22. But moving that does stop some bots)

2. As long as i go out not exposing anything the the global internet, you really don’t need a lot. The fire wall should already deny all inbound traffic.

The next step is monitoring. It's one thing to think your stuff is safe and locked down. It's another thing to know your stuff is safe. Something like Observium, Nagios, Zabbix, or otherwise is a great way to make sure everything stays up, as well as having insights into what everything it doing. Even Uptime Kuma is a good test. Then something like Wazuh to watch for security events and OpenVAS or Nessus, to look holes. I'd even though in CrowdSec for host based virus detection. (Warning, this will quickly send you down the rabbit hole of being a SOC analyst for your own home)

Honestly, between the home lab being behind a RTR, NATed, patched & updated, and given the lack of users clicking on random crap and plugging in thumb drives from God Only Knows Where ... I'd go out on a limb and say it's already more secure than most PCs.

There's also no data besides what I already put on Medium and GitHub, so it's not a very attractive target.

Don't expose anything to the outside world. If you do, use something like Cloudflare tunnels or Tailscale.

I watch networkchuck on occasion, but some of his ideas are... questionable I think. Not necessarily wrong, but not the "YOU MUST DO THIS" that his titles suggest (I get it, get clicks, no hate).

Of the ideas you mentioned, (2), (3), (4), and (5) are somewhere between "reasonable" and "definitely". The rest are either iffy (unattended updates) or security theater (disable ICMP, change ports).

Something to keep in mind for step (2), securing SSH login with a key: this is only as secure as your key. If your own machine, or any machine or service that stores your key, is compromised then your entire network is compromised. Granted, this is kind of obvious, but just making it clear.

As for security theater, specifically step (6). Don't disable ping. It adds nothing to security and makes it harder to troubleshoot. If I am an attacker in a position for ping to get to an internal resource in the first place, then I'm just going to listen for ARP broadcasts (on same subnet) or let an internal router do it for me ("request timed out" == host is there but not responding).

Take a look at CIS benchmarks and DoD STIGs. Many companies are starting to harden their infrastructure using these standards, depending on the requirements of the environment. Once you get the hang of it, then automate deployment. DO NOT blow in ALL of the rules at once. You WILL break shit. Every environment has security exceptions. If you’re running Active Directory, run Ping Castle and remediate any issues. Audit often, make sure everything is being monitored.

Don't worry about it, no one wants to hack your plex server xD just don't expose things directly to the internet and you'll be fine.

Hosted reverse proxy and VPN servers. I have no open ports on my home network.

Unattended updates are a recipe for trouble. I'd never enable that.

I have no public services apart from 2 OpenVPN servers. To access everything else I connect to one of the OpenVPNs and use the services through the VPN routings.

The VPN can only be accessed if you possess a cert and key. I could even implement 2fa but for now SSL auth works securely enough.

My home lab and production network are separated by a firewall.

I have backups and plans to rebuild my lab, I actually do it regularly.

My labs do risky things, I get comfortable with those things before doing it in production.

ssh default port is 22.

Really, unless I'm trying to learn security (valid), or have something to protect. I do the basic best practices.

Real security is an offline backup.

Air gapped, no Internet access. I don't use Internet services for any of my stuff though so I can get away without direct Internet access

UDM’s regular built in threat filtering, good firewall rules, updated services, and not opening up unnecessarily to the internet. And be vigilant but don’t worry too much about it. That’s it.

automatic updates is a great strategy for breaking the system

Armed guards at every entrance.

Don't expose unnecessary things to the internet, keep any client PCs patched, use some sort of malware protection ... and that's all you need to do.

All these VLANs are such are just overkill unless you're actively exposing things to the internet. They wind up breaking really useful stuff, especially stuff that relies on multicast.

Besides, that Chinese IoT device can't get hacked if it's not open to the 'net in the first place.

My security is basically if they get past an updated opnsense firewall I could be highly inconvenienced, but everything irreplaceable is backed up in the cloud and offline in my basement.

Easy, i keep it up to date, i have nothing exposed to the internet, and i lock the door :)

set up vpn and disable ssh access from outside network

Disable root login covers 99.9999 percent of it, as long as your box has only one or two obscure login accounts.

Tailscale, expose nothing to the wider web if not actually needed.

Disable ICMP? The network team sends their regards 🐴

Well your host management interfaces shouldn't be exposed to the internet. Use a VPN if you need to access it remotely.

I just host a bunch of worthless stuff that no one wants.

Honestly I just use a good firewall and forward_auth/authelia in caddy (so authentication happens before any apps) and it works well.

I also don't expose SSH to the public internet anymore (more laziness than anything, have it semi-exposed in yggdrasil and wireguard) (mostly because the SSH logs get annoying for journalctl -f)

Cloudflare and whitelist CF ips, they publish a file

This is ofc to redirect the traffic the services that are on the cloud.

And those services reside on a separate VLAN and have their own reverse proxy on their own VM/docker whatever.

I know this is a feature in Unifi, but disabling access from countries with know bot farms (China, India) etc.
Unless you need access to them.

Only expose applications to the Internet if you have a good need to. Otherwise, use a VPN to access your home network and get to your applications that way.

If you are exposing them to the internet, take precautions. Use a reverse proxy. Use 2FA if the app supports it. Always use good, long passwords. Login as a limited user whenever possible, and disable admin users for services whenever possible. Consider an alternative solution for authentication, like Authentik. Consider using Fail2ban or Crowdsec to help mitigate the risks of brute force attacks or attacks by known bad actors. Consider the use of Cloudflare tunnels (there are plusses and minuses) to help mitigate the risk of DDOS attacks or to implement other security enhancements that can sit in front of the service.

What might be a good reason for exposing an application to the Internet? Perhaps you want to make it available to multiple people who you don't expect to all install VPN clients. Perhaps you want to use it from devices where you can't install one yourself, like a work desktop. This is why my Nextcloud and Calibre Web installs, plus an instance of Immich I'm test-driving, are reachable online.

But if the application only needs to be accessed by you, with devices you control, use a VPN. There are a number of ways to do this. I run a Wireguard server directly on my router, and it only took a few clicks to enable and configure in tandem with the router company's DDNS service. Tailscale makes VPN setup very easy with minimal setup as well. My NAS administration has no reason to be accessible over the internet. Neither does my Portainer instance. Or any device on my network I might want to SSH into. For all of that, I connect with the VPN first, and then connect to the service.

Non standard ports.

Ssh keys.

Web certificates.

Lock and key, shotgun by the door

Also consider TCP Wrappers (hosts.allow/hosts.deny) and DenyHosts/fail2ban.

With a leash. She is very hyper.

By not opening anything to the wider internet.

Enabling unattended updates -> Hell no. Regular Patchdays
Enable only ssh login with key -> yes
Create user with sudo privileges -> yes
Disable root login -> no
Enable ufw with necessary ports -> Basic iptables, but not on all hosts. But fail2ban
Disable ping -> nope
Change ssh default port 21 to something else. -> nope

Is there really any security benefit to not using default ports? Especially if the service is not open externally? I cannot find any official documentation that states you should be doing that.

If it's a Debian system, "Create user with sudo privileges" and "Disable root login" can be done during initial setup. Just leave the root password blank and it'll disable the root user and grant sudo permission to the regular user you create.

Create a separate management VLAN and use it for all your infra (web UIs of all your networking hardware, Proxmox, SSH for servers, etc).

For unattended upgrades, ensure the auto updaters are properly configured so they're used ONLY for bug and security fixes, nor for minor or major releases! Debian unattended-upgrades has good settings out-of-the-box but you may want to add any custom repos you're using. Make sure you have an email relay server configured in the Exim config, as it uses apt-listchanges to email the changelogs to you.

But above all, press the power button to turn it off and then never turn it on again. 100% unhackable.

Hopes and prayers

Anything that faces the internet I have on a separate vlan. Each system on that vlan is treated as if it was facing the internet directly, that way if one of them gets compromised the hacker will not get far trying to get into any other machines.

Rest of my network is a little more tame just for ease of access since it's only me on here.

Although at some point I do want to revisit my security protocol even locally, just in case. Hitting some kind of drive by trojan script or something within the browser is always a possibility, it could work in reverse where it connects to an external server and then accesses the rest of the network that way. I'm not aware of such trojans but I'm sure it's possible.

I do block all outbound ports except for base internet ports but a properly written malicious script would probably take that into account and use a common port like 443.

At some point I might setup a honeypot. Just need to name the VM "cryptowallet" or something like that and it would be a very fast target. If access to it is detected it would alert me and shut off the internet.

Opnsense firewall at perimeter...and that's about it. Chances of anything getting in with no exposed ports is pretty slim so I don't really bother with anything more.

For SSH exposed servers/VPS I do change the port though. Cut down log noise & maybe dodge the odd portscanner or two

Do not discount physical security, lock the doors to your house and get an enclosed rack that you can lock

You have a good list to start with. Consider adding sshguard or fail2ban in the short term and crowdsec in the long term. Also use lynis on Unix systems and PingCastle on AD systems and see what suggestions those make. Just a few suggestions off the top of my head.

Rat traps… damn mice.

Change all root usernames and passwords to “toor”

Who is going to guess that? Not me.