How to harden against SSH brute-forcing?

someacnt@sh.itjust.works · 3 days ago

How to harden against SSH brute-forcing?

Xanza@lemm.ee · 3 days ago

Disable passwordless login.
Disable password login.
Require SSH keys
Move SSH port to non-standard port
Reject connections to port 22
Install and enable fail2ban

About the best you can do.

Semperverus@lemmy.world · 3 days ago

Don’t reject connections to port 22, honeypot it and ban on connection attempt.

sugar_in_your_tea@sh.itjust.works · 3 days ago

honeypot

That’s a lot more work.

ILaughBecauseFunny@feddit.dk · 2 days ago

By all means, I am no expert, but isn’t it “just” the fail2ban?

markstos@lemmy.world · 3 days ago

Using a nonstandard port doesn’t get you much, especially popular nonstandard ports like 2222.

I used that port once and just as much junk traffic and ultimately regretted bothering.

friend_of_satan@lemmy.world · 3 days ago

My experience running several ssh servers on uncommon nonstandard ports for over 10 years has been that it has eliminated all ssh brute forcing. I don’t even bother with fail2ban. I probably should though, just in case.

Also, PSA: if you use fail2ban, don’t try tab completing rsync commands without using controlmaster or you will lock yourself out.

irmadlad@lemmy.world · 3 days ago

My two cents: Using a nonstandard ssh port is good for dumping bots. True, you can easily do a port scan against a server and easily find all open ports nbd. But most off-the-shelf bots are looking for standard ports to penetrate. I know that when I format and reinstall the test server, as soon as I change the ssh port, bot noise goes down significantly. So, for a simple config edit and about 2 minutes of time, it seems worth the effort. It’s just one layer tho. And yes, it goes without saying to pick a port other than 22, 222, 2222, etc.

cmnybo@discuss.tchncs.de · 3 days ago

It gets rid of most of the login attempts for me. I don’t use a popular port though. Pick a 5 digit port so they have to put in some effort to find it.

Phoenixz@lemmy.ca · 3 days ago

Move the ssh port to higher ranges, 30-60000. That alone will stop 99% of the attacks

Disable root logins, now usernames must be guessed too which will make success even lower

Then require SSH keys

At that point it’s like being in a nuclear fallout nshelter behind a 3 meter thick steel door and you can hear some zombies scratching on the outside… I’m not worried about any of that shit

StructureOfChaos@lemmynsfw.com · 2 days ago

Regarding SSH Keys, I was wondering how you keep your key safe and potentially usable from another client?

JoshCodes@programming.dev · 3 days ago

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

Phoenixz@lemmy.ca · 3 days ago

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

JoshCodes@programming.dev · 3 days ago

100% agree, that is a “totally for fun” exercise

null_dot@lemmy.dbzer0.com · 3 days ago

This is what I do. Changing the port to a higher number will prevent almost all bots.

I understand that obscurity is not security but not getting probed is nice.

Also ssh keys are a must.

I do log in as root though.

However, I block all IPs other than mine from connecting to this port in my host’s firewall. I only need to log in from home, or my office, and in a crisis I can just log in to OVH and add whitelist my IP.

CondorWonder@lemmy.ca · 3 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@feddit.org · 3 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 · 3 days ago

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

Lucy :3@feddit.org · 3 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 · 3 days ago

Also, add 2FA

Lucy :3@feddit.org · 3 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 · 3 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 · 3 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)

kylian0087@lemmy.dbzer0.com · 3 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.

BrianTheeBiscuiteer@lemmy.world · 3 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@lemmy.nekusoul.de · edit-2 3 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.

zr0@lemmy.dbzer0.com · edit-2 3 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 · 3 days ago

did you mean crowdsec instead of crowdstrike?

zr0@lemmy.dbzer0.com · 3 days ago

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

whodatdair@lemmy.blahaj.zone · 3 days ago

Vietnam stare

Dima@feddit.uk · edit-2 3 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 · 3 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 3 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 3 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).

Arghblarg@lemmy.ca · 3 days ago

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

irmadlad@lemmy.world · edit-2 3 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@lemmy.dbzer0.com · 3 days ago

No Port-knocking? Amateurs! /s

RonnyZittledong@lemmy.world · 3 days ago

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

JubilantJaguar@lemmy.world · 3 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.

troed@fedia.io · 3 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)

NekuSoul@lemmy.nekusoul.de · 3 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 · 3 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.

sugar_in_your_tea@sh.itjust.works · 3 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@fedia.io · 3 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)

Realitätsverlust@lemmy.zip · 3 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 3 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.

bizdelnick@lemmy.ml · 2 days ago

The best way is to disable password login and use SSH keys only. Any further steps are not required, but you may additionally install fail2ban or sshguard.

Waryle@jlai.lu · edit-2 3 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 · 3 days ago

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

CausticFlames@sopuli.xyz · 3 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 · 3 days ago

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

hemmes@lemmy.world · 3 days ago

What VPS are you using?

You should be able to setup a firewall, blocking all access to the SSH port. Then setup a VPN so that only you can access via SSH after making your VPN connection.

If you connect via a static IP, you can also create an ACL for the VPN connection just in case. You can set an ACL for the SSH port forward rule directly as well, but I don’t like that personally. I prefer keeping things behind the VPN.

Voroxpete@sh.itjust.works · 3 days ago

This is the correct answer. Never expose your SSH port on the public web, always use a VPN. Tailscale, Netmaker or Netbird make it piss easy to connect to your VPS securely, and because they all use NAT traversal you don’t have to open any ports in your firewall.

Combine this with configuring UFW on the server (in addition to the firewall from the VPS provider - layered defence is king) and Fail2Ban. SSH keys are also a good idea. And of course disable root SSH just in case.

With a multi-layered defence like this you will be functionally impervious to brute force attacks. And while each layer of protection may have an undiscovered exploit, it will be unlikely that there are exploits to bypass every layer simultaneously (Note for the pendants; I said “unlikely”, not “impossible”. No defence is perfect).

troed@fedia.io · 3 days ago

This is not “the correct answer”. There’s absolutely nothing wrong with “exposing” SSH.

Voroxpete@sh.itjust.works · 3 days ago

You seem like a fan of the “pull out” method.

callcc@lemmy.world · 3 days ago

Public ssh is completely fine as long as you use key based auth only and keep your sshd up to date. Stop spreading bullshit.

Voroxpete@sh.itjust.works · 3 days ago

A lot of things are “fine”, but the cost of adding Netbird to your VPS is effectively zero, whether counted in dollars, time, or convenience.

Given the massive security benefits of using a VPN, and the lack of any meaningful downside to doing so, you’d be an idiot not to.

moonpiedumplings@programming.dev · 3 days ago

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.

Voroxpete@sh.itjust.works · 3 days ago

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.

callcc@lemmy.world · 3 days ago

And why exactly is that more secure?

sugar_in_your_tea@sh.itjust.works · 3 days ago

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

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

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.

troed@fedia.io · 3 days ago

Feel free to argue with facts. Hardening systems is my job.

Voroxpete@sh.itjust.works · 3 days ago

And mine. Clearly one of us is better at it.

peregus@lemmy.world · 3 days ago

Exactly, this I what alI do!