41–50 of 186 posts
The numbers on https://cdn-images-1.medium.com/max/1600/1*47UCBwMdQGFNtk2ao... look very suspicious.
Looks like the graph was generated from the Top 10 only. Obviously every item appears exactly once, so they all have the same 10%. The presentation as a graph is useless.
Earlier quoted context omitted.
Fail2Ban and psad will do wonders for that.
Yeah, I now simply removed 0.0.0.0/0 dport 22 from the whitelist and only added a select few IP ranges. That has calmed the storm significantly, and if an IP from this range (my ISP) tries it anyway I can contact my ISP (a small local ISP) to take that down.
Earlier quoted context omitted.
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.
Why is it that paranoid nerds need to waste so much time masturbating over failed SSH login attempts?
All you need to do is turn off password auth, or perhaps use wireguard.
No open port = no hacking attempts.
Investing a week of on-and-off studying and tinkering with openvpn is really paying off.
# cat /etc/ssh/sshd_config | grep PasswordAuthentication PasswordAuthentication no ^ it should return that. The end.
Is it worth mentioning useless uses of cat in this day and age?
Earlier quoted context omitted.
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.
Fairly standard stuff, definitely interesting to see all the IoT credentials attempred. I'd recommend SSHGuard over fail2ban though, I seem to remember the version of fail2ban in the Debian repos completely choking on IPv6 and failing open which is obviously undesirable.