How to harden against SSH brute-forcing?

[moonpiedumplings@programming.dev]

This is moving the goal posts. You went from "ssh is not fine to expose" to "VPN's add security". While the second is true, it's not what was being argued.

Never expose your SSH port on the public web,

Linux was designed as a multi user system. My college, Cal State Northridge, has an ssh server you can connect to, and put your site up. Many colleges continue to have a similar setup, and by putting stuff in your homedir you can have a website at no cost.

There are plenty of usecases which involve exposing ssh to the public internet.

And when it comes to raw vulnerabilities, ssh has had vastly less than stuff like apache httpd, which powers wordpress sites everywhere but has had so many path traversal and RCE vulns over the years.

[sugar_in_your_tea@sh.itjust.works]

honeypot

That's a lot more work.

[zr0@lemmy.dbzer0.com]

• harden sshd
• use fail2ban or even better CrowdStrike
• use a tool like the following to have a next-gen security solution: https://github.com/mrash/fwknop

[Guest]

Some people move the port to a nonstandard one, but that only helps with automated scanners not determined attackers.

While true, cleaning up your logs such that you can actually see a determined attacker rather than it just getting buried in the noise is still worthwhile.

[sugar_in_your_tea@sh.itjust.works]

There's more to it than that.

I recommend geoip blocking anything outside of your expected operating regions in addition to using key-based logins. iptables operates at a lower level in the network stack than SSH, so the vulnerability surface is a lot lower, and blocking before something actually looks at the packets cleans up the logs. This is huge because it makes it a lot more obvious when there's a legitimate attack.

Cover yourself with layers:

1. block obviously bad packets at the firewall level
2. eliminate insecure modes of login (only allow key-based login)
3. something like fail2ban to ban the few who make it through 1 & 2
4. use a secure root password so if someone does get in, they're less likely to get root access
5. have your services run as non-privileged users to limit issues if something gets compromised

If you only do one thing, it should be only allowing key-based logins. If you do two, run SSH on a non-standard port or set up geoip blocking (second is more work, but a lot more effective).

[nekusoul@lemmy.nekusoul.de]

Exactly. No root login and no password login are always useful as basic measures, but after that Wireguard is perfect tool for this, no weird rituals required and also quite useful for any other services you don't want and/or need to expose to the internet as well.

[Guest]

Main reason is that if you don't already have the right key, VPN doesn't even respond, it's just a black hole where all packets get dropped. SSH on the other hand will respond whether or not you have a password or a key, which lets the attacker know that there's something there listening.

That's not to say SSH is insecure, I think it's fine to expose once you take some basic steps to lock it down, just answering the question.

[sugar_in_your_tea@sh.itjust.works]

I don't know about Netbird specifically, but adding a VPN does a few things:

• a port scan of your VPS/router won't show an SSH or VPN port active - Wireguard only acknowledges packets if your key is valid (massively more useful than just changing the port)
• compromising both a VPN and SSH is difficult, you'd have to chain exploits together
• if your VPN is hosted by a separate service (e.g. something like Tailscale), it will be very unlikely to share vulnerabilities with your hosted SSH server

[sugar_in_your_tea@sh.itjust.works]

You should be. Most of it's noise, but if there's a serious attack, you'll appreciate clean logs.

I think fail2ban is nice as like a third or fourth layer of defense. In order of my priorities:

1. key-only login, root login completely disabled
2. solid root password, and user privilege separation (have each service use its own user)
3. geoip bans - if you never plan to support clients in a given region, block it at the firewall level (or better yet, whitelist the handful of regions you care about); I do this by port, so SSH gets a much more restricted set of allowed regions than HTTPS
4. fail2ban - especially if you have a relatively large whitelist
5. only access SSH over a Wireguard VPN - Wireguard doesn't show up in port scans, and SSH can bind to the VPN host instead of 0.0.0.0, so the ability to login via SSH will be completely hidden

If you're not going to do 3-5, at least change the default SSH port to cut down on log noise.

[joshcodes@programming.dev]

For added funs run an SSH tarpit to fuck with the attackers, something like endlessh.

[voroxpete@sh.itjust.works]

We're in selfhosted. If you have to bring up use cases that are in no way relevant to 99% of self hosters to justify your argument, you don't have an argument.

[nekusoul@lemmy.nekusoul.de]

Eh, while I agree that some recommendations are dodgy at best, I'll argue that Wireguard is not only adding to security, it also makes Fail2Ban obsolete. Due to the way it works, you'll completely hide the fact that you're even running a SSH server at all, and this includes even Wireguard itself. More importantly though, it's pretty much impossible to set up Wireguard in an insecure way, whereas SSH provides you with plenty of footguns. You're not risking locking yourself out either.

Also, security comes in layers.

[sugar_in_your_tea@sh.itjust.works]

You’re not risking locking yourself out either.

In a VPS, you should always be able to fall back to the web console. So locking yourself out shouldn't be a major concern.

[phoenixz@lemmy.ca]

Well yeah, sure, but that doesn't really add to your security and it only costs you work and resources

[someacnt@sh.itjust.works]

Thanks a lot! Geoblocking makes a lot of sense, will try!

[sugar_in_your_tea@sh.itjust.works]

I highly recommend using key-based SSH authentication exclusively for all users on your server, and disallow root login as well.

Geoblocking mostly cuts down on the spam, but also constrains where an actual attack can come from. If there's some kind of zero-day attack on SSH, this will dramatically reduce the risk you're hit.

[moonpiedumplings@programming.dev]

Again, this is distracting from the original argument to make some kind of tertiary argument unrelated to the original one: Is ssh secure to expose to the internet?

You said no. And that statement is inorrect.

[someacnt@sh.itjust.works]

Thanks, I will try fail2ban. I am using ED25519 for ssh keys, it seems like it's the best defense on the ssh side.
Do you happen to know why this kind of attack is so prevalent?

[someacnt@sh.itjust.works]

Fortunately my VPS (oracle) has set SSH authentication to be default. Disallowing root login sounds good, gotta try that as well.

[joshcodes@programming.dev]

100% agree, that is a "totally for fun" exercise