Everytime I read something about Linux server hardening, I get more confused. We're lacking a clear and simple, modern guide on how to do things. I know, every setup is different, but there should at least be consensus for a fresh installation.
Also, do I really HAVE to change something so that it is secure? Isn't a Ubuntu server secure out of the box? With a strong, unique root password of course.
Do not lock down to your IP address. Home IP's change all the time, and in proper security there should be no other way to access the server other than proper ssh authentication or physical access. There is no good reason to be doing it in this context. If SSH turns out to have a massive vulnerability that bypasses keyauth then every service on the net will be torn down.
What has helped me more than fail2ban with reducing login attempts by many orders of magnitude is changing default SSH port from 22 to something in 10000-30000 range.
After Security...on Performance, Brendan Gregg First 60 Seconds:
https://netflixtechblog.com/linux-performance-analysis-in-60...
First step is actually passwd -l root for me, I alwasy lock the root password. After ensuring I have a working admin account of course.
Using the root account at all is obsolete imho. Fedora, CentOS and RHEL all allow me to skip setting a root password and just use my admin user.
Naïve, black-&-white, over-simplified, amateurish advice.
Security measures to deploy depend on the risk level involved, e.g., potential costs of being hacked.
Measures like SELinux, grsec, fwknop, snort, IDS (tripwire or Samhain), HSMs, hw entropy sources, split SSH/TLS, and microservices compartmentalized into VM containers rather than Docker have their place.
What I'd like to see is a modern guide for setting up and operating a cluster of hosts that does not rely on any specific provider settings. Say you want to run a cluster of Ubuntu servers, maybe exclusively with a workload scheduler like k8s, maybe with a mixture of nodes, how do you set it up securely and consistently, how to you apply updates, provision users, deploy applications, and how do you centrally log and alert on events (systemd logs, docker logs, auditd). Bonus points if you there are pointers about how compliant that setup is wrt to modern compliance requirements.
I know it's a lot to ask, but maybe there is such a guide available that does not just fall back to talking about provider-specific features (e.g. IAM).
fail2ban is unnecessary if a non-standard port is used. Even a sub-1024 SSH port gets extremely little traffic with spurious login attempts just once per day or every few days and most of these aren't going anywhere (admin:admin). Similarly I don't think for personal servers and the like there is much point in disabling root login, though I disable password auth in SSH as a general rule. A firewall on a server itself should not be necessary in most cases, because unneeded "listen everywhere for everything" services should not be running in the first place. If this is managed by multiple people, the firewall should be external to the server so that the same person who "just wants to run this service for a test real quick" can't "change firewall policy real quick".
Is there an up to date version of this?
Here is my setup, but I’m sure it could use som work.
https://lamda-chops.bearblog.dev/steps-i-take-when-setting-u...
maybe read the last discussion on hn: https://news.ycombinator.com/item?id=5316093
Do you really need fail2ban if you require keys for ssh login?
Who cares about fail2ban? Unless you're worried about DOS, it seems pretty silly. Similarly with a firewall, assuming you have NAT and a firewall on your router.
TIL about logwatch. Seems handy as I run a couple of VPSs.
In a professional setting, today, there is much much more that needs to be taken into consideration.
Anyone else found it sus that the OP didn't mention backups?
That is not the whole job on /etc/ssh/sshd_config. You also need
ChallengeResponseAuthentication noVery beautiful and excellent
Even for 2013, this is not very good advice. fail2ban makes your iptables dynamic, which is a nightmare to audit.
This is what I do in 2021:
* Set up spiped[1] in front of SSH
* Install and setup nftables[2].
* Lock down every service as much as possible in systemd[3]. (If the service is built-in the distro, just use drop in files[4])
[1] https://www.tarsnap.com/spiped.html
[2] https://wiki.archlinux.org/title/nftables
[3] https://ruderich.org/simon/notes/systemd-service-hardening
[4] https://wiki.archlinux.org/index.php?title=Systemd&oldid=704...