On 08/05/2021 10:33, Dan Egli wrote:
On 5/8/2021 2:55 AM, Nick Howitt wrote:
On 08/05/2021 09:39, Dan Egli wrote:
On 5/8/2021 2:13 AM, Nick Howitt wrote:
Looking at the output, I think you've quoted the regex in your
/root/test.conf as the "failrexex =" line is different in your two
tests. Remove the quoting.
If only it were that simple. The file isn't quoted. Here's the exact
contents, character for character:
[Definition]
failrexex = .*<HOST>\#.*
ignoreregex =
I assume failrexex is a typo. Do you have an [Includes] section?
I wish. I cannot BELIEVE I missed that. What I put was a direct
copy/paste. That's fixed now and it matches in the test sequence.
But something strange is going on. Fail2ban created the named-refused
table in iptables just fine. But it is populated with a LOT of returns:
<non-F2B rule>
-A f2b-named-refused -j RETURN
-A f2b-named-refused -j RETURN
-A f2b-named-refused -j RETURN
-A f2b-named-refused -j RETURN
-A f2b-named-refused -j RETURN
-A f2b-named-refused -j RETURN
-A f2b-named-refused -j RETURN
-A f2b-named-refused -j RETURN
-A f2b-recidive -s 85.55.160.62/32 -j REJECT --reject-with
icmp-port-unreachable
Why on earth do we need that many returns?
BTW I think you are cutting way too much from the posts that they are
impossible to follow.
I will remember that. Sorry. I'm used to keeping emails small.
From memory, that is a potential bug in the f2b action. Personally I
don't use iptables actions. I use ipset actions which are much more
efficient for larger blocks, but you can't directly read what is blocked
from an iptables dump.
In a custom chain there is no need for a RETURN rule as that is the
default action anyway, so it is best to remove it from the action.
_______________________________________________
Fail2ban-users mailing list
Fail2ban-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
