| @@ -0,0 +1,302 @@
+# ---------------------------------------------------------------
+# Core ModSecurity Rule Set ver.1.6.1
+# Copyright (C) 2006-2007 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 2621440
+
+
+# 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.
+#
+# 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,log,deny,status:403,t:lowercase,t:replaceNulls,t:compressWhitespace"
+
+# 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)"
+# For this directive to work, you need to set Apache ServerTokens
+# to Full (this is the default option)
+SecServerSignature Apache
+
+# Add ruleset identity to the logs
+#
+SecComponentSignature 201001071602
+
+## -- File uploads configuration -----------------------------------------------
+# Temporary file storage path.
+#
+# TODO Change the temporary folder setting to a path where only
+# the web server has access.
+#
+SecUploadDir /var/asl/data/suspicious
+
+# 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 Concurrent
+SecAuditLog /var/log/apache2/audit_log
+# SecAuditLogStorageDir /var/log/apache2/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
|
