XAMPP ModSecurity Setup – OWASP ModSecurity Core Rule Set setup

[AITpro Admin]

General statement and explanation to customers/users regarding the ongoing Mod Security problem:
BPS Pro 14.1+ and BPS 3.6+ versions will no longer be broken by Mod Security after redesign has been completed in these new versions of BPS Pro and BPS.  Mod Security included with newer versions of cPanel breaks several things in the BPS and BPS Pro WordPress plugins. This problem has been occurring for 2 years now. Unfortunately, web host techs are not that familiar with editing Mod Security SecRules and typically it takes several days for web host techs to resolve Mod Security problems, which is unsatisfactory for everyone involved. In some cases web host techs are unable to fix the Mod Security SecRule problems. So instead of dealing with this ongoing tedious problem I have set up Mod Security with the OWASP/Spider Labs ModSecurity Core Rule Set for testing in order to redesign BPS and BPS Pro so that they completely bypass/”beat” the OWASP/SpiderLabs ModSecurity Core Rule Set. I believe it would be pointless and a significant waste of time to identify all of the Mod Security SecRules that break things in order to have them fixed eventually. So the simpler route for everyone involved is just to bypass/”beat” Mod Security altogether. This approach will ensure that any new future Mod Security SecRules will not break BPS and BPS Pro. I aplogize to everyone who has suffered through this mess.

Steps to install Mod Security on XAMPP and setup the OWASP ModSecurity Core Rule Set V3.0
Get your XAMPP version first from phpinfo:
Compiler: MSVC15 (Visual C++ 2017)
Architecture: x86
Thread Safety: enabled

You can also check the Apache server logs for info about your Apache build:
Apache/2.4.29 (Win32) OpenSSL/1.1.0g – Apache Lounge VC15 Server built: Nov 3 2017 10:30:36

Get and download the correct Mod Security Module for your XAMPP/Apache server build:
Go to: https://www.apachehaus.com/ and click the downloads link.
Scroll down until you find your Apache server build section. In my particular case the section is: Modules for Apache 2.4.x VC15
Important Note: x86 is for 32 bit installations. x64 is for 64 bit installations. You will find your XAMPP installation type under Architecture in phpinfo.

In my particular case the correct Mod Security Module download is: Mod Security Version 2.9.3 for Apache 2.4.x mod_security2-2.9.3-2.4.x-x86.zip

Extract the Mod Security zip file.
Open the readme_first.txt file. Follow the setup instructions in that file. I have copied those instructions below for my particular XAMPP/Apache/Mod Security setup and installation. Your setup instructions will be different if you have a different XAMPP/Apache/Mod Security version.

Download and install the Visual C++ 2017 x86 Redistributable Package:
This module is built with Visual Studio® 2017 x86, be sure to install the new Visual C++ 2017 x86 Redistributable Package, download from: https://aka.ms/vs/15/release/VC_redist.x86.exe
Note: The Visual C++ 2017 installation states that you must restart your computer before you can use the software. I completed all of the steps below and then rebooted by computer.

# Install:

Copy mod_security2.so to your Apache 2.4.x modules folder
…/apache24/modules/mod_security2.so

Important: rename your exising xampp/apache/bin/pcre.dll file just in case there is a problem.
so you can rollback the Mod Security setup if there is a problem or restore the original pcre.dll file if you are just testing Mod Security.

Copy libcurl.sll, libxml2.dll, pcre.dll and yajl.dll to your Apache 2.4.x bin folder
…/apache24/bin/libcurl.dll
…/apache24/bin/libxml2.dll
…/apache24/bin/pcre.dll
…/apache24/bin/yajl.dll

In my particular case the filename is: modsecurity.conf-recommended. I assume some things have changed since the original setup steps were created.  So I renamed the modsecurity.conf-recommended file to modsecurity.conf in the steps below.

Copy the minimal configuration file to your Apache 2.4.x conf/extra folder
…/apache24/conf/extra/modsecurity-minimal.conf

# Add to your httpd.conf:

LoadModule security2_module modules/mod_security2.so
Include conf/extra/modsecurity-minimal.conf

# Configuration

See the included modsecurity-minimal.conf file for a minimal
configuration example.

For much better security, a complete ruleset should be used.
The OWASP rules are open source and free of charge. For more
information see;

https://www.modsecurity.org/rules.html

See the modsecurity reference manual for full configuration details.
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual

Apache failed to load successfully for me:

12:39:46 PM [Apache] Status change detected: running
12:39:52 PM [Apache] Status change detected: stopped
12:39:52 PM [Apache] Error: Apache shutdown unexpectedly.
12:39:52 PM [Apache] This may be due to a blocked port, missing dependencies,
12:39:52 PM [Apache] improper privileges, a crash, or a shutdown by another method.
12:39:52 PM [Apache] Press the Logs button to view error logs and check
12:39:52 PM [Apache] the Windows Event Viewer for more clues
12:39:52 PM [Apache] If you need more help, copy and post this
12:39:52 PM [Apache] entire log window on the forums

I checked the Apache error log and Mod Security is not loading succesfully.  The Windows Event Viewer does not have any errors or clues about the problem.

I commented out the #Include conf/extra/modsecurity.conf line of code in the Apache httpd.conf file and Mod Security loaded successfully.  So there is a problem with some code in the modsecurity.conf file.

[Sat Aug 10 12:49:51.857031 2019] [:notice] [pid 6244:tid 744] ModSecurity for Apache/2.9.3 (http://www.modsecurity.org/) configured.
[Sat Aug 10 12:49:51.857031 2019] [:notice] [pid 6244:tid 744] ModSecurity: APR compiled version="1.6.5"; loaded version="1.6.3"
[Sat Aug 10 12:49:51.857031 2019] [:warn] [pid 6244:tid 744] ModSecurity: Loaded APR do not match with compiled!
[Sat Aug 10 12:49:51.857031 2019] [:notice] [pid 6244:tid 744] ModSecurity: PCRE compiled version="8.43 "; loaded version="8.43 2019-02-23"
[Sat Aug 10 12:49:51.857031 2019] [:notice] [pid 6244:tid 744] ModSecurity: LUA compiled version="Lua 5.1"
[Sat Aug 10 12:49:51.857031 2019] [:notice] [pid 6244:tid 744] ModSecurity: YAJL compiled version="2.1.0"
[Sat Aug 10 12:49:51.857031 2019] [:notice] [pid 6244:tid 744] ModSecurity: LIBXML compiled version="2.9.9"
[Sat Aug 10 12:49:51.857031 2019] [:notice] [pid 6244:tid 744] ModSecurity: Status engine is currently disabled, enable it by set SecStatusEngine to On.

The problem lines of code in the modsecurity.conf file are these below which I commented out for now:
I assume I need to enter a valid path for the Audit Log. This is not an important issue on XAMPP since I am choosing to log all Mod Security errors to the Apache error.log file.

# Use a single file for logging. This is much easier to look at, but
# assumes that you will use the audit log only ocassionally.
#
SecAuditLogType Serial
#SecAuditLog /var/log/modsec_audit.log

Apparently SpiderLabs states there is some sort of problem/bug with SecUnicodeMapFile unicode.mapping. I checked the OWASP ModSecurity Core Rule Set V3.0 setup .conf file and this line of code is not included. So I am going to assume it is not that important and move on to the OWASP ModSecurity Core Rule Set V3.0 setup.

# Specify your Unicode Code Point.
# This mapping is used by the t:urlDecodeUni transformation function
# to properly map encoded data to your language. Properly setting
# these directives helps to reduce false positives and negatives.
#
#SecUnicodeMapFile unicode.mapping 20127

After commenting out the 2 lines of code stated above Apache loads successfully and Mod Security loads successfully. Moving on to the OWASP ModSecurity Core Rule Set V3.0 setup now.

[Sat Aug 10 13:12:34.067013 2019] [:notice] [pid 13212:tid 744] ModSecurity for Apache/2.9.3 (http://www.modsecurity.org/) configured.
[Sat Aug 10 13:12:34.067013 2019] [:notice] [pid 13212:tid 744] ModSecurity: APR compiled version="1.6.5"; loaded version="1.6.3"
[Sat Aug 10 13:12:34.067013 2019] [:warn] [pid 13212:tid 744] ModSecurity: Loaded APR do not match with compiled!
[Sat Aug 10 13:12:34.067013 2019] [:notice] [pid 13212:tid 744] ModSecurity: PCRE compiled version="8.43 "; loaded version="8.43 2019-02-23"
[Sat Aug 10 13:12:34.067013 2019] [:notice] [pid 13212:tid 744] ModSecurity: LUA compiled version="Lua 5.1"
[Sat Aug 10 13:12:34.067013 2019] [:notice] [pid 13212:tid 744] ModSecurity: YAJL compiled version="2.1.0"
[Sat Aug 10 13:12:34.068011 2019] [:notice] [pid 13212:tid 744] ModSecurity: LIBXML compiled version="2.9.9"
[Sat Aug 10 13:12:34.070006 2019] [:notice] [pid 13212:tid 744] ModSecurity: StatusEngine call: "2.9.3,Apache/2.4.29 (Win32) Ope,1.6.5/1.6.3,8.43/8.43 2019-02-23,Lua 5.1,2.9.9,826783a941dd0186200011a4b33120efa65a0da3"

OWASP ModSecurity Core Rule Set V3.0 setup
Download the OWASP ModSecurity Core Rule Set from here: https://coreruleset.org/installation/
Unzip the folders on your computer.
Open the INSTALL file for setup instructions. I have copied the setup steps below from the INSTALL file.
I will be doing some variations of the setup instructions for XAMPP.
Manually created this folder: /xampp/apache/modsecurity/.
Copied the entire unzipped OWASP CRS folder: owasp-modsecurity-crs-3.1.0 to the /xampp/apache/modsecurity/ folder and renamed it to: owasp-modsecurity-crs
Renamed the crs-setup.conf.example file to crs-setup.conf.
Customized the crs-setup.conf file for my particular XAMPP environment.
Did Step #6 below word for word.
Did Step #7 below. The only difference is my modsecurity folder name is: /modsecurity/ without .d in the folder name.
Note: DO NOT commented out the #Include conf/extra/modsecurity.conf line of code in the httpd.conf file. You need to continue to include that .conf file.
Apache and Mod Security loaded successfully, but I see this error message: [Sat Aug 10 15:26:47.485166 2019] [:error] [pid 5716:tid 2140] ModSecurity: ModSecurity requires mod_unique_id to be installed.  Edited my httpd.conf file and uncommented this line of code: #LoadModule unique_id_module modules/mod_unique_id.so
Restarted Apache and then ran the basic test in the INSTALL file (see test below).
Checked the Apache error logs and see that Mod Security is working correctly.

[Sat Aug 10 15:31:19.343236 2019] [:error] [pid 12300:tid 2152] [client 127.0.0.1:51950] [client 127.0.0.1] 
ModSecurity: Warning. detected XSS using libinjection. 
[file "C:/xampp/apache/modsecurity/owasp-modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] 
[line "60"] [id "941100"] [msg "XSS Attack Detected via libinjection"] 
[data "Matched Data: XSS data found within ARGS:param: \\x22><script>alert(1);</script>"] 
[severity "CRITICAL"] [ver "OWASP_CRS/3.1.0"] [tag "application-multi"] [tag "language-multi"] 
[tag "platform-multi"] [tag "attack-xss"] [tag "OWASP_CRS/WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] 
[tag "WASCTC/WASC-22"] [tag "OWASP_TOP_10/A3"] [tag "OWASP_AppSensor/IE1"] [tag "CAPEC-242"] 
[hostname "demo9.local"] [uri "/"] [unique_id "XU9Ft1PnJhZVLMluwEDDDgAAAJU"]

Installing on Apache
——————–
1. Install ModSecurity for Apache
2. Ensure that ModSecurity is loading correctly by checking error.log
at start up for lines indicating ModSecurity is installed. An example
might appear as follows:
ModSecurity for Apache/2.9.1 (http://www.modsecurity.org/) configured.
3. The most common method of deploying ModSecurity we have seen is
to create a new folder underneath the Apache directory (typically
/usr/local/apache/, /etc/httpd/, or /etc/apache2). Often this folder
is called ‘modsecurity.d’. Create this folder and cd into it.
4. Clone the repository into the modsecurity.d folder using:
git clone https://github.com/SpiderLabs/owasp-modsecurity-crs .
This will create a new owasp-modsecurity-crs folder.
5. Move the crs-setup.conf.example file to crs-setup.conf.
Please take the time to go through this file and customize the settings
for your local environment. Failure to do so may result in false
negatives and false positives. See the section entitled OWASP CRS
Configuration for more detail.
6. Rename rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example and
rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example to remove the
‘.example’ extension. This will allow you to add exclusions without updates
overwriting them in the future.
7. Add the following line to your httpd.conf/apache2.conf (the following
assumes you’ve cloned CRS into modsecurity.d/owasp-modsecurity-crs). You
can alternatively place these in any config file included by Apache:

<IfModule security2_module>
Include modsecurity.d/owasp-modsecurity-crs/crs-setup.conf
Include modsecurity.d/owasp-modsecurity-crs/rules/*.conf
</IfModule>

8. Restart web server and ensure it starts without errors
9. Make sure your web sites are still running fine.
10. Proceed to the section “Testing the Installation” below.

Testing the Installation
========================
To test your installation you should be able to use any number
of attacks. A typical request which should trigger CRS would be
http://localhost/?param="><script>alert(1);</script>
Upon sending this request you should see events reported in the
error log (nginx apache) or the event viewer (IIS).
If have not changed the defaults with regards to anomaly scoring,
blocking and sampling percentage, then this request should have
been blocked and access forbidden. Likewise if you have configured
ModSecurity debug logging and/or audit logging this event should
log to these locations as well.

Test Results: Mod Security CRS 3.1.0 and 3.1.1 out of the box with default settings break BPS or BPS Pro.
Default Setting: Paranoia Level 1

# — [[ Paranoia Level Initialization ]] —————————————
#
# The Paranoia Level (PL) setting allows you to choose the desired level
# of rule checks that will add to your anomaly scores.
#
# With each paranoia level increase, the CRS enables additional rules
# giving you a higher level of security. However, higher paranoia levels
# also increase the possibility of blocking some legitimate traffic due to
# false alarms (also named false positives or FPs). If you use higher
# paranoia levels, it is likely that you will need to add some exclusion
# rules for certain requests and applications receiving complex input.
#
# – A paranoia level of 1 is default. In this level, most core rules
# are enabled. PL1 is advised for beginners, installations
# covering many different sites and applications, and for setups
# with standard security requirements.
# At PL1 you should face FPs rarely. If you encounter FPs, please
# open an issue on the CRS GitHub site and don’t forget to attach your
# complete Audit Log record for the request with the issue.
# – Paranoia level 2 includes many extra rules, for instance enabling
# many regexp-based SQL and XSS injection protections, and adding
# extra keywords checked for code injections. PL2 is advised
# for moderate to experienced users desiring more complete coverage
# and for installations with elevated security requirements.
# PL2 comes with some FPs which you need to handle.
# – Paranoia level 3 enables more rules and keyword lists, and tweaks
# limits on special characters used. PL3 is aimed at users experienced
# at the handling of FPs and at installations with a high security
# requirement.
# – Paranoia level 4 further restricts special characters.
# The highest level is advised for experienced users protecting
# installations with very high security requirements. Running PL4 will
# likely produce a very high number of FPs which have to be
# treated before the site can go productive.
#
# Rules in paranoia level 2 or higher will log their PL to the audit log;
# example: [tag “paranoia-level/2”]. This allows you to deduct from the
# audit log how the WAF behavior is affected by paranoia level.
#
# It is important to also look into the variable
# tx.enforce_bodyproc_urlencoded (Enforce Body Processor URLENCODED)
# defined below. Enabling it closes a possible bypass of CRS.
#
# Uncomment this rule to change the default:
#
#SecAction \
# “id:900000,\
# phase:1,\
# nolog,\
# pass,\
# t:none,\
# setvar:tx.paranoia_level=1”

Additional Notes:
Mod Security is set to log Mod Security errors by default in the modsecurity.conf file with this setting: SecRuleEngine DetectionOnly.  In order to check for actual Mod Security breakages you will need to change this setting to: SecRuleEngine On.

# The possible values are:
# On: process rules
# Off: do not process rules
# DetectionOnly: process rules but never executes any disruptive actions (block, deny, drop, allow, proxy and redirect)
#
SecRuleEngine On

Recommendation: Edit the modsecurity.conf file and change the PCRE Tuning settings from 1000 to 500000 so that you do not see additional unnecessary Mod security log entries about PCRE limits exceeded.

# PCRE Tuning
# We want to avoid a potential RegEx DoS condition
# Default is 1000. Changed to 500000
SecPcreMatchLimit 500000
SecPcreMatchLimitRecursion 500000

Solution Notes to prevent Mod Security CRS rules from breaking BPS and BPS Pro:  A pure js encryption and decryption method has been tested and works perfectly for BPS Custom Code to evade Mod Security CRS rules and allow encrypted custom code to be saved. There are various other Forms in BPS and BPS Pro that are blocked/broken by Mod Security CRS rules.  The cause of those Forms being blocked/broken by Mod Security CRS rules is that the Body content of the page that the Form is on is being checked by Mod Security CRS rules when the Form is submitted.  Those other BPS and BPS Pro Form pages are being redesigned to either use “includes” or to remove any page Body content that Mod Security CRS rules falsely see as a threat.

[AITpro Admin]

OWASP ModSecurity CRS testing, troubleshooting, solutions and pending redesign work for the BPS and BPS Pro Plugins:

Major Redesign|ModSecurity CRS Proofing: The OWASP ModSecurity Core Rule Set installed on cPanel breaks numerous Forms/Features/Pages and other things in the BPS and BPS Pro plugins:  A list of broken/fixed/pending Forms/Features/Pages is below.  In order to speed up the process of getting new BPS and BPS Pro versions released as quickly as possible we are fixing the most critical broken Forms/Features/Pages first and will be releasing several BPS and BPS Pro version releases in stages until all BPS and BPS Pro Forms/Features/Pages are no longer being broken by the OWASP Mod Security CRS Ruleset installed on cPanel.

Important Note:  Some people will experience more ModSecurity CRS problems than other people.  That will depend on the particular ModSecurity CRS configuration settings that each web host chooses to use.  Some web hosts may choose more restrictive ModSecurity CRS configuration settings than other web hosts.

Solution Methods used:

New:  ModSecurity CRS falsely sees legitimate htaccess code Form data as a threat.  JavaScript Encryption|Decryption and PHP openssl_encrypt|openssl_decrypt to encrypt and decrypt htaccess code submitted in various BPS Forms that save and submit htaccess code. Form data is encrypted in POST Form submission to evade/bypass ModSecurity CRS detection and decrypted in the Form processing code.

New: ModSecurity CRS falsely sees some log file data as a threat. View Log buttons added to BPS Plugin pages with log files to allow BPS Plugin Page loading instead of loading Log files in an open state when loading BPS Plugin pages that contain log files.  Pending additional log file data encryption|decryption redesign work for some BPS Plugin log file pages.

Pending: ModSecurity CRS falsely sees BPS Plugin page Body Response/Source Code as a threat. BPS Plugin page Body Response design for various BPS Plugin pages due to ModSecurity CRS detecting help text and BPS Plugin option setting names in the page Body/Source Code as malicious and blocking BPS Plugin pages from loading.  Limiting the amount of false positives that ModSecurity CRS Anomaly Scoring sees in the Body Response/Source Code by breaking up BPS Plugin pages so that limited Response Body data/Source Code is outputted should allow the broken BPS Plugin pages to load by falling under the ModSecurity CRS Anomaly Scoring threshold number that blocks BPS Plugin pages from loading.

Security Modes Page:
Root Folder BulletProof Mode (RBM) Activate Form: ModSecurity CRS Proofed – Encryption|Decryption completed
Root Folder BulletProof Mode (RBM) Deactivate Form: ModSecurity CRS Proofed – Encryption|Decryption completed
wp-admin Folder BulletProof Mode (WBM) Activate Form: ModSecurity CRS Proofed – Encryption|Decryption completed
Plugin Firewall BulletProof Mode (PFW) Activate Form (BPS Pro): ModSecurity CRS Proofed – Encryption|Decryption completed
Uploads Anti-Exploit Guard BulletProof Mode (UAEG) Form (BPS Pro): ModSecurity CRS Proofed – Encryption|Decryption completed

Details: These Forms now decrypt encrypted htaccess code in the WP Database before processing file writing.

Custom Code Page:
Root Custom Code Form: ModSecurity CRS Proofed – Encryption|Decryption completed
Wp-admin Custom Code Form: ModSecurity CRS Proofed – Encryption|Decryption completed
UAEG Custom Code Form (BPS Pro): ModSecurity CRS Proofed – Encryption|Decryption completed
Custom Code Export Form: ModSecurity CRS Proofed – Encryption|Decryption completed

Details: ModSecurity CRS falsely sees legitimate htaccess code as malicious. BPS now uses encryption and decryption in these Forms to evade/bypass ModSecurity CRS detection.

htaccess File Editor Page:
secure.htaccess Form: ModSecurity CRS Proofed – Encryption|Decryption completed
default.htaccess Form: ModSecurity CRS Proofed – Encryption|Decryption completed
wpadmin-secure.htaccess Form: ModSecurity CRS Proofed – Encryption|Decryption completed
Your Current Plugins htaccess File Form (BPS Pro): ModSecurity CRS Proofed – Encryption|Decryption completed
Your Current Uploads htaccess File Form (BPS Pro): ModSecurity CRS Proofed – Encryption|Decryption completed
Your Current Root htaccess File Form: ModSecurity CRS Proofed – Encryption|Decryption completed
Your Current wp-admin htaccess File Form: ModSecurity CRS Proofed – Encryption|Decryption completed

Details: ModSecurity CRS falsely sees legitimate htaccess code as malicious. BPS now uses encryption and decryption in these Forms to evade/bypass ModSecurity CRS detection.

My Notes Page:
My Notes Form: ModSecurity CRS Proofed – Encryption|Decryption completed

Details: ModSecurity CRS falsely sees legitimate htaccess code as malicious. BPS now uses encryption and decryption in these Forms to evade/bypass ModSecurity CRS detection.

Security Log Page:
Security Log Form: Partially ModSecurity CRS Proofed – View Log button added to allow the Security Log page to load. Pending further Log file data encryption|decryption redesign work.

Details: ModSecurity CRS sees legitimate Security Log errors logged in the Security Log as malicious. The Security Log now has a View Log button to allow the Security Log page to load. Pending additional redesign work to encrypt and decrypt log file data to allow viewing the Security Log file data. Pending further Log file data encryption|decryption redesign work.

Quarantine Page (BPS Pro):
View File Form: Pending additional redesign work
Restore File Form: Pending additional redesign work
Delete File Form: Pending additional redesign work

Details: ModSecurity CRS falsely sees legitimate file names and legitimate code in files in Quarantine as malicious when trying to view, restore or delete particular files in Quarantine. Pending additional redesign work.

System Info Page:
System Info Page Data Output: Pending additional redesign work

Details: The BPS System page is inaccessible due to ModSecurity CRS falsely seeing legitimate data output as malicious. Pending additional redesign work.

PHP Error Log Page (BPS Pro):
PHP Error Log Form: Partially ModSecurity CRS Proofed – View Log button added to allow the PHP Error Log page to load. Pending further Log file data encryption|decryption redesign work.
PHP Error Log Page: Pending additional redesign work

Note: The P-Security page, which contains the PHP Error Log page is blocked by ModSecurity CRS and is inaccessible. ModSecurity CRS looks at the Response Body output/Source Code of the P-Security page itself and is falsely seeing something as malicious. Pending additional Response Body/Page redesign work. This is also a ModSecurity CRS Anomaly Scoring threshold problem.

Details: ModSecurity CRS sees legitimate PHP errors logged in the PHP Error Log as malicious. The PHP Error Log now has a View Log button to allow the PHP Error Log page to load. Pending additional redesign work to encrypt and decrypt log file data to allow viewing PHP Error log file data. ModSecurity CRS also looks at the Response Body output/Source Code of the PHP Error Log page itself and is falsely seeing BPS option setting names and help text as malicious. Pending further Log file data encryption|decryption redesign work. Pending additional Response Body/Page redesign work. This is also a ModSecurity CRS Anomaly Scoring threshold problem.

General Log File Problems:

Details: ModSecurity CRS falsely sees legitimate log file data in most if not all BPS Log files. ModSecurity CRS blocks form submissions due to falsely seeing the Log file data as malicious. When attempting to save edited Log files ModSecurity CRS will block the Log file Form submission if the data in the Form exceeds a certain size. Encryption|Decryption would work to encrypt and decrypt Form data to evade/bypass ModSecurity CRS, but unfortunately nothing can be done to change the size of the Form data itself to evade/bypass ModSecurity CRS.

Pro-Tools Page (BPS Pro):

Details: The BPS Pro Pro-Tools page is blocked by ModSecurity CRS and is inaccessible. ModSecurity CRS looks at the Response Body output/Source Code of the Pro-Tools page itself and is falsely seeing something as malicious. Pending additional Response Body/Page redesign work. This is also a ModSecurity CRS Anomaly Scoring threshold problem.

JTC Anti-Spam|Anti-Hacker Page (BPS Pro) – JTC-Lite (BPS Free):
JTC Anti-Spam|Anti-Hacker Settings Form: Pending additional redesign work

Details: ModSecurity CRS falsely sees the CSS code in the Comment Form: CSS Styling text boxes as malicious and blocks saving the JTC Anti-Spam|Anti-Hacker Settings Form. Workaround: Delete the CSS code in the Comment Form: CSS Styling text box in order to save JTC Anti-Spam|Anti-Hacker settings. The default CSS code will automatically be populated in the CSS Styling text boxes after the form is submitted. This is also a ModSecurity CRS Anomaly Scoring threshold problem.

Idle Session Logout Page:
Idle Session Logout (ISL) Settings Form: Pending additional redesign work.

Details: ModSecurity CRS falsely sees the CSS code in the Idle Session Logout Page Custom CSS Style text boxes as malicious and blocks saving the Idle Session Logout (ISL) Settings Form. Workaround: Delete the CSS code in the Idle Session Logout Page Custom CSS Style text boxes in order to save Idle Session Logout (ISL) settings. The default CSS code will automatically be populated in the Idle Session Logout Page Custom CSS Style text boxes after the form is submitted. This is also a ModSecurity CRS Anomaly Scoring threshold problem.

DB Monitor Page (BPS Pro):

Details: The BPS Pro DB Monitor page is blocked by ModSecurity CRS and is inaccesible. ModSecurity CRS looks at the Response Body output/Source Code of the DB Monitor page itself and is falsely seeing something as malicious. Pending additional Response Body/Page redesign work. This is also a ModSecurity CRS Anomaly Scoring threshold problem.

Upload Zip Install Page (BPS Pro):

Details: The BPS Pro Upload Zip Installer is blocked/broken by ModSecurity CRS. ModSecurity CRS Errors: Error reading from temporary file and Failed to delete temporary file. Pending additional redesign work.  Note: Earlier versions of ModSecurity CRS broke the WordPress Plugin Upload Zip installer.  We assume this is the same type of ModSecurity CRS mistake for the BPS Pro Upload Zip Installer.  Dev Note:  The DetectionOnly SecRuleEngine setting also breaks the BPS Pro Upload Zip Installer.

Notes: There will most likely be more ModSecurity CRS problems with these BPS Pro pages once they are made accessible:  Pro-Tools, DB Monitor and P-Security.  These pages contain additional Forms and tools that will also most likely be blocked by ModSecurity CRS.  ModSecurity CRS breaks 100’s if not 1000’s of other WordPress Plugins and Themes.  This is an ongoing problem that was created by cPanel by including ModSecurity CRS in newer versions of cPanel.  The ideal solution would be to disable ModSecurity entirely for your website since ModSecurity CRS causes so many problems for numerous WordPress Plugins and Themes.

[Quentin]

Got it.

[Author]

Posts