] Fanged Menace 
Does anyone have a good like "security checklist" for hosting 
linux server security checklist
@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.
linux server security checklist
@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.
linux server security checklist
@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.
linux server security checklist
@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.
re: linux server security checklist
@joepie91 @katnjiapus by the way, would you recommend blocking SSH for the root user?
re: linux server security checklist
@madcap @katnjiapus I have personally not found any value in it from a security perspective; if you're going to be using your SSH access for server administration, then your account will functionally have to have root access anyway (password-based escalation is really easy to keylog by a hypothetical attacker...) so it mostly just adds an extra step for any administrative command you want to run.
That extra step *can* be desirable to reduce the chance of making destructive mistakes yourself, as an extra confirmation step; though it doesn't protect you from all failure modes. But that's not really a security thing so much as a slightly inconvenient usage safeguard.
re: linux server security checklist
@madcap The problem is that these are complex questions to answer without a lot of background knowledge and experience in server management - how would one know if their IP often changes if they haven't already been doing server stuff for a while, for example?
So providing a list with "niche" recommendations that the recipient is then supposed to choose from, is usually the opposite of helpful, and just becomes overwhelming - it still doesn't tell them what they should or shouldn't do, it just creates more questions they now need to figure out.
(The usual heuristic applies here - as soon as you're saying someone could "just" do something, you should take a step back and ask yourself what this actually entails, and whether it is as easy for someone else as it is for yourself.)
I don't know the exact background and experience of @katnjiapus, but given that they ask specifically for a checklist, I would assume that they are looking for a list of "things they definitely should be doing, so they can be confident that it's set up right even if they're just starting to do server stuff and aren't familiar with it yet".
And to be clear, this is not really about you specifically, I see a *lot* of tech folks having this tendency to frontload all the information (relevant or otherwise) when someone asks a beginner question, but that's really something we should all unlearn if we want to have any hope of having people run their own services. Focus on the certainties, add the nuances later.
re: linux server security checklist
@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.