HOWTO Setup fail2ban: Difference between revisions
Line 4: | Line 4: | ||
==Why we want fail2ban== | ==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, and others). Fail2ban is capable of working with multiple log-file and multiple services. The flexibility and integration with iptables is a major benefit of fail2ban, in our case. For most '''servers''', this is the way to go.<br><br> | 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, 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.<br><br> | ||
'''''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 :-)<br> | '''''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 :-)<br> | ||
<br> | <br> | ||
<hr> | <hr> | ||
One alternative to '''''fail2ban''''' is '''''denyhosts''''', which requires tcpwrappers ('''tcpd''' USE-flag), and makes entries in your /etc/hosts.deny file. The problem is that regular-expressions are not supplied to filter more than SSH, and denyhosts can only scan a single log-file. One advantage of denyhosts is that it doesn't require iptables.<br><br> | One alternative to '''''fail2ban''''' is '''''denyhosts''''', which requires tcpwrappers ('''tcpd''' USE-flag), and makes entries in your /etc/hosts.deny file. The problem is that regular-expressions are not supplied to filter more than SSH, and denyhosts can only scan a single log-file. One advantage of denyhosts is that it doesn't require iptables. One disadvantage in using /etc/hosts.deny is that filtering is performed at the user-level.<br><br> | ||
In fact, I would recommend that for a '''desktop/workstation''', where SSH is the '''only''' externally-accessible service, you use denyhosts. It is simpler, and informal testing has shown it works very well. Denyhosts also uses (optionally) a central server + database of abusive IP's, so it offers a bit more-proactive protection, rather than being purely reactionary.<br> | In fact, I would recommend that for a '''desktop/workstation''', where SSH is the '''only''' externally-accessible service, you use denyhosts. It is simpler, and informal testing has shown it works very well. Denyhosts also uses (optionally) a central server + database of abusive IP's, so it offers a bit more-proactive protection, rather than being purely reactionary.<br> | ||
Revision as of 19:26, 23 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, 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 entries in your /etc/hosts.deny file. The problem is that regular-expressions are not supplied to filter more than SSH, and denyhosts can only scan a single log-file. One advantage of denyhosts is that it doesn't require iptables. One disadvantage in using /etc/hosts.deny is that filtering is performed at the user-level.
In fact, I would recommend that for a desktop/workstation, where SSH is the only externally-accessible service, you use denyhosts. It is simpler, and informal testing has shown it works very well. Denyhosts also uses (optionally) a central server + database of abusive IP's, so it offers a bit more-proactive protection, rather than being purely reactionary.
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
In /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