HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials - fail2ban does not modify iptables entries

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)

- General (http://www.howtoforge.com/forums/forumdisplay.php?f=25)

- - fail2ban does not modify iptables entries (http://www.howtoforge.com/forums/showthread.php?t=55087)

fail2ban does not modify iptables entries

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:

Code:

[apache]

enabled = true

logpath = /var/log/ispconfig/httpd/*/error.log

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

Code:

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

Code:

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:

Code:

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!

Filter is working

Try to add

port= http,https

in your jail.local in the apache section.

Cheers

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:

Code:

# 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:

Code:

[apache]



enabled = false

port    = http,https

filter  = apache-auth

logpath = /var/log/apache*/*error.log

maxretry = 6

And again, the contents of jail.local:

Code:

[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!

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:

Code:

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:

Quote:

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

Code:

 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:

Code:

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.

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