HOWTO Setup fail2ban

What fail2ban does

fail2ban parses logfiles, and finds repeated-access-failures for various services. Once a specified number of failures (5) within a given time (10min) is reached, fail2ban makes an iptables-entry automatically, banning (blocking) that IP-address. After a configurable length of time (2 weeks), the IP-address is automatically unblocked. The status (number of hosts banned; number un-banned) is extracted from /var/log/fail2ban.log by logwatch, and summarized in our daily logwatch-email.

Why we want fail2ban

Our Gentoo systems use syslog-ng, sometimes with separate SSH auth.log file (many times, though SSH logging is integrated into /var/log/messages). Occasionally we also supply vsftpd connectivity for users, which uses yet another separate log-file. We may also add other services (apache2, postfix, and others). Fail2ban is capable of working with multiple log-files, and multiple services. The flexibility and integration with iptables/netfilter is a major benefit of fail2ban, and filtering is performed at the kernel-level. For most servers, this is the way to go.

---

One alternative to fail2ban is denyhosts, which requires tcpwrappers (tcpd USE-flag), and makes banned-host-IP entries in your /etc/hosts.deny file. I would recommend DenyHosts for a desktop/workstation, where SSH is the only externally-accessible service. It is simpler than fail2ban, and informal testing has shown it works very well.

• DenyHosts Advantages
  • doesn't require iptables
  • scans your log-files for SSH failures only, and doesn't (appear) to care about the actual port. This is very handy for SSH running on multiple, or non-standard ports.
  • can use an Internet server + database of abusive IP's, so it offers a bit more-proactive protection, rather than being purely reactionary
  • it's just a Python script, and easily adapted to some of our legacy systems (SuSE 9.3 is a working example)
• DenyHosts Disadvantages
  • filtering is performed at the user-level.
  • only capable of scanning a single log-file
  • only supplied with SSH scanning support
    
    

Pre-Requisites for fail2ban

• Python
• iptables
• logrotate (watch out! Some stuff doesn't rotate; follow the link to fix it!)
• gamin (if you're following my suggestion, below)

Installing fail2ban

hostname ~ # emerge -v gamin fail2ban

Configuring fail2ban

edit /etc/fail2ban/jail.conf

hostname ~ # emacs -nw /etc/fail2ban/jail.conf

• set the bantime to 2 weeks, measured in seconds:

bantime  = 1209600

• scroll to section "[ssh-iptables]" and enable it:

###enabled  = false
enabled  = true

• change the the SSH logfile we want to scan, if necessary (often it is not; sometimes it is):

###logpath = /var/log/sshd.log
logpath = /var/log/auth.log

• comment out the "mail-whois" actions, in order to reduce email-clutter. If you do wish to be notified each time an IP-address is blocked, edit jail.conf and replace you@mail.com with your own email-address.
  

#           mail-whois[name=SSH, dest=yourmail@mail.com] 

Repeat the enabling and configuring for all the other services you want, such as vsftpd, apache, etc.

# Don't block SFU-local folks, nor SHAW  / Telus
ignoreip = 142.58.0.0/16 209.87.56.0/24 24.64.0.0/13 24.76.0.0/14 24.80.0.0/13 24.108.0.0/15 64.59.128.0/18 70.64.0.0/12 137.186.0.0/16 206.75.0.0/16 207.81.0.0/16 207.134.0.0/16

Running fail2ban

hostname ~ # /etc/init.d/fail2ban start
* Starting fail2ban ...                                         [ ok ]

hostname ~ # rc-update add fail2ban default
* fail2ban added to runlevel default

Monitoring and Verifying fail2ban

Check the log file:

hostname ~ # tail /var/log/fail2ban.log

and, for scrolling/real-time monitoring of additions to the log-file:

hostname ~ # tail -f /var/log/fail2ban.log

Check Iptables:

hostname ~ # iptables -L

Example output, for a web-server (port 80 open), with SSH and FTP services too. Note the banned SSH user, resulting from too many failed-login-attempts:

Chain INPUT (policy DROP)
target     prot opt source               destination         
fail2ban-VSFTPD  tcp  --  anywhere             anywhere            tcp dpt:ftp 
fail2ban-SSH  tcp  --  anywhere             anywhere            tcp dpt:ssh 
ACCEPT     all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            state INVALID 
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ftp-data 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ftp 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:http

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 

Chain fail2ban-SSH (1 references)
target     prot opt source               destination         
DROP       all  --  sr-01504.iat.sfu.ca  anywhere            
RETURN     all  --  anywhere             anywhere            

Chain fail2ban-VSFTPD (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere

Troubleshooting fail2ban

One of the best ways of troubleshooting is to use the fail2ban-regex tool. Feed this with the log-file you want to watch, and point it to the filter you want applied:

hostname ~ # /usr/bin/fail2ban-regex /var/log/messages /etc/fail2ban/filter.d/sshd.conf

Example output:

Unable to find a corresponding IP address for eges.esstel.ru
Unable to find a corresponding IP address for adsl-75-22-172-193.dsl.sndg02.sbcglobal.net
Unable to find a corresponding IP address for adsl-75-22-172-193.dsl.sndg02.sbcglobal.net

Running tests
=============

Use regex file : /etc/fail2ban/filter.d/sshd.conf
Use log file   : /var/log/messages


Results
=======

Failregex:
[1] Authentication failure for .* from <HOST>$
[2] Failed [-/\w]+ for .* from <HOST>$
[3] ROOT LOGIN REFUSED .* FROM <HOST>$
[4] [iI](?:llegal|nvalid) user .* from <HOST>$

Number of matches:
[1] 3161 match(es)
[2] 0 match(es)
[3] 0 match(es)
[4] 932 match(es)

Addresses found:
[1]
    203.98.175.182 (Wed Nov 19 06:04:16 2008)
    59.125.226.213 (Wed Nov 19 06:07:05 2008)
    80.153.123.179 (Wed Nov 19 06:10:13 2008)
    76.255.174.78 (Wed Nov 19 06:13:03 2008)
    66.158.139.11 (Wed Nov 19 06:15:54 2008)
    66.158.139.11 (Wed Nov 19 06:18:54 2008)

<truncated the rest of the output, for brevity's sake>

This verifies that the logfile you are parsing does indeed contain appropriate information for fail2ban, and it shows the filter-rules and numbers of matches for each rule. Some attacks try to sneak under a fail2ban threshold, so this kind of regex-test may show only a single, or perhaps 2 failures from a given IP-address... often (depending on configuration), this isn't enough to trigger a ban (the default config may require 5 attempts, or a tweaked version may reduce this threshold to 3 failures before banning).