In this post we're going to explain how to set up fail2ban on your Ubuntu servers, and how to configure it to automatically block suspicious IP addresses, greatly improving your server security.
Fail2ban is a command-line program that automatically checks your system logs for signs of suspicious activity, and then automatically blocks IP addresses.
So if for example an IP address was repeatedly trying to log in to your server via SSH and was trying out a different username and password combinations, fail2ban would kick in and put a stop to it.
Its abilities extend beyond SSH, however. Many automated bots scan the web for signs of insecure WordPress installations, checking for known files and common security holes to exploit. By monitoring the access logs of your Apache or Nginx web server, fail2ban can block these from any further attempts.
The basic installation of fail2ban simply requires you to run an install command from your package manager.
Ubuntu/Debian Based Systems:
apt update && apt install fail2ban
CentOS/Fedora/RedHat Based Systems:
dnf install epel-release
dnf update && dnf install fail2ban
If you're on an older version of a RedHat based system you can substitute
Your OS may ask you to confirm you wish to install.
Now that you've got fail2ban installed it's time to configure how it protects your server.
A 'default' configuration file is located in
/etc/fail2ban/jail.conf however this can be overwritten during upgrades. To prevent your server settings from being lost each time, the first thing you'll need to do is to copy the file to a
jail.local, which will be loaded after the
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Now you can open the
jail.local file with your preferred editor. We're using nano:
Out of the box, fail2ban's configuration file will block SSH connections that look suspicious, but there's a few tweaks you'll possibly want to make.
If you're working from a fixed IP address, search for
ignoreip and you should find a commented out section that looks like this:
# "ignoreip" can be a list of IP addresses, CIDR masks or DNS hosts. Fail2ban
# will not ban a host which matches an address in this list. Several addresses
# can be defined using space (and/or comma) separator.
#ignoreip = 127.0.0.1/8 ::1
The last line there is the command, you can uncomment this and add IP addresses, or a whole range of IP addresses.
So if my IP address was
172.24.195.4 I could change that line to look like this, and my IP would be whitelisted:
ignoreip = 172.24.195.4
If my organization owned the whole of the
172.24.195.x IP range then I could whitelist all IP's in that range like this:
ignoreip = 172.24.195.0/24
If I wanted to only allow both my IP Address, and a co-workers I could do this:
ignoreip = 172.24.195.4 172.24.195.10
Out of the box, a fail2ban will block an IP for 10 minutes.
It's recommended that you increase this to prevent repeat attempts, generally an hour is usually enough, but some people choose to extend it to a day, or even a week. One thing to bear in mind if you do this is that you really do need to make sure your own IP is whitelisted, or you could risk locking yourself out for a long period of time!
To increase the ban time, search the config file for
bantime - it's usually right below the
To increase the ban to one hour:
bantime = 60m
You can also permanently ban IPs by setting the value to
-1 however caution should be used when doing so, as if your IP isn't whitelisted you risk permanently locking yourself out.
Another great feature is the ability to keep increasing the ban length every time an IP address gets blocked.
For example, if an IP was blocked for 10 minutes, and then they manage to get blocked again, they could be blocked for 20 minutes, then 40 minutes, then 80 minutes, etc.
Search the file for
bantime.increment - it'll be commented out as standard, and there are detailed instructions above each line explaining how to use it.
Start by uncommenting that line, and then you can change the settings below such as
bantime.factor, which is used to work out how long to extend the ban to each time.
At the bottom of the config file, we're going to add an extra configuration block to keep track of your website's access log. This will be searching for anyone trying to break into your admin area, or trying to find common exploits.
For this step, you'll need to know where your access log is located. If this is your only website on the server, or you've got a generic/shared access log it'll likely be located in
If you're unsure where your logs are stored, you check your apache or nginx configuration in
For our example we're assuming you're using nginx in its standard access log location.
port = http,https
logpath = /var/log/nginx/access.log
filter = wordpress-auth
enabled = true
bantime = 12h
maxretry = 5
We've also added our own custom retry limit and bantime here - these are optional and if they aren't provided then the default settings at the top of the jail.local file will be used instead.
Once you've finished tinkering with the configuration, save the file (if you're using Nano it's CTRL + X followed by 'Y' to confirm and then enter).
Now restart fail2ban with
systemctl restart fail2ban to apply the configuration changes.
You can now test the changes out, or alternatively, monitor the fail2ban log to see it in action:
tail -f fail2ban.log
ServerAuth provides a whole host of management tools, from controlling who can access your server, to managing your website deployments. And with an ever-growing suite of tools you'll always be one step ahead!Start for free