Wouldn't it make more sense then to keep SSH on 22? Think of it like a honeypot. The more accessible you make it, the more bans you get. There was a guy on here saying that fail2ban banning SSH bruteforcers also reduced the number of HTTP bruteforcers, because they overlap.

Collecting bans isn't a good thing today with the scale of background noise malicious behavior. You will very quickly collect thousands of IP addresses doing this and need to implement ipset - an iptables plugin that allows O(log n) lookup time on a list of IP addresses.

Another issue; the overlap between SSH scanners also running HTTP/S attacks is negligible.

From experience; what makes sense is shifting your SSH port away from 22, disabling password based authentication, whitelisting your IP address from your cloud provider's firewall, and still aggressively auto-banning incorrect logins with fail2ban.

Then, for good measure, implement a WAF to protect your HTTP/S traffic as well.

Do not turn your production system into a honeypot. Only do this with a separate system that contains no valuable data.

Why can't there be an O(1) iptable? Just a hashmap?

For IPv4 it can be done, but it would take at least 512Mb of kernel memory. A hashmap would be inefficient in that case, just use a bit-array. For IPv6 however, you run out of memory with a bit-array. Using a dynamically allocated hashmap in the kernel in that would help the initial allocation, but then you can easily be DOS'ed by having a lot's of banned access and running out of kernel memory.

This is a noob question, but could you not setup fail2ban to ban bad IPs on both ports, even if you're not using SSH on one? I'm wondering if it's possible to close port 22 and set fail2ban rules to ban any IPs that try to SSH there, while changing your SSH port and also setting up fail2ban on that port, too. Does a closed port work like that?

You could have the firewall log connection attempts on port 22 and plug that into fail2ban.

fail2ban works by tailing authentication logs and matching regexes to find failed attempts and the IP address of the source. So if nothing is listening on the port, there won't be anything to spit out logs that fail2ban can read.

You could potentially create a fake daemon that listens on port 22 and just logs every access attempt, and set up fail2ban to block any IP that even opens a connection to the port, regardless of what they try to send over it.

Actually, I think iptables has a LOG target that can log connection attempts even without something listening, so that could work too and be much simpler.

Just make sure to exclude that port from service checks ;)

> anyone trying to log in with a password is full of it Dang! But so true