HOWTO Setup fail2ban: Difference between revisions

From Research
Jump to navigation Jump to search
Line 31: Line 31:


==Configuring fail2ban==
==Configuring fail2ban==
In '''/etc/fail2ban/jail.conf'''
edit '''/etc/fail2ban/jail.conf'''
*change how we monitor failures, preferring a file-alteration monitor over polling (you may have to '''emerge gamin'''):
*change how we monitor failures, preferring a file-alteration monitor over polling (you may have to '''emerge gamin'''):
  ###backend = auto
  ###backend = auto

Revision as of 17:57, 29 January 2008

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, the fail2ban makes an iptables-entry automatically, banning (blocking) that IP-address. After a configurable length of time (1 week), the IP-address is unblocked.

Why we want fail2ban

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

fail2ban creates it's own logfile (/var/log/fail2ban.log), which is scanned and reported via logwatch every morning, in our case. So, we get a daily summary, at no extra cost :-)


One alternative to fail2ban is denyhosts, which requires tcpwrappers (tcpd USE-flag), and makes banned-host-IP entries in your /etc/hosts.deny file.

  • 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 a central 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

I would recommend DenyHosts for a desktop/workstation, where SSH is the only externally-accessible service. It is simpler, and informal testing has shown it works very well.

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 fail2ban
hostname ~ # emacs -nw /etc/fail2ban/jail.conf

Configuring fail2ban

edit /etc/fail2ban/jail.conf

  • change how we monitor failures, preferring a file-alteration monitor over polling (you may have to emerge gamin):
###backend = auto
backend = gamin
  • 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.

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

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