EasyApache: mod_security Module

Introduction

According to the ModSecurity website:

"ModSecurity is a web application firewall that can work either embedded or as a reverse proxy. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis."

Note: Apache 1.3 uses ModSecurity 1.x, and Apache 2.x uses ModSecurity 2.x

Important Things To Know When Changing ModSecurity Versions

Here are some important things to know when you change between ModSecurity versions:

• Upgrades are performed automatically when you run EasyApache
• The ModSecurity Activity Viewer in WHM complies easily
• The rule editor in WHM will automatically work with the installed version of ModSecurity's rules.
• Rule syntax is completely different and located in different locations. When you migrate between major version numbers of ModSecurity, your mod_security 1 rules will need to be redone in mod_security 2 and vice versa.

Unfortunately, there is no easy one-to-one relationship or translation ability. You can find resources to help with this migration at the following locations:

• http://www.modsecurity.org/ including a "ModSecurity 1.x to 2.x Migration Matrix"
• "ModSecurity FAQ" (under Documentation)
• The ModSecurity mailing list

WARNING: ModSecurity version 2.7.0 is less forgiving of rule syntax problems than previous versions. We strongly recommend that you review your custom rulesets to confirm that they are valid and contain no duplicates.

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.

Servers with this patch will trigger the rule correctly and not incorrectly report that DROP is unimplemented.

Rules ID Required in ModSecurity

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

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

The following table lists ranges that have been reserved:

EasyApache will automatically add a unique numeric ID to any existing rules without IDs, starting with the ID number 1,234,123,380. EasyApache will also convert 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 mod_security Actions documentation

Automatic Patches in ModSecurity 2.7.0

EasyApache will add the following patch to ModSecurity automatically:

SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"id:'200002',phase:2,t:none,log,deny,status:44,msg:'Multipart request body \
failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_MISSING_SEMICOLON}, \
IQ %{MULTIPART_INVALID_QUOTING}, \
IP %{MULTIPART_INVALID_PART}, \
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"

2.5.6 Transformation Caching Deprecated

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 can crash the Apache server. We advise that you disable caching for all 2.5 versions of ModSecurity in your configuration with the following directive:

SecCacheTransformations Off

For more information, please visit: http://blog.modsecurity.org/2008/08/transformation.html

Upgrade from ModSecurity 2.1 to 2.5

Using version 2.1 rules on version 2.5

So far, it appears that version 2.1 format rules work on version 2.5. However, the ModSecurity team has made no official announcement of 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 rules included by cPanel for version 2.1 will 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 halt, but errors will appear in the build log upon build failure, and lua support will not be enabled. If you wish to use lua in your custom ruleset, you should carefully read about the proper usage of lua and ensure that the lua build was a success.

Some things to watch out for when you use lua:

• ModSecurity marks it as "Experimental," use at your own risk.
• Lua syntax or permission errors will result in Apache not being able to start.
• Apache must be able to read the lua file.
• Lua script changes require an Apache restart to take effect.

Lua scripts should be stored in /usr/local/apache/conf in a sub directory such as /usr/local/apache/conf/modsec-lua. Storing scripts in this location will ensure that they are available whenever Apache configurations are tested or when Apache is restarted. It will also keep them intact through EasyApache builds.

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

More information on !ModSecurity 2.5 is available.

Information about using lua scripts in your ModSecurity rules can be found here: http://www.modsecurity.org/documentation/modsecurity-apache/2.5.5/modsecurity2-apache-reference.html#N109A9.

Related Documentation

The ModSecurity website includes more information.