Hacker News Reader

Comment by vbezhenar | Hacker News Reader

I never understood why people would use fail2ban or similar approaches. Just set proper password and move on. SSH traffic is tiny, it's not a problem. You'll never be hacked with a proper password. Let them waste their time.

View on HN

I think you mean just use key-based authentication only ;)

You aren't infallible. While it's easy enough to secure a minimal server with only SSH access, every time you add another service, provide access to a new user, or change a configuration, there's a chance you'll miss something or make a dumb mistake. Running Fail2Ban is a very cheap and easy method to ensure that, even if you do fuck up somewhere, there's another layer of security that should prevent malicious access in most cases (nothing will save you if you set the pass to admin/admin, e.g.).

Because fail2bans approach to log parsing is totally sane and confidence inspiring, right?

The failed attempts make it harder to monitor for other attacks because of the noise in log files, network traffic, etc. and if an attacker IP is blocked early they can't try more effective attacks.

I've set up a second obstacle by allowing access to the device from a certain range of IPs on the router. Cleaned up the log pretty good.

logins can be delayed [0] and TOTP can be used in conjunction with SSH (without google authenticator)

[0] https://unix.stackexchange.com/questions/105553/how-to-provi...

edit:

quick and dirty notes of my setup [1]

[1] https://pastebin.com/yYzSrM61

Except actual attacks don't show up in logs anyway, so it's still pointless?

The SSH daemon logs when it successfully rejects an access. A successfully rejected access is inconsequential to your security. If you are using secure passwords or pubkey authentication, it will never log a successful login by an attacker. What remains then is exploitation of the SSH server ... but the SSH server doesn't have a code path that logs "I have been exploited".

/etc/sshrc executes before a successful ssh login, you can use that to be notified before an attacker has any access to log files

... so? How does that contradict what I wrote?

I originally set up fail2ban because I got fed up with the noise of the hard disk going tick...tick...tick every 15 seconds or so, as another password guessing bot login attempt got logged and the disk heads had to seek as the logfile was written out to disk...

Do you ever examine logs? Fail2ban (or even better, using a nonstandard port or both) keep the noise out of lots to the point that you can still examine them manually.

Without it, 99.99% of the average ssh log is failed back attempts.

Changing the port away from 22 also had that effect in my experience.

This was like night and day. Non stop constant barrages on the default port, all quiet on the ssh k@ip -p XXX.

I found that setting the port and user in ~/.ssh/config made everything way easier. Also fill in the IP as HostName if you're not using DNS names.

Another more secure option is just to only allow key auth.

Port knocking + key-based auth... What more do you need?

What benefit does port knocking add to having a key auth only setup?

What benefit does locking the glass doors into a bank add to having time-locked vault? Defense in depth.

A port knock is just a clear password :/

I much prefer restricting port 22 to a few ip and disable passwords

Not with single packet authentication from fwknop

http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#w...

fwknop has a cache to prevent replay attacks, that plus the fact the packets are only valid for a certain length of time pretty much thwarts this. Remember, fwknop is _in addition_ to your existing security practices, it is not the only "password."

"A port knock is just a clear password"

It is only clear to the routers in your traceroute ... third party attackers cannot snoop on this traffic.

Right, exactly like a clear text password.

The vault and the locked glass doors defend against entirely different things. Same doesn’t really apply for ssh keys and port knocking.

If it's set up properly, it could mean you don't have log files filled with login attempts since the SSH port won't open to them until a successful knock and the knocking doesn't have to be logged.

While port knocking is really just another layer of obscurity, obscurity works really well on scattershot/random attacks. An attacker dedicated to getting into your specific server is another matter but thankfully far more rare.

"While port knocking is really just another layer of obscurity, obscurity works really well on scattershot/random attacks."

Thank you. Remember - security through only obscurity is a bad idea, but additional layers of obscurity can be very valuable.

Also remember: a typical port knock is a series of three ports that all have to be hit in a certain timeframe - for instance, 2000, 4000, 8000 - that's a big "keyspace" to brute force through at WAN packet speeds ...

Ideally, your port-knocking service is much simpler and easier to audit than your ssh service. It's also much more obscure. So you have a service which is very unlikely to suffer a 0-day vulnerability listening all the time to engage a much more vulnerable service only at those exact times you need it.

I have SSH with key auth everywhere, so I have no security worries.

But when sshd ends up pegging an entire core, and I can't login myself anymore, then fail2ban (or even whitelisting IP ranges for ssh) becomes necessary.

It would most probably never end up pegging an entire core if you use key auth and have conventional logins deactivated, no?

I mean, why would people even try.

Keys, like passwords, can be leaked, so it's possible there are databases of leaked keys out in the world, because unlike PGP or SSL certs, ssh keys don't have a revocation mechanism built in. So they could just try all the known leaked keys - like they try known leaked or default passwords.

Then there was this: https://jblevins.org/log/ssh-vulnkey (tl;dr - there was a bug in debian that caused ssh-keygen to only produce a very small number of keys rather than keys distributed across the whole keyspace). After that became public the bots were all about trying those keys for a few years after. To this day it's recommended to not used keys from that set.

Point being - the bots will try because it the tiny marginal cost is not high enough to stop the attempt.

They simply try password auth, and fail with a message that password auth is off. Constantly. All the time.

Set up a non standard port. This will stop over night.

It has stopped now (I simply removed port 22 from the whitelist except for connections originating with my home ISP, which is a local ISP where abuse reports actually work)

Have you tried port knocking as a way of temporarily whitelisting the right IPs?

That would be problematic, but I never encountered that. I'm using cheapest VPS with public IP and without any additional protections. I just checked and its load average is 0.00, so load is non-existant.

I did just to keep the logs cleaner.

Largely, I think, moving to an alternate port cut SSH crack attempts to near zero; but I use fail2ban too.

Reply on news.ycombinator.com