Hi,

Please consider implementing Mod Security v3.x.x (aka libmodsecurity) for NGINX and Apache in the next Plesk update.

At the moment any Plesk user if he wants to use Mod Security (official version supported by Plesk) is forced to use it as a web server:

• Apache

or

• Apache + NGINX

Any Plesk user who wants to use only NGINX as a web server and without using Apache at the moment cannot use Mod Security because Plesk does not currently support it for NGINX exclusively web servers.

Here are some of the advantages of Mod Security v3.x.x (aka libmodsecurity and these advantages apply to any type of webserver, apache, NGINX, IIS, etc., etc.,) compared to the now old and obsolete Mod Security v2.x.x as reported on the official GitHub page relating to SpyderLabs - Mod Security available at this link https://github.com/SpiderLabs/ModSecurity for anyone who wants to deepen the subject.

"Libmodsecurity is one component of the ModSecurity v3 project. The library codebase serves as an interface to ModSecurity Connectors taking in web traffic and applying traditional ModSecurity processing. In general, it provides the capability to load/interpret rules written in the ModSecurity SecRules format and apply them to HTTP content provided by your application via Connectors.

If you are looking for ModSecurity for Apache (aka ModSecurity v2.x), it is still under maintenence and available: here.

What is the difference between this project and the old ModSecurity (v2.x.x) ?

• All Apache dependences have been removed
• Higher performance
• New features
• New architecture

Libmodsecurity is a complete rewrite of the ModSecurity platform. When it was first devised the ModSecurity project started as just an Apache module. Over time the project has been extended, due to popular demand, to support other platforms including (but not limited to) Nginx and IIS. In order to provide for the growing demand for additional platform support, it has became necessary to remove the Apache dependencies underlying this project, making it more platform independent.

As a result of this goal we have rearchitected Libmodsecurity such that it is no longer dependent on the Apache web server (both at compilation and during runtime). One side effect of this is that across all platforms users can expect increased performance. Additionally, we have taken this opprotunity to lay the groundwork for some new features that users have been long seeking. For example we are looking to nativly support auditlogs in the JSON format, along with a host of other functionality in future versions.

It is no longer just a module.
The 'ModSecurity' branch no longer contains the traditional module logic (for Nginx, Apache, and IIS) that has traditionally been packaged all together. Instead, this branch only contains the library portion (libmodsecurity) for this project. This library is consumed by what we have termed 'Connectors' these connectors will interface with your webserver and provide the library with a common format that it undersands. Each of these connectors is maintained as a seperate GitHub project. For instance, the Nginx connector is supplied by the ModSecurity-nginx project (https://github.com/SpiderLabs/ModSecurity-nginx).

Keeping these connectors seperated allows each project to be have different release cycles, issues and development trees. Addtionally, it means that when you install ModSecurity v3 you only get exactly what you need, no extras you won't be using."

Thanks in advance for the support.

At the moment the situation is following:

I scenario

The WordPress instance is installed in the /var/www/vhosts/example.com/httpdocs/old/ directory.
If the mentioned directory was manually removed from the server-side and the Detach button was pressed after in Domains > example.com > WordPress, the leftovers of the non-existed WordPress instance still can be found in WordPress SQLite database /usr/local/psa/var/modules/wp-toolkit/wp-toolkit.sqlite3

II scenario

The WordPress instance is installed in the /var/www/vhosts/example.com/httpdocs/old/ directory and files from this directory were manually moved to /var/www/vhosts/example.com/httpdocs/.
The Detach button was pressed after in Domains > example.com > WordPress, however the leftovers from the WordPress instance that currently is non-existed in /var/www/vhosts/example.com/httpdocs/old/ directory still can be found in WordPress SQLite database /usr/local/psa/var/modules/wp-toolkit/wp-toolkit.sqlite3

In both scenarios, it can cause error notifications that are sent to Administrator or Customers.

Thus based on the points above after pressing the Detach button for the removed WordPress instance, it should check and remove leftovers from the WordPress SQLite database in case such an instance does not exist anymore