1 # ---------------------------------------------------------------
2 # Core ModSecurity Rule Set ver.2.0.3
3 # Copyright (C) 2006-2009 Breach Security Inc. All rights reserved.
5 # The ModSecuirty Core Rule Set is distributed under GPL version 2
6 # Please see the enclosed LICENCE file for full details.
7 # ---------------------------------------------------------------
10 # The directives within this file can be included within
11 # Virtual Host containers.
13 # Configuration contained in this file should be customized
14 # for your specific requirements before deployment.
16 # Next to each rule there is a description of what it does. Each
17 # location where customization is needed is marked with "TODO". It
18 # is recommended that you:
20 # 1) Keep a copy of the original file. This will allow you to use
21 # the "diff" command to quickly see the changes. It will also
22 # make upgrades to future rule sets easier.
24 # 2) Document your changes thoroughly.
26 # You are advised to start with ModSecurity in detection mode only.
27 # Switch to protection when you are comfortable with your rule set.
28 # For maximum protection monitor your logs on daily basis (or
32 # TODO You may want to provide an error friendly message to your
33 # users when you start rejecting requests. You can do this using
34 # the Apache ErrorDocument directive. You should also add
35 # mod_unique_id to your configuration and display the unique
36 # request ID on the error page. This would allow your users to
37 # report the request ID back to you so that you can investigate
38 # the false positive (if that's what it is). A nice error page
39 # usually reduces the impact of false positives on the users.
41 # The drawback of this user friendly approach is that it is
42 # easier for the attackers to figure out there is an web
43 # application firewall protecting the application.
45 # ErrorDocument 403 /path/to/error_document.php
47 # For more information see
48 # http://httpd.apache.org/docs-2.0/custom-error.html
51 ## -- Configuration ----------------------------------------------------------
53 # Turn ModSecurity on ("On"), set to monitoring only
54 # ("DetectionOnly") or turn off ("Off").
58 # Define which part of the HTTP transaction to inspect.
60 # Inspecting request body (SecRequestBodyAccess) should probably be always set
61 # to "on". Only very high volume sites that never use POST requests might want
62 # to set it to "off" to optimize performance.
64 # Inspecting response body is useful for monitoring for information leaks,
65 # or for signs of intrusion. However, it does require all responses to be
66 # buffered in memory. For most sites this should not be a problem, but special
67 # care must be taken to avoid buffering file downloads (through
68 # MIME type selection, as shown below).
70 # TODO If you decide to enable output filtering make sure to
71 # review the list of scanned MIME types. If pages of the types specified
72 # for outbound inspection are smaller than 512K in you application
73 # (which is usually the case) you may reduce the SecResponseBodyLimit
74 # to protect from potential denial of service attacks.
76 SecRequestBodyAccess On
77 SecResponseBodyAccess On
78 SecResponseBodyMimeType (null) text/html text/plain text/xml
79 SecResponseBodyLimit 524288
81 # The following directive will not block large response bodies, but rather will
82 # only inspect data up to the size SecResponseBodyLimit setting.
83 SecResponseBodyLimitAction ProcessPartial
85 # Initiate XML Processor in case of xml content-type
87 # TODO Uncomment this rule if you wish to parse
88 # text/xml requests using the XML parser. Note
89 # that this may cause considerable overhead in processing
91 #SecRule REQUEST_HEADERS:Content-Type "text/xml" \
92 #"phase:1,pass,nolog,ctl:requestBodyProcessor=XML"
95 # What to do when an error is encountered.
97 # The default is to log the error and let the request go through.
98 # This is a reasonable setting to start with because you do not
99 # want to reject legitimate requests with an untuned rule set.
101 # The following line's settings will be inherited by rules that
102 # either do not specify an action at all, or if they use the
103 # "block" action. This will also allow the rules to use
104 # Anomaly Scoring (must use the
105 # modsecurity_crs_49_anomaly_scoring.conf file).
107 SecDefaultAction "phase:2,pass"
109 # If, after monitoring the performance of the rule set after a
110 # sufficient period, you determine the rules never (or rarely
111 # trigger on legitimate requests) you can change to something
112 # else, such as "log,deny,status:403". You can also leave the
113 # default setting here as is, but use per rule action configuration
114 # to only configure some rules to reject requests, leaving most
115 # of them to work in detection mode.
117 #SecDefaultAction "phase:2,deny"
119 ## -- File uploads configuration -----------------------------------------------
120 # Temporary file storage path.
122 # TODO Change the temporary folder setting to a path where only
123 # the web server has access.
127 # Whether or not to keep the stored files.
129 # In most cases you don't want to keep the uploaded files (especially
130 # when there is a lot of them). It may be useful to change the setting
131 # to "RelevantOnly", in which case the files uploaded in suspicious
132 # requests will be stored.
134 SecUploadKeepFiles Off
136 # Inspect uploaded files.
138 # TODO If there is a danger of attack through uploaded files then it
139 # is possible to configure an external script to inspect each file
140 # before it is seen by the application. An example script is
141 # included with ModSecurity (/util/modsec-clamscan.pl).
143 # Inspecting uploaded files is especially important in a hosting,
144 # community or blogging environments where uploading files is permitted.
146 # NOTE the t:none action is required in order not to process the files names
147 # passed to the script based on previously defined actions in a
148 # SecDefaultAction directive.
150 # SecRule FILES_TMPNAMES "@inspectFile /opt/apache/bin/inspect_script.pl" \
153 ## -- Logging ----------------------------------------------------------------
155 # Whether to log requests to the ModSecurity audit log.
157 # By default, only requests that trigger a ModSecurity events (as detected
158 # by) or a serer error are logged ("RelevantOnly"). This is a reasonable
159 # setting. Full logging can be set by using # "on". If the system is used
160 # for protection only and no logging is desired (not reccomended) logging can
161 # be turned of using "off"
163 # NOTE It is also possible to configure forensic logging on the
164 # per request basis using the "auditlog" and "noauditlog" rule
167 # TODO The default rule set logs requests that generate a 404 "file not found"
168 # response. These events are interesting, but may log a lot of information.
169 # you may consider removing it by setting SecAuditLogRelevantStatus
170 # to "^(?:5|4\d[^4])".
172 SecAuditEngine RelevantOnly
173 SecAuditLogRelevantStatus "^(?:5|4(?!04))"
175 # Log files structure
177 # You can select to log all events to a single log file (set SecAuditLogType to
178 # "Serial") or to log each request to a separate file (set it to "Concurrent").
179 # The former is usually easier to use, but if full logging is required or if
180 # the protected system supports a large transaction volume the later may
181 # be a better option.
183 # TODO Set the SecAuditLog (for "Serial" logging) or SecAuditLogStorageDir (for
184 # "Concurrent" logging).
186 # TODO If you change from "Serial" to "Concurrent" uncomment the
187 # SecAuditLogStorageDir directive and make sure the direcory specified
188 # exists and has write permissions for the Apache user.
190 SecAuditLogType Serial
191 SecAuditLog logs/modsec_audit.log
192 # SecAuditLogStorageDir logs/modsec_audit
194 # Select what portions of the request to log
196 # Modify the string by adding any of the letter below to it:
197 # A - audit log header (mandatory)
198 # B - request headers
199 # C - request body (present only if the request body exists and ModSecurity is
200 # configured to intercept it)
201 # E - intermediary response body (present only if ModSecurity is configured to
202 # intercept response bodies, and if the audit log engine is configured to
203 # record it). Intermediary response body is the same as the actual response
204 # body unless ModSecurity intercepts the intermediary response body, in
205 # which case the actual response body will contain the error message
206 # (either the Apache default error message, or the ErrorDocument page).
207 # F - final response headers (excluding the Date and Server headers, which are
208 # always added by Apache in the late stage of content delivery).
209 # H - audit log trailer
210 # I - This part is a replacement for part C. It will log the same data as C in
211 # all cases except when multipart/form-data encoding in used. In this case
212 # it will log a fake application/x-www-form-urlencoded body that contains
213 # the information about parameters but not about the files. This is handy
214 # if you don't want to have (often large) files stored in your audit logs.
215 # Z - final boundary, signifies the end of the entry (mandatory)
217 SecAuditLogParts "ABIFHKZ"
219 # Create a separate log to monitor performance.
221 # TODO Performance monitoring only works with Apache 2.x. You need
222 # to add mod_unique_id and mod_logio to your configuration. Then
223 # uncomment the following two lines.
225 # 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
226 # CustomLog logs/modsec_performance.log mperformance
228 # Custom application access log.
230 # TODO You should consider creating a custom access log. It could contain
231 # the performance metrics from above, but should also record the
232 # session ID for every request. That would make it possible to
233 # list all requests performed as part of a session.
235 # One custom log should be used per application but if you want
236 # multiple applications to share one log file make sure each
237 # line includes a unique application ID (unless the hostname is
238 # sufficient for differentiation).
240 ## -- Tuning and debugging
242 # This section include tuning and debugging directives that usually require no
243 # modifications unless
246 # Selects the cookie format that will be used in the current configuration
249 # Possible values are:
250 # 0 - use version 0 (Netscape) cookies. This is what most applications use.
251 # It is the default value.
252 # 1 - use version 1 cookies.
256 # Maximum size of the request body to keep in memory
258 # A higher value requires more server memory while a lower number would slow
259 # the server due to additional disk access. By default the limit is 128 KB:
260 SecRequestBodyInMemoryLimit 131072
263 # Whether to send ModSecurity messages to a separate debug log.
265 # Debug messages are very useful for, well, debugging. The default
266 # setting here copies (they always appear in the Apache error log)
267 # only the most important messages (errors and warnings).
269 # NOTE Debug logging is generally very slow. You should never
270 # use values greater than "3" in production.
272 SecDebugLog logs/modsec_debug.log
275 # Configures the directory where temporary files will be created.