Hacker News Reader

Comment by thesuperbigfrog | Hacker News Reader

Similar tool: fail2ban: https://www.fail2ban.org/wiki/index.php/Main_Page

Tools like these are essential if you have Internet-facing SSH services.

If you do not need Internet-facing SSH, do not enable it. It can be an attack vector and there are hundreds of bots that will try to brute-force access within minutes of opening Internet-facing SSH daemon.

Best practices for Internet-facing SSH:

- run on non-standard port (not port 22)

- disable passwords, use SSH passkeys instead: https://www.techrepublic.com/article/how-to-setup-ssh-key-au...

- disable root SSH login

- run fail2ban, sshguard, or similar "block IP addresses for suspicious activity" services

- setup port knocking: https://www.tecmint.com/port-knocking-to-secure-ssh/

edit:

- run WireGuard VPN (https://en.wikipedia.org/wiki/WireGuard) for defense-in-depth

View on HN

Or just run wireguard and ssh on top of that without all the fussy config and tooling to expose ssh to the internet. You could even live dangerously and just use telnet once you have wireguard going.

> You could even live dangerously and just use telnet once you have wireguard going.

Using telnet makes me feel a little dirty and a lot alive. Using it over wireguard seems like taking a 60s muscle car and adding brakes that actually work before a track day; probably not a bad idea.

>> Or just run wireguard and ssh on top of that without all the fussy config and tooling to expose ssh to the internet.

Nice! Wireguard was not around when I was using Internet-facing SSH in a previous job.

Adding it to the recommendations.

Tailscale is a good solution. I have no ports open on my internet facing router at all any more. Tailscale has proved to be as reliable as the servers themselves. I like it so much I use it to access my AWS machines as well, by running it as an exit node up there.

I use ssh as a fallback for when my VPN fails to activate somehow.

True, true, true. You cannot rely on the VPN always working.

Is Wireguard more secure than SSH?

It runs over UDP and doesn't respond to anything until it sees a valid key sent to it, so right there it totally removes any need for stuff like port knocking. There's no way to use passwords or low security keys so there's less brute force chance. It's basically the same as going through all those machinations to make ssh secure publically (high quality key auth only, nonstandard port, port knocking, etc) but ready to go out of the box.

It's not TCP based so you can't port scan it like SSH, and it will only respond on successful authentication, so a failed attempt is undistinguishable from it not being there.

It is also fairly easy to DoS SSH by having too many connections in the authentication state leaving no slots open, which SSHGuard is useful to counter.

Apart from that, SSH's intrinsic security is the same, but if you have password authentication enabled, you are only as strong as the weakest password.

> Apart from that, SSH's intrinsic security is the same, but if you have password authentication enabled, you are only as strong as the weakest password.

A number of configurations also ship with ssh root login enabled by default. For example if you setup a new Linode VPS. You need to add a user, remember to at least turn off root access and probably also password access. I get why they're doing it because it easier, but yeah ... not a huge fan of this configuration.

Never used Linode. Most of the services I am familiar with will let you upload your SSH public key that is auto provisioned for root authorized_keys by cloud-init. Using SSH certificates would be even better but I don’t know of any cloud that support them.

Yup, Linode does that too, but unless they changed things it still ships with root login + password auth enabled by default.

I agree, neither is a sensible default.

That sound like big advantages indeed, thanks.

This is akin to asking if a bike is more reliable than a car. They are very different use cases with different implications, so it depends on what you're doing with them and how.

Wireguard is just a very simple network bridge. Whoever has the key can send anything over the network. There isn't a robust mechanism required to keep the key, to revoke it, to audit its use, to enable it to only provide access to specific applications. It doesn't have 1/20th the features SSH has, and SSH itself lacks a bunch of security features.

Bottom line is that you should only use Wireguard if you need a simple encrypted network bridge. It does not remove the need for other more complex security products.

> This is akin to asking if a bike is more reliable than a car.

It's really not. It's a technical question with many technical answers, thankfully they were provided by other commenters before you posted this.

If anything, it's similar to asking if a bike is faster than a car, to which you would reply than a bike might be faster in traffic because of small size but slower over long distances because of propulsion. It is possible to compare apples and oranges over specific axes.

> This is akin to asking if a bike is more reliable than a car. They are very different use cases with different implications, so it depends on what you're doing with them and how.

Cars and bikes are both fine for point to point travel. They'll each give you a vastly different experience though. It"s prolly better to stick with what you know how to use, in my opinion. You're likely gonna have a bad day if you crash and die.

It has orders of magnitude less code (which has been reviewed by many people), its configuration is a lot simpler, and it doesn’t allow password authentication, so… probably yes?

Edit: deleted false information about TLS.

SSH doesn't rely on TLS and I'm sure its transport isn't a lot of code.

My bad. I was fooled by it using OpenSSL/LibreSSL.

What I find funny though is that every implementation not involving Donenfeld has "drama" (Free- and NetBSD). The small code still leave a lot of room for failure.

That’s why I mentioned reviewed code. The original FreeBSD code which sparked the drama wasn’t reviewed.

And honestly some of the issues that were there are not something preventable by limiting oneself to even 50 LOC. I don’t want to speculate how they came to be though. It’s really baffling.

It was reviewed, with prejudice. Netgate (company behind pfSense) asked Donenfeld "by the way, we are merging this into FreeBSD next week, would you mind having a look?". Donenfeld dropped whatever he was doing (the short notice period: not cool at all), looked at the code, was horrified by what he saw, and blew the whistle. Instead of being grateful, the team at Netgate/pfSense started being snitty. Colin Perceval (Chief Security Officer for FreeBSD) decided to just yank it, but the clear influence Netgate has over the FreeBSD project is not a good look.

Here's a good summary:

https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...

Contrast this with how easily and well Wireguard was integrated into OpenBSD.

The issue with fail2ban is that it's an extremely heavy python application. It takes up a boatload of resources!

SSHGuard however is much lighter and even less to configure manually.

From quickly skimming the docs, Fail2Ban can do a few other things like execute a script for the action. I have it doing an API call to block the offending IP on OPNSense firewall.

I am not trying to compare fail2ban and SSHGuard.

I used fail2ban in the past and it was helpful.

If I was currently running an Internet-facing SSH daemon, I would give SSHGuard a try.

This is advice from the 90s and is mostly security through obscurity, except for the last one. Modern advice: don’t use password auth.

Dismissing security through obscurity as pointless is an advice from the 90s.

Basically security comes with layers of obscurity. Even key based auth is a random string that no one is meant to guess.

If you have more obscurity, the less chance one reaches to the actual attack surface.

If an attacker gains a key, without fail2ban etc, he may try bunch of user names against the key file consecutively but if a login attempt is limited to 3 times every 5 minutes, see it's better than nothing.

Crowdsec seems to be the modern Fail2Ban replacement, it works quite well and has led to some useful insights.

Reply on news.ycombinator.com