@katnjiapus The recommendations I usually give people are basically:

1. Disable password authentication for SSH, and use keypair authentication only (these are two separate steps!). Changing ports is not needed, fail2ban also isn't really.

2. Either set up automatic system updates ("unattended upgrades", or whatever your distro of choice calls them) or have a scheduled event every week to update manually and keep track of security notices. The former is easiest.

Make sure to do full distro upgrades when a new release comes out; those are usually not automatic, even with automatic updates enabled.

3. When running public-facing services, if you *can* sandbox them, do so. On NixOS this is automatic for a lot of services, using Docker it's *sort of* sandboxed (but not very well, usually), on other systems you may have to do this manually but it can usually be done directly in the systemd service file.

That's... more or less it, as the basic steps? Like, there's a lot more that can be done, that's specific to the services you run (and often explained in their documentation), but if you get these few things right, you're already doing better than a lot of public-facing production servers.

Of course, if you intend to do something especially sensitive (eg. services for activists), you should be getting someone involved who has experience in this sort of thing. This list is just for your run-of-the-mill personal/community/small-company/etc. server.

--

To elaborate on the port changing and fail2ban thing a bit: these are really common recommendations but I don't find them useful in practice, and they bring their own issues.

The port-changing is a form of security-through-obscurity that dates back to when internet-wide scanners only scanned for SSH servers on port 22 for capacity reasons. This hasn't been relevant since zmap, and so doesn't do anything anymore besides "making you manually specify the port for any SSH-based tool like rsync".

The fail2ban recommendation comes from the password login days; it's a way to throttle login attempts so that someone can't bruteforce a password over the network. But with keypair authentication this is not relevant, as long as password auth is entirely *disabled*; the search space is so big that even without throttling you will never bruteforce a key.

*At best* it reduces log entries and slightly reduces CPU use, at the cost of making it very easy to accidentally lock yourself out if eg. you try to connect from a spotty mobile connection that has to reconnect a couple of times in a short time.

@joepie91 @katnjiapus I get your point, but fail2ban is still relevant because it also helps protect other services. It's not just for SSH. Even for SSH it may prevent attacks exploiting 0-day vulns.

Apart from that I would also suggest having a firewall in front of your server and allow SSH only from your home/office IP addresses. It protects your server and frees your cpu a little.

@madcap @katnjiapus Sure, fail2ban has other usecases, but in this case I was talking about SSH only - other usecases would fall under "application-specific needs" (because modern applications generally handle rate-limiting themselves, and do not need an external tool for this).

For "SSH only from home/office IP", a similar problem applies - it is very easy to lock yourself out if, for instance, your ISP suddenly changes your IP. These sorts of measures are not free to add, so before adding them, you need to understand very well what the tradeoffs are.

There are a million things you could do that theoretically, in some rare edge cases, some tiny amount of the time, might slightly help security - usually more by coincidence than anything else. Using fail2ban against SSH exploits is one of those cases; it is vanishingly unlikely to actually do that under real-world circumstances.

Stacking a ton of those "might as well" measures together is not actually good security policy - you just end up adding a lot of complexity (and therefore new ways for the system as a whole thing to fail, through human error or otherwise), with very little to show for it. It can easily end up making things worse.

So unless server security is your expertise, you should just stick with a small set of known-good security policies (like key-only auth) that has a clear and unambiguous security benefit, and leave it at that, honestly.

@madcap @katnjiapus Or to put it differently and perhaps more concisely: "fiddling with all the subtle knobs and tradeoffs to get a perfect security profile" is the job of security experts and, especially, designers of systems who then package these decisions into simple-to-reason about policy options/defaults.

This is not something to expect from your everyday server admin, they should only need to select the simple-to-reason about policies - and if you feel that the available policies in existing systems aren't good enough, then that is best addressed by contributing to those systems, not by trying to tell individual server admins to deal with a highly complex landscape of unfamiliar security options.

@joepie91 @katnjiapus yes, sure, having a security checklist doesn't mean you should apply all the itens in the list.

You just choose a set that makes sense to you and are enough to protect your server.

For example, for the "SSH only from home/office IP" item, I'm assuming you don't need to SSH often from different IP's and/or your home IP doesn't change often.

Also, I'm assuming your server is hosted on some cloud provider or something where you have a web console where you can update your firewall rules. Sorry for not mentioning that, before.