Branched 2.1.0-rc7

rules/modsecurity_crs_10_config.conf

@@ -0,0 +1,285 @@
+# ---------------------------------------------------------------
+# Core ModSecurity Rule Set
+# Copyright (C) 2006 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.
+# ---------------------------------------------------------------
+
+
+# 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
+
+
+# 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.
+#
+# 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:500". 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,log,pass,status:500"
+
+# Set web server identification string
+#
+# TODO In case you use Apache, you may want specify a simple server signature
+#      instead of the detailed Apache default signature that list most modules
+#      used on the specific Apache deployment:
+#      "Apache/2.2.0 (Fedora)"   
+#
+SecServerSignature "Apache/2.2.0 (Fedora)"
+
+## -- 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 forensic 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 "^[45]"
+
+# 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 "ABIFHZ"
+
+# 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 
+
+ 
+# Parameters separator
+#
+# Specifies which character to use as separator for 
+# application/x-www-form-urlencoded content. 
+# Defaults to "&". Applications are sometimes (very rarely) written to use 
+# a semicolon (";").
+#
+# NOTE Changing the value for this directive has significant influence on how
+#      ModSecurity works. Make the change only if you are absolutely sure it
+#      is required.
+SecArgumentSeparator "&" 
+
+
+# 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
+
+# Path where persistent data (e.g. IP address data, session data, etc) is to
+# be stored. Must be writable by the web server user.
+#
+# TODO It is advisable to create a directory structure for ModSecurity such as
+#      /var/log/msa and create sub directories for SecDataDir, SecTmpDir,
+#      SecUploadDir, SecAuditLog and SecAuditLogStorageDir
+#      underneath it and set the permission for read and write only by the
+#      Apache user.
+
+SecDataDir /tmp
+
+# Configures the directory where temporary files will be created.
+SecTmpDir /tmp