0

In modsecurity default-script:

base_rules/modsecurity_crs_20_protocol_violations.conf

there is a rule, 960011:

SecRule REQUEST_METHOD "^(?:GET|HEAD)$" \
  "msg:'GET or HEAD Request with Body Content.',\
  severity:'2',\
  id:'960011',\
  ver:'OWASP_CRS/2.2.9',\
  rev:'1',\
  maturity:'9',\
  accuracy:'9',\
  phase:1,\
  block,\
  logdata:'%{matched_var}',\
  t:none,\
  tag:'OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ',\
  tag:'CAPEC-272',\
  chain"
    SecRule REQUEST_HEADERS:Content-Length "!^0?$"\
      "t:none,\
      setvar:'tx.msg=%{rule.msg}',\
      setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\
      setvar:'tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ-%{matched_var_name}=%{matched_var}'"

I only want to disable logging for this rule (it gives too many false positives), and therefore add my own script

base_rules/z99_logging_suppress.conf

to remove the default-rule and create a new identical rule -- only without logging:

SecRuleRemoveById 960011

SecRule REQUEST_METHOD "^(?:GET|HEAD)$" \
  "msg:'GET or HEAD Request with Body Content.',\
  severity:'2',\
  id:'9960011',\
  ver:'OWASP_CRS/2.2.9',\
  rev:'1',\
  maturity:'9',\
  accuracy:'9',\
  phase:1,\
  block,nolog,\
  logdata:'%{matched_var}',\
  t:none,\
  tag:'OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ',\
  tag:'CAPEC-272',\
  chain"
    SecRule REQUEST_HEADERS:Content-Length "!^0?$"\
      "t:none,\
      setvar:'tx.msg=%{rule.msg}',\
      setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},\
      setvar:'tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ-%{matched_var_name}=%{matched_var}'"

The only differences to the original rule are the new id 9960011, and the nolog additions:

  ...
  id:'9960011',\
  ...
  block,nolog,\
  ...

But when I restart httpd with this additional rule, I get error:

AH00526: Syntax error on line 18 of /path/base_rules/z99_logging_suppress.conf:
ModSecurity: Execution phases can only be specified by chain starter rules.

The same strategy --- SecRuleRemoveById + then re-create it with new id --- works for all other default-rules I tried, but not for this one.

Anyone can tell me why that is?

Rop
  • 3,359
  • 3
  • 38
  • 59

1 Answers1

2

It basically says that the phase command can only be in the first rule in a chain and not in a subsequent rule which forms part of the chain.

There is nothing wrong with the rule as you have written it, phase is only specified in the first SecRule. In fact I've tried it on my instance and it works. So either one of two things has gone wrong:

  1. You have copied and pasted it incorrectly into this question.
  2. The rule above where you have defined this, has chain in it and so has left an open chain, that your rule 9960011 is then effectively trying to continue on from.

Or something else weird is happening! But I'm going with 1 or 2 for now :-)

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • Are u saying the above works for you with the default base-rules? hmm... Your pt 1: For that to be true I would have it wrong on the server, but got it correct in this post -- extremely unlikely since I copied from the server into here :) -- Re pt 2: To debug, I tried with only the mod-security base_rules plus the above rule, and still got the error.... I'm really confused if this actually worked for you :) --- But I will check if I have maybe not the latest version of mod-security and/or apache. – Rop Apr 27 '17 at 18:57
  • 1
    For pt 2 it depends where you have above config? Have you pasted it after opening a previous chain? – Barry Pollard Apr 27 '17 at 19:02
  • No, I still got the error when I only added the above script to base_rules. Nothing else, other than the default base_rules files. – Rop Apr 27 '17 at 19:06
  • 1
    There's a bug saying ModSecurity doesn't alert when an open chain is left: https://github.com/SpiderLabs/ModSecurity/issues/1042. So possibly you (or the CRS!) have an open chain somewhere but haven't noticed it before? – Barry Pollard Apr 27 '17 at 19:35
  • You are entirely correct! I was more confused than I thought, and apparently had not tested what I thought I had tested :/ -- Yes, turned out there was an open chain in a previous file that caused the problem. It's working now :) Much thanks for your help!! – Rop Apr 27 '17 at 20:52
  • 1
    Good stuff. Can recommend this book enough btw: https://www.feistyduck.com/books/modsecurity-handbook/. Written by the original author of ModSecurity and updated recently by a guy who's very active on the CRS mailing list: https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set – Barry Pollard Apr 27 '17 at 21:05