cPanel & WHM no longer develops or updates EasyApache 3. We deprecated EasyApache 3 on December 31, 2018. We removed support for EasyApache 3 in cPanel & WHM version 78.
Apache Module: ModSecurity - EasyApache - cPanel Documentation
Page tree
Skip to end of metadata
Go to start of metadata


The mod_security Apache module provides the ModSecurity™ web application firewall for Apache.


If your ruleset contains rule ID conflicts or syntactical errors, ModSecurity will fail and Apache will not start. For more information on how EasyApache handles issues with your ModSecurity rules, view the Compatibility section.

Featured documentation

  EasyApache 3


Change Log Release Notes  



Migrate from Tomcat 5.5 to 7

How to Deploy Java Applications


EasyApache 3 does not support new installations of Tomcat.

As of cPanel & WHM version 76, EasyApache 4 now supports Tomcat 8.5. For more information, read our Tomcat documentation.


Use the mod_security Apache module to install the ModSecurity web application firewall. You can configure this module to protect your Apache web applications from various attacks. The ModSecurity web application firewall also provides additional tools to monitor your Apache web server.


This module has no requirements.



To build EasyApache with Mod Security and the MPM ITK option on the CloudLinux™ operating system, you must either uninstall or properly enable and configure CageFS before you run EasyApache with the Mod Security and MPM ITK options.

For more information about CageFS, read CloudLinux's CageFS documentation. 

Mod_ruid2 Apache module

If you select the Mod Security option and either the Mod Ruid2 or the MPM ITK option in EasyApache, the ModSecurity log location changes to the following:


In the above example, [user] is the cPanel account's user name; YYYYMMDD is the year, month, and day in numeric form; HHmm is the hour and minute; HHmmSS is the hour, minute, and second; and [unique-id] is a unique identifier for the log.  

Rule compatibility

Major versions of the mod_security Apache module use different syntaxes for ModSecurity rules.


  • If your build of EasyApache uses Apache version 1.3, you must rewrite your ModSecurity rules to work with mod_security version 2.x. EasyApache no longer supports Apache version 1.3, and will update your version of the mod_security Apache module to the latest 2.x version.
  • There is no conversion utility available to rewrite rules between versions.
  • Minor versions of ModSecurity may also have syntactical changes that are incompatible with older rulesets.

For more information on the migration process from ModSecurity 1.x to ModSecurity 2.x, visit the following websites:

  • ModSecurity — This website includes ModSecurity 1.x to 2.x Migration Matrix documentation.
  • ModSecurity FAQ — This website includes directions for how to migrate rules from the ModSecurity 1.x format into the 2.x format.
  • The ModSecurity mailing list — This is the ModSecurity users' mailing list.

How to install or uninstall mod_security


  • When you run EasyApache, it installs or upgrades to the latest version of the mod_security Apache module. The rule editor in WHM adjusts automatically to work with the rules for the version of ModSecurity that EasyApache installs.
  • If you use cPanel & WHM version 11.40 or later, all of the profiles in the cPanel Recommended Profiles section in the EasyApache 3 interface include the mod_security Apache module by default.

To install or uninstall the mod_security Apache module, perform the following steps:

  1. Run EasyApache in WHM's  EasyApache 3 interface (Home >> Software >> EasyApache  3).


    • To access EasyApache from the command line interface, run the /scripts/easyapache script as the root user.
    • For more information on EasyApache, read our Apache Module: ModSecurity documentation.
  2. Select the profile that you wish to modify.
  3. Click the  that corresponds to your selection.
  4. Click Next Step in the Apache Version interface.
  5. Click Next Step in the PHP Version interface.
  6. Perform one of the following actions in the Short Options List interface: 
    • To install the mod_security Apache module, select the Mod Security option.

    • To uninstall the mod_security Apache module, deselect the Mod Security option.
  7. Click Save and Build.
  8. After your EasyApache build completes, you must configure the module. For more information on how to configure the mod_security Apache module, view the ModSecurity website.
    • If you use WHM version 11.44 or earlier, use WHM's Mod Security interface (Home >> Plugins >> Mod Security) to configure the module.
    • If you use WHM version 11.46 or later, use WHM's  Apache Module: ModSecurity interface (Home >> Security Center >> ModSecurity Configuration) to configure the module. 

Apache, mod_security, and EasyApache


  • EasyApache installs the mod_security Apache module with several include files.
  • WHM versions 11.44 and earlier include very basic ModSecurity rules. You must update these rules within the WHM Mod Security interface (Home >> Plugins >> Mod Security).
  • WHM versions 11.46 and later do not include any ModSecurity rules. You must configure your rules with the WHM Apache Module: ModSecurity interface (Home >> Security Center >> ModSecurity Tools).

Use the following file information when you configure your ModSecurity firewall rules:

  • The EasyApache build process adds the ModSecurity firewall application to your Apache build with the following entry to your /usr/local/apache/conf/httpd.conf file:

    Include "/usr/local/apache/conf/modsec2.conf"
  • For WHM 11.44 and earlier builds, the /usr/local/apache/conf/modsec2.conf file contains the basic directives for the mod_security Apache module, and the following include directive:

    Include "/usr/local/apache/conf/modsec2.user.conf"
  • For WHM 11.46 and later builds, the /usr/local/apache/conf/modsec2.conf file contains the basic directives for the mod_security Apache module, and the following include directives:

    Include "/usr/local/apache/conf/modsec2.user.conf"
    Include "/usr/local/apache/conf/modsec2.cpanel.conf"

The /usr/local/apache/conf/modsec2.user.conf file contains the ModSecurity firewall application rules that you define.


  • For WHM 11.44 and earlier, the system defines ModSecurity rules in WHM's Mod Security interface (Home >> Plugins >> Mod Security).
  • For WHM 11.46 and later, the system defines ModSecurity rules in WHM's Apache Module: ModSecurity interface (Home >> Security Center >> ModSecurity Configuration).
  • EasyApache enables the mod_security Apache module for all virtualhosts by default, except the default virtualhost. For example, if your server's hostname is, then the section for that virtualhost in your /usr/local/apache/conf/httpd.conf file will contain the following directive:

        <IfModule mod_security2.c>
            SecRuleEngine Off
  • By default, the mod_security Apache module stores its log file in the /usr/local/apache/logs/modsec_audit.log file.

Raw Opts and ModSecurity

Advanced users can use Apache Module: ModSecurity to add additional configuration directives. 

How to enable or disable the module in a custom EasyApache profile file

The following table provides information about how EasyApache refers to the mod_security Apache module:

EasyApache module namemod_security
EasyApache Profile Entry


To enable or disable the mod_security Apache module in a custom EasyApache profile file, set the Cpanel::Easy::ModSec profile entry to one of the following values:

  • 1 – This value enables the module.
  • 0 – This value disables the module.


DateEasyApache versionActionDetails
6/2/20153.30.1Ea update

Implemented case 183781: Provide ModSecurity 2.9.0 for EasyApache 3

  Implemented case 185213: Make ModSecurity 2.9.0 use apr-util crypto functionality

Implemented case 185353: Add rawopts functionality to ModSecurity

  Implemented case 188133: Fix ModSecurity crypto patch for 32-bit systems

12/16/20143.28.0EA update

Implemented case 127757: Add missing rule id in stock Mod Security configuration file

Implemented case 139549: Stop distributing Mod Security rules for cPanel & WHM 11.46 and later

Implemented case 61094: Remove additional rule from modsec2.conf for cPanel & WHM 1.46 and later

Implemented case 131377: Fix duplicate rule id in default Mod Security rule set

10/20/20143.26.9EA update

Implemented case 118317: EasyApache now sets WHM 11.46+ ModSecurity directives in modsec2.cpanel.conf

9/22/20143.26.8EA updateFixed case 116941: Fixed disabled custom mod_security rules
7/16/20143.26.0EA updateImplemented case 76837: Add mpm-itk to EasyApache
5/5/20143.24.18EA update

Implemented case 99397: Update Mod Security to version 2.8.0 (drop 2.7.7)

3/10/20143.24.12EA update

Fixed case 76493: Resolve incompatibility between ModRuid2 and ModSecurity

2/11/20143.24.11Doc update

Implemented case 73225: Remove Apache 1.3 and 2.0

1/6/20143.22.28EA update

Implemented case 85957: Update Mod Security to version 2.7.7 (dropped 2.7.5)

Fixed case 86893: Resolve MySQL version 5.6 table creation issue with Mod Security (cPanel & WHM version 11.41)

Fixed case 86905: Resolve MySQL version 5.6 import issue with Mod Security (cPanel & WHM version 11.41)

11/18/20133.22.20EA update

Fixed case 81241: Resolve EasyApache Build Screen stops at “Mod Security”

8/29/20133.22.10EA updateImplemented case 75941: Update mod_security for cPanel & WHM 11.40 compatibility
8/6/20133.22.4EA update

Implemented case 74273: Update ModSecurity to version 2.7.5

7/22/20133.20.4EA update

Implemented case 69173: Update ModSecurity to version 2.7.4 (and drop 2.7.3)

4/2/20133.18.12EA update

Implemented case 64472: Update ModSecurity to version 2.7.3 (and drop 2.7.2)

2/14/20133.18.1EA update

Implemented case 63304: Update ModSecurity to version 2.7.2 (and drop 2.7.1)

Fixed case 63498: ModSecurity: Resolve auto-id generation in chain rules containing comments and blank lines


EA update

Doc update

Implemented case 62063: Update ModSecurity to version 2.7.1

Fixed case 62369: ModSecurity 2.7.1: change default rule id range to avoid collisions

Fixed case 62466: ModSecurity needs module dependencies for 11.36 compatibility

Fixed case 62602: ModSecurity 2.7.1: Ensure rules receive an ID even if optional fields are unused

Fixed case 63109: ModSecurity needs module dependencies for 11.36 compatibility

Implemented case 51105: Update for Apache 2.4

11/27/20123.16.3EA updateImplemented case 60604: Update ModSecurity to 2.7.0

Implemented case 61873: ModSecurity 2.7.0 requires new MULTIPART_INVALID_PART to resolve CVE

Implemented case 62217: Backport: mod_security 2.7.1 fix to 2.7.0: DROP disabled w/Apache2

9/26/201323.14.13EA updateImplemented case 61382: Update EasyApache to mod_security 2.6.8
8/10/20123.14.7EA updateImplemented case 60603: update mod security to 2.6.7
7/28/20123.14.5EA update

Implemented case 60072: Update mod_security to version 2.6.6.

2/10/20123.9.1EA update

Fixed case 55361: The user is not informed in the WHM UI when mod_security fails to connect to the database

Fixed case 56449: Improve input validation and reporting in mod security UI script

12/28/20113.8.3EA update

Implemented case 55982: PCRE reverted to version 8.12 due to compatibility problems with some mod_security configurations

10/28/20113.7.0EA update

Implemented case 52050: EasyApache: Upgrade ModSecurity to 2.6.2

12/13/20105270EA update

Implemented sase 45289: Update mod security 2 to 2.5.13

mod_security version history

Version 2.9.0

ModSecurity 2.9.0 contains the following improvements:

  • 'pmFromFile' and 'ipMatchFromFile' operators are now accepting HTTPS served files as parameter.
  • 'SecRemoteRules' directive - allows you to specify a HTTPS served file that may contain rules in the SecRule format to be loaded into your ModSecurity instance.
  • 'SecRemoteRulesFailAction' directive - allows you to control whenever the user wants to Abort or just Warn when there is a problem while downloading rules specified with the directive: `SecRemoteRules'.
  • 'fuzzyHash' operator - allows to match contents using fuzzy hashes.
  • 'FILES_TMP_CONTENT' collection - make available the content of uploaded files.
  • InsecureNoCheckCert - option to validate or not a chain of SSL certificates on mlogc connections.
ModSecurity 2.9.0 bug fixes

ModSecurity 2.9.0 contains the following bug fixes:

  • ModSecurityIIS: ModSecurity event ID was changed from 0 to 0x1. [Issue #676]
  • Fixed signature on "status call": ModSecurity is now using the original server signature. [Issues #702]
  • YAJL version is printed while ModSecurity initialization. [Issue #703]
  • Fixed subnet representation using slash notation on the @ipMatch operator. [Issue #706]
  • Limited the length of a status call. [Issue #714]
  • Added the missing -P option to nginx regression tests. [Issue #720]
  • Fixed automake scripts to do not use features which will be deprecated in the upcoming releases of automake [Issue #760]
  • apr-utils's LDFALGS is now considered while building ModSecurity. [Issue #782]
  • IIS installer is not considering IIS 6 as compatible anymore. [Issue #790]
  • Fixed yajl build script: now looking for the correct header file. [Issue #804]
  • mlgoc is now forced to use TLS 1.x. [Issue #806]
 Click to view older ModSecurity updates

Version 2.8.0

ModSecurity 2.8.0 contains the following improvements:

  • JSON Parser is no longer under tests. Now it is part of our mainline.
  • Connection limits (SecConnReadStateLimit and SecConnWriteStateLimit) now support white and suspicious list;
  • New variables: FULL_REQUEST and FULL_REQUEST_LENGTH were added, which allow the rules to access the full content of a request.
  • ModSecurity status is now part of our mainline.
  • New operator: @detectXSS was added. It makes usage of the newest libinjection XSS detection functionality.
  • Memory usage improvement: uses correct memory pools in accordance with the context (Ref: #618, #620, #619).
  • Remove warnings from the build process (Ref: #617).
  • Reduce the amount of warnings during the compilation (Ref: #385a2828e87897bd611bd2a519727ef88dc6d632, #1e63e49db4a592d28e08a33fc60750c37a3886fe).
  • Increased the timeout while the system reads the auditlog.
  • Updates to fix errors that Parfait static code analysis finds (Ref: #612).
Mod Security 2.8.0 bug fixes

Mod Security 2.8.0 contains the following bug fixes:

  • Added mod_extract_forwarded.c to run before mod_security2.c (Ref: #594).

  • Fixed typo in README file.

  • Removed the non standard compliant HTTP response status code 44 from modsecurity recommended file (Ref: #665).

  • Fixed segmentation fault if it fails to write on the audit log (Ref: #668).

  • Not rejecting a larger request with ProcessPartial. Regression tests were also added (Ref: #597).

  • Fixed UF8 to unicode conversion. Regression tests were also added(Ref: #672).

  • Checks if a structure is null before it accesses its members to avoid segmentation fault.

  • Now alerts the users that there is no memory to proceed the configuration's installation instead of just die.

  • Build system is now more flexible.Older ModSecurity updates

Version 2.7.7

ModSecurity 2.7.7 contains the following improvements:

  • Updated Libinjection to version 3.8.0.

Version 2.7.5

ModSecurity 2.7.5 contains the following improvements:

  • SecUnicodeCodePage is DEPRECATED. SecUnicodeMapFile now accepts the code page as a second parameter.
  • Updated Libinjection to version 3.4.1.
  • Severity action now supports strings (For example, emergency, alert, critical, error, warning, notice, info, debug).
ModSecurity 2.7.5 bug fixes

ModSecurity 2.7.5 contains the following bug fixes:

  • Fixed utf8toUnicode tfn null byte conversion.
  • Fixed flush output buffer before inject modified hashed response body.
  • Fixed url normalization for Hash Engine.

Version 2.7.4

ModSecurity 2.7.4 contains the following improvements:

  • Added the Libinjection Project operator – @detectSQLi
  • Added SDBM_DELETE_ERROR variable – This variable is set to 1 when the sdbm engine fails to delete entries.
ModSecurity 2.7.4 bug fixes

ModSecurity 2.7.4 contains the following bug fixes:

  • Fixed SecRulePerfTime, which no longer stores unnecessary rule performance times.
  • Fixed possible SDBM deadlock condition.
  • Fixed possible @rsub memory leak.
  • Fixed REMOTE_ADDR content, which receives the client ip address when the mod_remoteip.c directive is present.
ModSecurity 2.7.4 security fixes
  • The Remote Null Pointer DeReference issue in CVE-2013-2765 has been fixed.


    CVE-2013-2765 reports the following issue:

    When forceRequestBodyVariable action is triggered and a unknown Content-Type is used, mod_security will crash trying to manipulate msr->msc_reqbody_chunks->elts however msr->msc_reqbody_chunks is NULL.

Version 2.7.3

ModSecurity 2.7.4 contains the following improvements:

  • New MULTIPART directives: MULTIPART_NAME and MULTIPART_FILENAME – ModSecurity's Core Rule Set (CRS) uses these directives to help prevent attacks that use multipart data.
  • New functionality with .htaccess: --enable-htaccess-config configure option. This option is not available with EasyApache.
  • Security feature for SecXmlExternalEntity – This option is off by default, which disables the ability of the LibXml2 function to load external entities.

Version 2.7.1

Parse failures in EasyApache 3.18.0

A chained rule comment or an empty line can cause a parse failure in EasyApache 3.18.1. However, there is a patch to properly parse and append missing rule IDs in chained rules that contain comments and empty lines.

The following is a syntactically correct example from the ruleset from Atomix:

#Enforce proper requests per HTTP RFC
SecRule REQUEST_LINE "!^(?:(?:[a-z]{3,10}\s+(?:\w{3,7}?://[\w\-\./]*(?::\d+)?)?/[^?#]*(?:\?[^#\s]*)?(?:#[\S]*)?|connect (?:\d{1,3}\.){3}\d{1,3}\.?(?::\d+)?|options \*)\s+[\w\./]+|get /[^?#]*(?:\?[^#\s]*)?(?:#[\S]*)?)$" \
    "chain,deny,status:403,t:none,t:lowercase,capture,phase:2,rev:2,log,auditlog,msg:' UNSUPPORTED DELAYED Rules: Invalid HTTP Request Line in violation of RFC (if you do not wish to follow HTTP RFCs, disable this rule)',id:'330700',severity:'4',logdata:'%{TX.0}'"
#Java 1.6 doesnt seem to follow the RFC correctly
SecRule REQUEST_HEADERS:User-Agent "^java/1\.6"

The following example shows how EasyApache 3.18.0 incorrectly parses the rule when it attempts to append an ID number:

#Enforce proper requests per HTTP RFC
SecRule REQUEST_LINE "!^(?:(?:[a-z]{3,10}\s+(?:\w{3,7}?://[\w\-\./]*(?::\d+)?)?/[^?#]*(?:\?[^#\s]*)?(?:#[\S]*)?|connect (?:\d{1,3}\.){3}\d{1,3}\.?(?::\d+)?|options \*)\s+[\w\./]+|get /[^?#]*(?:\?[^#\s]*)?(?:#[\S]*)?)$" \
    "chain,deny,status:403,t:none,t:lowercase,capture,phase:2,rev:2,log,auditlog,msg:' UNSUPPORTED DELAYED Rules: Invalid HTTP Request Line in violation of RFC (if you do not wish to follow HTTP RFCs, disable this rule)',id:'330700',severity:'4',logdata:'%{TX.0}'"
#Java 1.6 doesnt seem to follow the RFC correctly
SecRule REQUEST_HEADERS:User-Agent "^java/1\.6" "id:123456789"

In general, each rule must contain only one unique ID. In this example, this rule is broken because the rule already contains an ID number of 330700.

To fix this issue, you must remove the extra " id:123456789" from the second SecRule.


This issue was resolved in EasyApache 3.18.3.

Changes to directives and options in ModSecurity 2.7.1

In version 2.7.0, ModSecurity created five new configuration directives and three new options for Encryption. In version 2.7.1, these directives and options were renamed to use the word "Hash" instead of "Encryption."

Original NameNew Name

Version 2.7.0

Patch for libxml2 2.9.0 in ModSecurity 2.7.0

EasyApache contains a patch for libxml2 2.9.0 that fixes an incompatibility issue with ModSecurity 2.7.0.

Patch for Disabled Drop action in ModSecurity 2.7.0

EasyApache contains a patch for ModSecurity 2.7.0 that fixes an issue where Apache 2.0 disabled the DROP action.

Any servers with this patch trigger the rule correctly and do not incorrectly report that DROP is unimplemented.

Rules ID required in ModSecurity

In ModSecurity version 2.7.0, any rules that you add must include an ID action. This ID must be numeric and unique. Otherwise, you will see an error that resembles the following example:

"Syntax error on line 15 of /usr/local/apache/conf/modsec2.conf:
No action id present within the rule"

The following table lists reserved and available ranges:

ID RangeDescription
1–99,999Reserved for local (internal) use. Use as you see fit, but do not use this range for rules that are distributed to others.
100,000–199,999Reserved for internal use of the engine, to assign to rules that do not have explicit IDs.
200,000–299,999Reserved for rules published at
300,000–399,999Reserved for rules published at
400,000–419,999Unused (available for reservation).
420,000–429,999Reserved for ScallyWhack.
430,000–439,999Reserved for rules published by Flameeyes.
440.000-599,999Unused (available for reservation.)
600,000-699,999Reserved for use by Akamai.
700,000–799,999Reserved for Ivan Ristic.
900,000–999,999Reserved for the OWASP ModSecurity Core Rule Set Project.
1,000,000-1,999,999Unused (available for reservation).
2,000,000-2,999,999Reserved for rules from Trustwave's SpiderLabs Research team.
3,000,000 and aboveUnused (available for reservation).
1,234,123,380 and aboveEasyApache places converted rules here (not reserved).

EasyApache automatically adds a unique numeric ID to any existing rules without IDs, starting with the ID number 1,234,123,380.

EasyApache also converts any non-numeric IDs into unique numeric IDs, while it updates all references to the new unique numeric IDs within configuration directives.

For more information, read ModSecurity's Actions documentation.

ID syntax issue with rules that use the default option

When earlier versions of EasyApache encountered a rule that uses the default options and does not have an ID, it improperly added the new ID to preceding section as follows:

SecRule REQUEST_URI "/db_mysql\.inc,id:1234123380"

We corrected this issue so that the system will add the ID correctly:

SecRule REQUEST_URI "/db_mysql\.inc" "id:1234123380"
Automatic patches in ModSecurity 2.7.0

EasyApache automatically adds the following patch to ModSecurity:

"id:'200002',phase:2,t:none,log,deny,status:44,msg:'Multipart request body \
failed strict validation: \

Version 2.5.6 and earlier

Transformation caching deprecated in ModSecurity 2.5.6

With the release of ModSecurity 2.5.6, transformation caching has been deprecated. In all releases prior to 2.5.6, the underlying transformation caching subsystem was unstable and could crash the Apache server. We strongly suggest that you disable caching for all versions of ModSecurity 2.5 in your configuration with the following directive:

SecCacheTransformations Off

For more information, visit ModSecurity's Transformation blog post.

Version 2.1 rules in version 2.5

The format for version 2.1 works in version 2.5. However, the ModSecurity team has made no official announcement about compatibility. You will need to verify that your custom rulesets work with version 2.5 to ensure no interruption of service due to the upgrade. The default rules that cPanel & WHM provide work on version 2.5.

ModSecurity 2.5 rule scripting - lua

ModSecurity version 2.5 adds support for rule scripting via Lua. Lua is known to have difficulties building. Lua build failures will not cause an Apache build to fail, but errors appear in the build log if there is a build failure. The system will not enable Lua support if there are errors in the build. If you wish to use Lua in your custom ruleset, carefully read about the proper usage of Lua and ensure that the Lua build succeeded.


  • ModSecurity marks lua as "Experimental." Use lua at your own risk.
  • Any LA syntax or permission errors result in Apache's inability to start.
  • Lua script changes require an Apache restart to take effect.

Store Lua scripts in a subdirectory of the /usr/local/apache/conf directory. For example, the /usr/local/apache/conf/modsec-lua directory. Store scripts in this location to ensure that scripts are available whenever a user tests Apache configuration or when Apache restarts. It also keeps them intact through EasyApache builds.


If you fail to store Lua scripts in /usr/local/apache/conf, then Apache cannot build. This could result in a broken ModSecurity configuration.

For more information, read ModSecurity's Initial Release Candidate for ModSecurity 2.5.0 (2.5.0-rc1).

Related documentation

Vendor documentation

The following text is an excerpt from the ModSecurity website:

With over 70% of all attacks now carried out over the web application level, organisations need every help they can get in making their systems secure. Web application firewalls are deployed to establish an external security layer that increases security, detects, and prevents attacks before they reach web applications.

For more information on the mod_security Apache module, visit the ModSecurity for Apache website.