easyapache is breaking 3rd party modsec rules (atomicorp/gotroot)

[qwerty]

Just towards the end of easyapache's recompile of php it does this:

-- End step 'Updating modsec2 conf file for multipart_stric_error ruleset' --
-- Begin step 'Updating rule id(s) and directive names in modsec conf file(s)' --


That second bit adds ID's to all modsec configuration files so if you use something like Atomicorp/gotroot rules it adds id's to them also and this stops easyapache from completing.

The only solution is to re-upload our original unmodified 3rd party rules (Atomic in my case) and easyapache is able to complete as its able to restart httpd once the modified (by easyapache!!) modsec config files are restored so that they do NOT contain those IDs.

AS AN EXAMPLE ...


This following rule is part of atomicorp's "REAL TIME RULES" (not delayed ones):

#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}\.)$
"chain,deny,status:403,t:none,t:lowercase,capture,phase:2,rev:2,log,auditlog,msg:'Atomicorp.com WAF Rules: Invalid HTTP Request L$
#Java 1.6 doesnt seem to follow the RFC correctly
SecRule REQUEST_HEADERS:User-Agent "^java/1\.6"


The above is the ORIGINAL, UNMODIFIED, rule - current and up to date and fully functional and valid.

However during easyapache's final step, it adds an id just behind "^java/1\.6" so it looks something like "^java/1\.6" id:123456

and that is what breaks the apache config according to easyapache.

This is part of the easyapache log:

Determining PHP version
Installing IonCube Loader binaries
Activating IonCube Loader extension in /usr/local/lib/php.ini
IonCube Loader extension activated
-- End step 'Install IonCube loader' --
-- End opt 'IonCube Loader for PHP' --
Building global cache for cpanel...Done
Updating Apache configuration
Updating Apache configuration
Updating Apache configuration
Distilled successfully
!! Failed to utilize existing Apache configuration file. Resetting Apache configuration to default. !!
Updating Apache configuration
Updating Apache configuration
Distilled successfully
!! Failed to generate a syntactically correct Apache configuration (/usr/local/apache/conf/httpd.conf.1361919693):
An error occurred while running: /usr/local/apache/bin/httpd -DSSL -t -f /usr/local/apache/conf/httpd.conf.1361919693
Exit signal was: 0
Exit value was: 1
Output was:
---
Syntax error on line 42 of /usr/local/apache/conf/modsec/10_asl_rules.conf:
ModSecurity: Metadata actions (id, rev, msg, tag, severity, ver, accuracy, maturity, logdata) can only be specified by chain starter rules.
---
!!
!! Archiving successful build so it can be restored via --restore-archive once the httpd.conf are resolved !!
!! 'safecopy(/usr/local/apache/etc, /usr/local/apache.ea3-buildok-confgen-failed)' did not return true !!
!! Done Archiving successful build !!
!! Restoring original working apache !!


Note the bit in BOLD. Line 42 is "SecRule REQUEST_HEADERS:User-Agent "^java/1\.6" but it looks something like SecRule REQUEST_HEADERS:User-Agent "^java/1\.6" id:123456 because easyapache ADDED the id bit.

 

[Infopro]

This thread is related I believe:
ModSecurity Changes in EasyApache 3.16 - cPanel Forums

 

[qwerty]

Indeed it is related but does not really offer any other info other than that IDs are now required.

Which is all fine and good BUT I just came accross this doc Apache Module: Security ID required in _ModSecuri

Even cpanel themselves state that easyapache erronously attempts to add ID to that same rule that I quoted initially (as it's the first one affected) in Easyapache 3.18.0 - look for the sub-heading "Parse failures in EasyApache 3.18.0"

However I am using EasyApache 3.18.2 and it is STILL doing the same thing ie. it's trying to add erronously add IDs to rules that already have them such as the rule quoted above (it's a chain rule and has an id well before the 'java' line)

So why is EA 3.18.2 still doing this when apparently cpanel knew that 3.18.0 was causing this problem ?!??

 

[mikegotroot]

Just towards the end of easyapache's recompile of php it does this:

-- End step 'Updating modsec2 conf file for multipart_stric_error ruleset' --
-- Begin step 'Updating rule id(s) and directive names in modsec conf file(s)' --


That second bit adds ID's to all modsec configuration files so if you use something like Atomicorp/gotroot rules it adds id's to them also and this stops easyapache from completing.

(Posting here because it was requested by the customer)

So if I understand you correctly, cpanel is adding ids to our rules. Two issues with that:

1) Its not necessary for our rules, they all have ids. So if its adding ids, something is wrong with the code in EasyApache to detect when a rule id is missing.
2) Theres a bug in EasyApache if its adding an id to a chained rule.

For example, this is the chained rule in both the delayed rules and real time rules (its the same in both):

#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:'Atomicorp.com WAF 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"

Thats a chained rule. Chained rules let you add multiple directives together into a single rule. So you will see multiple directives joined with the "chain" action. If you look on the third line you'll see the id, and a "chain" directive. Then the next line is added to the rule, and so on until the chain ends. Thats a single rule.

So what appears to be happening in your case is EasyApache is adding an id to the last line, which isnt necessary, because its part of a chained rule and is not its own rule. And thats why you are getting this error:

Syntax error on line 42 of /usr/local/apache/conf/modsec/10_asl_rules.conf:
ModSecurity: Metadata actions (id, rev, msg, tag, severity, ver, accuracy, maturity, logdata) can only be specified by chain starter rules.

Because you cant add an id to a rule that already has an id. So this is a bug in easyapache.

 

[kdean]

Confirmed the same problem. Already had a ticket open with cPanel regarding this so I've pointed them to this thread.

 

[qwerty]

Thanks for confirming that this is a bug in EA Michael. Now let's hope cpanel actually fix this promptly because otherwise the only way to run EA without errors/broken build is to either:

1) disable the rulesets/files inside modsec2.user.conf

or

2) re-upload the original atomicorp rulesets during EA when it fails to restart and then restart manually.

Obviously option 1 is much cleaner BUT leaves you vulnerable to attacks for a minute or 2 while you re-enable the modsec2.user.conf rulesets after the EA process ends. So neither solution is reliable or safe.

IDEALLY cpanel could simply add a "do not parse modsec rules" option in EA so that people who use 3rd party rules like Atomicorp's don't have this problem.

 

[kdean]

Having a little trouble convincing the cPanel tech that this is an EasyApache bug since it's breaking something that wasn't broken. Hopefully my last message back to them clarified things enough.

qwerty, I even offered up the same idea of not modifying the 3rd party rules as a build option as well.

This cost me a large security outage today as I figured out what was going on myself.

 

[qwerty]

Well they can't possibly be denying EA is the culprit when they've even documented this problem themselves at this link:

Apache Module: Security

Scroll down to "Parse failures in EasyApache 3.18.0"

So they acknowledged the problem already (no idea when) but it seems they simply forgot about it?

 

[kdean]

or their idea of a fix is "well we documented it and it's 3rd party, so... done"

 

[Infopro]

Having a little trouble convincing the cPanel tech that this is an EasyApache bug since it's breaking something that wasn't broken. Hopefully my last message back to them clarified things enough.

qwerty, I even offered up the same idea of not modifying the 3rd party rules as a build option as well.

This cost me a large security outage today as I figured out what was going on myself.

Would you mind posting the ticket ID here please?

Thanks.

 

[kdean]

Would you mind posting the ticket ID here please?

Ticket # 3801595

I haven't received any further messages in a while so maybe they're looking at the easy apache issue.

 

[kdean]

I've been told:

"It looks like this functionality has been addressed and resolved by our developers in easyApache version 3.19.X and appears to have been back ported to the 3.18.X versions."

 

[qwerty]

Can you let them know it's still occurring in 3.18.2 and I'm running the latest 'RELEASE' verion of cpanel. Cheers

 

[Infopro]

Can you let them know it's still occurring in 3.18.2 and I'm running the latest 'RELEASE' verion of cpanel. Cheers

Please open a ticket about this, thanks.

 

[cPanelKenneth]

This should be fixed in EasyApache 3.18.3

 

[Zepplin]

Also occuring in EasyApache 3.18.4