HOWTO Setup fail2ban: Difference between revisions
Line 4: | Line 4: | ||
==Why we want fail2ban== | ==Why we want fail2ban== | ||
One alternative is denyhosts, which requires tcpwrappers, 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> | One alternative is denyhosts, which requires tcpwrappers, 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> | ||
Our Gentoo systems use syslog-ng, 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. | 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.<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. 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> | |||
==Pre-Requisites== | ==Pre-Requisites== |
Revision as of 02:59, 23 January 2008
What fail2ban does
Fail2ban parses logfiles, and finds repeated-access-failures for various services. Once a specified number of failures within a given time is reached, the fail2ban makes an iptables-entry automatically, banning (blocking) that IP-address. After a configurable length of time, the IP-address is unblocked.
Why we want fail2ban
One alternative is denyhosts, which requires tcpwrappers, 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.
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.
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. The flexibility and integration with iptables is a major benefit of fail2ban, in our case. For most servers, this is the way to go.
Pre-Requisites
- 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:
###backend = auto backend = gamin
In /etc/fail2ban/jail.conf, scroll to section "[ssh-iptables]" and enable it:
###enabled = false enabled = true
In /etc/fail2ban/jail.conf, change the the SSH logfile we want to scan:
###logpath = /var/log/sshd.log logpath = /var/log/auth.log
In /etc/fail2ban/jail.conf, comment out the "mail-whois" actions.
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