I installed fail2ban on my server to ban brute force attacks. But, fail2ban is not banning malicious IPs. Please help!

That was recent support ticket received at our Server Support department where we resolve support queries for web hosts.

Servers owners use Fail2ban tool to automatically ban suspicious IP addresses in firewall.

But, what happens when fail2ban fails to ban? Do you have time to manually block each IPs in the server?

Absolutely No, because we know that it’s quite tiresome to check each server log and manually ban IPs.

Today, let’s discuss the top 6 reasons for fail2ban not banning IPs and how our Server Support Engineers fix them.

Fail2ban not banning IPs – Causes & Fixes

In our experience managing the servers, we’ll see the major causes for this error and how we fix them.

1) Service status

Fail2ban service scans log files for patterns of repeated attempts and bans IPs that show malicious signs.

If this service crashes, fail2ban will not get any data and result in fail2ban not banning IPs.

How we fix?

The reasons for service failures can be traffic spikes, resource outages,  DDoS attacks, disk errors, and so on.

We’ll identify the reason and fix it.

If a back end service fails or doesn’t respond, we’ll kill the dead process, and restart the service.

For example, we use the below command to restart the fail2ban service in CentOS 7 servers.

systemctl restart fail2ban.service

[Want to recover the failed service in your server? Our Support Experts can fix it for you.]

2) Disabled jails

Secondly, our Hosting Engineers check the status of Fail2ban jails.

A Fail2ban jail is a combination of filter and actions.

In other words, Filter contains mainly regular expressions which are used to detect break-in attempts, password failures, etc.

And, Action defines commands that are executed when the filter catches an abusive IP address.

In addition to that, jails can be in active or inactive status and only active jails are used to monitor logs files and ban IPs.

For instance, all jails are disabled by default in CentOS 7 servers.

In such cases, you can see a result as below.

# fail2ban-client status
Status
|- Number of jail: 0
`- Jail list:

Finally, the result will be fail2ban not banning IP addresses.

How we fix?

In such cases, our Support engineers create or enable necessary jails in the “/etc/fail2ban/jail.local” file.

For example, to enable the SSH daemon jail, we un-comment the following lines in jail.local.

[sshd]
enabled = true

Likewise, in Plesk servers, we activate or deactivate jails from Plesk control panel using the IP Address banning option as shown below.

Plesk Jails

3) Incorrect log path

We’ve seen cases where server owners set incorrect logpath in the custom jails that they create.

As a result, fail2ban monitors the wrong log files and doesn’t block malicious IP addresses.

For example, failed SIP registration attempts are logged in /var/log/asterisk/, but we’ve seen server owners mistakenly set the log path as /var/log/messages.

So, fail2ban doesn’t catch the suspicious IPs that connects to the server.

How we fix?

In such cases, we check and ensure that correct logpath entries are given in the jails created.

For example in some systems, SSH failed logins go to /var/log/messages or /var/log/secure.

By default, fail2ban has the following jail in jail.local file.

[ssh]

enabled = true
port = ssh
filter = sshd
logpath = /var/log/secure
maxretry = 6

Here, our Hosting Engineers create another custom jail for SSH with logpath as /var/log/messages.

[Need help to fix bad or missing firewall configuration files? Our Support Engineers are here for your help.]

4) Wrong time zone

Similarly, screwed up date/timezone of the log files can cause problems.

In other words, fail2ban compares log file entries to check if it has to ban or unban IPs.

If the timezone of the logs files is wrong, fail2ban considers this as too old entries and fails to process it.

How we fix?

So, in such cases, our Support Engineers compare the server timezone and timezone of the log files.

If any mismatch noted, we correct the timezone of the log files and restart rsyslog daemon. And, fail2ban start to work fine.

Similarly, if we find the timezone of the server is wrong, we fix it and install services like NTP to sync the time.

5) IPs not blocked in firewall

In some servers, fail2ban triggers the ban, and iptables blocks that IP. But after that, the IP still connects to the server.

This happens because iptables rules apply to new incoming connections only.

So, the existing connections can continue to use the server until they are disconnected.

How we fix?

Our Hosting Engineers setup firewall rules to rate limit connections to all ports in the server.

For example, we tweak the settings like “smtpdclientconnectionratelimit”, “smtpderrorsleeptime”,“smtpdsofterrorlimit”, etc. in Postfix config file to rate limit the connections.

6) Customization in wrong file

Again, fail2ban fails to block IPs when the server owner make changes in the wrong file.

The default jail configuration file is  /etc/fail2ban/jail.conf. But, this file can get modified during package upgrades.

So, we recommend to customize the jail configuration in the file /etc/fail2ban/jail.local.

We’ve seen server owners mistakenly made modifications in jail.conf file, but this got reverted during upgrades.

Result is, fail2ban not banning IPs.

How we fix?

Here our Hosting Engineers, replicate the customization made in jail.local file to fix the problem.

Also, we recommend our server owners to set all default settings in the file jail.conf and the settings that override the default one in the file jail.local.

Conclusion

In short, Fail2ban not banning malicious IPs is really an annoying problem for server owners. Today, we’ve discussed the top 6 reasons for this problem and how our Dedicated Support Engineers fix them.