Background: 15 years of experience in software and apparently spoiled because it was already set up correctly.
Been practicing doing my own servers, published a test site and 24 hours later, root was compromised.
Rolled back to the backup before I made it public and now I have a security checklist.
At least you had a backup
I’ve gotta say this post made me appreciate switching to lemmy. This post is actually helpful for the poor sap that didn’t know better, instead of pure salt like another site I won’t mention.
On a new linux install or image I will always:
- Make new users(s)
- Setup new user to sudo
- Change ssh port
- Change new user to authenticate ssh via key+password
- Disable root ssh login
- Setup new user to sudo
I hope it is not a passwordless sudo, it is basically the same as root.
That’s more or less the advice I’ve gotten as well. I’ve also read good things about fail2ban which tries to ban sources of repeated authentication failures to prevent brute force password attempts. I’ve used it, but the only person who has managed to get banned is myself! I did get back in after the delay, but I’m happy to know it works.
As a linux n00b who just recently took the plunge and set up a public site (tho really just for my own / selfhosting),
Can anyone recommend a good guide or starting place for how to harden the setup? Im running mint on my former gaming rig, site is set up LAMP
Paranoid external security. I’m assuming you already have a domain name. I’m also assuming you have some ICANN anonymization setup.
This is your local reverse Proxy. You can manage all this with a container called nginx proxy manager, but it could benefit you to know it’s inner workings first. https://www.howtogeek.com/devops/what-is-a-reverse-proxy-and-how-does-it-work/
https://cloud9sc.com/nginx-proxy-manager-hardening/
https://github.com/NginxProxyManager/nginx-proxy-manager
Next you’ll want to proxy your IP address as you don’t want that pointing to your home address
https://developers.cloudflare.com/learning-paths/get-started-free/onboarding/proxy-dns-records/
Remote access is next. I would suggest setting up wireguard on a machine that’s not your webserver, but you can also set that up in a container as well. Either way you’ll need to punch another hole in your router to point to your wire guard bastion host on your local network. It has many clients for windows and linux and android and IOS
https://github.com/angristan/wireguard-install
https://www.wireguard.com/quickstart/
https://github.com/linuxserver/docker-wireguard
Now internally, I’m assuming you’re using Linux. In that case I’d suggest securing your ssh on all machines that you log into. On the machines you’re running you should also install fail2ban, UFW, git, and some monitoring if you have the overhead but the monitoring part is outside of the purview of this comment. If you’re using UFW your very first command should be
sudo ufw allow sshhttps://www.howtogeek.com/443156/the-best-ways-to-secure-your-ssh-server/
https://github.com/fail2ban/fail2ban
https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands
Now for securing internal linux harden the kernel and remove root user. If you do this you should have a password manager setup. keepassx or bitwarden are ones I like. If those suck I’m sure someone will suggest something better. The password manager will have the root password for all of your Linux machines and they should be different passwords.
https://www.makeuseof.com/ways-improve-linux-user-account-security/
https://bitwarden.com/help/self-host-an-organization/
Finally you can harden the kernel
https://codezup.com/the-ultimate-guide-to-hardening-your-linux-system-with-kernel-parameters/
TLDR: it takes research but a good place to start is here
Correct, horse battery staple.
I couldn’t justify putting correct in my username on Lemmy. But I loved the reference too much not to use it, so here I am, a less secure truncated version of a better password.
