• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • 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.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue Problems with recidive jail

Tim Clarke

New Pleskian
Server operating system version
AlmaLinux 8.9 (Midnight Oncilla)
Plesk version and microupdate number
18.0.62 #2
My host has just migrated my server from the Centos that I was on (I understand that is now end of life).

I am now running

AlmaLinux 8.9 (Midnight Oncilla)
Product
Plesk Obsidian
Version 18.0.62 Update #2, last updated on July 25, 2024 05:16 AM

However, since the migration has happened, I keep getting locked out of my own server! Initially, it appeared to be being caused by send and return of emails. This would initially block email access and then full server access (including browsing domains).

According to the host, this was an authorisation error - implying that there was an incorrect password somewhere.

To put this into context, both my wife and I have a number of email accounts across four domains, and we each have a laptop, a mobile and a tablet accessing these accounts. From the log messages it appeared to be one (or more) of my wife's devices causing the problem, although that may just be because it was only her email address showing up at the time I was testing.

However, I know there is no error because when it is working properly, both my wife and I get all the emails on all accounts. I could do send and receive on a device and see the IP address get banned. I would then unban it, do send and receive on the same device again and it would work perfectly!

The jails throwing up this issue were plesk-recidive and plesk-apache. I disabled the latter jail, and things improved slightly. My host provider set the "Maximum number of connections for a user per IP address" in dovecot to 40, and this seemed to help as well, but I am still getting banned occasionally.

Although I could take up my hosts suggestion of whitelisting my IP address, I am on mobile internet. My IP address changes regularly, so this isn't really a practical option. I could, of course, disabled plesk-recidive, but I don't know if this would be a good idea as I guess potentially it leaves the server more exposed.

I didn't have this issue with the old Centos server, so I just wonder if anyone has any ideas?
 
Hi there, have looked at the mail logs? There must some log entries which trigger fail2ban filter. Those should provide some clue to what's going on.
 
Of course, makes sense to find out why it happened.

Just an additional idea of a workaround for "the issue" with dynamic IP addresses. In the case when I am on mobile internet and an IP address is changed regularly, I have found what pool of IP addresses is used by my mobile operator and added this pool to fail2ban as trusted. You do not to add each address individually, it could be a network in CIRD format.

E.g.: network /19 has 8192 IP-addresses. IPv4 allows to use one of 4,294,967,296 IP-addresses. 8192 / 4,294,967,296 = 0.00000190734; 0.0002% that you and a hacker will use the same network range :)
 
My host has just migrated my server from the Centos that I was on (I understand that is now end of life).

I am now running

AlmaLinux 8.9 (Midnight Oncilla)
Product
Plesk Obsidian
Version 18.0.62 Update #2, last updated on July 25, 2024 05:16 AM

However, since the migration has happened, I keep getting locked out of my own server! Initially, it appeared to be being caused by send and return of emails. This would initially block email access and then full server access (including browsing domains).

According to the host, this was an authorisation error - implying that there was an incorrect password somewhere.
This is most likely a standard response and an equivalent for "do not bother us" ... :(
To put this into context, both my wife and I have a number of email accounts across four domains, and we each have a laptop, a mobile and a tablet accessing these accounts. From the log messages it appeared to be one (or more) of my wife's devices causing the problem, although that may just be because it was only her email address showing up at the time I was testing.

However, I know there is no error because when it is working properly, both my wife and I get all the emails on all accounts. I could do send and receive on a device and see the IP address get banned. I would then unban it, do send and receive on the same device again and it would work perfectly!

The jails throwing up this issue were plesk-recidive and plesk-apache. I disabled the latter jail, and things improved slightly. My host provider set the "Maximum number of connections for a user per IP address" in dovecot to 40, and this seemed to help as well, but I am still getting banned occasionally.

Although I could take up my hosts suggestion of whitelisting my IP address, I am on mobile internet. My IP address changes regularly, so this isn't really a practical option. I could, of course, disabled plesk-recidive, but I don't know if this would be a good idea as I guess potentially it leaves the server more exposed.

I didn't have this issue with the old Centos server, so I just wonder if anyone has any ideas?

It's certainly not the recidive filter that is blocking you! This one is only adding IP's that have been blocked by other filters for a certain number of times.

Thus you should at first find out what fail2ban filter is (or what filters are) actually blocking your IP's. You will have to check /var/log/fail2ban.log for this.

If you know the filter(s) you can check the appropriate log file(s) for what exactly has happened. Only then you can take reasonable actions.

However, DO NOT use that "workaround" to add "the pool of IP addresses your ISP uses" to the whitelist. It's a bad advice for several reasons.
 
Back
Top