On 06/28/2015 04:42 AM, Michael Grant wrote: > On Thu, Jun 25, 2015 at 3:59 PM, Lee Clemens <j...@leeclemens.net > <mailto:j...@leeclemens.net>> wrote: > > On 06/24/2015 05:03 AM, Michael Grant wrote: > > apache-fakegooglebot uses an ignore command in jail.conf as follows: > > > > [apache-fakegooglebot] > > > > port = http,https > > logpath = %(apache_access_log)s > > maxretry = 1 > > ignorecommand = %(ignorecommands_dir)s/apache-fakegooglebot <ip> > > > > This does seem to work however, in my logs this is what I see: > > > > 2015-06-24 04:41:39,255 fail2ban.action [3210]: ERROR > /etc/fail2ban/filter.d/ignorecommands/apache-fakegooglebot 97.74.198.34 -- > stdout: b'' > > 2015-06-24 04:41:39,288 fail2ban.action [3210]: ERROR > /etc/fail2ban/filter.d/ignorecommands/apache-fakegooglebot 97.74.198.34 -- > stderr: b'' > > 2015-06-24 04:41:39,419 fail2ban.action [3210]: ERROR > /etc/fail2ban/filter.d/ignorecommands/apache-fakegooglebot 97.74.198.34 -- > returned 1 > > 2015-06-24 04:41:40,205 fail2ban.action [3210]: ERROR > /etc/fail2ban/filter.d/ignorecommands/apache-fakegooglebot 98.27.207.80 -- > stdout: b'' > > 2015-06-24 04:41:40,221 fail2ban.action [3210]: ERROR > /etc/fail2ban/filter.d/ignorecommands/apache-fakegooglebot 98.27.207.80 -- > stderr: b'' > > 2015-06-24 04:41:40,360 fail2ban.action [3210]: ERROR > /etc/fail2ban/filter.d/ignorecommands/apache-fakegooglebot 98.27.207.80 -- > returned 1 > > > > ... about 4 minutes later... > > > > 2015-06-24 04:45:37,398 fail2ban.actions [3210]: NOTICE > [apache-fakegooglebot] Ban 97.74.198.34 > > 2015-06-24 04:45:38,681 fail2ban.actions [3210]: NOTICE > [apache-fakegooglebot] Ban 98.27.207.80 > > > > It appears that fail2ban sees the return code from the ignorecommand as > an error, whereas it is correctly using this return code to know whether to > ban this hit or not. Initially I thought this might be a python 2 vs 3 > difference, now I'm not sure. > > Correct, the return code is how the action determines if it should be > ignored. It uses the same function to execute other commands, which is why it > is logged as an error with stdout and stderr (same as if an iptables command > failed). If the ignorecommand returns 0, the line is ignored - similar to > ignoreregex matching). > > The b'' output is a Python 3 difference, since stdout and stderr are > bytes. > > > Ah ok I see why it's putting all this ERROR stuff in the log now. I know > it's minor but is it possible to clean this up in the future? I know this > might be a painful change but maybe instead of using the return code, how > about defining that ignore commands should return a number say 0 or 1.
They do return a 0 or 1, that's pretty standard (well, 0 and non-zero return codes, anyway). What if there is an error while executing the ignorecommand (not the intentional non-zero, but an actual error), shouldn't that get logged? I see your point, but given the construct of the existing framework for `ignorecommand`, what do you have in mind? > > Or here's another possible idea: Instead of an ignorecommand, what about a > postfilter command which is given arguments like the ignorecomand but returns > a list of addresses or address/masks to ban, one per line? This way, it > could return nothing and have the same effect as the ignorecommand. It could > also return multiple addresses if it wanted to (for example the corresponding > a net block of ipv4 addresses or an ip6 address block...nudge nudge). This > would get around overloading the error code for ignorecommand and allow you > to return a true error if the postfilter command really failed. > > > > > > > Secondly, why does it take about 4 minutes before the actual ban > happens? I also don't see any FOUND line for these events. > > I haven't see it take longer than half a second or so looking at my logs. > I tried looking up the two IPs you provided as well and they returned in > under 0.1s. It is performing a DNS lookup, so if that takes a long time it > would cause a delay in the action. It may be useful to see what else was > going on during those 4 minutes (any other ignorecommands being run?, etc) or > overall network and system load. > > Does it take long to run the ignorecommand manually? > > > $ time /etc/fail2ban/filter.d/ignorecommands/apache-fakegooglebot 97.74.198.34 > > real 0m0.263s > user 0m0.063s > sys 0m0.037s > > $ echo $? > 1 > > Something else is going on here. I am wondering if this is thread related. > I do have large logs and I have bantime and failtime set to 7776000 (90 > days). > > I wonder, does fail2ban go back over the old log lines for any reason? When it restarts, it parses each log to find when time() - bantime starts, so it can start checking to ban hosts. It still needs to parse each line of the log though, in order to determine the timestamp. > > No something is not right. I'm also seeing a delay as per my other mail with > the already-banned lines. > > > > > > It seems to be working, I just am trying to understand what's going on. > ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ Fail2ban-users mailing list Fail2ban-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fail2ban-users
