Upgrading mod security to OWASP 3.0

rinkleton

Well-Known Member
Jul 16, 2015
108
4
68
Cleveland
cPanel Access Level
Root Administrator
When upgrading to OWASP 3.0, do the rules get all new ID's, or do they stay the same, in which case I will have to go through all of the currently disabled rules and re-enable?
 

rinkleton

Well-Known Member
Jul 16, 2015
108
4
68
Cleveland
cPanel Access Level
Root Administrator
Thanks, that seems to indicate the IDs are the same. So it seems like the recommended upgrade path would be to switch over to 3.0 and enable all rules previously disabled due to false positives?
 

Infopro

Well-Known Member
May 20, 2003
17,090
518
613
Pennsylvania
cPanel Access Level
Root Administrator
Twitter
Near bottom of page there is a list and over 20 of them are marked: Rule gone in v3.0.0-dev. I wouldn't rely on all IDs working any longer.

I can't check the ruleIDs themselves as I don't use OWASP any longer, I like and use Comodo rules with this vendor URL in WHM:
Code:
https://waf.comodo.com/doc/meta_comodo_apache.yaml
 

fuzzylogic

Well-Known Member
Nov 8, 2014
154
93
78
cPanel Access Level
Root Administrator
All rule numbers have changed between versions.
The Post referenced by infopro on netnea used an early version of v3.0.0-dev which was from before the time renumbering was complete. As a for instance, 950000 (the first common id number listed on netnea) is now 943120 in cPanels OWASP3 crs.
A full list of id references can be found on your server at...
/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/id_renumbering/IdNumbering.csv
or at owasp-modsecurity-crs/IdNumbering.csv at v3.0/master · SpiderLabs/owasp-modsecurity-crs · GitHub
No ids in the left column match ids in the right column.

So as for your original questions.
All rule IDs have changed.
This makes any rules disabled by ID from OWASP crs version 2 irrelevant to OWASP crs version 3.

Do you have to delete these old disable rules by ID?
No but they will have no effect on crs version 3 rules because none of the old ids exist there.
Best course of action would be to switch to OWASP crs version 3.
Re-enable all the old IDs you have disabled (these will be hard to find later once you start disabling new rule IDs)
Begin disabling new fp IDs as necessary.
fyi. When you disable rule 000000 through cPanel, it writes the line...
SecRuleRemoveById 000000
to the bottom of
/etc/apache2/conf.d/modsec/modsec2.cpanel.conf
When you re-enable the rule it deletes this line.

Will you have to redo the disable rules by ID with the new rule id numbers?
Quite probably for some of them.
OWASP crs version 2 was in traditional mode by default. (1 rule hit for a block action)
OWASP crs version 3 is in Anomaly Scoring by default (some attack rules block but indicator rules add the the Anomaly Score)
I would expect you will find less rules will require false positive action on your part.
 
Last edited:
  • Like
Reactions: Infopro

rinkleton

Well-Known Member
Jul 16, 2015
108
4
68
Cleveland
cPanel Access Level
Root Administrator
Thanks fuzzylogic, that was exactly the info I was looking for!

I'm going to give the OWASP 3.0 rules a try. It it still triggers a lot of false positives (I've gotten at least 1 already), then I'm going to give the Comodo rules a try.