<IfModule mod_security2.c>
    # Default recommended configuration

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

    # -- Request body handling ---------------------------------------------------

    # Allow ModSecurity to access request bodies. If you don't, ModSecurity
    # won't be able to see any POST parameters, which opens a large security
    # hole for attackers to exploit.
    SecRequestBodyAccess On

    # Enable XML request body parser.
    # Initiate XML Processor in case of xml content-type
    SecRule REQUEST_HEADERS:Content-Type "text/xml" \
         "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"

    # Enable JSON request body parser.
    # Initiate JSON Processor in case of JSON content-type; change accordingly
    # if your application does not use 'application/json'
    SecRule REQUEST_HEADERS:Content-Type "application/json" \
        "id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"

    # Maximum request body size we will accept for buffering. If you support
    # file uploads then the value given on the first line has to be as large
    # as the largest file you are willing to accept. The second value refers
    # to the size of data, with files excluded. You want to keep that value as
    # low as practical.
    SecRequestBodyLimit 13107200
    SecRequestBodyNoFilesLimit 262144

    # Store up to 128 KB of request body data in memory. When the multipart
    # parser reaches this limit, it will start using your hard disk for
    # storage. That is slow, but unavoidable.
    SecRequestBodyInMemoryLimit 262144

    # What do do if the request body size is above our configured limit.
    # Keep in mind that this setting will automatically be set to ProcessPartial
    # when SecRuleEngine is set to DetectionOnly mode in order to minimize
    # disruptions when initially deploying ModSecurity.
    SecRequestBodyLimitAction Reject

    # Verify that we've correctly processed the request body.
    # As a rule of thumb, when failing to process a request body
    # you should reject the request (when deployed in blocking mode)
    # or log a high-severity alert (when deployed in detection-only mode).
    SecRule REQBODY_ERROR "!@eq 0" \
    "id:'200002', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"

    # By default be strict with what we accept in the multipart/form-data
    # request body. If the rule below proves to be too strict for your
    # environment consider changing it to detection-only. You are encouraged
    # _not_ to remove it altogether.
    SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
    "id:'200003',phase:2,t:none,log,deny,status:400,msg:'Multipart request body \
    failed strict validation: \
    PE %{REQBODY_PROCESSOR_ERROR}, \
    BQ %{MULTIPART_BOUNDARY_QUOTED}, \
    BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
    DB %{MULTIPART_DATA_BEFORE}, \
    DA %{MULTIPART_DATA_AFTER}, \
    HF %{MULTIPART_HEADER_FOLDING}, \
    LF %{MULTIPART_LF_LINE}, \
    SM %{MULTIPART_MISSING_SEMICOLON}, \
    IQ %{MULTIPART_INVALID_QUOTING}, \
    IP %{MULTIPART_INVALID_PART}, \
    IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
    FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"

    # Did we see anything that might be a boundary?
    SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
    "id:'200004',phase:2,t:none,log,deny,status:44,msg:'Multipart parser detected a possible unmatched boundary.'"

    # PCRE Tuning
    # We want to avoid a potential RegEx DoS condition
    SecPcreMatchLimit 100000
    SecPcreMatchLimitRecursion 100000

    # Some internal errors will set flags in TX and we will need to look for these.
    # All of these are prefixed with "MSC_".  The following flags currently exist:
    # MSC_PCRE_LIMITS_EXCEEDED
    SecRule TX:/^MSC_/ "!@streq 0" \
            "id:'200005',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"

    # -- Response body handling --------------------------------------------------

    # Allow ModSecurity to access response bodies. 
    # You should have this directive enabled in order to identify errors
    # and data leakage issues.
    # 
    # Do keep in mind that enabling this directive does increases both
    # memory consumption and response latency.
    SecResponseBodyAccess Off

    # Which response MIME types do you want to inspect? You should adjust the
    # configuration below to catch documents but avoid static files
    # (e.g., images and archives).
    # SecResponseBodyMimeType text/plain text/html text/xml

    # Buffer response bodies of up to 512 KB in length.
    # SecResponseBodyLimit 524288

    # What happens when we encounter a response body larger than the configured
    # limit? By default, we process what we have and let the rest through.
    # That's somewhat less secure, but does not break any legitimate pages.
    # SecResponseBodyLimitAction ProcessPartial

    # -- Filesystem configuration ------------------------------------------------

    # The location where ModSecurity stores temporary files (for example, when
    # it needs to handle a file upload that is larger than the configured limit).
    SecTmpDir /usr/local/nagiosxi/tmp

    # The location where ModSecurity will keep its persistent data.
    SecDataDir /usr/local/nagiosxi/tmp

    # -- Debug log configuration -------------------------------------------------

    # The default debug log configuration is to duplicate the error, warning
    # and notice messages from the error log.
    # SecDebugLog /var/log/httpd/modsec_debug.log
    # SecDebugLogLevel 0

    # -- Audit log configuration -------------------------------------------------

    # Log the transactions that are marked by a rule, as well as those that
    # trigger a server error (determined by a 5xx or 4xx, excluding 404,  
    # level response status codes).
    SecAuditEngine RelevantOnly
    SecAuditLogRelevantStatus "^(?:5|4(?!04))"

    # Log everything we know about a transaction.
    SecAuditLogParts ABIJHZ

    # Use a single file for logging. This is much easier to look at, but
    # assumes that you will use the audit log only ocassionally.
    SecAuditLogType Serial
    SecAuditLog /var/log/httpd/modsec_audit.log

    # -- Miscellaneous -----------------------------------------------------------

    # Use the most commonly used application/x-www-form-urlencoded parameter
    # separator. There's probably only one application somewhere that uses
    # something else so don't expect to change this value.
    SecArgumentSeparator &

    # Settle on version 0 (zero) cookies, as that is what most applications
    # use. Using an incorrect cookie version may open your installation to
    # evasion attacks (against the rules that examine named cookies).
    SecCookieFormat 0

    # Exceeding the limit will set the REQBODY_ERROR variable, and 
    # additional arguments beyond the limit will not be included. With JSON body processing,
    # there is an additional short-circuit to halt parsing once the limit is breached.
    # As with the enforcement of other issues that signal REQBODY_ERROR, a rule should be in
    # place to test this value, like rule 200002 in modsecurity.conf-recommended. 
    # Same as limit set in php.ini
    # SecArgumentsLimit 50000

    # Specify your Unicode Code Point.
    # This mapping is used by the t:urlDecodeUni transformation function
    # to properly map encoded data to your language. Properly setting
    # these directives helps to reduce false positives and negatives.
    # SecUnicodeMapFile unicode.mapping 20127

    # ModSecurity Core Rules Set and Local configuration
	IncludeOptional modsecurity.d/*.conf
	IncludeOptional modsecurity.d/coreruleset/crs-setup.conf
	IncludeOptional modsecurity.d/coreruleset/rules/*.conf

</IfModule>
