Preventing Brute Force Attacks With Fail2ban On Debian Etch

Want to support HowtoForge? Become a subscriber!
 
Submitted by falko (Contact Author) (Forums) on Tue, 2007-05-01 18:05. :: Debian | Security

Preventing Brute Force Attacks With Fail2ban On Debian Etch

Version 1.0
Author: Falko Timme <ft [at] falkotimme [dot] com>
Last edited 04/24/2007

In this article I will show how to install and configure fail2ban on a Debian Etch system. Fail2ban is a tool that observes login attempts to various services, e.g. SSH, FTP, SMTP, Apache, etc., and if it finds failed login attempts again and again from the same IP address or host, fail2ban stops further login attempts from that IP address/host by blocking it with an iptables firewall rule.

This document comes without warranty of any kind! I want to say that this is not the only way of setting up such a system. There are many ways of achieving this goal but this is the way I take. I do not issue any guarantee that this will work for you!

 

Preliminary Note

Fail2ban is similar to DenyHosts which I covered in this tutorial: http://www.howtoforge.com/preventing_ssh_dictionary_attacks_with_denyhosts, but unlike DenyHosts which focuses on SSH, fail2ban can be configured to monitor any service that writes login attempts to a log file, and instead of using /etc/hosts.deny to block IP addresses/hosts, fail2ban uses iptables.

In this example I will configure fail2ban to monitor login attempts to the SSH server, the Proftpd server, login attempts to .htaccess/.htpasswd protected web sites, to Courier POP3 and Courier IMAP, and to SASL (for sending emails). I will install the fail2ban package that is available for Debian Etch. It comes with a default configuration, but unfortunately that configuration doesn't quite work for most of the aforementioned services. Therefore I will create a customized fail2ban configuration that I have tested and that works for me.

 

Installing fail2ban

Fail2ban can be installed as follows on Debian Etch:

apt-get install fail2ban

Afterwards, you will find all fail2ban configuration files in the /etc/fail2ban directory.

 

Configuring fail2ban

The default behaviour of fail2ban is configured in the file /etc/fail2ban/jail.conf. Take a look at it, it's not hard to understand. There's a [DEFAULT] section that applies to all other sections unless the default options are overriden in the other sections.

I explain some of the configuration options here:

  • ignoreip: This is a space-separated list of IP addresses that cannot be blocked by fail2ban. For example, if the computer from which you're connecting to the server has a static IP address, you might want to list it here.
  • bantime: Time in seconds that a host is blocked if it was caught by fail2ban (600 seconds = 10 minutes).
  • maxretry: Max. number of failed login attempts before a host is blocked by fail2ban.
  • filter: Refers to the appropriate filter file in /etc/fail2ban/filter.d.
  • logpath: The log file that fail2ban checks for failed login attempts.

As suggested by a comment at the top of /etc/fail2ban/jail.conf, we don't modify /etc/fail2ban/jail.conf itself to adjust it to our needs, but override it by creating a new configuration file, /etc/fail2ban/jail.local.

This is what my /etc/fail2ban/jail.local file looks like:

vi /etc/fail2ban/jail.local

[DEFAULT]

# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1 192.168.0.99
bantime  = 600
maxretry = 3

# "backend" specifies the backend used to get files modification. Available
# options are "gamin", "polling" and "auto".
# yoh: For some reason Debian shipped python-gamin didn't work as expected
#      This issue left ToDo, so polling is default backend for now
backend = polling

#
# Destination email address used solely for the interpolations in
# jail.{conf,local} configuration files.
destemail = root@localhost

# Default action to take: ban only
action = iptables[name=%(__name__)s, port=%(port)s]


[ssh]

enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 5


[apache]

enabled = true
port    = http
filter  = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 5


[apache-noscript]

enabled = false
port    = http
filter  = apache-noscript
logpath = /var/log/apache*/*error.log
maxretry = 5


[vsftpd]

enabled  = false
port     = ftp
filter   = vsftpd
logpath  = /var/log/auth.log
maxretry = 5


[proftpd]

enabled  = true
port     = ftp
filter   = proftpd
logpath  = /var/log/auth.log
failregex = proftpd: \(pam_unix\) authentication failure; .* rhost=<HOST>
maxretry = 5


[wuftpd]

enabled  = false
port     = ftp
filter   = wuftpd
logpath  = /var/log/auth.log
maxretry = 5


[postfix]

enabled  = false
port     = smtp
filter   = postfix
logpath  = /var/log/mail.log
maxretry = 5


[courierpop3]

enabled  = true
port     = pop3
filter   = courierlogin
failregex = courierpop3login: LOGIN FAILED.*ip=\[.*:<HOST>\]
logpath  = /var/log/mail.log
maxretry = 5


[courierimap]

enabled  = true
port     = imap2
filter   = courierlogin
failregex = imapd: LOGIN FAILED.*ip=\[.*:<HOST>\]
logpath  = /var/log/mail.log
maxretry = 5


[sasl]

enabled  = true
port     = smtp
filter   = sasl
failregex = warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed
logpath  = /var/log/mail.log
maxretry = 5

My client computer has the static IP address 192.168.0.99, and because I don't want to be locked out, I've added it to the ignoreip list. I've set the max. number of failed login attempts to 5 for all services, and I've created two new sections, [courierpop3] and [courierimap], so that fail2ban can block login attempts to my Courier-POP3 and Courier-IMAP server.

I want to control login attempts to ssh, apache, proftpd, courierpop3, courierimap, and sasl, so I've set enabled to true for these services and to false for all other services.

If you compare the file with /etc/fail2ban/jail.conf, you'll also notice that I've changed some log files because the log files in /etc/fail2ban/jail.conf are not correct for Debian Etch. In addition to that, I've added a failregex line to some services because the regular expressions in the appropriate filter files in the /etc/fail2ban/filter.d directory do not work for Debian Etch. The failregex line overrides the filter rule in the appropriate file in /etc/fail2ban/filter.d.

Whenever we modify the fail2ban configuration, we must restart fail2ban, so this is what we do now:

/etc/init.d/fail2ban restart

That's it already. Fail2ban logs to /var/log/fail2ban.log, so you can check that file to find out if/what hosts got blocked. If a host got blocked by fail2ban, it looks like this:

2007-04-24 17:49:09,466 fail2ban.actions: WARNING [apache] Ban 1.2.3.4
2007-04-24 18:08:33,213 fail2ban.actions: WARNING [sasl] Ban 1.2.3.4
2007-04-24 18:26:37,769 fail2ban.actions: WARNING [courierlogin] Ban 1.2.3.4
2007-04-24 18:39:06,765 fail2ban.actions: WARNING [courierimap] Ban 1.2.3.4

You can also check your firewall to see if any hosts are currently blocked. Simply run

iptables -L

 

Links


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by Ribamar FS (not registered) on Tue, 2012-05-29 11:21.

The howtoforge.com is now my biggest  reference in terms of Linux servers, especially the master Falko Timme to whom I am very grateful.Happiness and long life to all who do Howtoforge.

Submitted by Igor (not registered) on Thu, 2011-11-03 23:05.

There are a number of tools to address brute force/dictionary attacks. Fail2ban and DenyHost are two being around the longest. I recently switched from fail2ban to sshguard, because it's written in C and it seems more consistently maintained. Also, sshguard did not require any configuration besides apt-get on my debian box.

Submitted by datarescue (not registered) on Thu, 2011-06-16 20:18.

Hey, thanks for you excellent guides, but anyway fail2ban blocks my internal xrdp connection, how can I monitor xrdp?

 regards, DR

Submitted by Anonymous (not registered) on Thu, 2010-12-23 02:23.

Great! I didn't know you could actually write your regular expressions directly into the .local files. I had them in separate files after following this guide: http://penguinapple.blogspot.com/2010/12/installing-fail2ban-other-step-in.html. I guess that if you get a lot of rules separate files are ok too.

 Thanks for taking the time to write this.

Submitted by Thomas M (not registered) on Wed, 2010-04-07 20:01.

 I have this working under Ubuntu 8.04, It's been mentioned a couple of times in the forum, 

 If you get the message in your logfile 

  WARNING Invalid command: ['set', 'courierpop3', 'failregex', 'courierpop3login: LOGIN FAILED.*ip=\\[.*:<HOST>\\]']

 I managed to get it running with the following changes:

 in the /etc/fail2ban/jail.conf I removed the regex line:

 [pop3d]

enabled  = true
port     = pop3
filter   = pop3d
logpath  = /var/log/mail.log
maxretry = 5

Therefor I aded the file /etc/fail2ban/filter.d/pop3d.conf    with the following content:
 # Fail2Ban configuration file
#
# Author: Cyril Jaquier
#
# $Revision: 510 $
#

[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
#
failregex = pop3d: LOGIN FAILED.*ip=\[.*:<HOST>\]

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex = 
 
 Good luck and what a wonderful tool
 Thomas
Submitted by Rollopack (not registered) on Wed, 2014-11-12 16:27.
THANKS!
Submitted by innerphaze (registered user) on Tue, 2009-04-28 03:42.

Would this jail.local config file work on Ubuntu server 8.04?

Thanks! 

Submitted by El Vato (not registered) on Tue, 2008-12-09 07:32.
Well, just a minor correction in Falko's example jail.local section,
as copied verbatim below: 
 
[apache]

enabled = true
port = http
filter = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 5
 
the variable logpath above should point to:
logpath = /var/log/apache*/*access.log
 
That's all 
 
Submitted by AlArenal (registered user) on Tue, 2007-06-26 10:33.

Occasionally fail2ban will refuse to restart. If I don't check my mails every morning and have a look at the start/stop mails I'll run into trouble after a while. Fail2ban will refuse to work, processes will hang and I'll have to kill them manually, delete the PID file and fire fail2ban up again :(
 

Submitted by jagabullox (registered user) on Wed, 2007-05-02 09:45.

According to me, fail2ban is :

  • efficient
  • very easy to configure
  • fly weight

 I have fail2ban installed on my personnal server, which was often attacked by robots via ssh.

Fail2ban blocks all robots, consequently my system has more free RAM and CPU. 

 Regards,

Jagabullox. 

 

Submitted by harm (registered user) on Wed, 2007-05-02 14:20.
in case of bots attacking sshd you could just put it on a non-standard port ;) definately since your talking about a private (home) server.   
Submitted by Anonymous (not registered) on Fri, 2009-01-02 13:58.
I changed my port but that doesn't help. In few hours bots find my new port.
Submitted by Anonymous (not registered) on Sun, 2008-11-30 23:29.
using a non-standard port is not considered effective or practical for clients. any good bot will port scan. server maintenance is an ongoing practice. fail2ban looks good.
Submitted by foobar (not registered) on Tue, 2009-04-21 08:26.
They haven't found mine yet ;). Been running non-standard for close to a year. It helps that I do filtering, and already use ipt_recent rules... that already helped, but I grew tired of seeing them at all, so I just changed port on the f**kers.
Submitted by Anonymous (not registered) on Tue, 2009-06-09 17:07.
Its a matter of time.  They will find you.  Portscanning is common and if you are not being scanned, maybe you are not very 'interesting' to them.  That's not a bad thing, but if you haven't been bruteforced yet, you will.  Fail2ban is helpful, as are any other bruteforce scripting tools out there (and there are dozens of them)
Submitted by Anonymous (not registered) on Wed, 2009-06-24 20:53.
Use portsentry + fail2ban + ssh in a not default port.
Submitted by shahjees (not registered) on Thu, 2009-12-03 21:41.
excellent guide, works right away, and you know what, the 'smart' bots now seems to know we are using fail2ban and completely stopped attacking my port 22, i am sure they have a 'central bot database network' which stops other bots from wasting time attacking my IP