Using fail2ban to reduce attacks on Gentoo

You can use fail2ban to reduce the amount of time your servers spend dealing with spam, ssh attacks, and more.

Installation is simple. First we check the dependencies and what will be installed:

emerge -uDpv fail2ban

If everything looks normal, install fail2ban. In my case, 0.8.0-r1 was the version installed.

emerge -uDv fail2ban

Then it's simply a matter of configuring it. In my case, I'm using shorewall on a 2.6 kernel, so I modified the files as follows. As I agreed with Uno_Code's opinion I edited /etc/fail2ban/fail2ban.conf so that it used /var/run/fail2ban.sock instead of /tmp/fail2ban.sock.

The next step is editing /etc/fail2ban/jail.conf for your setup. I changed the default bantime to 6000 seconds:

bantime = 6000

This is 100 minutes, 10 times the default, which should give enough time for whoever is bothering your server to give up and go away. You'll probably want to modify the ignoreip line to contain and fixed IP addresses you control (so that you can never be locked out via SSH, for example).

ignoreip = 127.0.0.1 10.0.0.2

After configuring the defaults, we need to setup the jails for each service. You'll notice many sections like this in jail.conf:

[ssh-iptables]

enabled  = false
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
           mail-whois[name=SSH, dest=yourmail@example.com]
logpath  = /var/log/sshd.log
maxretry = 5

Notice the enabled = false on each one. We'll edit them for our purposes, and then change it enabled = true.

The most important lines are filter = sshd and the action = iptables. Since we're using shorewall as our firewall, we'll need to change it to use shorewall instead of using iptables directly. The filter = sshd line refers to the /etc/fail2ban/sshd.conf file, which is where the regular expression that detects the log failure (in this case, an SSH authentication failure) is defined. In this case, the default sshd.conf is usable, so we won't need to edit it.

However, we do need to change the section as follows. I've renamed it to ssh-shorewall to keep with the default naming pattern.

[ssh-shorewall]

enabled  = true
filter   = sshd
action   = shorewall
           mail[name=SSH, dest=yourmail@example.com]
logpath  = /var/log/messages
maxretry = 3

We've changed from mail-whois to mail (mail-whois simply does some reverse lookup on the IP before mailing you), and replaced iptables with shorewall. You need to change logpath to point to /var/log/messages, as that's where sshd reports login failures (at least in my Gentoo installation). I've changed maxretry to 3. The number you pick is basically based on how often you think you may mistype your password or forget to load your SSH key.

The next thing I enabled was a filter that would drop connections from mail servers that are greylisted 5 times in 5 minutes. This is a bit extreme, but based on log perusal of my server I don't have any valid people trying to send me 5 emails in a 5 minute time-span. Depending on how many users you have, you may need to change these numbers. Currently these mainly seem to be Storm virus emails. To create this filter is a two step process. First we edit /etc/fail2ban/jail.conf as shown:

[greylisting-shorewall]

enabled  = true
filter   = postfix-greylisting
action   = shorewall
           mail[name=greylisting, dest=yourmail@example.com]
logpath  = /var/log/messages
maxretry = 5
bantime  = 60000
findtime = 300

You can see that I've overridden the default bantime and findtime, banning the servers for 1000 minutes. Then we need to create a new filter for this in /etc/fail2ban/filter.d that contains the regex that will catch these servers. I copied it from /etc/fail2ban/filter.d/postfix.conf and called it postfix-greylisting.conf. The important line changed is the failregex line:

failregex = reject: DATA from (.*)\[\]: 450.*Greylisted

The regular expression has been changed to capture greylisting notices from the messages file. When editing the regular expression, you can use fail2ban-regex to test them, as seen here:

fail2ban-regex /var/log/messages "reject: DATA from (.*)\[\]: 450.*Greylisted"

Note that the above line is one command. The regular expression catches all 450 rejects that have Greylisted in the text.

The next filter we'll setup is one that is designed to block servers that try to update against named when they're not authorized to. I copied one of the filters to /etc/fail2ban/filter.d/named.conf and changed failregex to:

failregex = named\[\d*\]: client .* denied

This catches servers that are hitting your named server, such as seen here:

Aug 27 09:48:45 server named[19283]: client 148.160.29.6#33116: query (cache) 'example.com/NS/IN' denied

We then need a configuration section in jail.conf for named:

[named-shorewall]

enabled  = true
filter   = named
action   = shorewall
           mail[name=named, dest=yourmail@example.com]
logpath  = /var/log/messages
maxretry = 2

Now we just need to start fail2ban:

/etc/init.d/fail2ban start

If you're editing jail.conf you can cause a reload easily:

fail2ban-client reload

Once you're satisified that everything is working, you can add fail2ban to your default runlevel:

rc-update add fail2ban default

You'll notice that every one of our setups has a mail command attached. Until you're certain that you no longer need to monitor what's being blocked, I'd recommend leaving them. All action is logged in /var/log/fail2ban.log, so you can use that to check what is happening after you disable the mail commands.

Further information can be found at the fail2ban wiki.