Thanks, I was unaware of this---I initially (naively?) thought that being banned would at least deter some wannabe attackers. In your experience, does it do anything if I start collecting some reports on repeat offenders and notify their ISP? Or is that just more wishful thinking of my part?
Absolutely nothing will be done about reports of people running SSH scanners against your host; it would be like Cnut on his seashore throne ruling the waves to recede: even in the unlikely event that a hosting provider shut someone off (we probably would, if you told us), they'd be followed by 10,000 more.
Thanks for the reality check, I appreciate it! At least I got a nice map out of this (and made sure that nothing was configured incorrectly, to the best of my knowledge)...
I don't think this idea is aligned with how these types of attacks actually work. The dumb stuff like this is almost entirely automated, nobody will notice enough to be deterred by it. Possibly whoever is running it will get a list of servers where the bruteforce login attempts worked, or maybe they just get some kind of low-effort thing like cryptominer or spam server installed automatically.
If an actual person of at least modest skill takes an interest in your server in particular, they're probably not going to do the sorts of things that would trigger fail2ban anyways. They're going to do things like probe around as lightly as possible to determine which services and which versions are running where to try and find things that are misconfigured or at known-vulnerable versions.
As an individual your reports will likely be ignored, however if you do want to report consider contributing to a service like AbuseIPDB. It probably doesn't do much either but at least it feels like I'm doing my part to report abuse and maybe some ISPs will choose to act on it.
That's one of many reason why https://crowdsec.net/ was created. It collects (anonymized) threat intelligence from all users, vets it and distributes it as relevant blocklists. Once there's enough users it will be a very effective way to fight bad guys. And unlike your suggestion it DOES make a difference. Currently around 800k signals are collected daily and around 19k vetted malevolent ips are distributed to users on a daily basis.
You should just not allow any IP to access your server to begin with… have a list of trusted IPs - this and only allow public / private key access with a second factor device and I think you should be good…
I like to be able to maintain contact with my servers outside of a few specific ip's - I've locked myself out far too many times when I whitelist a very small number.
Stop using fail2ban/tallow/etc, and follow a sensible guide like https://infosec.mozilla.org/guidelines/openssh to harden your ssh configuration. This will result in about half the attempts failing at protocol negotiation, long before auth (though that ratio is decreasing over time).
Wireguard is also very strong here, as it learned from this kind of problem in SSH and does not reply at all unless authentication succeeds. This makes debugging harder, but also makes leaving it openly listening quite a bit safer, as the protocol surface in pre-auth is absolutely minimal.
I found it harder to use. I even wrote tests for my use cases and what I learned was a real appreciation of what ssh does, is, and provides and I went the other way and use it in more places than I did before.
I don't know the mechanics, but a port knock is hitting pre-defined ports in a pre-defined order. When you "shave and a haircut" the ports properly, the server opens something up. In this case white listing (gray listing?) the IP that the knock came from.
You could add a layers to it to make it more complicated.
Please don't use silly stuff like port knocking. Your SSH server already does a cryptographically sound authentication step. "Port knocking" is even more performative than fail2ban.
I VPN into my home network as a bastion host, so I'm always connecting from the same IP.
I'm using the cloud providers IP filtering to block everything but my IP on port 22. If something goes horribly wrong, I can disable it thru their web interface.
During holiday trips, where I might need to access a server from anywhere, I use a list of one time passwords (more or less just a bunch of md5sums) which I can send to a server on https, which then adds the requesting ip address to /etc/hosts.allow for a limited time. This ip address will be able to connect via ssh (still secured with a key) then for that time.
This is a really cool idea! I've also toyed with a similar approach of watching ssh logs within very specific time windows and providing a one time key in order to temporarily add another SSH key which I can use to recover the server.
Probably a bit overkill - but it was a fun feature to implement with Go over the weekend. The new Fido2 SSH implementation is also incredibly cool.
Eh I’ve scanned the entire IPv4 space and tested default passwords over ssh from both AWS and my Comcast connection at home and never got banned from either one. I’m sure it can happen, but it’s no big deal.
The GP is right: If you use ed25519 keys, looking at logs and playing whack a mole with countries is just security theater for people who are new to the internet and get scared when their MOTD says “500 failed logins”.
That depends on the machine you are using. Tools like mass scan to locate open ssh ports and then testing them doesn’t need to take long if you have a beefy machine and pipe to the internet.
