Forwarded to devs Plesk fail2ban jails and iptables not working correctly [SECURITY ISSUE?]

[Azurel]

Username: Azurel

TITLE

Plesk fail2ban jails and iptables not working correctly [SECURITY ISSUE?]

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

CentOS Linux 8.2.2004, Plesk Obsidian Version 18.0.30 Update #2

PROBLEM DESCRIPTION

Plesk shows in GUI banned IPs, but many of this IPs are not blocked in iptables.

I have take a look in iptables -L -n and ip6tables -L -n
Here are missing nearly 100 banned IPs, which exists in plesk.

f2b-plesk-modsecurity have in iptables 1 address, but in plesk 2 addresses (0 addresses in ip6tables)
f2b-recidive have in iptables 35 addresses, but in plesk 65 addresses (2 addresses in ip6tables)
2b-banned-servers have in iptables 10 addresses, but in plesk 119 addresses (1 address in ip6tables)
f2b-default have in iptables 3 addresses, and in plesk 3 addresses. This is the only one that is correct.

# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
f2b-plesk-dovecot tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 143,993,110,995,4190
f2b-banned-servers tcp -- 0.0.0.0/0 0.0.0.0/0
f2b-default tcp -- 0.0.0.0/0 0.0.0.0/0
f2b-recidive tcp -- 0.0.0.0/0 0.0.0.0/0
f2b-plesk-postfix tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587
f2b-ssh tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
f2b-plesk-modsecurity tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443,7080,7081

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain f2b-plesk-modsecurity (1 references)
target prot opt source destination
REJECT all -- 185.234.216.38 0.0.0.0/0 reject-with icmp-port-unreachable
RETURN all -- 0.0.0.0/0 0.0.0.0/0

Chain f2b-ssh (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0

Chain f2b-plesk-postfix (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0

Chain f2b-recidive (1 references)
target prot opt source destination
REJECT all -- 45.148.10.15 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 52.252.105.88 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 165.227.164.165 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 156.146.63.138 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 157.230.184.77 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 84.17.46.157 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 77.87.228.66 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 216.189.151.64 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 63.250.47.109 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 52.161.94.131 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 5.62.63.82 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 14.142.57.66 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 212.70.149.69 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 5.62.61.107 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 172.93.160.76 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 156.146.63.135 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 84.17.46.155 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 3.234.246.94 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 212.102.35.15 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 212.70.149.84 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 212.70.149.53 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 212.70.149.21 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 84.17.46.248 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 84.17.46.201 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 45.148.10.28 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 3.238.110.7 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 94.237.109.119 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 3.137.158.36 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 84.17.46.156 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 129.146.99.134 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 217.138.209.149 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 212.7.204.175 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 62.102.148.69 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 212.102.35.158 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 79.89.61.90 0.0.0.0/0 reject-with icmp-port-unreachable
RETURN all -- 0.0.0.0/0 0.0.0.0/0

Chain f2b-default (1 references)
target prot opt source destination
REJECT all -- 54.38.81.231 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 45.125.65.31 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 51.68.196.103 0.0.0.0/0 reject-with icmp-port-unreachable
RETURN all -- 0.0.0.0/0 0.0.0.0/0

Chain f2b-banned-servers (1 references)
target prot opt source destination
REJECT all -- 5.9.104.222 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 212.252.143.209 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 31.156.79.187 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 54.90.45.134 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 108.6.40.25 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 5.186.69.37 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 79.223.226.145 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 79.223.235.144 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 84.174.68.180 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- 79.223.226.75 0.0.0.0/0 reject-with icmp-port-unreachable
RETURN all -- 0.0.0.0/0 0.0.0.0/0

Chain f2b-plesk-dovecot (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0

I have take a look in f2b-banned-servers logfile that the last entries in this file

2020-10-16 17:28:01 1542 79.223.226.75
2020-10-17 05:29:01 1534 84.174.68.180
2020-10-18 05:36:01 1544 79.223.235.144
2020-10-19 02:44:02 1539 159.255.169.130
2020-10-19 05:29:01 1538 79.223.226.145
2020-10-19 05:32:01 1518 5.186.69.37
2020-10-19 05:39:01 1542 108.6.40.25
2020-10-19 20:55:02 1531 54.90.45.134
2020-10-19 22:58:02 1505 31.156.79.187
2020-10-20 01:27:02 1529 2003:c6:9738:f200:19c3:c87f:d48f:3a72
2020-10-20 03:34:01 1915 212.252.143.209
2020-10-20 04:57:01 1503 5.9.104.222

What I can see is the same ips (reverse) in iptables
- ipv4 159.255.169.130 is missing in iptables, but exists in plesk (this ip exists 3 times in logfile in last 2 months, because its not banned anymore, although the ban lasts 180 days.)
- ipv6 2003:c6:9738:f200:19c3:c87f:d48f:3a72 is in ip6tables
This file have 119 entries, all IPs are in plesk, but only 10 are blocked.
The "IP address ban period" for this jail is "15552000", thats 180 days. I can see that this fake blocked IPs request pages with http status code 200.

New banned ips are added. Is it possible that the "IP address ban period" is evaluated differently here and thus the IP is removed too earlier in iptables or another jail free this ips?

This data above are from tuesday. Today its WORST...
- f2b-banned-servers have 128 IPs in plesk and iptables show for this jail nothing.
- f2b-plesk-postfix have 6 IPv4s in plesk, but only 4 in iptables. (this 4 IPs are from today)
- f2b-default have have 4 IPs in plesk, but nothing in iptables.
- f2b-recidive have have 62 IPs in plesk, but nothing in iptables.

STEPS TO REPRODUCE

see description

ACTUAL RESULT

Plesk shows many Ips, which are not really banned.

EXPECTED RESULT

Plesk and iptables should match

ANY ADDITIONAL INFORMATION

Nothing self-installed, this system have iptables and firewalld.
# iptables -L -n
# firewall-cmd --check-config

# firewall-cmd --permanent --get-ipsets
Shows me only my own IPSets for custom blocked IPs. There are no plesk IPSets.
I have a script that weekly remove my custom IPSets and create it again by file. With "firewall-cmd --reload" its update all IPSets.

Weekly starts cronjob "50plesk-weekly". Is there somthing that change iptables? Its look like that weekly the iptables is cleared? All exists IPs have disappeared from this friday.



YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[Azurel]

After little chat with others, I think its maybe my weekly firewall-cmd --reload call? Does this command delete the iptables? Because I update a huge list of blocked ips weekly in firewalld with custom IPSets.

So what is here the way to manage my own firewalld IPSets and not clear banned ips with fail2ban in iptables?

Is here a way to re-insert banned ips from plesk to iptables?

 

[IgorG]

Both of them (fail2ban and firewalld) try to setup iptables so firewalld rewrites changes made by fail2ban.
It seems fail2ban can be configured to work with firewalld, it will be researched in the scope of PPPM-12458.

 

[Azurel]

Is there any news on the issue yet. As noted, you can no longer import IPs, because it resets the bans from Plesk without this being noticed in Plesk.

 

[Azurel]

I checked the banned IPs and this system is still a mess. This has an impact on security and performance!
Since august 2020 I have disabled my important script which import and ban country ip-ranges, which call firewall-cmd --reload because this issue here and now I see there is still a huge difference between ips in iptable and plesk.

In Plesk I can see for a single custom jail 400 IPs banned and in iptables(ipv4+ipv6) for this jail there are only 44 IP listed!
The Jail have a time of 180 days. Is here a hard limit thats clear iptables all maybe ~14 days?


EDIT: I have create a rebuild of my logfile thats fail2ban watched. Currently plesk and iptable v4+v6 have the same number of ips. I will observe when this differs again.