* SSH Host Key
* SSH Authorized Keys
* SSH PermitRootLogin
* Disabling password auth in favour of keys
* Security updates from the distro
* SELinux (maybe?)
Anything else?
b) Software firewall via e.g. IPtables is generally the first thing I turn on after rebooting SSHd with the new settings.
c) (Optional) Consider using an architecture where you have N boxes and SSH only listens on a local interface on N-1 boxes, with the Nth box running nothing but your VPN. (This is also a good architecture choice for admin consoles, folks. www.example.com resolves to a public IP, admin.example.com resolves to a private IP, so even if they're technically speaking on the same box/boxes you won't lose the admin console if someone unwisely uses the same password for a WordPress blog somewhere.)
It can be configured to automatically add (and later remove) ip addresses to iptables based on login failures (found by running regexes on logfiles).
I've got rules blocking ip addresses with multiple failed ssh or wordpress login attempts for an hour to be very effective. I've still got a bit of "brute force poop" in the logfiles, but much less than before. I've seen a suggestion for adding an additional fail2ban "recursive rule" - dropping any ip address with repeated fail2ban lockouts for much longer times - if you trigger multiple 1 hour lockouts for ssh auth failures, you might get dropped for a week or more. I haven't felt the need to implement that one yet.
Any service that has bound to a public-facing port on a machine I run has done so because I wanted it to; if I had a firewall I'd need to add an exception for it. Any service that's only meant to be accessed from the same machine has bound on loopback. Services that are accessed from another "internal" machine are properly authenticated, which means the network doesn't have to be trusted; spoofing packets won't help an attacker at all. Frankly if your defences rely on the idea that all packets from ip xxx.xxx.xxx.xxx are "safe" you're going to get burned.
Where's the value in a software firewall supposed to be?
Or what if I want to run a mail relay but only allow machines I control to access it. Or block a user who's doing something nefarious?
Sure, most services allow you to control access by ip, but I'd much rather manage it all in one place. And the ports show up as closed if you block at the firewall.
Hmm. In that specific instance it makes sense, because spoofing the IP is the whole point of the attack. I'd argue that's basically unique to DNS though, in which case the advantage of managing it in the same place as your other services goes away.
>Or what if I want to run a mail relay but only allow machines I control to access it.
Then you use a real authentication mechanism (i.e. SMTP AUTH). Otherwise it would seem perfectly possible for a spammer to spoof one of your IPs and use your relay.
The most dramatic example I have is that I manage a very heavy database-driven web application from an outside vendor that must be public to the entire world. Even a simple request of the home page results in dozens of queries, and users that are logged in put an additional load on resources. I've addressed performance with other optimizations, but since we have no need to generate additional traffic, I have iptables rules to detect unwanted crawlers or pen-testers and block them (based on probes to unused ports/IP addresses, user-agent strings, etc.). When we originally deployed the application, crashes were routine during peak cycles. Now, the server barely breaks a sweat. The ability to implement simple logic in a robust, time-tested software firewall plays an important role.
Other examples include mitigating SSH brute force attacks, port knocking, forensic logging and honeypots. My honeypots protect me from many undisclosed vulnerabilities, simply because attackers are poking around in places they shouldn't be and are automatically blocked. It's much nicer to review a simple report of blocked attacks than it is to troubleshoot a compromised server.
In any case, there was discussion on those issues not long ago: https://news.ycombinator.com/item?id=5316093
I assume you mean to disable it? I see that listed in various places, but I don't understand why it matters… I like to kill all passwords on my VMs (so there's nothing to brute force), uninstall sudo and only use ssh keys to authenticate. I would like to know why this is a bad idea.
So if you disable root logins, they have no idea what to use as a username. Oh sure someone who personally knows which machine you maintain might be able to guess jonwood is your username or my username is vlm... but they'll never be able to log in as root and botnets aren't smart enough to try anything else. Aside from root, I wouldn't make your "primary user name" = "hostname" either.
Thinking back at my occasional examination of logs, I don't know if I've ever been scanned by bot nets trying Anything other than root as a username. I'm sure it happens, but I can't afford to spend 5 minutes per syslog line in my life either...