ip already banned log message

[gjpc]

I am running ubuntu 20.04.5 and occasionally I see an IP already banned log message. When I see this, I print the iptable ( iptables -nL ) and I invariably see this line in the table:

RETURN all -- 0.0.0.0/0 0.0.0.0/0

target prot opt source destination
REJECT all -- 151.80.76.65 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 106.4.163.21 0.0.0.0/0 reject-with icmp-port-unreachable
RETURN all -- 0.0.0.0/0 0.0.0.0/0
REJECT all -- 91.103.252.239 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 212.87.204.201 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 117.95.106.119 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 91.103.252.248 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 121.239.48.183 0.0.0.0/0 reject-with icmp-port-unreachable
RETURN all -- 0.0.0.0/0 0.0.0.0/0

I don't know if this artifact gets into the table because of a bug in fail2ban or a clever hacker exploit.
Regardless, the RETURN all goes away after a fail2ban service restart.
I am contemplating a cron job to restart fail2ban every few hours or at least once a day.

Anyone have any thoughts?

[sebres]

I don't understand your output (excerpt?)...
What do you show here - it is single chain containing all that IPs and RETURN all twice? Or are that 2 chains of 2 different jails?

Anyway that RETURN all must be only one time per chain and at end of chain.
It looks like something additionally manipulate your iptables, just...
I guess your output was for some chain f2b-*, which were definitely a chain of fail2ban. Nobody excepting fail2ban shall change there something.

One thing I can imagine is missing or disabled parameter -w (for locking) in your iptables action (e. g. for historic reasons deactivated previously?).

fail2ban/config/action.d/iptables-common.conf

Line 71 in 514cca9

lockingopt = -w

Check whether the dump (fail2ban-client -d or fail2ban-client --dp) contains it in all calls of iptables.
If it doesn't contain that, try to find your config where it is overwritten with empty value.
Also check whether you have configured some chain twice (normally it is always f2b-*, where * is the jail name).
Or simply provide here your config dump.

If it is not a misconfiguration - a good "workaround" may be the switch to another action, e. g. iptables-ipset or nftables (if you have it).

[gjpc]

Thanks for the quick reply @sebres

What do you show here - it is single chain containing all that IPs and RETURN all twice? Or are that 2 chains of 2 different jails?

It is a section of the Chain f2b-postfix-sasl table. I agree the RETURN all should only appear at the end of the table. To my knowledge I have no other process that manipulates the fail2ban tables.

One thing I can imagine is missing or disabled parameter -w (for locking) in your iptables action (e. g. for historic reasons deactivated previously?).

The /etc/fail2bban/action.d/iptables-common.conf has the lockingopt = -w in it. A grep of all the configuration directories reveals lockingopt in only in the iptables-common.conf file. it is assigned once and used twice.

I attached the entire output of the fail2ban-client --dp command with the ip's redacted.
f2b_dp_dump.txt

Thanks again, I shall be happy to provide you with any other information you would like. I shall study up on iptables-ipset and nfttables I am not familiar with either of them.

[sebres]

Hmm... The config seems to be OK (as for postfix-sasl jail), also it has only one chain with that name...

There was already an issue alleged that actionstart will be invoked twice - #3342, just I cannot reproduce it at all.
Although in the artificial case like that you'd see something like iptables: Chain already exists. in fail2ban.log (implicitly somewhere after ban in that jail), did you?

Which fail2ban version is it?

Regarding the actions, it'd be enough to add this in default section of your jail.local (for fail2ban ver. > 1.0):

[DEFAULT]
banaction = iptables-ipset[type=multiport]
banaction_allports = iptables-ipset[type=allports]

or this (for previous versions):

[DEFAULT]
banaction = iptables-ipset-proto6
banaction_allports = iptables-ipset-proto6-allports

(that actions are obsolete)

[gjpc]

# fail2ban-server --version
Fail2Ban v0.11.1

# fail2ban-client --version
Fail2Ban v0.11.1

0.11.1 is the latest version in the Ubuntu channel. Unfortunately when I add the second set of directives to jail.local. I get a set of errors for each banned ip restored on server startup in the fail2ban.log file:

18.159', 'family': 'inet4', 'fid': <function Actions.ActionInfo.<lambda> at 0x7f77fef33c10>, 'raw-ticket': <function Actions.ActionInfo.<lambda> at 0x7f77fef37310>})': Error starting action Jail('postfix')/iptables-ipset-proto6: 'Script error'
2023-03-14 10:58:02,216 fail2ban.actions        [153642]: NOTICE  [postfix] Restore Ban 92.253.40.120
2023-03-14 10:58:02,223 fail2ban.utils          [153642]: ERROR   7f77ffab0210 -- exec: ipset create f2b-postfix hash:ip timeout 600
iptables -w -I INPUT -p tcp -m multiport --dports smtp,ssmtp -m set --match-set f2b-postfix src -j REJECT --reject-with icmp-port-unreachable
2023-03-14 10:58:02,224 fail2ban.utils          [153642]: ERROR   7f77ffab0210 -- stderr: '/bin/sh: 1: ipset: not found'
2023-03-14 10:58:02,224 fail2ban.utils          [153642]: ERROR   7f77ffab0210 -- stderr: "iptables v1.8.4 (legacy): Set f2b-postfix doesn't exist."
2023-03-14 10:58:02,224 fail2ban.utils          [153642]: ERROR   7f77ffab0210 -- stderr: ''
2023-03-14 10:58:02,225 fail2ban.utils          [153642]: ERROR   7f77ffab0210 -- stderr: "Try `iptables -h' or 'iptables --help' for more information."
2023-03-14 10:58:02,225 fail2ban.utils          [153642]: ERROR   7f77ffab0210 -- returned 2
2023-03-14 10:58:02,226 fail2ban.actions        [153642]: ERROR   Failed to execute ban jail 'postfix' action 'iptables-ipset-proto6' info 'ActionInfo({'ip': '92.253.40.120', 'family': 'inet4', 'fid': <function Actions.ActionInfo.<lambda> at 0x7f77fef33c10>, 'raw-ticket': <function Actions.ActionInfo.<lambda> at 0x7f77fef37310>})': Error starting action Jail('postfix')/iptables-ipset-proto6: 'Script error'

Thanks for you help.

[sebres]

But did you see iptables: Chain already exists. in fail2ban.log as I asked before:
Although in the artificial case like that you'd see something like iptables: Chain already exists. in fail2ban.log (implicitly somewhere after ban in that jail), did you?

0.11.1 is the latest version in the Ubuntu channel.

It is not a big issue, you can upgrade or install it manually, see https://github.com/fail2ban/fail2ban/wiki/How-to-install-or-upgrade-fail2ban-manually.

ipset: not found

Well, ipset needs to be installed (and supported by the kernel), additionally the path returned by ?sudo? whereis ipset must be in PATH of fail2ban service (what should be normally the case, but...) otherwise the action needs to be adjusted to use full-qualified path.

[gjpc]

Sorry, I did search for Chain already exists and it is not in any of my logs.

My kernel does support ipset I installed it and now the second set of directives result in a working fail2ban server.

I'll keep an eye on the tables and let you know if the errant RETURN all reappears.

[sebres]

I did search for Chain already exists and it is not in any of my logs.

Strange. And some other errors in fail2ban.log?

and let you know if the errant RETURN all reappears.

Why it should? There are no chains f2b-* with iptables-ipset, it inserts only single rule per jail with match-set into INPUT chain that looking like:

# iptables -nL INPUT
Chain INPUT (policy DROP)
target     prot opt source               destination
DROP       all  --  0.0.0.0/0            0.0.0.0/0            match-set f2b-net-flood src
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22,2222 match-set f2b-sshd src reject-with icmp-port-unreachable
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            match-set f2b-pam-generic src reject-with icmp-port-unreachable
...

(there are 2 rules of allports jails and 1 rule with multiport jail)
and the IPs going into corresponding sets, which could be retrieved with ipset list, e. g. ipset list f2b-sshd.

Just if the actionstart would be erroneously invoked second time, this could add the same rule once more (so maybe then you'd see double entries in INPUT chain), what would not cause a unbanned state like with iptables action, but bother by the net-filter subsystem (extra load by checking of the set twice).

[gjpc]

Hi @sebres I caught another IP 157.97.120.50 that got around the failtoban ip tables even after a restart of the fail2ban service.
When I added it to my f2b-failed2ban chain the ip was stopped.
I am attaching log excerpts and the iptables

157.97.120.50.already.banned.iptable.txt
fail.to.ban.157.97.120.50.log
mail.fail.to.ban.157.97.120.50.log

[sebres]

Well, that IP is continuously found by postfix jail and related chain f2b-postfix is a multiport chain referenced in INPUT with 25 and 465 ports only.
Either there are another ports where postfix is listening or it can be connected to another service (also on another port) authenticating via postfix. Check it (e. g. ?sudo? netstat -tunlp) and extend the parameter port of postfix jail with corresponding port(s).
For another issues see FAQ in wiki for instance the answer to 2nd question.