How to harden against SSH brute-forcing?

@someacnt@sh.itjust.works · 10 days ago

How to harden against SSH brute-forcing?

@RonnyZittledong@lemmy.world · 10 days ago

Disable passwords and use public private keys and don’t worry about it

@JubilantJaguar@lemmy.world · 10 days ago

This is the only answer you need to read. It’s a non-problem if you just do this, and there’s no reason not to do it.

@callcc@lemmy.world · 9 days ago

Agreed!

Waryle · edit-2 10 days ago

You can look up for:

Setting up max authentication attemps per connection -> slows up a lot brute force attacks. If your password is strong enough, that’s already a big step to secure your server.
Generate SSH Keys and disable password authentication -> do this only if you’re connecting through the same devices, because you won’t be able to connect from any device that has not being set up. Personally I don’t use this because I want to be able to access my server even if I’m not home and without my laptop
Set up Crowdsec -> it’s a local service which scans logs and will block access to any suspicious IPs. It also relies on a crowdsourced list of IPs that are identified as threat and will preventively block them

@LlilL@lemm.ee · 10 days ago

Is this an alternative/replacement to fail2ban or something you would use along with f2b?

@CausticFlames@sopuli.xyz · 10 days ago

You could technically still use it alongside f2b, but in my experience Crowd-Sec seems to do a better job and can do the same things.

@LlilL@lemm.ee · 9 days ago

Thank for that! You just turned a student onto a new tool to play with.

troed · 10 days ago

A few replies here give the correct advice. Others are just way off.

To those of you who wrote anything else than “disable passwords, use key based login only and you’re good” - please spend more time learning the subject before offering up advice to others.

(fail2ban is nice to run in addition, I do so myself, but it’s more for to stop wasting resources than having to do with security since no one is bruteforcing keys)

@sugar_in_your_tea@sh.itjust.works · 10 days ago

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:

block obviously bad packets at the firewall level
eliminate insecure modes of login (only allow key-based login)
something like fail2ban to ban the few who make it through 1 & 2
use a secure root password so if someone does get in, they’re less likely to get root access
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).

troed · 9 days ago

Still no. Here’s the reasoning: A well known SSHd is the most secure codebase you’ll find out there. With key-based login only, it’s not possible to brute force entry. Thus, changing port or running fail2ban doesn’t add anything to the security of your system, it just gets rid of bot login log entries and some - very minimal - resource usage.

If there’s a public SSHd exploit out, attackers will portscan and and find your SSHd anyway. If there’s a 0-day out it’s the same.

(your points 4 and 5 are outside the scope of the SSH discussion)

@sugar_in_your_tea@sh.itjust.works · 9 days ago

It’s also one of the biggest targets for attack. Here’s a somewhat recent CVE and here is another. Staying on top of security patches is absolutely critical, and many don’t do that.

The best security practice is to layer your protections.

your points 4 and 5 are outside the scope of the SSH discussion

They’re not about SSH, sure, but they are relevant to securing a system to remote access. Always assume your security infra will be compromised and plan accordingly. Generally speaking, the more layers, the better.

NekuSoul · 10 days ago

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 · 10 days ago

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.

@kylian0087@lemmy.dbzer0.com · 9 days ago

Configure the firewall with a IP whitelist to only allow connections to ssh be made from your home IP.

Other then that, disable password logon for ssh and setup up key based authentication.

@sugar_in_your_tea@sh.itjust.works · 9 days ago

Agreed, but be careful about the whitelist. If your home IP changes, you’ll be locked out until you update it, so you should consider an IP range if that’s a possibility for you. Likewise, if you’ll be accessing it from multiple locations (say, a family member’s house), then make sure to add those as well.

Gerowen · edit-2 9 days ago

I generally do a few things to protect SSH:

Disable password login and use keys only
Install and configure Fail2Ban
Disable root login via ssh altogether. Just change “permit root login” from “no password” to just “no”. You can still become root via sudo or su after you’re connected, but that would trigger an additional password request. I always connect as a normal user and then use sudo if/when I need it. I don’t include NOPASSWD in my sudoers to make certain sudo prompts for a password. Doesn’t do any good to force normal user login if sudo doesn’t require a password.
If connecting via the same network or IPs, restrict the SSH open port to only the IPs you trust.
I don’t have SSH internet visible. I have my own Wireguard server running on a separate raspberry pi and use that to access SSH when I’m away, but SSH itself is not open to the internet or forwarded in the router.

k_rol · 9 days ago

I vote for wireguard here, I don’t expose anything other than game servers to the internet

Possibly linux · 9 days ago

Use key based auth only and then run ssh-audit.

@BrianTheeBiscuiteer@lemmy.world · 10 days ago

In addition to other advice you could also use SSH over Wireguard. Wireguard basically makes the open port invisible. If you don’t provide the proper key upfront you get no response. To an attacker the port might as well be closed.

Here’s at least one article on the subject: https://rair.dev/wireguard-ssh/

NekuSoul · edit-2 10 days ago

Exactly. No root login and no password login will do just fine 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.

@sugar_in_your_tea@sh.itjust.works · 9 days ago

Just remember that you’ll only be able to SSH in w/ a device that’s already configured for WireGuard. So if you’re at a friend’s house and haven’t set up your phone to do it yet, you’ll be forced to use the VPS console to get in. Make sure this is what you want before you do it.

@tomsh@lemmy.world · 9 days ago

In addition to what others say, I also have ntfy notifications on successful login.

@joseandres42@lemmy.world · 9 days ago

That’s genius. I’ll do the same from now on.

@tomsh@lemmy.world · 9 days ago

There is actually an example on their website.

ntfy ssh login alert

@CondorWonder@lemmy.ca · 10 days ago

We can’t ever stop this kind of stuff, but with something like fail2ban you can set it up to block on too many failures.

Really though - ensuring your system is kept up to date and uses strong passwords or use a SSH keys is the best defence. Blocking doesn’t prevent them from trying a few times. Moving SSH to a non standard port will stop most of the automated attacks but it won’t stop someone who is dedicated.

Lucy :3 · 10 days ago

Move SSH to non-standard port, make endlessh use the default port. Only use SSH keys. Only allow correct users (so eg. your user and git/forgejo). Use fail2ban to aggressively ban (redirect to default port, so 22) and report to abuseipdb everything that fails to authenticate first try (wrong user, password instead of key), has non-compatible ciphers (generally, only allow TLS1.3 etc.), or fails in any other way. Just be sure that if you accidentally get banned yourself (eg. Ctrl+C-ing during authentication), you can use another IP (eg. force v4) for connecting.

@cron@feddit.org · 10 days ago

Nice list of suggestions, but implementing all of them feels a little over-the-top.

Lucy :3 · 10 days ago

Tbh, I myself still have SSH on port 22. Firstly, because I’m lazy, and secondly … yeah that’s it. I’m honestly just lazy. But spam bots trying office/cookie123 are not a real threat, and anyone trying to actually target me will either have somehow acquired my key + password, use one of the probably many security issues that exist in the dozen services I selfhost, social engineer me into doing something (not saying I’ve given out my (old) KeePass password once, but it could be, as love makes blind (I still love her)), or just smash my kneecaps until I give out everything.

@bigBananas@feddit.nl · 10 days ago

Also, add 2FA

Lucy :3 · 10 days ago

But remember, on a third device. Not the one where your KeePass DB is one fingerprint away, and your private SSH key too.

@someacnt@sh.itjust.works · 10 days ago

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?

@WhyJiffie@sh.itjust.works · 9 days ago

I’m not them, but among other reasons they are looking to build botnets (cryptomining, dosing, mass crawling), and they are searching for hosts with low security (or if you just made a mistake)

irmadlad · edit-2 10 days ago

OP, here is what I do. It might seem overboard, and my way doesn’t make it the best, or the most right, but it seems to work for me:

Fail2ban
UFW
Reverse Proxy
IPtraf (monitor)
Lynis (Audit)
OpenVas (Audit)
Nessus (Audit)
Non standard SSH port
CrowdSec + Appsec
No root logins
SSH keys
Tailscale
RKHunter

The auditing packages, like Lynis, will scour your server, and make suggestions as to how to further harden your server. Crowdsec is very handy in that it covers a lot of ‘stuff’. It’s not the only WAF around. There is Wazuh, Bunkerweb, etc. Lots of other great comments here with great suggestions. I tend to go overboard on security because I do not like mopping up the mess after a breach.

ETA: just looked up one of your attackers:

218.92.0.201 was found in our database! This IP was reported 64,044 times. Confidence of Abuse is 100%: ISP CHINANET jiangsu province network Usage Type Fixed Line ISP ASN AS4134 Domain Name chinatelecom.cn Country China City Shanghai, Shanghai

busy little cunts.

db0 · 9 days ago

No Port-knocking? Amateurs! /s

@sugar_in_your_tea@sh.itjust.works · 9 days ago

It’s absolutely overboard, and you can get 99% of the way there with this:

WireGuard config (Tailscale in your case)
Bind SSH to WireGuard IP only (so no public SSH port)
SSH keys only, and disable root login over SSH

That will require breaking WireGuard and openSSH’s key-based authentication, which just isn’t happening. The rest looks like mostly auditing. Even a firewall isn’t necessary if no ports are accessible anyway (i.e. everything only accessible over Tailscale), and you can just configure iptables to block everything on the WAN IP and call it a day.

irmadlad · 9 days ago

sugar_in_your_tea @sh.itjust.works

It’s nice to be commented by someone famous.

Open up the window, let some air into this room I think I’m almost chokin’ from the smell of stale perfume And that cigarette you’re smokin’ 'bout scare me half to death Open up the window, sucker, let me catch my breath

@sugar_in_your_tea@sh.itjust.works · edit-2 9 days ago

Mama told me not to come.

Fun fact, my usernames on Reddit (I would cycle them every couple of years) were all Three Dog Night lyrics, so I continued the theme on Lemmy.

Thanks for noticing. 😀

@zr0@lemmy.dbzer0.com · edit-2 9 days ago

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

@om1k@sopuli.xyz · 9 days ago

did you mean crowdsec instead of crowdstrike?

@zr0@lemmy.dbzer0.com · 9 days ago

Fml… yes, I meant CrowdSec. Thanks for the hint

@whodatdair@lemmy.blahaj.zone · 9 days ago

Vietnam stare

@dev_null@lemmy.ml · 9 days ago

Your answer to “how to harden SSH?” is “harden SSH”?

I know your two other points gave concrete suggestions, but it’s pretty funny you suggested to “harden sshd” when that is what OP is asking how to do.

@zr0@lemmy.dbzer0.com · 9 days ago

Yeah, I see your point. No use to repeat the same you can read in other comments or in those 274772 guides online. I was trying to imply to just generally harden ssh because then brute-force attempts should be no issue, unless you log everything and the disk space gets maxed out :D

@sugar_in_your_tea@sh.itjust.works · 9 days ago

harden sshd

More details:

require keys to login
don’t allow login as root

That should be plenty, but you could go a bit further and restrict the types of algorithms allowed (e.g. disallow RSA if you’re worried about quantum attacks). For this, I recommend a subtractive config (e.g. HostbasedAcceptedAlgorithms=-rsa-*). This is way over the top since an attacker is unlikely to attack the cipher directly, but it could be part of an attack.

Arghblarg · 9 days ago

There’s a dedicated tool named sshguard which works nicely.

EarMaster · edit-2 10 days ago

For a general guide on how to make ssh more secure I stick to https://www.sshaudit.com/

You can check your config and they also provide step by step guides for several distros…

@Dima@feddit.uk · edit-2 10 days ago

For security disable password authentication - use public key instead, disable root login via ssh - use sudo or su from another user.

To reduce the number of attempts of others trying to get in change the ssh port and/or set-up fail2ban.

You could also set a firewall rule to only allow ssh from your IP address, if you have a static address at home and only need access from there, or have a way to VPN into your home network. Make sure you have a static address if you do this though, you don’t want your IP to change and be left locked out of your server.

@sugar_in_your_tea@sh.itjust.works · 10 days ago

You could also set a firewall rule to only allow ssh from your IP address

You can also broaden this to a region. You may still want to access SSH from various places around your country (e.g. when visiting family or friends), but likely won’t ever need to from most of the rest of the world, so block everything except IPs from your region (or regions you care about, e.g. any VPSs you have).

@7toed@midwest.social · edit-2 10 days ago

No if you’re doing that, use a VPN through your firewall. Local traffic is a fair exception as this can only ever be a device on your network, but that depends on your threat model (as those local devices could be compromised). Opening to “your region’s” IP range opens you to a lot more than LAN access…

@sugar_in_your_tea@sh.itjust.works · edit-2 10 days ago

Sure. I’m just assuming that you’d want to access it from areas in your region, like at a friend or family member’s house, work, coffee shop, etc. This is especially true if you or one of them has DHCP from their ISP. You only really need to whitelist a handful of IP ranges to get most of the benefit of IP-based blocking and most of the convenience of not having a block.

If you only ever truly need it at home, then sure, do that. In fact, for something like SSH, you could probably create a Wireguard endpoint that’s accessible almost anywhere and connect to that before logging in via SSH.

My point is to not make it more restrictive than you need, otherwise it’ll just be frustrating and you’ll end up disabling whatever protections you have. You can get a lot of value with a broad ban on troublesome areas (e.g. I don’t visit most of the places OP has in their logs, so those would be banned), and then fine-tune the rest w/ something like fail2ban.

I use my ISP’s firewall rule to whitelist regions I’m interested in, such as:

data centers where I have services
my town and my friends’ and families’ towns
the town near where I work

I have different rules by port, so SSH is a lot more restricted than HTTP(s).

Realitätsverlust · 10 days ago

You don’t. This is normal. Ensure key-only auth, ensure you do not login directly as root, maybe install fail2ban and you’re good. Some people move the port to a nonstandard one, but that only helps with automated scanners not determined attackers.

You could look into port-knocking if you want it really safe.

@suicidaleggroll@lemm.ee · edit-2 10 days ago

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.