Wednesday, March 22, 2017

Some Fail2ban Success

I've been playing with Fail2ban jail configurations since the last post and I think I've got my setup running close to perfect.

In my last post, I mentioned that I wanted Fail2ban to block non-ssh traffic.  This was difficult to get working because there aren't all that many explanations on the inner workings of this tool.  The readmes aren't exactly descriptive.  With a lot of web searches I got things working.

The jail list shows that I've enabled the following filters: 

root@linode:/var/log# fail2ban-client status
|- Number of jail:      15
`- Jail list:   apache, apache-multiport, apache-noscript, apache-overflows, courier-auth, courier-smtp, dropbear, mysqld-auth, php-url-fopen, postfix, postfix-sasl, sasl, ssh-ddos, sshd, xinetd-fail

Of them, I've seen traffic blocked from apache-noscript, apache-overflows, ssh-ddos, and sshd.

The rest of the filters have not captured any logs, but that just means conditions haven't been met to block/log.  In fact, I've only seen one apache-overflows alert trigger.

What I've been doing is trying to correlate the Fail2ban log entries to the service logs (ie, an alert is generated against the apache-noscript filter and I grep the apache logs for the IP to see what occurred.

Here's an example Fail2ban alert:

root@linode:/var/log# cat /var/log/fail2ban.log | grep 'script' | grep 'Ban'
2017-03-23 00:00:00,322 fail2ban.actions        [26381]: NOTICE  [apache-noscript] Ban

Here's the Apache log entries for that IP:

root@linode:/var/log# cat apache2/access.log | grep - - [22/Mar/2017:18:13:56 +0000] "GET //wp-includes/registration-functions.php HTTP/1.1" 500 185 "-" "Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko" - - [22/Mar/2017:23:59:59 +0000] "GET //wall_login.php?login=cmd HTTP/1.1" 404 510 "-" "Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko"

Here's how the apache-noscript section looks within my jail.local file:


enabled  = true
port     = http,https
filter   = apache-noscript
logpath  = /var/log/apache2/error.log
maxretry = 1
findtime = 60
bantime  = -1

You see two log entries.  In this case, the filter is looking for more than one violation in a 60 second timeframe.  Violators are banned indefinitely.

The logs look hokey when comparing against the apache-noscript configuration within the jail.local file, but it's correct.  The logs look like this attack occurred after the offending IP connected to the Apache server twice within five hours and was banned at midnight on the second attempt.  That's not what happened.  The logs are deceiving.  The attacks (defined by maxretry) must occur within the findtime value.  Since the maxretry is 1 and the findtime is 60, a ban occurred when the offending IP tried a consecutive attack within 60 seconds (at midnight).  Apache only logged the first attempt (at midnight).  After the second attempt occurred, a ban was set before Apache could log the attempt.

The ssh-ddos filter discovers distributed attacks relating to brute-forcing of SSH connections.  There are also many other filters relating to ssh but they're pretty much redundant in that they block the same activity, so if I have several of them enabled, I end up with redundant alerts in my log file.  I've turned off the ones that generate duplicate alerts.

I also need to back up my configuration files so that I don't have to experiment with and tune the setup if I happen to lose my configuration files later and have to reinstall Fail2ban.  That would suck.
Post a Comment