# ---------------------------------------------------------------
# Core ModSecurity Rule Set ver.2.0.2
# Copyright (C) 2006-2009 Breach Security Inc. All rights reserved.
#
# The ModSecuirty Core Rule Set is distributed under GPL version 2
# Please see the enclosed LICENCE file for full details.
# ---------------------------------------------------------------


# The directives within this file can be included within
# Virtual Host containers.
#
# Configuration contained in this file should be customized
# for your specific requirements before deployment.
#
# Next to each rule there is a description of what it does. Each
# location where customization is needed is marked with "TODO". It
# is recommended that you:
#
#  1) Keep a copy of the original file. This will allow you to use
#     the "diff" command to quickly see the changes. It will also
#     make upgrades to future rule sets easier.
#
#  2) Document your changes thoroughly.
#
# You are advised to start with ModSecurity in detection mode only.
# Switch to protection when you are comfortable with your rule set.
# For maximum protection monitor your logs on daily basis (or
# better).
#

# TODO You may want to provide an error friendly message to your
#      users when you start rejecting requests. You can do this using
#      the Apache ErrorDocument directive. You should also add
#      mod_unique_id to your configuration and display the unique
#      request ID on the error page. This would allow your users to
#      report the request ID back to you so that you can investigate
#      the false positive (if that's what it is). A nice error page
#      usually reduces the impact of false positives on the users.
#
#      The drawback of this user friendly approach is that it is
#      easier for the attackers to figure out there is an web
#      application firewall protecting the application.
#
#      ErrorDocument 403 /path/to/error_document.php
#
#      For more information see 
#      http://httpd.apache.org/docs-2.0/custom-error.html


## -- Configuration ----------------------------------------------------------

# Turn ModSecurity on ("On"), set to monitoring only 
# ("DetectionOnly") or turn off ("Off").
#
SecRuleEngine On

# Define which part of the HTTP transaction to inspect.
#
# Inspecting request body (SecRequestBodyAccess) should probably be always set
# to "on". Only very high volume sites that never use POST requests might want 
# to set it to "off" to optimize performance.
#
# Inspecting response body is useful for monitoring for information leaks, 
# or for signs of intrusion. However, it does require all responses to be 
# buffered in memory. For most sites this should not be a problem, but special
# care must be taken to avoid buffering file downloads (through
# MIME type selection, as shown below).
#
# TODO If you decide to enable output filtering make sure to
#      review the list of scanned MIME types. If pages of the types specified 
#      for outbound inspection are smaller than 512K in you application
#      (which is usually the case) you may reduce the SecResponseBodyLimit 
#      to protect from potential denial of service attacks.
#
SecRequestBodyAccess On
SecResponseBodyAccess On
SecResponseBodyMimeType (null) text/html text/plain text/xml
SecResponseBodyLimit 524288

# The following directive will not block large response bodies, but rather will
# only inspect data up to the size SecResponseBodyLimit setting.
SecResponseBodyLimitAction ProcessPartial

# Initiate XML Processor in case of xml content-type
#
# TODO Uncomment this rule if you wish to parse
#      text/xml requests using the XML parser.  Note 
#      that this may cause considerable overhead in processing 
#      text/xml requests.
#SecRule REQUEST_HEADERS:Content-Type "text/xml" \
#"phase:1,pass,nolog,ctl:requestBodyProcessor=XML"


# What to do when an error is encountered.
#
# The default is to log the error and let the request go through.
# This is a reasonable setting to start with because you do not
# want to reject legitimate requests with an untuned rule set.
#
# The following line's settings will be inherited by rules that
# either do not specify an action at all, or if they use the 
# "block" action. This will also allow the rules to use 
# Anomaly Scoring (must use the
# modsecurity_crs_49_anomaly_scoring.conf file).
#
SecDefaultAction "phase:2,pass"

# If, after monitoring the performance of the rule set after a
# sufficient period, you determine the rules never (or rarely
# trigger on legitimate requests) you can change to something
# else, such as "log,deny,status:403". You can also leave the
# default setting here as is, but use per rule action configuration
# to only configure some rules to reject requests, leaving most
# of them to work in detection mode.
#
#SecDefaultAction "phase:2,deny"

## -- File uploads configuration -----------------------------------------------
# Temporary file storage path.
#
# TODO Change the temporary folder setting to a path where only
#      the web server has access.
#
SecUploadDir /tmp

# Whether or not to keep the stored files.
#
# In most cases you don't want to keep the uploaded files (especially
# when there is a lot of them). It may be useful to change the setting
# to "RelevantOnly", in which case the files uploaded in suspicious
# requests will be stored.
#
SecUploadKeepFiles Off

# Inspect uploaded files.
#
# TODO If there is a danger of attack through uploaded files then it
#      is possible to configure an external script to inspect each file
#      before it is seen by the application. An example script is
#      included with ModSecurity (/util/modsec-clamscan.pl).
#
#      Inspecting uploaded files is especially important in a hosting,  
#      community or blogging environments where uploading files is permitted. 
#
# NOTE the t:none action is required in order not to process the files names 
#      passed to the script based on previously defined actions in a 
#      SecDefaultAction directive.
#
# SecRule FILES_TMPNAMES "@inspectFile /opt/apache/bin/inspect_script.pl" \
#       "t:none"

## -- Logging ----------------------------------------------------------------

# Whether to log requests to the ModSecurity audit log.
#
# By default, only requests that trigger a ModSecurity events (as detected 
# by) or a serer error are logged ("RelevantOnly"). This is a reasonable 
# setting. Full logging can be set by using # "on". If the system is used 
# for protection only and no logging is desired (not reccomended) logging can 
# be turned of using "off"
#
# NOTE It is also possible to configure forensic logging on the
#      per request basis using the "auditlog" and "noauditlog" rule
#      actions.
#
# TODO The default rule set logs requests that generate a 404 "file not found"
#      response. These events are interesting, but may log a lot of information.
#      you may consider removing it by setting SecAuditLogRelevantStatus
#      to "^(?:5|4\d[^4])".
#
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

# Log files structure
#
# You can select to log all events to a single log file (set SecAuditLogType to 
# "Serial") or to log each request to a separate file (set it to "Concurrent"). 
# The former is usually easier to use, but if full logging is required or if 
# the protected system supports a large transaction volume the later may
# be a better option.
#
# TODO Set the SecAuditLog (for "Serial" logging) or SecAuditLogStorageDir (for
#      "Concurrent" logging).
#
# TODO If you change from "Serial" to "Concurrent" uncomment the 
#      SecAuditLogStorageDir directive and make sure the direcory specified 
#      exists and has write permissions for the Apache user. 

SecAuditLogType Serial
SecAuditLog logs/modsec_audit.log
# SecAuditLogStorageDir logs/modsec_audit

# Select what portions of the request to log
#
# Modify the string by adding any of the letter below to it:
# A - audit log header (mandatory)
# B - request headers
# C - request body (present only if the request body exists and ModSecurity is 
#     configured to intercept it)
# E - intermediary response body (present only if ModSecurity is configured to 
#     intercept response bodies, and if the audit log engine is configured to 
#     record it). Intermediary response body is the same as the actual response 
#     body unless ModSecurity intercepts the intermediary response body, in 
#     which case the actual response body will contain the error message 
#     (either the Apache default error message, or the ErrorDocument page).
# F - final response headers (excluding the Date and Server headers, which are 
#     always added by Apache in the late stage of content delivery).
# H - audit log trailer
# I - This part is a replacement for part C. It will log the same data as C in 
#     all cases except when multipart/form-data encoding in used. In this case 
#     it will log a fake application/x-www-form-urlencoded body that contains 
#     the information about parameters but not about the files. This is handy 
#     if you don't want to have (often large) files stored in your audit logs.
# Z - final boundary, signifies the end of the entry (mandatory)

SecAuditLogParts "ABIFHKZ"

# Create a separate log to monitor performance.
#
# TODO Performance monitoring only works with Apache 2.x. You need
#      to add mod_unique_id and mod_logio to your configuration. Then
#      uncomment the following two lines.
#
# LogFormat "%V %h %t %{UNIQUE_ID}e \"%r\" %>s %X | %I %O | %<{mod_security-time1}n %<{mod_security-time2}n %<{mod_security-time3}n %D" mperformance
# CustomLog logs/modsec_performance.log mperformance

# Custom application access log.
#
# TODO You should consider creating a custom access log. It could contain
#      the performance metrics from above, but should also record the
#      session ID for every request. That would make it possible to
#      list all requests performed as part of a session.
#
#      One custom log should be used per application but if you want
#      multiple applications to share one log file make sure each
#      line includes a unique application ID (unless the hostname is
#      sufficient for differentiation).

## -- Tuning and debugging

# This section include tuning and debugging directives that usually require no
# modifications unless 

 
# Selects the cookie format that will be used in the current configuration 
# context. 
#
# Possible values are:
# 0 - use version 0 (Netscape) cookies. This is what most applications use. 
#     It is the default value.
# 1 - use version 1 cookies.

SecCookieFormat 0

# Maximum size of the request body to keep in memory
# 
# A higher value requires more server memory while a lower number would slow
# the server due to additional disk access. By default the limit is 128 KB:
SecRequestBodyInMemoryLimit 131072


# Whether to send ModSecurity messages to a separate debug log.
#
# Debug messages are very useful for, well, debugging. The default
# setting here copies (they always appear in the Apache error log)
# only the most important messages (errors and warnings).
#
# NOTE Debug logging is generally very slow. You should never
#      use values greater than "3" in production.
#
SecDebugLog             logs/modsec_debug.log
SecDebugLogLevel        3

# Configures the directory where temporary files will be created.
SecTmpDir /tmp