Fail2ban Not Blocking Non-Standard SSH Port: Why 22022 Was Open
One day, I started noticing continuous SSH brute-force attack attempts on the DB server I manage. To enhance security, I had changed the default SSH port from 22 to 22022, and naturally, fail2ban was installed with the sshd jail enabled. I thought, 'Surely fail2ban will block them,' and watched, but the attacks didn't stop. When I ran the fail2ban-client status sshd command, I saw that the 'Banned' list was empty. I thought it was enabled and running well, so why weren't the attacking IPs being blocked? This post details how I identified and resolved the cause of this puzzling situation I experienced firsthand.
What This Post Covers
Why fail2ban might not work on a non-standard SSH portThe impact of the sshd jail's port setting on blockingHow to modify fail2ban settings using jail.localHow to verify if fail2ban is actually blocking IPs*Target Audience:* Solo developers and server administrators who operate SSH on a port other than the default 22.Difficulty: Beginner
SSH Brute-Force Attacks Continued Despite Fail2ban Activation
For security, the DB server I manage used SSH access on port 22022 instead of the default port 22. However, at some point, I started seeing continuous SSH brute-force attempts from a specific IP in the logs. Since fail2ban was installed and the sshd jail was enabled, I naturally expected the attacking IP to be automatically blocked. But as time passed, the attacks didn't stop. Even checking fail2ban's status with the fail2ban-client status sshd command showed the Banned IP list consistently empty. The fail2ban service was running normally, but it wasn't actually blocking the attackers. Login failure records were clearly accumulating in the logs, so I wondered why fail2ban wasn't translating these into blocks. It was a moment when I realized that a service 'running' and 'doing its job' are completely different things.
The Blocking Gap Caused by 'port = ssh' Default Setting and Actual Port Mismatch
Delving deeper into the cause of the problem, I found an issue with fail2ban's default sshd jail configuration. Looking at fail2ban's default configuration file, jail.conf, you'll find port = ssh specified in the sshd jail section. Here, 'ssh' refers to the default port 22, as defined in the /etc/services file. This means fail2ban's sshd jail was configured by default to detect and apply blocking rules for SSH attack attempts coming through port 22. However, my server's actual SSH service was running on port 22022, and login failure logs were also recorded based on port 22022. The fail2ban filter likely successfully identified the attacking IPs by analyzing the logs. But because the jail's port setting was fixed at 22, even when fail2ban generated blocking rules via iptables, those rules only applied to port 22. Consequently, port 22022, where the actual attack traffic was coming in, remained open without any blocking measures. The fundamental cause was a paradoxical situation where a security enhancement (using a non-standard port) conflicted with fail2ban's default settings, effectively neutralizing its blocking function.
Explicitly Specifying the SSHD Jail Port in jail.local
Once the cause of the problem was identified, the solution was clear. I needed to change fail2ban's sshd jail configuration to recognize the actual SSH service port. Instead of directly modifying fail2ban's default configuration file, jail.conf, it's good practice to create a jail.local file to override the desired settings. This prevents settings from being reset by package updates. I opened the /etc/fail2ban/jail.local file and added or modified the sshd jail settings as follows. Here, I explicitly specified the port as 22022, the actual SSH port, and adjusted values like maxretry, findtime, and bantime to suit my operating environment as needed. maxretry is the allowed number of retries, findtime is the time window to find those retries, and bantime is the duration of the ban. After completing the settings, I restarted the fail2ban service with systemctl restart fail2ban to apply the changes. Now, fail2ban can detect SSH login attempts on port 22022 and apply blocking rules for that port. /etc/fail2ban/jail.local [sshd] enabled = true port = 22022 filter = sshd maxretry = 3 findtime = 600 bantime = 86400
Immediate Blocking and Prevention of Recurrence After Configuration Change
As soon as I restarted the fail2ban service, I could immediately see its effect. Running the sudo fail2ban-client status sshd command again, I found that 13 attacking IP addresses, which had previously accumulated in the logs, were immediately registered in the Banned IP list in the order they exceeded the threshold. The attacks that had been attempted countless times were finally blocked by fail2ban. Additionally, checking the actual iptables rules with sudo iptables -L -n | grep 22022 showed that DROP rules for port 22022 were correctly created. This was clear evidence that fail2ban was properly blocking traffic to port 22022. Subsequently, there were retries from the same attacking IPs, but the connection to the server itself was blocked, and no further login attempt logs occurred. This experience reinforced how crucial it is not to simply assume fail2ban is working just because it's 'running,' but to verify that it's 'properly blocking' with correct settings. Post-application status check sudo systemctl restart fail2ban sudo fail2ban-client status sshd Verify actual blocking rules sudo iptables -L -n | grep 22022
Conclusion
Just because fail2ban is enabled doesn't mean it's blocking all attacks. Especially in environments where the SSH port is changed from the default 22 to another port, you must ensure that the fail2ban sshd jail settings (especially the port entry) match the actual service port. Remember that 'running' and 'actually blocking' are completely different issues, and I recommend maintaining a robust security system through regular status checks with commands like fail2ban-client status. I hope this experience helps those who find fail2ban not working as expected due to non-standard port usage.
