Sysadmins of Mastodon, please share your knowledge with me! I have a Hetzner server set up that's running my website on a secondary domain. Before I fully make the transition, I want to make sure security is entirely correct. I have disabled root login and am only allowing access to the user account via SSH, I have a firewall up, and everything is updated. The internal code I've written should also be up to scratch.
What am I missing? I really want this to be as airtight as it can be.
@iris_meredith I'm guessing you disabled password ssh login, and installed fail2ban?
I'll also assume you've pared the user permissions on your services down to what they need.
Depending on your feelings you may want to bind your custom application to local host only and run a reverse proxy for the ingress traffic.
@iris_meredith also robots.txt, ai.text if you want, and if you have input forms or anything consider some kind of bot protection. IPv4 space is absolutely bombarded with scans and spams
@arichtman I'm running it behind Cloudflare (will need to change to a different CDN eventually, but for not it'll help). And I am running a reverse proxy. Robots.txt is done, and input forms aren't exactly protected, but they *are* very strictly validated on multiple levels, which seems to catch most of the shit. Fail2ban is the only thing I've missed, but that should be easy enough to install.
@arichtman @iris_meredith fail2ban is useless with password login disabled, but lets an attacker who can spoof lock the legitimate user (you) out.
@dalias @arichtman
That makes sense, I think. My one concern is if there's a password login exposed somewhere that I've not caught...
@iris_meredith Make sure all the alternative authentication stuff (kerberos, pam, etc) is disabled in your sshd config. That's where all the preauth rce exploits have historically happened.
@iris_meredith are unattended upgrades working so it'll get security patches and reboot itself automatically?
@0x2ba22e11 No, I'll add that to the list. I tear down and rebuild the entire VM every time I deploy though, and that's about once a week, so that does help.
@iris_meredith oh neat! Since you have already done the hard work, I would be tempted to run that rebuild and deploy process on a cron job instead of using unattended upgrades. :)
@0x2ba22e11 Simple enough: I have it all set up in OpenTofu, so that's very easy to do.
@iris_meredith okay that set up sounds beautiful
@0x2ba22e11 Oh, it's probably got a whole lot of flaws in it. I'm planning to write it up and publish it today, so you'll be able to have a look at the guts of it then.
@iris_meredith use SSH keys and turn off password authentication.
If you are comfortable depending on another service, setting up Tailscale with SSH (https://tailscale.com/kb/1193/tailscale-ssh) is a good option, block port 22 on the firewall but can still get in via Tailscale.
@iris_meredith Consider using another port than 22, seriously reduces the amount of intrusion attempts.
If you ever update firewall rules / ssh port nums through ssh, never _ever_ drop your running ssh connection before you do a successful parrallel connection attempt first.
Don't ask me how I know.
@nlovsund I do all of that at setup with OpenTofu, so... hmm
@iris_meredith @jerry might be of help here.