recidive.local is being read but after recidive.conf, so breaking the conf file would fail to start.
Then dbpurgeage is just me mulling things over, fail2ban keeps it’s own list of ban lengths (e.g. you restart and logs have been rotated), so it may be that a 3 day ban is being implemented from the database rather than the log files (in which case then the local file is going to do nothing until everything has expired). But Tom’s answer is much better for a blanket whitelist in jail.conf | jail.local https://www.fail2ban.org/wiki/index.php/Whitelist although you may want to look at man fail2ban-client (to deal with any issues arising from the internal database) and unban <IP> or set <JAIL> delignoreip <IP> like fail2ban-client set recidive unbanip 145.249.104.70 except using your ip’s. Something(s) to consider though. The first regex works > ignoreregex = 11\.11\.11\.11 > 22\.22\.22\.22 > 33\.33\.33\.33 so the second should be > ignoreregex = \[recidive\]\s+Ban\s+11\.11\.11\.11\s*$ > \[recidive\]\s+Ban\s+22\.22\.22\.22\s*$ > \[recidive\]\s+Ban\s+33\.33\.33\.33\s*$ as .* globs are very general (my original perl / regex teachers were not fans), are on a line by line match it may be trimming so it may be worth removing the \s* at the end. if receive is still causing issues then why not move backwards to using the original jail/ filter that triggered the block as a holistic view if you have definite ip addresses that are triggering the system then surely you don’t want to get any kind of ban even a 5 minute one implemented? if you wanted to go down the regex route the an example from hacking my own nginx-botsearch.local would be failregex = ^<HOST> \- \S+ \[\] \"(OPTIONS|PROPFIND) \S+ \S+\" (301|4(0|4)(0|4|5)) .+$ ignoreregex = ^<ips2ignore> \- \S+ \[\] \"(OPTIONS|PROPFIND) \S+ \S+\" (301|4(0|4)(0|4|5)) .+$ and under [Init] in botsearch-common.local ips2ignore = (11\.11\.11\.11|22\.22\.22\.22|33\.33\.33\.33) Tom’s answer is still the better one, and my last answer above involves playing with two files which is more difficult to track but on the other hand it does use the established regex that would match the ip addresses puts them into a variable which is a little easier to read and goes to the root of the issue which really is why are those ip addresses failing in the first place. Let’s say 11.11.11.11 gets hacked through the web server, they install a bot and start searching to brute force SSH on 22.22.22.22, Tom’s answer is great but surely you would want damage limitation on 11.11.11.11 on your internal network by still having recidive in place? so I’m thinking that as an overall policy it’s probably best to get down to the original sources of the blocks rather than issuing blanket whitelists or trying to give a free pass on recidive. Sorry for the long answer, just mulling over what you’re trying to achieve and considering the alternative angles. > On 3 Aug 2018, at 08:13, Michael Fox <[email protected]> wrote: > > 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 ------------------------------------------------------------------------------ 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
