• 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 Plesk-modsecurity jail issue

Gabor H

Basic Pleskian
Hi,

Experiencing issues with the Plesk-Modsecurity jail within the Fail2Ban in Plesk.
It looks to be too strict.
The main problem is, that when it's enabled, then it's blocking sometime(not all the time)
-good bots(Google, MSN)
-organic visits

Checking the blocking of organic visits was easy. Checked one of the website running on Plesk from a
4G network, via mobile Chrome browser, and the website was inaccessible.
Had to disable Plesk-Modsecurity jail to be able to see the content of the website. It solved the issue

Why this jail is too restrictive by default? How to "whitelist" non-hacking organic visits??
And why it's blocking once a good bot, and the next time let in without adding it to whitelist?

Cheers,
 
@Gabor H

Actually, irregardless of what you did find out, the modsecurity jail is not strict at all, it (amongst others) allows a lot of bad bots.

Nevertheless, it is not the best jail in the default Fail2Ban jails shipped with Plesk.

In general, if you have set Modsecurity (WAF) to "on" and apply the WAF settings "Tradeoff", one can safely turn off the modsecurity jail, even though I would not recommend it.

With respect to the question

And why it's blocking once a good bot, and the next time let in without adding it to whitelist?

I can give the following ansers:

a) Fail2Ban does not whitelist IPs without you doing explicitly so (note: one can create a jail, automating whitelisting, but that would not be in lign with the concept of Fail2Ban)

b) Fail2Ban works in the fashion "x number of log entries concerning IP y, hence ban during period t", which simply implies that IP y will be unbanned after period t has expired and, as a result, traffic from IP y will be allowed again, until a x number of log entries has been found again, which triggers the ban action by Fail2Ban.

In short, when working with Fail2Ban, there is always some time period in which an IP (read: bot) can cause some traffic and enter the logs.

For that resason, the default recidive jail has been created, in order to prevent that IPs continuously reoccur in the logs, scanned by Fail2Ban.

However, there are two flaws in the general Fail2Ban jail setup:

- the recidive jail is based on a process defined by "x number of log entries concerning IP y, hence ban during period T", with T > t (read: a longer ban period)
- a specific scan interval has to be defined (read: bots and hack scripts can work around Fail2Ban, by timing attempts just "outside" the scan interval)

and you can imagine by now that the Fail2Ban behaviour, as observed by you, has many potential causes.

In general, it is recommend to decrease the number of retries for all jails, but the recidive jail in specific (take a value of 2 or 3).

It is also recommend to increase the ban period for the recidive jail to a longer time period, for instance the equivalent of a month (in seconds).

Hope the above explains and helps a bit!

Ciao
 
Back
Top