Hacker News new | ask | show | jobs
by ynezz 2698 days ago
That's really terrible recommendation. You should add firewall rules and allow SSH access only from trusted hosts, ideally over VPN. It's not about login attempts but about possible bug in SSH (and other network services), because it's all just software, written in C, so believe it or not, but it's there, it's not if but when.
5 comments

The firewall isn't immune to exploitable bugs: https://nvd.nist.gov/vuln/detail/CVE-2017-18017

Likewise for VPN stacks: https://nvd.nist.gov/vuln/detail/CVE-2017-7521

If you're not prepared to expose a service to the world, you probably should run it at all. Ad hoc, non-standard configurations add substantial complexity and maintenance burdens. Complexity is the enemy of security, and having less time to manage more complex configurations is not a good recipe.

If you really need a service, then choose the best one and move on. The rule of thumb is that if you can reach a service, you should assume anybody else can, as well. This is especially true regarding SSH. I've seen plenty of servers p0wned via SSH, but never by breaking SSH. Instead the vector was always through an SSH user's computer infected by malware.

You want secure SSH? Disable password authentication and force everybody to use smartcard authentication like a Yubikey. I do rate limit SSH access using OpenBSD PF, but only because the authentication failures fill up and pollute the logs.

Have you seen yubikey/smartcard being used for sshin a large team? Would love to hear about your setup and learnings.
OpenSSH is solid piece of software. It hasn't had any (public) authentication bypasses that wasn't configuration related since it started to look like it looks today. Multiple skilled teams have looked at it thoroughly since. It has also been hardened with things like privsep and sandboxing.

This is not OpenSSL. Language alone does not make a product insecure. For practical purposes it is certainly not just a matter of when.

Contrast that with your VPN product, which probably falls over if someone looks at it funnily. Unless your product is called Wireguard, and we are ten years in the future, perhaps.

> That's really terrible recommendation

it would be if it was meant to be comprehensive.

Absolutely this. Sad to see how many people refer changing ssh port to non-standard as "security" measure.
Every little bit helps. I have hosts I access from "where ever."
It's fallen out of favor these days, but if you're running on firewalls that can be configured for port knocking consider doing that. A non-sequential knock pattern that unlocks the remote IP for X amount of time can prevent a ton of grinding attacks.
Add a TLS auth channel to the portknock with a wait window and OTP and you are really in business with this approach.