Problem with "ModSecurity: Found another rule with the same id"

[lupoalberto12]

Hi, I have a problem with this rule:

_SecRule REMOTEADDR "@ipMatch MyIP" phase:2,id:'960015',nolog,allow,ctl:ruleEngine=Off

in "modsecurity_crs_10_config.conf" file. When I reboot Apache, I received this error with any ID:

_Starting httpd: AH00526: Syntax error on line 444 of /etc/httpd/modsecurity-crs/modsecurity_crs_10config.conf: ModSecurity: Found another rule with the same id

In my "httpd.conf":

<IfModule security2_module>
Include /etc/httpd/modsecurity-crs/modsecurity_crs_10_config.conf
Include /etc/httpd/modsecurity-crs/base_rules/*.conf
</IfModule>

In "/etc/httpd/conf.d/mod_security.conf":

LoadModule security2_module modules/mod_security2.so
LoadModule unique_id_module modules/mod_unique_id.so

# -- Rule engine initialization ----------------------------------------------

# Enable ModSecurity, attaching it to every transaction. Use detection
# only to start with, because that minimises the chances of post-installation
# disruption.
#
SecRuleEngine On

.................

How can I resolve this? Thanks. Regards.

[zimmerle]

Most likely you are including the rules twice. You may want to remove:

Include /etc/httpd/modsecurity-crs/base_rules/*.conf

And start to include file by file.

[lupoalberto12]

New configuration in "httpd.conf":

<IfModule security2_module>
Include modsecurity-crs/modsecurity_crs_10_config.conf

Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_20_protocol_violations.conf
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_21_protocol_anomalies.conf
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_23_request_limits.conf
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_30_http_policy.conf
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_35_bad_robots.conf
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_40_generic_attacks.conf
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_41_xss_attacks.conf
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_42_tight_security.conf
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_45_trojans.conf
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_47_common_exceptions.conf
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_48_local_exceptions.conf.example
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_49_inbound_blocking.conf
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_50_outbound.conf
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_59_outbound_blocking.conf
Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_60_correlation.conf
</IfModule>

same error: ModSecurity: Found another rule with the same id

I "solved" commenting this: _#Include /etc/httpd/modsecurity-crs/base_rules/modsecurity_crs_21_protocolanomalies.conf

My "modsecurity_crs_10_config.conf":

# ---------------------------------------------------------------
# Core ModSecurity Rule Set ver.2.2.9
# Copyright (C) 2006-2012 Trustwave All rights reserved.
#
# The OWASP ModSecurity Core Rule Set is distributed under
# Apache Software License (ASL) version 2
# Please see the enclosed LICENCE file for full details.
# ---------------------------------------------------------------

#
# -- [[ Recommended Base Configuration ]] -------------------------------------------------
#
# The configuration directives/settings in this file are used to control
# the OWASP ModSecurity CRS. These settings do **NOT** configure the main
# ModSecurity settings such as:
#
# - SecRuleEngine
# - SecRequestBodyAccess
# - SecAuditEngine
# - SecDebugLog
#
# You should use the modsecurity.conf-recommended file that comes with the
# ModSecurity source code archive.
#
# Ref: https://github.com/SpiderLabs/ModSecurity/blob/master/modsecurity.conf-recommended
#

#
# -- [[ Rule Version ]] -------------------------------------------------------------------
#
# Rule version data is added to the "Producer" line of Section H of the Audit log:
#
# - Producer: ModSecurity for Apache/2.7.0-rc1 (http://www.modsecurity.org/); OWASP_CRS/2.2.4.
#
# Ref: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-SecComponentSignature
#
SecComponentSignature "OWASP_CRS/2.2.9"

#
# -- [[ Modes of Operation: Self-Contained vs. Collaborative Detection ]] -----------------
#
# Each detection rule uses the "block" action which will inherit the SecDefaultAction
# specified below.  Your settings here will determine which mode of operation you use.
#
# -- [[ Self-Contained Mode ]] --
# Rules inherit the "deny" disruptive action.  The first rule that matches will block.
#
# -- [[ Collaborative Detection Mode ]] --
# This is a "delayed blocking" mode of operation where each matching rule will inherit
# the "pass" action and will only contribute to anomaly scores.  Transactional blocking
# can be applied
#
# -- [[ Alert Logging Control ]] --
# You have three options -
#
# - To log to both the Apache error_log and ModSecurity audit_log file use: "log"
# - To log *only* to the ModSecurity audit_log file use: "nolog,auditlog"
# - To log *only* to the Apache error_log file use: "log,noauditlog"
#
# Ref: http://blog.spiderlabs.com/2010/11/advanced-topic-of-the-week-traditional-vs-anomaly-scoring-detection-modes.html
# Ref: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-SecDefaultAction
#
SecDefaultAction "phase:1,deny,log"
SecDefaultAction "phase:2,deny,log"

#
# -- [[ Collaborative Detection Severity Levels ]] ----------------------------------------
#
# These are the default scoring points for each severity level.  You may
# adjust these to you liking.  These settings will be used in macro expansion
# in the rules to increment the anomaly scores when rules match.
#
# These are the default Severity ratings (with anomaly scores) of the individual rules -
#
#    - 2: Critical - Anomaly Score of 5.
#         Is the highest severity level possible without correlation.  It is
#         normally generated by the web attack rules (40 level files).
#    - 3: Error - Anomaly Score of 4.
#         Is generated mostly from outbound leakage rules (50 level files).
#    - 4: Warning - Anomaly Score of 3.
#         Is generated by malicious client rules (35 level files).
#    - 5: Notice - Anomaly Score of 2.
#         Is generated by the Protocol policy and anomaly files.
#
SecAction \
  "id:'900001', \
  phase:1, \
  t:none, \
  setvar:tx.critical_anomaly_score=5, \
  setvar:tx.error_anomaly_score=4, \
  setvar:tx.warning_anomaly_score=3, \
  setvar:tx.notice_anomaly_score=2, \
  nolog, \
  pass"

#
# -- [[ Collaborative Detection Scoring Initialization and Threshold Levels ]] ------------------------------
#
# These variables are used in macro expansion in the 49 inbound blocking and 59
# outbound blocking files.
#
# **MUST HAVE** ModSecurity v2.5.12 or higher to use macro expansion in numeric
# operators.  If you have an earlier version, edit the 49/59 files directly to
# set the appropriate anomaly score levels.
#
# You should set the score level (rule 900003) to the proper threshold you
# would prefer.  If set to "5" it will work similarly to previous Mod CRS rules
# and will create an event in the error_log file if there are any rules that
# match.  If you would like to lessen the number of events generated in the
# error_log file, you should increase the anomaly score threshold to something
# like "20".  This would only generate an event in the error_log file if there
# are multiple lower severity rule matches or if any 1 higher severity item matches.
#
SecAction \
  "id:'900002', \
  phase:1, \
  t:none, \
  setvar:tx.anomaly_score=0, \
  setvar:tx.sql_injection_score=0, \
  setvar:tx.xss_score=0, \
  setvar:tx.inbound_anomaly_score=0, \
  setvar:tx.outbound_anomaly_score=0, \
  nolog, \
  pass"

SecAction \
  "id:'900003', \
  phase:1, \
  t:none, \
  setvar:tx.inbound_anomaly_score_level=5, \
  setvar:tx.outbound_anomaly_score_level=4, \
  nolog, \
  pass"

#
# -- [[ Collaborative Detection Blocking ]] -----------------------------------------------
#
# This is a collaborative detection mode where each rule will increment an overall
# anomaly score for the transaction. The scores are then evaluated in the following files:
#
# Inbound anomaly score - checked in the modsecurity_crs_49_inbound_blocking.conf file
# Outbound anomaly score - checked in the modsecurity_crs_59_outbound_blocking.conf file
#
# If you want to use anomaly scoring mode, then uncomment this line.
#
#SecAction \
  "id:'900004', \
  phase:1, \
  t:none, \
  setvar:tx.anomaly_score_blocking=on, \
  nolog, \
  pass"

#
# -- [[ GeoIP Database ]] -----------------------------------------------------------------
#
# There are some rulesets that need to inspect the GEO data of the REMOTE_ADDR data.
#
# You must first download the MaxMind GeoIP Lite City DB -
#
#       http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
#
# You then need to define the proper path for the SecGeoLookupDb directive
#
# Ref: http://blog.spiderlabs.com/2010/10/detecting-malice-with-modsecurity-geolocation-data.html
# Ref: http://blog.spiderlabs.com/2010/11/detecting-malice-with-modsecurity-ip-forensics.html
#
#SecGeoLookupDb /opt/modsecurity/lib/GeoLiteCity.dat

#
# -- [[ Regression Testing Mode ]] --------------------------------------------------------
#
# If you are going to run the regression testing mode, you should uncomment the
# following rule. It will enable DetectionOnly mode for the SecRuleEngine and
# will enable Response Header tagging so that the client testing script can see
# which rule IDs have matched.
#
# You must specify the your source IP address where you will be running the tests
# from.
#
#SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" \
  "id:'900005', \
  phase:1, \
  t:none, \
  ctl:ruleEngine=DetectionOnly, \
  setvar:tx.regression_testing=1, \
  nolog, \
  pass"

#
# -- [[ HTTP Policy Settings ]] ----------------------------------------------------------
#
# Set the following policy settings here and they will be propagated to the 23 rules
# file (modsecurity_common_23_request_limits.conf) by using macro expansion.
# If you run into false positives, you can adjust the settings here.
#
# Only the max number of args is uncommented by default as there are a high rate
# of false positives.  Uncomment the items you wish to set.
#
#
# -- Maximum number of arguments in request limited
SecAction \
  "id:'900006', \
  phase:1, \
  t:none, \
  setvar:tx.max_num_args=255, \
  nolog, \
  pass"

#
# -- Limit argument name length
#SecAction \
  "id:'900007', \
  phase:1, \
  t:none, \
  setvar:tx.arg_name_length=100, \
  nolog, \
  pass"

#
# -- Limit value name length
#SecAction \
  "id:'900008', \
  phase:1, \
  t:none, \
  setvar:tx.arg_length=400, \
  nolog, \
  pass"

#
# -- Limit arguments total length
#SecAction \
  "id:'900009', \
  phase:1, \
  t:none, \
  setvar:tx.total_arg_length=64000, \
  nolog, \
  pass"

#
# -- Individual file size is limited
#SecAction \
  "id:'900010', \
  phase:1, \
  t:none, \
  setvar:tx.max_file_size=1048576, \
  nolog, \
  pass"

#
# -- Combined file size is limited
#SecAction \
  "id:'900011', \
  phase:1, \
  t:none, \
  setvar:tx.combined_file_sizes=1048576, \
  nolog, \
  pass"

#
# Set the following policy settings here and they will be propagated to the 30 rules
# file (modsecurity_crs_30_http_policy.conf) by using macro expansion.
# If you run into false positves, you can adjust the settings here.
#
SecAction \
  "id:'900012', \
  phase:1, \
  t:none, \
  setvar:'tx.allowed_methods=GET HEAD POST OPTIONS', \
  setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/x-amf|application/json', \
  setvar:'tx.allowed_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1', \
  setvar:'tx.restricted_extensions=.asa/ .asax/ .ascx/ .axd/ .backup/ .bak/ .bat/ .cdx/ .cer/ .cfg/ .cmd/ .com/ .config/ .conf/ .cs/ .csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .resources/ .resx/ .sql/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/', \
  setvar:'tx.restricted_headers=/Proxy-Connection/ /Lock-Token/ /Content-Range/ /Translate/ /via/ /if/', \
  nolog, \
  pass"

#
# -- [[ Content Security Policy (CSP) Settings ]] -----------------------------------------
#
# The purpose of these settings is to send CSP response headers to
# Mozilla FireFox users so that you can enforce how dynamic content
# is used. CSP usage helps to prevent XSS attacks against your users.
#
# Reference Link:
#
#       https://developer.mozilla.org/en/Security/CSP
#
# Uncomment this SecAction line if you want use CSP enforcement.
# You need to set the appropriate directives and settings for your site/domain and
# and activate the CSP file in the experimental_rules directory.
#
# Ref: http://blog.spiderlabs.com/2011/04/modsecurity-advanced-topic-of-the-week-integrating-content-security-policy-csp.html
#
#SecAction \
  "id:'900013', \
  phase:1, \
  t:none, \
  setvar:tx.csp_report_only=1, \
  setvar:tx.csp_report_uri=/csp_violation_report, \
  setenv:'csp_policy=allow \'self\'; img-src *.yoursite.com; media-src *.yoursite.com; style-src *.yoursite.com; frame-ancestors *.yoursite.com; script-src *.yoursite.com; report-uri %{tx.csp_report_uri}', \
  nolog, \
  pass"

#
# -- [[ Brute Force Protection ]] ---------------------------------------------------------
#
# If you are using the Brute Force Protection rule set, then uncomment the following
# lines and set the following variables:
# - Protected URLs: resources to protect (e.g. login pages) - set to your login page
# - Burst Time Slice Interval: time interval window to monitor for bursts
# - Request Threshold: request # threshold to trigger a burst
# - Block Period: temporary block timeout
#
#SecAction \
  "id:'900014', \
  phase:1, \
  t:none, \
  setvar:'tx.brute_force_protected_urls=#/login.jsp# #/partner_login.php#', \
  setvar:'tx.brute_force_burst_time_slice=60', \
  setvar:'tx.brute_force_counter_threshold=10', \
  setvar:'tx.brute_force_block_timeout=300', \
  nolog, \
  pass"

#
# -- [[ DoS Protection ]] ----------------------------------------------------------------
#
# If you are using the DoS Protection rule set, then uncomment the following
# lines and set the following variables:
# - Burst Time Slice Interval: time interval window to monitor for bursts
# - Request Threshold: request # threshold to trigger a burst
# - Block Period: temporary block timeout
#
#SecAction \
  "id:'900015', \
  phase:1, \
  t:none, \
  setvar:'tx.dos_burst_time_slice=60', \
  setvar:'tx.dos_counter_threshold=100', \
  setvar:'tx.dos_block_timeout=600', \
  nolog, \
  pass"

#
# -- [[ Check UTF enconding ]] -----------------------------------------------------------
#
# We only want to apply this check if UTF-8 encoding is actually used by the site, otherwise
# it will result in false positives.
#
# Uncomment this line if your site uses UTF8 encoding
#SecAction \
  "id:'900016', \
  phase:1, \
  t:none, \
  setvar:tx.crs_validate_utf8_encoding=1, \
  nolog, \
  pass"

#
# -- [[ Enable XML Body Parsing ]] -------------------------------------------------------
#
# The rules in this file will trigger the XML parser upon an XML request
#
# Initiate XML Processor in case of xml content-type
#
SecRule REQUEST_HEADERS:Content-Type "text/xml" \
  "id:'900017', \
  phase:1, \
  t:none,t:lowercase, \
  nolog, \
  pass, \
  chain"
        SecRule REQBODY_PROCESSOR "!@streq XML" \
          "ctl:requestBodyProcessor=XML"

#
# -- [[ Global and IP Collections ]] -----------------------------------------------------
#
# Create both Global and IP collections for rules to use
# There are some CRS rules that assume that these two collections
# have already been initiated.
#
SecRule REQUEST_HEADERS:User-Agent "^(.*)$" \
  "id:'900018', \
  phase:1, \
  t:none,t:sha1,t:hexEncode, \
  setvar:tx.ua_hash=%{matched_var}, \
  nolog, \
  pass"

SecRule REQUEST_HEADERS:x-forwarded-for "^\b(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\b" \
  "id:'900019', \
  phase:1, \
  t:none, \
  capture, \
  setvar:tx.real_ip=%{tx.1}, \
  nolog, \
  pass"

SecRule &TX:REAL_IP "!@eq 0" \
  "id:'900020', \
  phase:1, \
  t:none, \
  initcol:global=global, \
  initcol:ip=%{tx.real_ip}_%{tx.ua_hash}, \
  nolog, \
  pass"

SecRule &TX:REAL_IP "@eq 0" \
  "id:'900021', \
  phase:1, \
  t:none, \
  initcol:global=global, \
  initcol:ip=%{remote_addr}_%{tx.ua_hash}, \
  setvar:tx.real_ip=%{remote_addr}, \
  nolog, \
  pass"

#SecRule REMOTE_ADDR "@ipMatch 92.223.213.172,93.58.28.0/24,95.240.25.107,5.158.67.215,213.165.151.210,2.232.52.79" phase:1,nolog,allow,ctl:ruleEngine=Off

SecRule REMOTE_ADDR "@ipMatch MYIP/24" phase:2,id:'960015',nolog,allow,ctl:ruleEngine=Off

My "modsecurity_crs_21_protocol_anomalies.conf":

# ---------------------------------------------------------------
# Core ModSecurity Rule Set ver.2.2.9
# Copyright (C) 2006-2012 Trustwave All rights reserved.
#
# The OWASP ModSecurity Core Rule Set is distributed under
# Apache Software License (ASL) version 2
# Please see the enclosed LICENCE file for full details.
# ---------------------------------------------------------------

#
# Some common HTTP usage patterns are indicative of attacks but may also be used by non-browsers for legitimate uses.
#
# Do not accept requests without common headers.
# All normal web browsers include Host, User-Agent and Accept headers.
# Implies either an attacker or a legitimate automation client.
#

#
# Missing/Empty Host Header
#
# -=[ Rule Logic ]=-
# These rules will first check to see if a Host header is present.
# The second check is to see if a Host header exists but is empty.
#
SecMarker BEGIN_HOST_CHECK

        SecRule &REQUEST_HEADERS:Host "@eq 0" \
                "skipAfter:END_HOST_CHECK,phase:2,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,block,msg:'Request Missing a Host Header',id:'960008',tag:'OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_HOST',tag:'WASCTC/WASC-21',tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10',severity:'4',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER-%{matched_var_name}=%{matched_var}"
        SecRule REQUEST_HEADERS:Host "^$" \
                "phase:2,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,block,msg:'Empty Host Header',id:'960007',tag:'OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_HOST',severity:'4',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER-%{matched_var_name}=%{matched_var}"

SecMarker END_HOST_CHECK

#
# Missing/Empty Accept Header
#
# -=[ Rule Logic ]=-
# These rules will first check to see if an Accept header is present.
# The second check is to see if an Accept header exists but is empty.
#

SecMarker BEGIN_ACCEPT_CHECK

        SecRule REQUEST_METHOD "!^OPTIONS$" \
                "skipAfter:END_ACCEPT_CHECK,chain,phase:2,rev:'1',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,block,msg:'Request Missing an Accept Header',severity:'5',id:'960015',tag:'OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT',tag:'WASCTC/WASC-21',tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10'"
                SecRule &REQUEST_HEADERS:Accept "@eq 0" "t:none,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER-%{matched_var_name}=%{matched_var}"
        SecRule REQUEST_METHOD "!^OPTIONS$" \
                "chain,phase:2,rev:'1',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,block,msg:'Request Has an Empty Accept Header',severity:'5',id:'960021',tag:'OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT'"
                SecRule REQUEST_HEADERS:Accept "^$" "t:none,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER-%{matched_var_name}=%{matched_var}"

SecMarker END_ACCEPT_CHECK

#
# Missing/Empty User-Agent Header
#
# -=[ Rule Logic ]=-
# These rules will first check to see if a User-Agent header is present.
# The second check is to see if a User-Agent header exists but is empty.
#

SecMarker BEGIN_UA_CHECK

        SecRule &REQUEST_HEADERS:User-Agent "@eq 0" \
                "skipAfter:END_UA_CHECK,phase:2,rev:'1',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,block,msg:'Request Missing a User Agent Header',id:'960009',tag:'OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_UA',tag:'WASCTC/WASC-21',tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10',severity:'5',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER-%{matched_var_name}=%{matched_var}"
        SecRule REQUEST_HEADERS:User-Agent "^$" \
                "phase:2,t:none,block,msg:'Empty User Agent Header',id:'960006',rev:'1',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',tag:'OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_UA',severity:'5',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER-%{matched_var_name}=%{matched_var}"

SecMarker END_UA_CHECK

#
# Missing Content-Type Header with Request Body
#
# -=[ Rule Logic ]=-
# These rules will first check to see if a Content-Type header is missing.
# The second check is to see if a Content-Length header is present and is
# not empty or contains a 0.  If the Content-Length header contains other data
# than this means that there is a request body and the RFC states that there
# MUST be a Content-Type header so that the app knows how to parse the data.
#

SecRule &REQUEST_HEADERS:Content-Type "@eq 0" \
    "chain,phase:1,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,block,msg:'Request Containing Content, but Missing Content-Type header',id:'960904',severity:'5'"
        SecRule REQUEST_HEADERS:Content-Length "!^0$" "t:none,ctl:forceRequestBodyVariable=On,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER-%{matched_var_name}=%{matched_var}"

# Check that the host header is not an IP address
# This is not an HTTP RFC violation but it is indicative of automated client access.
# Many web-based worms propagate by scanning IP address blocks.
#
# -=[ Rule Logic ]=-
# This rule triggers if the Host header contains all digits (and possible port)
#
# -=[ References ]=-
# http://technet.microsoft.com/en-us/magazine/2005.01.hackerbasher.aspx
#

SecRule REQUEST_HEADERS:Host "^[\d.:]+$" "phase:2,rev:'2',ver:'OWASP_CRS/2.2.9',maturity:'9',accuracy:'9',t:none,block,msg:'Host header is a numeric IP address',logdata:'%{matched_var}',severity:'4',id:'960017',tag:'OWASP_CRS/PROTOCOL_VIOLATION/IP_HOST',tag:'WASCTC/WASC-21',tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10',tag:'http://technet.microsoft.com/en-us/magazine/2005.01.hackerbasher.aspx',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/POLICY/IP_HOST-%{matched_var_name}=%{matched_var}"

# Log a security event when the request is rejected by apache
#
# You must patch mod_unique_id for this to work correctly.  See the following
# mod-security-users mail-list post for the patch details -
# http://article.gmane.org/gmane.comp.apache.mod-security.user/5808
#
#SecRule RESPONSE_STATUS ^400$ "t:none,phase:5,chain,pass,msg:'Invalid request',id:'960913',severity:'4'"
#SecRule WEBSERVER_ERROR_LOG !ModSecurity "t:none,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.leakage_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-OWASP_CRS/LEAKAGE/ERRORS-%{matched_var_name}=%{matched_var}"

#
# Require Content-Length to be provided with every POST request in a HTTP/1.1 request.
#
# -=[ Rule Logic ]=-
# This chained rule checks if the request method is POST, if so, it checks that a Content-Length
# header is present in case a Transfer-Encoding header is missing.
#
# -=[ References ]=-
# http://httpwg.github.io/specs/rfc7230.html#header.content-length
#
SecRule REQUEST_METHOD "^POST$" \
  "msg:'HTTP/1.1 POST request missing Content-Length Header and missing Transfer-Encoding header.',\
  severity:'4',\
  id:'960013',\
  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_PROTOCOL "^HTTP/1\.1$" \
          "chain"
        SecRule &REQUEST_HEADERS:Transfer-Encoding "@eq 0" \
          "chain"
        SecRule &REQUEST_HEADERS:Content-Length "@eq 0" \
          "t:none,\
          setvar:'tx.msg=%{rule.msg}',\
          setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},\
          setvar:'tx.%{rule.id}-OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER-%{matched_var_name}=%{matched_var}'"

Maybe did I commit a mistake with the rule? _SecRule REMOTEADDR "@ipMatch MYIP/24" phase:2,id:'960015',nolog,allow,ctl:ruleEngine=Off

Thanks. Regards.