# ---------------------------------------------------------------
# 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 ----------------------------------------------------------

# 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 Off
SecResponseBodyAccess Off
SecResponseBodyMimeType (null) text/plain text/xml
#caselli
SecRequestBodyAccess Off
# cioni
SecResponseBodyLimit 134217728
#caselli
SecRequestBodyLimit 134217720
SecRequestBodyNoFilesLimit 1342178

# Initiate XML Processor in case of xml content-type
#
# TODO Remove this rule if you don't wish to parse XML request
#      Note that this will disable XML protection
SecRule REQUEST_HEADERS:Content-Type "text/xml" \
"phase:1,pass,nolog,ctl:requestBodyProcessor=XML,id:'1'"


# 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.21 (CentOS)"

## -- 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 /web/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 6553600


# 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             /web/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

# Loades the variable collection relating to the requested resource
# NOTE: We will not initiate a collection if there was an error (To prevent overloading)
SecRule RESPONSE_STATUS "!^(?:30[12]|[45]\d\d)$" "phase:3,pass,nolog,initcol:resource=%{REQUEST_FILENAME},id:'2'"



#
## 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_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1', \
  nolog, \
  pass"