fail2ban does not modify iptables entries

Discussion in 'General' started by cbj4074, Nov 23, 2011.

  1. cbj4074

    cbj4074 Member HowtoForge Supporter

    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!
     
    Last edited: Nov 23, 2011
  2. pititis

    pititis Member

    Filter is working

    Try to add

    port= http,https

    in your jail.local in the apache section.

    Cheers
     
  3. cbj4074

    cbj4074 Member HowtoForge Supporter

    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!
     
  4. cbj4074

    cbj4074 Member HowtoForge Supporter

    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....ban.actions.action_ERROR_on_startup.2Frestart and implemented the last recommended fix:

    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.
     
  5. cbj4074

    cbj4074 Member HowtoForge Supporter

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

Share This Page