fail2ban does not modify iptables entries

[cbj4074]

Hello,

I realize that this problem may not be ISPConfig-specific, but I'd like to eliminate that possibility, if nothing else. I'm using ISPConfig 3.0.4.

I've installed fail2ban 0.8.4, with minimal configuration changes, on Ubuntu 10.04-2 LTS. I installed fail2ban from the Ubuntu repository using apt-get.

My goal is to cover Apache authentication first, and then extend the fail2ban configuration to other services, such as ftp, dovecot, etc.

The default fail2ban configuration seems to be adequate, and the only change I made was to create the file /etc/fail2ban/jail.local and insert the following:

[apache]
enabled = true
logpath = /var/log/ispconfig/httpd/*/error.log

Likewise, the default regular expressions appear to be functioning as expected:

# fail2ban-regex /var/log/ispconfig/httpd/example.com/error.log /etc/fail2ban/filter.d/apache-auth.conf

Running tests
=============

Use regex file : /etc/fail2ban/filter.d/apache-auth.conf
Use log file   : /var/log/ispconfig/httpd/example.com/error.log


Results
=======

Failregex
|- Regular expressions:
|  [1] [[]client <HOST>[]] user .* authentication failure
|  [2] [[]client <HOST>[]] user .* not found
|  [3] [[]client <HOST>[]] user .* password mismatch
|
`- Number of matches:
   [1] 48 match(es)
   [2] 119 match(es)
   [3] 0 match(es)

Ignoreregex
|- Regular expressions:
|
`- Number of matches:

Summary
=======

Addresses found:
[1]
    xxx.xxx.xxx.xxx (Fri Sep 09 11:26:18 2011)
    ... [etc] ...

Date template hits:
9836 hit(s): MONTH Day Hour:Minute:Second
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second
0 hit(s): Year/Month/Day Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/MONTH/Year:Hour:Minute:Second
0 hit(s): Month/Day/Year:Hour:Minute:Second
0 hit(s): Year-Month-Day Hour:Minute:Second
0 hit(s): Day-MONTH-Year Hour:Minute:Second[.Millisecond]
0 hit(s): Day-Month-Year Hour:Minute:Second
0 hit(s): TAI64N
0 hit(s): Epoch
0 hit(s): ISO 8601
0 hit(s): Hour:Minute:Second
0 hit(s): <Month/Day/Year@Hour:Minute:Second>

Success, the total number of match is 167

However, look at the above section 'Running tests' which could contain important
information.

In my attempts to trigger a ban, I've entered invalid Apache credentials as many as two dozen times over the course of several minutes, yet the iptables rules are never modified accordingly (even though fail2ban is parsing the log entries correctly, per the above output).

Nothing significant is written to the fail2ban logs when I intentionally fail Apache authentication a dozen or so times. When I start the service, the following output is written to fail2ban's log:

2011-11-23 13:49:35,406 fail2ban.server : INFO   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.4
2011-11-23 13:49:35,407 fail2ban.jail   : INFO   Creating new jail 'ssh'
2011-11-23 13:49:35,407 fail2ban.jail   : INFO   Jail 'ssh' uses poller
2011-11-23 13:49:35,425 fail2ban.filter : INFO   Added logfile = /var/log/auth.log
2011-11-23 13:49:35,425 fail2ban.filter : INFO   Set maxRetry = 6
2011-11-23 13:49:35,427 fail2ban.filter : INFO   Set findtime = 600
2011-11-23 13:49:35,428 fail2ban.actions: INFO   Set banTime = 600
2011-11-23 13:49:35,519 fail2ban.jail   : INFO   Creating new jail 'apache'
2011-11-23 13:49:35,519 fail2ban.jail   : INFO   Jail 'apache' uses poller
2011-11-23 13:49:35,520 fail2ban.filter : INFO   Added logfile = /var/log/ispconfig/httpd/sub1.example.com/error.log
2011-11-23 13:49:35,521 fail2ban.filter : INFO   Added logfile = /var/log/ispconfig/httpd/sub2.example.com/error.log
2011-11-23 13:49:35,521 fail2ban.filter : INFO   Set maxRetry = 6
2011-11-23 13:49:35,522 fail2ban.filter : INFO   Set findtime = 600
2011-11-23 13:49:35,523 fail2ban.actions: INFO   Set banTime = 600
2011-11-23 13:49:35,532 fail2ban.jail   : INFO   Jail 'ssh' started
2011-11-23 13:49:35,533 fail2ban.jail   : INFO   Jail 'apache' started

Where should I be looking next? Am I overlooking something obvious?

Thanks for any insights!

[pititis]

Filter is working

Try to add

port= http,https

in your jail.local in the apache section.

Cheers

[cbj4074]

Thank you for the reply, pititis.

I tried adding that line in jail.local, and restarting fail2ban, but I am still unable to trigger a ban by failing Apache authentication.

And, technically speaking, the suggested line should already have been active due to its presence in jail.conf. As I understand it, all configuration directives from jail.conf apply until they are overridden (optionally) in jail.local. From the documentation:

# Optionally you may override any other parameter (e.g. banaction,
# action, port, logpath, etc) in that section within jail.local

Here is the relevant section of jail.conf, which I have not modified:

[apache]

enabled = false
port    = http,https
filter  = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 6

And again, the contents of jail.local:

[apache]
enabled = true
logpath = /var/log/ispconfig/httpd/*/error.log

So, the only configuration change I've made is to override the "enabled" and "logpath" values via jail.local.

Any other thoughts?

Thanks again!

[cbj4074]

I realized that fail2ban stopped working for SSH, too, at some point during this process.

I thought that perhaps I'd butchered a configuration value somewhere while attempting to implement banning for Apache authentication.

But after comparing all files in /etc/fail2ban with those on a similarly-configured server on which SSH banning works as intended, I ruled-out that possibility: all files were identical.

So, I elected to remove fail2ban (with apt-get remove fail2ban) and reinstall it (with apt-get install fail2ban)... Apache banning now functions (at least somewhat... more on that in a moment).

In jogging my memory, it occurred to me that, at some point, I modified a core fail2ban python file to solve a race-condition that appears to be Debian-specific. I was receiving these types of messages in the log when I first attempted to implement banning for services other than SSH:

2011-11-23 10:48:56,713 fail2ban.actions.action: ERROR  iptables -N fail2ban-postfix
iptables -A fail2ban-postfix -j RETURN
iptables -I INPUT -p tcp --dport smtp -j fail2ban-postfix returned 200
2011-11-23 11:15:29,932 fail2ban.actions.action: ERROR  iptables -D INPUT -p tcp --dport smtp -j fail2ban-postfix
iptables -F fail2ban-postfix
iptables -X fail2ban-postfix returned 100

I found discussion of the issue at http://www.fail2ban.org/wiki/index.p...rtup.2Frestart and implemented the last recommended fix:

In /usr/share/fail2ban/server/action.py` (Debian) just add a sleep(1):

 def execActionStart(self):
   startCmd = Action.replaceTag(self.__actionStart, self.__cInfo)
   sleep(1)
   return Action.executeCmd(startCmd)

After reinstalling fail2ban, which presumably undid the change to the python file, Apache banning works, as mentioned above, but I still receive errors like this in the fail2ban log:

2011-12-01 14:20:16,994 fail2ban.server : INFO   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.4
2011-12-01 14:20:16,995 fail2ban.jail   : INFO   Creating new jail 'ssh'
2011-12-01 14:20:16,995 fail2ban.jail   : INFO   Jail 'ssh' uses poller
2011-12-01 14:20:17,015 fail2ban.filter : INFO   Added logfile = /var/log/auth.log
2011-12-01 14:20:17,016 fail2ban.filter : INFO   Set maxRetry = 6
2011-12-01 14:20:17,018 fail2ban.filter : INFO   Set findtime = 600
2011-12-01 14:20:17,019 fail2ban.actions: INFO   Set banTime = 600
2011-12-01 14:20:17,104 fail2ban.jail   : INFO   Creating new jail 'apache'
2011-12-01 14:20:17,104 fail2ban.jail   : INFO   Jail 'apache' uses poller
2011-12-01 14:20:17,105 fail2ban.filter : INFO   Added logfile = /var/log/ispconfig/httpd/site1.example.com/error.log
2011-12-01 14:20:17,107 fail2ban.filter : INFO   Added logfile = /var/log/ispconfig/httpd/site2.example.com/error.log
2011-12-01 14:20:17,108 fail2ban.filter : INFO   Set maxRetry = 6
2011-12-01 14:20:17,110 fail2ban.filter : INFO   Set findtime = 600
2011-12-01 14:20:17,110 fail2ban.actions: INFO   Set banTime = 600
2011-12-01 14:20:17,125 fail2ban.jail   : INFO   Jail 'ssh' started
2011-12-01 14:20:17,126 fail2ban.jail   : INFO   Jail 'apache' started
2011-12-01 14:20:17,218 fail2ban.actions.action: ERROR  iptables -N fail2ban-ssh
iptables -A fail2ban-ssh -j RETURN
iptables -I INPUT -p tcp -m multiport --dports ssh -j fail2ban-ssh returned 400

Further, it seems that only one of any number of jails is able to write to the iptables configuration at a time. In other words, if Apache banning functions as expected, SSH banning does not -- and vice versa.

At this point, it's worth mentioning that I believe that the following bug describes this very issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554162

So, I'll wait until fail2ban_0.8.5-2_all.deb is the latest stable release and see if the issue is resolved. And I'll report back at that time.

[cbj4074]

Well, I just couldn't wait, so I installed the latest .deb package. The problem appears to be resolved.