• Hi, Pleskians! We are running a UX testing of our upcoming product intended for server management and monitoring.
    We would like to invite you to have a call with us and have some fun checking our prototype. The agenda is pretty simple - we bring new design and some scenarios that you need to walk through and succeed. We will be watching and taking insights for further development of the design.
    If you would like to participate, please use this link to book a meeting. We will sent the link to the clickable prototype at the meeting.
  • (Plesk for Windows):
    MySQL Connector/ODBC 3.51, 5.1, and 5.3 are no longer shipped with Plesk because they have reached end of life. MariaDB Connector/ODBC 64-bit 3.2.4 is now used instead.
  • Our UX team believes in the in the power of direct feedback and would like to invite you to participate in interviews, tests, and surveys.
    To stay in the loop and never miss an opportunity to share your thoughts, please subscribe to our UX research program. If you were previously part of the Plesk UX research program, please re-subscribe to continue receiving our invitations.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

Issue Fail2ban: Ip addresses are not blocked by Recidive

F

frg62

Basic Pleskian
Server operating system version
Debian 11
Plesk version and microupdate number
Plesk Obsidian 18.0.67 Update #3
Hello,

I have noticed that the IP addresses that are supposed to be banned in Recidive, actually still can access the server.
Here is an extract from the F2B logs for a specific attacking IP address:

2025-02-23 02:36:01,726 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-23 02:36:01
2025-02-23 02:37:38,237 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-23 02:37:38
2025-02-23 02:39:13,230 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-23 02:39:13
2025-02-23 02:39:13,613 fail2ban.actions [939832]: NOTICE [plesk-postfix] Ban 185.226.117.240
2025-02-23 02:39:13,614 fail2ban.filter [939832]: INFO [recidive] Found 185.226.117.240 - 2025-02-23 02:39:13
2025-02-23 03:39:13,243 fail2ban.actions [939832]: NOTICE [plesk-postfix] Unban 185.226.117.240
2025-02-23 03:39:15,657 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-23 03:39:15
2025-02-23 03:40:47,978 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-23 03:40:47
2025-02-23 03:42:23,482 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-23 03:42:23
2025-02-23 03:42:23,511 fail2ban.actions [939832]: NOTICE [plesk-postfix] Ban 185.226.117.240
2025-02-23 03:42:23,521 fail2ban.filter [939832]: INFO [recidive] Found 185.226.117.240 - 2025-02-23 03:42:23
2025-02-23 04:42:23,137 fail2ban.actions [939832]: NOTICE [plesk-postfix] Unban 185.226.117.240
2025-02-24 03:23:24,790 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-24 03:23:24
2025-02-24 03:24:52,367 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-24 03:24:52
2025-02-24 03:26:28,062 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-24 03:26:28
2025-02-24 03:26:28,392 fail2ban.actions [939832]: NOTICE [plesk-postfix] Ban 185.226.117.240
2025-02-24 03:26:28,401 fail2ban.filter [939832]: INFO [recidive] Found 185.226.117.240 - 2025-02-24 03:26:28
2025-02-24 04:26:28,378 fail2ban.actions [939832]: NOTICE [plesk-postfix] Unban 185.226.117.240
2025-02-24 04:27:45,311 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-24 04:27:45
2025-02-24 04:29:32,061 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-24 04:29:32
2025-02-24 04:31:20,203 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-24 04:31:20
2025-02-24 04:31:20,750 fail2ban.actions [939832]: NOTICE [plesk-postfix] Ban 185.226.117.240
2025-02-24 04:31:20,906 fail2ban.filter [939832]: INFO [recidive] Found 185.226.117.240 - 2025-02-24 04:31:20
2025-02-24 04:31:21,413 fail2ban.actions [939832]: NOTICE [recidive] Ban 185.226.117.240
2025-02-24 05:31:20,391 fail2ban.actions [939832]: NOTICE [plesk-postfix] Unban 185.226.117.240 <----------------------------------- !!!!!!!!!!!!!!!!!!!!
2025-02-24 06:25:46,311 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-24 06:25:46
2025-02-25 19:02:40,854 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-25 19:02:40
2025-02-25 19:02:47,885 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-25 19:02:47
2025-02-25 19:02:57,898 fail2ban.filter [939832]: INFO [plesk-postfix] Found 185.226.117.240 - 2025-02-25 19:02:57
2025-02-25 19:02:57,925 fail2ban.actions [939832]: NOTICE [plesk-postfix] Ban 185.226.117.240
2025-02-25 19:02:57,933 fail2ban.filter [939832]: INFO [recidive] Found 185.226.117.240 - 2025-02-25 19:02:57

As you can see, everything works correctly at the beginning:
The address is banned a few times by the Postfix jail (for 1 hour), and the Recidive counter is running until this jail bans the address (for 1 week).

OK, but one hour later the Postfix jail unbans the address!

And the cycle starts again, making the Recidive jail completely useless.

Where did I go wrong in my configuration?

Regards,
François
 
Is the banned IP address present in iptables?
Code: 
iptables -L -n | grep 185.226.117.240
 
No it is not:
Code: 
root@server:~# iptables -L -n | grep 185.226.117.240
# Warning: iptables-legacy tables present, use iptables-legacy to see them
root@server:~#

Yet it should be, because it was supposedly sent to Recidive 2 days ago (2025-02-24 04:31:21,413).
 
frg62 said:
# Warning: iptables-legacy tables present, use iptables-legacy to see them
Click to expand...
This warning indicates that you server is running nftables, whith legacy compatibility for iptables.

So instead of using the iptables command use the iptables-legacy command (or the equivalent nftables command) to get a proper output.
Code: 
iptables-legacy -L -n | grep 185.226.117.240
 
It looks like the warning should no longer be displayed, see the results for each command line:

Code: 
root@server:~# iptables-legacy -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
root@server:~#

Code: 
root@server:~# iptables -L -n
# Warning: iptables-legacy tables present, use iptables-legacy to see them
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
f2b-plesk-one-week-ban  udp  --  0.0.0.0/0            0.0.0.0/0
f2b-plesk-one-week-ban  tcp  --  0.0.0.0/0            0.0.0.0/0
f2b-plesk-wordpress  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443,7080,7081
f2b-apache  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443,7080,7081
f2b-recidive  tcp  --  0.0.0.0/0            0.0.0.0/0
f2b-plesk-modsecurity  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 80,443,7080,7081
f2b-plesk-dovecot  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 143,993,110,995,4190
f2b-plesk-postfix  tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 25,465,587
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
DROP       all  --  100.64.0.0/10        0.0.0.0/0
DROP       all  --  127.0.0.0/8          0.0.0.0/0
[...]
Chain f2b-recidive (1 references)
target     prot opt source               destination
REJECT     all  --  80.94.95.228         0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  194.0.234.11         0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  87.120.93.11         0.0.0.0/0            reject-with icmp-port-unreachable
REJECT     all  --  193.41.206.98        0.0.0.0/0            reject-with icmp-port-unreachable
RETURN     all  --  0.0.0.0/0            0.0.0.0/0
root@server:~#
 
If you're dealing with IP bans in Plesk and need to adjust the ban period for WordPress-related security blocks, follow these steps:

1. Log into Plesk.
2. Navigate to Tools & Settings > IP Address Banning (Fail2Ban) > Jail tab.
3. Locate plesk-wordpress and click Change Settings.
4. Set a new value for the IP address ban period according to your preference.
5. Click OK to save the changes.

This should help manage how long IPs remain blocked by Fail2Ban in Plesk. Hope this helps!
 
To me it seems o.k. that the Postfix chain entry is removed. Our servers here are doing this all the time: They remove entries from the individual jail chains while they keep the entries in the recidive jail chain. The problem here seems to be that the IP is not being added to the recidive chain in the first place. Removing an IP from another chain does not modify the recidive jail chain (unless that is a bug with the iptables-legacy thing ...)

It is thinkable that the "action" defined in jail.local for the recidive jail fails. After the recidive ban is logged, do you see the IP address in the recidive jail chain at all?
 
OK, after looking at F2B logs over a long period, I think I have finally understood how it works.

It looks like each jail works in total independence.
An IP address can first be jailed several times by f.i. "postfix", and "recidive" increment its counter, until it jails the attacking address.

But this does not stop "postfix" from continuing to detect and jailing the same address as long, as this one persists in trying to connect.
And the increment in "recidive" starts again, ending up in re-banning the address.
(Which, I suppose, means resetting the banning period.)

For example, here is a filtered extract from my logs, that shows a very persistent attacking IP address:

Code: 
2025-03-10 11:48:47,133 fail2ban.actions        [1146993]: NOTICE  [plesk-postfix] Ban 194.0.234.230
2025-03-10 11:48:47,141 fail2ban.filter         [1146993]: INFO    [recidive] Found 194.0.234.230 - 2025-03-10 11:48:47
2025-03-10 11:48:47,533 fail2ban.actions        [1146993]: WARNING [recidive] 194.0.234.230 already banned
2025-03-10 11:48:47,533 fail2ban.actions        [1146993]: NOTICE  [recidive] Reban 194.0.234.230, action 'iptables-allports'
2025-03-10 12:48:46,288 fail2ban.actions        [1146993]: NOTICE  [plesk-postfix] Unban 194.0.234.230
[...]
2025-03-12 04:05:51,996 fail2ban.actions        [1146993]: NOTICE  [plesk-postfix] Ban 194.0.234.230
2025-03-12 04:05:52,352 fail2ban.filter         [1146993]: INFO    [recidive] Found 194.0.234.230 - 2025-03-12 04:05:51
2025-03-12 04:05:52,898 fail2ban.actions        [1146993]: WARNING [recidive] 194.0.234.230 already banned
2025-03-12 04:05:52,899 fail2ban.actions        [1146993]: NOTICE  [recidive] Reban 194.0.234.230, action 'iptables-allports'
2025-03-12 05:05:51,221 fail2ban.actions        [1146993]: NOTICE  [plesk-postfix] Unban 194.0.234.230
[...]
2025-03-14 03:14:31,663 fail2ban.actions        [1146993]: NOTICE  [plesk-postfix] Ban 194.0.234.230
2025-03-14 03:14:31,672 fail2ban.filter         [1146993]: INFO    [recidive] Found 194.0.234.230 - 2025-03-14 03:14:31
2025-03-14 03:14:32,268 fail2ban.actions        [1146993]: WARNING [recidive] 194.0.234.230 already banned
2025-03-14 03:14:32,269 fail2ban.actions        [1146993]: NOTICE  [recidive] Reban 194.0.234.230, action 'iptables-allports'
2025-03-14 04:14:31,296 fail2ban.actions        [1146993]: NOTICE  [plesk-postfix] Unban 194.0.234.230
[...]
2025-03-14 09:53:19,592 fail2ban.actions        [1146993]: NOTICE  [plesk-postfix] Ban 194.0.234.230
2025-03-14 09:53:19,600 fail2ban.filter         [1146993]: INFO    [recidive] Found 194.0.234.230 - 2025-03-14 09:53:19

At this moment, this address has been continuously re-banned by "recidive" for over 4 days.
 
It does work like this, but once the address is banned, no further login attempts should be logged by the plesk-postfix jail, because the recidive ban should prohibit access to the server for that IP address. If it is listed in the recidive jail, but not actually banning the IP, something is wrong with the chain in iptables. For that case, examine whether the entry really exists in iptables.
 
I am going to have a look at it, because presently, the address appears as jailed by 2 processes:

F2B-20250314.jpg
 
Here is what I find in iptables:
Code: 
root@server:~# iptables -L -n | grep 194.0.234.230
# Warning: iptables-legacy tables present, use iptables-legacy to see them
REJECT     all  --  194.0.234.230        0.0.0.0/0            reject-with icmp-port-unreachable
root@server:~# iptables-legacy -L -n | grep 194.0.234.230
root@server:~#
 
Another cause for this could be that the plesk-postfix jail is configured to look too far into the past. It will then find and ban IPs from the past that are long blocked by the recidive jail (= it might not ban actually new attempts to attack the server, but old attempts, because these still exist in the log and the jail examines the lock for a too long time backwards from the current time).
 
In jail.conf, I find:
  • Default findtime = 10m
  • recidive findtime = 1d (bantime = 1w)
In jail.local:
  • Default findtime = 600
  • no specific findtime in recidive:

    Code: 
    [recidive]
enabled = true
action = iptables-allports[name=recidive]
        sendmail-whois[mailcmd='/usr/sbin/sendmail -f "<sender>" "<dest>"', dest="root", sender="fail2ban", sendername="Fail2Ban", name="recidive"]
Should findtime for recidive not be specified in jail.local?
 
frg62 said:
Should findtime for recidive not be specified in jail.local?
Click to expand...
Not necessarily. The .local files contains user made modifications, which will take precedence over any configurations in the .conf files. If there isn't any specific configuration for a jail in jail.local, the configuration from jail.conf gets used.
 
OK, thanks for the explanation.

But it still does not explain why, when an IP address is jailed in recidive, other jails still detect it.
 
You must log in or register to reply here.

Similar threads

W
Issue Mail forwarded on the server in the target mailbox is delivered to the SPAM folder
Replies
0
Views
375
W4ru
W
Gianni
Question My IP in jail fail2ban using plesk
Replies
0
Views
384
Gianni
Gianni
TimReeves
Fail2Ban Jail needed for /var/log/sw-cp-server/error_log
Replies
5
Views
7K
roon
R
X
Resolved Plesk Extension: Plesk Email Security (Very Slow Delivery)
Replies
8
Views
7K
Kaspar@Plesk
Kaspar@Plesk
K
Issue Docker containers don't start after plesk/extension upgrades
Replies
0
Views
2K
kassi
K
Back
Top