View Single Post
  #4  
Old 2nd December 2011, 00:12
cbj4074 cbj4074 is offline
Senior Member
 
Join Date: Nov 2010
Posts: 392
Thanks: 29
Thanked 58 Times in 50 Posts
Default

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.
Reply With Quote