Fail2ban is an excellent tool for preventing brute force SSH attacks. However, we have encountered a number of cases where Fail2ban was causing high CPU usage.
To make a long story short, this issue seems to happen when the auth.log file on Ubuntu becomes too large.
logrotate only rotates the auth.log file every week.
If your server witnesses a spike in SSH attempts, then the auth.log file will grow in size.
However, logrotate will not rotate this file every day. Instead, it will only rotate it once per week.
In some cases, the auth log will swell in size because of an increase in SSH activity. As a result, Fail2ban can run into difficulties.
Rotate auth.log on a daily basis.
The first step towards fixing this issue is to configure logrotate to rotate the auth file on a daily basis instead of a weekly basis.
On Ubuntu, the logrotate settings for the auth.log file are in the following file.
sudo nano /etc/logrotate.d/rsyslog
By default, the auth.log settings will share the same settings as mail.info, cron.log and mail.warn, etc.
However, you will need to remove /var/log/auth.log from that list and give it a separate configuration block.
/var/log/auth.log
{
rotate 4
daily
missingok
notifempty
size 10M
su root syslog
compress
delaycompress
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
Here, you can see that auth.log has its own configuration block. You can also see that we are using daily instead of weekly.
We also added “su root syslog” to the settings. If this line is not present, logrotate will throw an error when we manually run it. This error will say that the parent directory does not have the correct permissions.
Fixing the high CPU usage.
After you have saved those changes to your /etc/logrotate.d/rsyslog file, you can use the following steps.
1. Stop the Fail2ban service.
Firstly, we are going to stop the Fail2ban service while we do a “clean up”.
sudo service fail2ban stop
2. Remove the SQLite database.
After that, we are going to remove the temporary SQLite database that Fail2ban uses.
sudo rm /var/lib/fail2ban/fail2ban.sqlite3
Don’t worry. Fail2ban will recreate this database once it restarts.
3. Manually force logrotate to rotate the auth.log file.
At this stage, we are going to manually run logrotate and tell it to rotate the auth.log file.
sudo logrotate --force rsyslog
For some of the other log files, you might see a few errors about the parent directory not having the correct permissions. However, the main thing is that you do not see this error for auth.log.
Once the command is finished running, the auth file should be much smaller in size.
4. Restart Fail2ban.
Now that we have taken care of the log size issue, we can restart the Fail2ban service.
sudo service fail2ban start
And that’s it!
Hopefully, when the Fail2ban service restarts, it will go back to running normally instead of hogging your server’s CPU.