ModSecurity Changes in EasyApache 3.16

[Infopro]

cPanel recently released EasyApache 3.16. This version of EasyApache contains an updated version of ModSecurity that has an important change to Rule IDs which will affect you.

In addition to the RuleID change, another change in ModSecurity that affects directive names will be incorporated into EasyApache 3.18.

Unique Rule IDs are mandatory

Unique Rule IDs are mandatory. When EasyApache runs, it tries to automatically assign unique Rule IDs to any existing rules that do not already have Rule IDs. However, you will need to manually check your ruleset to confirm that there are no Rule ID conflicts or syntactical errors.

Also, if you automatically download and import rulesets into your ModSecurity on a schedule, EasyApache will not check these rules for Rule ID conflicts or syntactical errors. If the third-party ruleset contains Rule ID conflicts or syntactical errors, ModSecurity will fail and Apache will not start.

The following is an example of a rule that does not contain a Rule ID:

 SecRule  REMOTE_ADDR  "^127.0.0.1$"  "nolog,allow"
SecAction  "phase:2,pass,nolog"

You will see an error similar to the following:

 1. Critical Error: No Rule ID

  Syntax error on line XX of /some/config/file.conf:
  ModSecurity: No action id present within the rul

The following is the same rule that has been changed to include a unique Rule ID:

 SecRule  REMOTE_ADDR  "^127.0.0.1$"  "nolog,allow,id:1234123455"
SecAction  "phase:2,pass,nolog,id:1234123456"

However, if the Rule ID duplicates another Rule ID, you will see:

2. Critical Error: Duplicate Rule ID:

  Syntax error on line XX of /some/config/file.conf:
  ModSecurity: Found another rule with the same id

Configuration directive changes

Six configuration directives have been changed to use the word “Hash” instead of “Encryption” and they are not backwards-compatible.

EasyApache will try to convert all references within your existing ruleset from “Hash” into “Encryption.” However, if you automatically download and import rulesets into your ModSecurity on a schedule, EasyApache will not check these rules for the deprecated term “Encryption.” ModSecurity does not support the deprecated term “Encryption” and it will fail, which will make Apache fail to start.

The following is an example of a rule that used the deprecated term “Encryption”

# Validates requested URI that matches a regular expression.
SecRule REQUEST_URI "@validateEncryption product_info|product_list" "phase:1,deny,id:123456"

You will see an error similar to the following

Syntax error on line XX of /usr/local/apache/conf/modsec2.conf:
Invalid command '@validateEncryption', perhaps misspelled or defined by a module not included in the server configuration

The following is an example of the example rule that has been changed to use the new term “Hash”

# Validates requested URI that matches a regular expression.
SecRule REQUEST_URI "@validateHash product_info|product_list" "phase:1,deny,id:123456"

These two changes are important because if you have any rules which ModSecurity cannot process, ModSecurity will fail and Apache will not start. This is a change from ModSecurity’s previous behavior, which was to fail with a warning, but allow Apache to start successfully.

For more information, please visit the ModSecurity Page - cPanel Documentation

 

[XenomediaBV]

Is there a version indication for the default rule set?

The default rule set generates a lot of false-positives in combination with some well-known open-source script (e.g. Joomla, X-Cart, jQuery). You should be very careful using these rules. The default rule set causes me a lot of customer complains. Because of the complex regexps not every rule is easy to adjust and must be completely disabled to provide a solution for customers. This results in security holes. Also, bots like Google will also receive 404 and 406 warnings resulting in bad Google indexes for websites on your server.

Some examples:

Taken from a eBay-like script:

/subcategorie/6540-Overige_.php?pagina=884®els=20&goedkeuring=1&sorteren=oplopend&order=cast(prijs%20as%20signed)

which triggers:

Access denied with code 406 (phase 2). Pattern match "(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b(?:(?:length|count|top)\\b.{1,100}?\\bfrom|from\\b.{1,100}?\\bwhere)|.*?\\b(?:d(?:ump\\b.*\\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebt ..." at ARGS:order. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "92"] [id "1234123415"] [msg "SQL Injection Attack"] [data "cast("] [severity "CRITICAL"] [tag "WEB_ATTACK/SQL_INJECTION"]

• With X-Cart it blocks the installation of a payment method (cc_processor.php);
• With the jQuery cookie plugin (jquery.cookie.js).

Is cPanel aware of the fact that the default rule set is causing so much trouble? Is it possible, since cPanel provides this default rule set, to maintain the set and take out the false-positives by default?

 

[XenomediaBV]

Some rules I had to disable to make the open-source scripts work again:

# allow request methods
#SecRule REQUEST_METHOD "!^((?:(?:POS|GE)T|OPTIONS|HEAD))$" \
#    "phase:2,t:none,log,auditlog,status:501,msg:'Method is not allowed by policy', severity:'2',id:'1234123435',tag:'POLICY/METHOD_NOT_ALLOWED'"

#SecRule REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS:Referer "\b(\d+) ?= ?\1\b|[\'\"](\w+)[\'\"] ?= ?[\'\"]\2\b" \
#        "phase:2,capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:replaceComments,t:compressWhiteSpace,t:lowercase,ctl:auditLogParts=+E,log,auditlog,msg:'SQL Injection

 

[Infopro]

...

Some examples:

Taken from a eBay-like script:
...

How would cPanel know anything about an "eBay-like" script?

Depending on any rulesets you use, the same could be said. You're going to have to continue working with the rules as needed I would think. In that regard, here's a handy addon tool to have available:
ConfigServer ModSecurity Control

 

[XenomediaBV]

I don't say cPanel should know anything about any rule or script. That is, obviously, out of scope for them. I am just mentioning that, when applying the default rules set on a virtual hosting environment, sysadmins should be aware of the fact that the default rule set will break a lot of existing open-source scripts. I am just showing some examples hoping this can help anybody and perhaps they can also post examples of situations they encountered.

The only modification cPanel might be able to add to the default rule set is a version number and perhaps mention the source of this set within WHM. This might be a big help in case of debugging. That's all.

 

[Infopro]

I don't say cPanel should know anything about any rule or script. That is, obviously, out of scope for them.
...

That's how I read this comment by you:

...
Is cPanel aware of the fact that the default rule set is causing so much trouble? Is it possible, since cPanel provides this default rule set, to maintain the set and take out the false-positives by default?
...

The only modification cPanel might be able to add to the default rule set is a version number and perhaps mention the source of this set within WHM. This might be a big help in case of debugging. That's all.

From the original post above:

...
For more information, please visit the ModSecurity Page - cPanel Documentation

Hope that helps!

 

[XenomediaBV]

Actually, you're not helping. I already knew this addon. I just don't prefer addons other than officially approved by cPanel on a production environment.

And my comments had to be read as questions (Are they aware? Is it possible?). That doesn't mean I am saying they must do so

But thank you anyway. I do know you're always trying to provide some information so keep up the good work :D