3 ms·

SSH is constantly hammered by bots as well: % ssh example.com Last failed login: Sun Jan 28 16:59:35 UTC 2024 from 180.101.88.233 on ssh:notty Ther

by sph 3y ago

SSH is constantly hammered by bots as well: % ssh example.com Last failed login: Sun Jan 28 16:59:35 UTC 2024 from 180.101.88.233 on ssh:notty There were 5385 failed login attempts since the last successful login. Last login: Sat Jan 27 13:33:30 2024 from xxx.xxx.xxx.xxx 5.3k failed attempts in ~30 hours. I know, I should be setting up fail2ban.

SoftTalker 3y ago
fail2ban will reduce your log noise but it's another thing to manage, you can end up locking yourself out also, and if you're using good passwords (or better, public key auth) it's not really providing any additional safety. Ideally you don't need ssh open to the whole world anyway, and can restrict it to a certain subnet or set of addresses. Then your attacks will drop to nearly zero.
NavinF 3y ago
> I should be setting up fail2ban. No, that does nothing if you followed best practices and disabled password login. fail2ban is just another Denial of Service risk that has the added bonus of bloating your firewall table and slowing down all your new connections
idoubtit 3y ago
fail2ban is not very performant and it will only reduce the amount of attempts. An alternative is to add a nftables rule (or iptables or whatever firewall). Something like : table inet filter { chain input { tcp dport ssh accept comment "Accept SSH" tcp dport 22 ct state new limit rate over 2/minute drop But even with rate limiting, the logs are still polluted by auth attempts. Changing the port does little. The only solution we found was to configure port knocking (with direct access from a few whitelisted IPs).
miyuru 3y ago
Most of my servers are IPv6 only and there are no failed ssh attempts on those. I install fail2ban just in case and firewall the IPv4 address, since I don't SSH via IPv4.
nerdponx 3y ago
I set my SSH port to something with a high number that is not used by any other known service. Drive-by attacks dropped to 0.
vldb7 3y ago
I’m not a fan of fail2ban. A simple but quite effective approach would be permitting remote login only from certain IP ranges. I know that it looks like a bad trade for self hosted web apps, but it is very easy to setup on many cloud providers. Also I normally set up a jump host first - a smallest instance that only runs ssh and everything else would not open ssh port to the outside at all. One nice effect is having to search just one auth log if something about ssh looks concerning.
emmanueloga_ 3y ago
In case you are using AWS, I learned that you can close port 22 on your EC2 instances, and connect trough the Systems Manager (SSM): https://cloudonaut.io/connect-to-your-ec2-instance-using-ssh-the-modern-way/ https://cloudonaut.io/connect-to-your-ec2-instance-using-ssh...

by sph 3y ago

SoftTalker 3y ago

fail2ban will reduce your log noise but it's another thing to manage, you can end up locking yourself out also, and if you're using good passwords (or better, public key auth) it's not really providing any additional safety. Ideally you don't need ssh open to the whole world anyway, and can restrict it to a certain subnet or set of addresses. Then your attacks will drop to nearly zero.

NavinF 3y ago

> I should be setting up fail2ban. No, that does nothing if you followed best practices and disabled password login. fail2ban is just another Denial of Service risk that has the added bonus of bloating your firewall table and slowing down all your new connections

idoubtit 3y ago

fail2ban is not very performant and it will only reduce the amount of attempts. An alternative is to add a nftables rule (or iptables or whatever firewall). Something like : table inet filter { chain input { tcp dport ssh accept comment "Accept SSH" tcp dport 22 ct state new limit rate over 2/minute drop But even with rate limiting, the logs are still polluted by auth attempts. Changing the port does little. The only solution we found was to configure port knocking (with direct access from a few whitelisted IPs).

miyuru 3y ago

Most of my servers are IPv6 only and there are no failed ssh attempts on those. I install fail2ban just in case and firewall the IPv4 address, since I don't SSH via IPv4.

nerdponx 3y ago

I set my SSH port to something with a high number that is not used by any other known service. Drive-by attacks dropped to 0.

vldb7 3y ago

I’m not a fan of fail2ban. A simple but quite effective approach would be permitting remote login only from certain IP ranges. I know that it looks like a bad trade for self hosted web apps, but it is very easy to setup on many cloud providers. Also I normally set up a jump host first - a smallest instance that only runs ssh and everything else would not open ssh port to the outside at all. One nice effect is having to search just one auth log if something about ssh looks concerning.

emmanueloga_ 3y ago

In case you are using AWS, I learned that you can close port 22 on your EC2 instances, and connect trough the Systems Manager (SSM): https://cloudonaut.io/connect-to-your-ec2-instance-using-ssh-the-modern-way/ https://cloudonaut.io/connect-to-your-ec2-instance-using-ssh...