Hacker News new | ask | show | jobs
by yock 5734 days ago
Those Asian addresses are only banging away at your server with weak u/p combinations, so if you've implemented PKA then they're already nothing to worry about. Blocking those IP addresses does little more than filters them out of one log (sshd) and into another (netfilter, assuming you're logging). The same goes for moving it to a non-standard port. You're only protecting yourself from the unsophisticated attackers looking for low-hanging fruit, which you've presumably mitigated with PKA already.

The author of the article advocates filtering to trusted sources because it's so much more effective. Ask yourself just how often you access your sshd from a new-to-you location. I'd be willing to bet that it isn't so often that you can't anticipate it. This effectively becomes a third factor in your authentication schema. It requires any attacker to have your private key, know it's passkey, and be at a pre-approved location. Gaining access to your sshd then necessitates attack vectors for your sshd, your private key or the encryption algorithm you used to generate it, and netfilter or whatever runs your firewall.

1 comments

This ignores vectors like say, ubuntu/debian having an insecure keygen due to their own crappy custom patch to ssh, which was actually the case for quite a while.
I don't imagine there are too many Ubuntu installations in environments where this kind of SSH security is desirable. I could be wrong though, and you'd be right that this doesn't excuse them from shipping broken software. Yet broken software doesn't legitimize these frivolous measures. It only delegitimizes distributions like Ubuntu for settings like these.
I was glad that I was using openbsd with pf as my firewall when that came down.