XAMPP Mod Security Setup – OWASP ModSecurity Core Rule Set setup

Home Forums BulletProof Security Pro XAMPP Mod Security Setup – OWASP ModSecurity Core Rule Set setup


This topic contains 0 replies, has 1 voice, and was last updated by  AITpro Admin 1 week, 3 days ago.

Viewing 1 post (of 1 total)
  • Author
  • #37750

    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

    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

    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

    # 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;


    See the modsecurity reference manual for full configuration details.

    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] [client] 
    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

    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
    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.

Viewing 1 post (of 1 total)

You must be logged in to reply to this topic.