Hacker News new | ask | show | jobs
by timtadh 3530 days ago
I'm confused, how is SSH an example of defense in depth? It is an access method. You should absolutely harden your SSH configuration. Fail2Ban is useless on a properly configured SSH server (no root, no passwords, no kerberos, only keys). Managing the keys at scale, well that is a different story.

I agree with you that ASLR, NX, and CFI are the most important system level defenses to employ.
2 comments
Jedd 3530 days ago
> Fail2Ban is useless on a properly configured SSH server (no root, no passwords, no kerberos, only keys).

This assertion confuses me.

I use fail2ban on boxes I have key-only ssh configured for.

Are you aware fail2ban works for services other than ssh?

If an attacker / script knocks unsuccessfully on my ssh door, other doors are then closed to them.

I also get much (much!) cleaner logs thanks to fail2ban.

link
nixos 3530 days ago
>This assertion confuses me.

I suspect that you're confusing fail2ban and port-knocking (or using fail2ban as a port-knocker).

The point of fail2ban is to prevent an attacker from brute-forcing your server. In a key-only config, the chances of getting brute forced is smaller (by a few orders of magnitude) than getting hit by an asteroid and having the server get hit by an asteroid, so fail2ban doesn't really help.

_In theory_, the same would be true for port-knocking.

However, in practice, sshd can have security holes which a malicious scanner could exploit. And while port-knocking doesn't help against a determined attacker (it's subject to MITM, replay-attacks), it does help with defense-in-depth.

link
timtadh 3530 days ago
That is true and a good use case for fail2ban. Useless was probably a strong word, what I really meant was of limited utility in increasing the security of the SSH service.
link
tytso 3530 days ago
The main reason I use fail2ban is I got tired of the log file noise/bloat. I use key-only access on my servers already, with the key stored on a hardware token (Yubikey).
link
problems 3530 days ago
I guess the question then is why you're looking at failed Auth logs. Failed auths are boring, doubly so on a key only server. Successful auths are where the fun is at.
link
pm215 3530 days ago
When I first set up fail2ban it was because I got annoyed that the machine on my desk was making regular "clunk...clunk...clunk" noises from the hard disk as it wrote another failed-auth attempt to the log every second or so...
link
tptacek 3530 days ago
SSH is fine. Stacking extra stuff on top of SSH to create a defense-in-depth stack for it SSH is what's silly. Just disable passwords and use SSH.
link
Karunamon 3529 days ago
Not entirely reasonable for all use cases. If there's a machine that you need access to from many different locations, a keyfile is more of a PITA than a long passphrase.
link
jabl 3530 days ago
A HPC center (that is, lots of users coming in via ssh) I know about disabled key logins IIRC due to some incident where an attacker had got hold of a password-less key.

Too bad that sshd can't enforce use of password-proctected keys on the server side..

link
dozzie 3529 days ago
You got the thing backwards. It's not "too bad that sshd can't enforce keys" of some property that happened to be missing in the key attackers got their hands on. It's "too bad the HPC center staff didn't have tools good enough to manage their servers". CFEngine and Puppet being two examples of such tools the staff missed (or didn't know how to put into use in this case).
link
jabl 3529 days ago
The problem, AFAIU, was that some user had a password-less key stored on some external system (their personal home computer, for all I know). That system was hacked, and allowed the attacker to access the HPC system. I don't see how the HPC center staff getting the Puppet-gospel could have prevented that person from using a password-less key. Well, except by disabling key-based logins (which, AFAIU, they could have used Puppet/cfengine/whatever for).

My point is that in general it would be better to disable password auth and only use key based auth, but only if you could somehow guarantee that the users wouldn't do crazy things like use password-less keys. But as you can't do that on the server-side, what other options do you have?

link
dozzie 3529 days ago
> I don't see how the HPC center staff getting the Puppet-gospel could have prevented that person from using a password-less key.

It's about reaction of the staff to key leak:

>> A HPC center [...] disabled key logins IIRC due to some incident where an attacker had got hold of a password-less key.

This reaction seems just silly.

link
nixos 3530 days ago
sshd can have vulnerabilities which port-knocking can (temporarily) block.
link