Live data from Hacker News

What SSH Hacking Attempts Look Like

medium.com

21–30 of 186 posts

Re: What SSH Hacking Attempts Look Like

#21
post #17

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.

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.

Re: What SSH Hacking Attempts Look Like

#22

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.

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.

Re: What SSH Hacking Attempts Look Like

#23
post #17

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.

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.

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.

Re: What SSH Hacking Attempts Look Like

#24
post #21
post #17

Earlier quoted context omitted.

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.

Re: What SSH Hacking Attempts Look Like

#25
post #18

Earlier quoted context omitted.

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...

Re: What SSH Hacking Attempts Look Like

#26
post #18

Earlier quoted context omitted.

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

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."

Re: What SSH Hacking Attempts Look Like

#27
post #21
post #17

Earlier quoted context omitted.

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.

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

Re: What SSH Hacking Attempts Look Like

#29
post #22

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.

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.
Post reply on HN