Vigilant system administrators will notice many failed login attempts on their internet connected servers. While its good to know that you are preventing these logins, they are filling your logs and potentially making it harder to see other problems. Additionally, these failed logins are taking up bandwidth and likely trying over and over again to get into your system. Fortunately, there is a solution to preventing these attacks from continuing on a Linux based system. The following tutorial will set up Fail2ban on a RedHat based system. We will monitor failed SSH logins and failed Webmin logins. Additionally, we will set up a unique jail that will block persistant attackers for a longer period of time.

We will begin by installing Fail2ban and the dependencies required. At the time this was published Fail2ban was on version 0.8.3.

yum install fail2ban

Though its installed, there are no jails active. A jail is used to tell Fail2ban what to monitor. We are going to activate the SSH jail first. Please substitute your text editor of choice for nano, below. It is used in this example because of its ease of use for new users.

Enabling SSH Monitoring

nano /etc/fail2ban/jail.conf

Look for the line that begins [ssh-iptables]. Under this line, change the enabled value to true. Additionally, on a RedHat system, we need to change the log that is being monitored for SSH failures. Change the logpath value to /var/log/secure.

Hit the F3 button to save your configuration. This is specific to nano. Change as appropriate for your text editor.

Enabling Webmin Monitoring

Next we are going to add an additional jail. This is only needed and will only function if you have webmin installed. If not, skip to the next section.

At the tail end of the [ssh-iptables] jail that you just editted above add the following block.

[webmin-iptables]
enabled  = true
filter   = webmin-auth
action   = iptables[name=webmin, port=10000, protocol=tcp]
 sendmail-whois[name=WEBMIN, dest=example@example.com, sender=example@example.com]
logpath  = /var/log/secure

Modify the two instances of example@example.com with the destination and sender email address. This jail will monitor attempted logins to the Webmin user interface, which runs on port 10000, and if there are to many, issue a ban on the IP address. The email address supplied in dest= will receive an email saying the ban as been issued. If you moved your install of Webmin to run on something other than port 10000, change the port= value as appropriate.

Deal with Persistant Attackers

After you’ve had Fail2ban installed for a while, you will notice that you are banning the same IP address(es) over and over again. By default, Fail2ban issues an IP block for 10 minutes. This is often long enough to deter someone running an automated scan against your particular network segment. This length is also configurable in the jail.conf file. Look for the bantime value at the top of the configuration file. Additionally, individual jails can override this, as we are about to do.

After banning the same IP many times, I have decided that I don’t want to see that IP address again for a while. Using a jail found on the Fail2ban website, we will issue a month long ban if we block the same IP ten times in a week.

First we will add another jail to jail.conf. After the [ssh-iptables] jail, paste the following.

[fail2ban]
enabled = true
filter = fail2ban
action = iptables-allports[name=fail2ban]
 sendmail-whois[name=fail2ban, dest=example@example.com, sender=example@example.com]
logpath = /var/log/fail2ban.log
maxretry=10
# Search past week
findtime = 604800
# Ban for 30 days
bantime = 2592000

As stated above, this will issue a 30 day block of an IP address if it is blocked 10 times within a week. Again, change the example@example.com to your email address to receive notification of blocks.

Save and exit nano. Now we need to create one more file – the code behind the last jail we created.

nano /etc/fail2ban/filter.d/fail2ban.conf

Paste the following into this file

# fail2ban configuration file
#
# Author: Tom Hendrikx
#
# $Revision$
#

[Definition]

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>\S+)
# Values:  TEXT
#

# Count all bans in the logfile
failregex = fail2ban.actions: WARNING \[(.*)\] Ban <HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#

# Ignore our own bans, to keep our counts exact. This means it doesn't count any bans this jail issues.
# In your config, name your jail 'fail2ban', or change this line! This means in the jail added to jail.conf, the jail must be like this:
# [fail2ban], else this won't work.
ignoreregex = fail2ban.actions: WARNING \[fail2ban\] Ban <HOST>

Save and exit nano.

Last we set up Fail2ban to run while the server is on and then start it

chkconfig --levels 2345 fail2ban on
service fail2ban start

To see the status of fail to ban run the fail2ban-client

fail2ban-client status

It should output something similar to

Status
|- Number of jail:      3
`- Jail list:           webmin-iptables, fail2ban, ssh-iptables

Fail2ban is now running.

For more information on Fail2ban, check the Fail2ban project website
If you are interested in other things to block or how to do something with Fail2ban, check their HOWTOs