HOWTO fail2ban
Fail2ban is a package available in the EPEL repository. It provides a mechanism to ban access via iptables to any service that have log files available to be grepped.
The advantage of using Fail2ban over no intrusion prevention is that brute force or denial-of-service attacks are more easily countered, and are done so in an automated fashion. The advantages of fail2ban over a solution such as denyhosts is twofold:
- It uses iptables rather than the /etc/hosts.deny file, which allows for a broader level of scripting for response actions, as well as more flexibility in ban listing
- fail2ban can look at a large number of different logfiles for various services, from SQL databases and httpd-secure, to ssh and whatever else you might have. Denyhosts is solely focused on ssh.
Installation
Easy peasy on any Centos/RHEL 6.x machine.
yum install epel-release && yum clean all
then
yum install fail2ban
Configuration
The typical fail2ban installation tree looks something like this:
(source: http://www.fail2ban.org/wiki/index.php/MANUAL_0_8#Configuration) /etc/fail2ban/ ├── action.d │ ├── dummy.conf │ ├── hostsdeny.conf │ ├── iptables.conf │ ├── mail-whois.conf │ ├── mail.conf │ └── shorewall.conf ├── fail2ban.conf ├── fail2ban.local ├── filter.d │ ├── apache-auth.conf │ ├── apache-noscript.conf │ ├── couriersmtp.conf │ ├── postfix.conf │ ├── proftpd.conf │ ├── qmail.conf │ ├── sasl.conf │ ├── sshd.conf │ └── vsftpd.conf ├── jail.conf └── jail.local
NOTE: fail2ban by default looks for and uses '.local' files over '.conf' files in /etc/fail2ban/. It assumes that if a .local exists, that .conf is used as the 'default' file provided by the rpm, and is being retained for reference. If no '.local' exists, .conf is used.
Key files to note are:
- fail2ban.local - General settings
- jail.local - 'Jail' settings, where services to be monitored are enabled
- filter.d/ - Contains the files which define the regex calls to run on target logfiles. Any jail must have a corrosponding file here.
- jail.d/ - A folder for jail settings, an alternative and frankly better method than managing a jail.local file.
TL;DR - Configuring fail2ban from a fresh install
- Add "enable = true" to each relevant entry in jail.conf.
- (Optional) Edit fail2ban.conf and change logtarget to /var/log/fail2ban.log, if you want fail2ban to log to it's own file rather than syslog.
- Edit fail2ban.conf, change the line "ignoreip = $trustedIPs". This is critical, to prevent locking yourself out.
- /etc/init.d/fail2ban start
Management
Frequently Used Commands
Fail2ban management can be done entirely via textfiles (namely your logfiles and iptables), but life is made infinitely easier by using the built in commands.
These commands are:
- fail2ban-client
- fail2ban-server
And, though not part of the fail2ban package, a primary method of looking at what IPs have currently been banned:
- iptables -L
What's been banned?
For the most part, fail2ban operates through denying access from an ip via iptables. It does this through a series of chained iptables rulesets, one per active jail. Conceptually, the logic looks something like:
Incoming packets
└── jail 1
└── bans from jail1 get dropped, else return to main chain
└── jail 2
└── drop any more bans, then return
└── the rest of your iptables setup.
Note: But what about IPs we trust? Fail2ban can be set up to IGNORE trusted IPs. Those IPs, CIDR addresses, URLs, etc, will /never/ be jailed.
The actual iptables rules are beyond the scope of a howto document, and are covered in the fail2ban documentation found at TODO
So, how do we see what's actually been banned? The simplest method is simply to run "iptables -L". Scroll through the various jales, and you'll see any banned hosts listed there.
Managing bans
Unbanning IPs (say, if you forgot your password) can be managed through the fail2ban-client command
fail2ban-client set <jail> unbanip x.x.x.x