Hi Yassine,
The shorewall action does not ban on a per-jail basis, but puts all
ip-addresses on a single blacklist, as that is how shorewall works.
In the original recidive implementation (which I wrote) it was
especially mentioned that you shouldn't use the same jail action for the
recidive jail as for the other jails just because of this: I used the
shorewall jail too.
In short: don't use the 'shorewall' action, or use the 'iptables' action
for the recidive jail (and 'shorewall' for the regular jails).
Kind regards,
Tom
On 07-07-2020 15:22, Yassine Chaouche wrote:
Thank you Peter, that was much appreciated.
Maybe the problem comes from the shorewall action I am using, which
isn't as feature-rich as the iptables action. Compare :
root@messagerie[10.10.10.19] ~ # removeblanks
/etc/fail2ban/action.d/iptables.conf
[INCLUDES]
before = iptables-blocktype.conf
[Definition]
actionstart = iptables -N fail2ban-<name>
iptables -A fail2ban-<name> -j RETURN
iptables -I <chain> -p <protocol> --dport <port> -j
fail2ban-<name>
actionstop = iptables -D <chain> -p <protocol> --dport <port> -j
fail2ban-<name>
iptables -F fail2ban-<name>
iptables -X fail2ban-<name>
actioncheck = iptables -n -L <chain> | grep -q 'fail2ban-<name>[ \t]'
actionban = iptables -I fail2ban-<name> 1 -s <ip> -j <blocktype>
actionunban = iptables -D fail2ban-<name> -s <ip> -j <blocktype>
[Init]
name = default
port = ssh
protocol = tcp
chain = INPUT
root@messagerie[10.10.10.19] ~ # removeblanks
/etc/fail2ban/action.d/shorewall.conf
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = shorewall <blocktype> <ip>
actionunban = shorewall allow <ip>
[Init]
blocktype = reject
root@messagerie[10.10.10.19] ~ #
(removeblanks is just an alias)
root@messagerie[10.10.10.19] ~ # type removeblanks
removeblanks is aliased to `egrep -v '(^[[:space:]]*#|^$|^[[:space:]]*//)''
root@messagerie[10.10.10.19] ~ #
This explains why there are no fail2ban-* chains in iptable, everything
seems to done in the dynamic chain.
root@messagerie[10.10.10.19] ~ # iptables -vnL | grep fail
root@messagerie[10.10.10.19] ~ #
Yassine.
Le 2020-07-07 13:35, Peter Heirich a écrit :
Am 07.07.2020 um 13:32 schrieb Yassine Chaouche:
Let us examine what f2b logs for 185.143.72.27 say :
1. Is is banned/unbanned by *postfix-sasl* 4 times
2. on the fifth occurence, it is first banned by the *postfix-sasl*
jail then by the *recidive* jail. Curiously, the *recidive* jail
doesn't detect that it has already been banned before. Maybe because
each ban is related to a jail. Since the *recidive* jail hasn't seen
this IP before, it bans it.
3. After 10 minutes, the ban set by *postfix-sasl* expires, and that
jail unbans the IP, cancelling the *recidive* jail ban ?
Dont't worry !
No jail does know about another one.
recidive jail only scans the log of fail2ban for "NOTICE [ xxxxxx] Ban
<ip>"
However, xxxxxx may not be "revidive" to prevent a loop. That's the
(?!%(_jailname)s\]) part in filter.
Because _jailname is defined as "recidive" some lines above
%(_jailname)s expands to recidive.
So finaly (?!recidive\]) is used. That is a negative forward lookup,
if found "recidive]" the whole regex fails
All other Ban 's ( note: not Restore Ban ) are counted within the
findtime window, if exceeds maxretry= the ip is banned within the
recidive jail.
So, you are seeing right, first ban ist postfix-sasl (probably false
password for smtp), log entry is done for that. And this log entry
triggers the recidive ban.
After the bantime of postfix-sasl ip is removed from posfix-sasl jail.
But that doesn't mean to be removed from recidive jail.
However a faulty setup ( one ip-set for all jails ) can cause
mailfunction, because the first unban removes ip from ipset.
Usualy each jail has its own ipset or chain in ip-tables.
I, for myself, found a problem also with jailing a ip longer then 55h
on my Centos 6 within ipset. Therefor i'm jailing recidive ip's within
2 chains in iptables.
(2 chains: one for input, one for output, output to make live hard for
a hacker, who already started code on my system[maybe by
stackoverflow]. In this case, maybe a "call-to-home" program should be
prevented from call to home; OK in real they are 4 chains: 2 for IPv4
and 2 for IPv6 of course)
Try "ipset list" command, if you are run ipset based jails, "iptables
-vn -L" otherwise
You should find some f2b-<jailname> ipsets or chains in iptables, i.e.
f2b-postfix-sasl and f2b-recidive too.
Peter
_______________________________________________
Fail2ban-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
_______________________________________________
Fail2ban-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fail2ban-users
