Thanks Philip. Lots of stuff there that I wouldn't have known to do. Point by
point:
$ fail2ban-client -dvv status 2>&1 | grep recidive | grep local
DEBUG Reading config files: /etc/fail2ban/filter.d/recidive.conf,
/etc/fail2ban/filter.d/recidive.local
INFO Loading files: ['/etc/fail2ban/filter.d/recidive.local']
INFO Loading files: ['/etc/fail2ban/filter.d/common.conf',
'/etc/fail2ban/filter.d/recidive.conf', '/etc/fail2ban/filter.d/common.conf',
'/etc/fail2ban/filter.d/recidive.local']
['set', 'recidive', 'action', 'sendmail-whois-lines', 'dest', 'root@localhost']
['set', 'recidive-ext', 'action', 'sendmail-whois-lines', 'dest',
'root@localhost']
$
I'm not sure what the above is saying, but it seems to be saying that
recidive.local is being read.
But, if I break recidive.conf (as you described), fail2ban fails to start. So,
this hints at recidive.local not being used. But it could be that f2b checks
the syntax of x.conf even if x.local exists, even though that doesn't seem
necessary. So, this doesn't seem to be a definitive test ... but interesting.
The contents of recidive.local are simple. I just copied recidive.conf to
recidive.local and add an ignoreregex.
I tried two approaches:
ignoreregex = 11\.11\.11\.11
22\.22\.22\.22
33\.33\.33\.33
ignoreregex = ^.*Ban\s+11\.11\.11\.11\s*$
^.*Ban\s+22\.22\.22\.22\s*$
^.*Ban\s+33\.33\.33\.33\s*$
Both produce the same result in fail2ban-regex (the ignore regex matches what
it should), yet both fail to ignore the IPs (as evidenced by lines in iptables
for the f2b-recidive chain.
Very strange.
I don't know why you wanted this (i.e. it seems irrelevant to the issue at
hand), but:
$ sudo fail2ban-client get dbpurgeage
Current database purge age is:
`- 648000seconds
Michael
> -----Original Message-----
> From: Philip James Clarke <[email protected]>
> Subject: Re: [Fail2ban-users] recidive filter ignores ignoreregex?
>
> Hmm, looking thought fail2ban.log (set to debug level INFO) and also
> checking fail2ban-client -d, I can’t see anything that says specifically
> that a local file is overriding a conf file. Your fail2ban-regex test is
> very precise in the file it defines, so to check fail2ban is working I
> suggest you break the conf file :) to check local is being loaded (I added
> the line junk junk junk to the definition and it certainly crashed on a
> restart plus confirmed in syslog that the recidive.local fails was the
> cause), my first rule of debugging try and work out whether the files
> loading.
>
> A bit of guesswork and the following shell command
>
> fail2ban-client -dvv status 2>&1 | grep recidive | grep local
>
> should show if recidive.local is being read without changing the debug
> level and ending up in an infinite loop ad per the instructions in the
> configuration file.
>
> You may want to have a look at
>
> man fail2ban-client
>
> and
>
> fail2ban-client get dbpurgeage
>
> as possibly recidive works in an entirely different manner.
>
> Posting your modified recidive.local might help too, I’m prepared to have
> a play around on a VM and see if I can trigger an example Ignoreregex
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Fail2ban-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
