Selfhosted

Anything exposed to the internet will be found by the scanners. Moving ssh off of port 22 doesn’t do anything except make it less convenient for you to use. The scanners will find it, and when they do, they will try to log in.

(It’s actually pretty easy to write a little script to listen on port 20 (telnet) and collect the default login creds that the worms so kindly share)

The thing that protects you is strong authentication. Turn off password auth entirely, and generate a long keypair. Disable root login entirely.

Most self-hosted software is built by hobbyists with some goal, and rock solid authentication is generally not that goal. You should, if you can, put most things behind some reverse-proxy with a strong auth layer, like Teleport.

You will get lots of advice to hide things behind a vpn. A vpn provides centralized strong authentication. It’s a good idea, but decreases accessibility (which is part of security) - so there’s a value judgement here between the strength of a vpn and your accessibility goals.

Some of my services (ssh, wg, nginx) are open to the internet. Some are behind a reverse proxy. Some require a vpn connection, even within my own house. It depends on who it’s for - just me, technical friends, the world, or my technically-challenged parents trying to type something with a roku remote.

After strong auth, you want to think about software vulnerabilities - and you don’t have to think much, because there’s only one answer: keep your stuff up to date.

All of the above covers the P in PICERL (pick-uh-rel) for Prepare. I stands for Identify, and this is tricky. In an ideal world, you get a real-time notification (on your phone if possible) when any of these things happen:

• Any successful ssh login
• Any successful root login
• If a port starts listening that you didn’t expect
• If the system watching for these things goes down (have two systems that watch each other)

That list could be much longer, but that’s a good start.

After Identification, there’s Contain + Eradicate. In a homelab context, that’s probably a fresh re-install of the OS. Attacker persistence mechanisms are insane - once they’re in, they’re in. Reformat the disk.

R is for recover or remediate depending on who you ask. If you reformatted your disks, it stands for “rebuild”. Combine this with L (lessons learned) to rebuild differently than before.

To close out this essay though, I want to reiterate Strong Auth. If you’ve got strong auth and keep things up to date, a breach should never happen. A lot of people work very hard every day to keep the strong auth strong ;)

It depends on what you're self-hosting and If you want / need it exposed to the Internet or not. When it comes to software the hype is currently setup a minimal Linux box (old computer, NAS, Raspberry Pi) and then install everything using Docker containers. I don't like this Docker trend because it 1) leads you towards a dependence on property repositories and 2) robs you from the experience of learning Linux (more here) but I it does lower the bar to newcomers and let's you setup something really fast. In my opinion you should be very skeptical about everything that is "sold to the masses", just go with a simple Debian system (command line only) SSH into it and install what you really need, take your time to learn Linux and whatnot.

Strictly speaking about security: if we're talking about LAN only things are easy and you don't have much to worry about as everything will be inside your network thus protected by your router's NAT/Firewall.

For internet facing services your basic requirements are:

• Some kind of domain / subdomain payed or free;
• Preferably Home ISP that has provides public IP addresses - no CGNAT BS;
• Ideally a static IP at home, but you can do just fine with a dynamic DNS service such as https://freedns.afraid.org/.

Quick setup guide and checklist:

1. Create your subdomain for the dynamic DNS service https://freedns.afraid.org/ and install the daemon on the server - will update your domain with your dynamic IP when it changes;
2. List what ports you need remote access to;
3. Isolate the server from your main network as much as possible. If possible have then on a different public IP either using a VLAN or better yet with an entire physical network just for that - avoids VLAN hopping attacks and DDoS attacks to the server that will also take your internet down;
4. If you're using VLANs then configure your switch properly. Decent switches allows you to restrict the WebUI to a certain VLAN / physical port - this will make sure if your server is hacked they won't be able to access the Switch's UI and reconfigure their own port to access the entire network. Note that cheap TP-Link switches usually don't have a way to specify this;
5. Configure your ISP router to assign a static local IP to the server and port forward what's supposed to be exposed to the internet to the server;
6. Only expose required services (nginx, game server, program x) to the Internet us. Everything else such as SSH, configuration interfaces and whatnot can be moved to another private network and/or a WireGuard VPN you can connect to when you want to manage the server;
7. Use custom ports with 5 digits for everything - something like 23901 (up to 65535) to make your service(s) harder to find;
8. Disable IPv6? Might be easier than dealing with a dual stack firewall and/or other complexities;
9. Use nftables / iptables / another firewall and set it to drop everything but those ports you need for services and management VPN access to work - 10 minute guide;
10. Configure nftables to only allow traffic coming from public IP addresses (IPs outside your home network IP / VPN range) to the Wireguard or required services port - this will protect your server if by some mistake the router starts forwarding more traffic from the internet to the server than it should;
11. Configure nftables to restrict what countries are allowed to access your server. Most likely you only need to allow incoming connections from your country and more details here.

Realistically speaking if you're doing this just for a few friends why not require them to access the server through WireGuard VPN? This will reduce the risk a LOT and won't probably impact the performance. Here a decent setup guide and you might use this GUI to add/remove clients easily.

Don't be afraid to expose the Wireguard port because if someone tried to connect and they don't authenticate with the right key the server will silently drop the packets.

Now if your ISP doesn't provide you with a public IP / port forwarding abilities you may want to read this in order to find why you should avoid Cloudflare tunnels and how to setup and alternative / more private solution.

Definitely look into fail2ban. There might be something newer out there, but something like that is essential for running open WAN ports.

I hear you can get a pretty good offer from CrowdStrike these days.