 |  |
| |
Unconditionally processes the action list it receives as the first
and only parameter. It accepts one parameter, the syntax of which is
identical to the third parameter of SecRule.
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 (;).
Configures the audit logging engine. Possible values are:
On - log all transactions by
default.
Off - do not log transactions by
default.
RelevantOnly - by default only log
transactions that have triggered a warning or an error, or have a
status code that is considered to be relevant (see
SecAuditLogRelevantStatus).
Path to the main audit logging file. This file will be used to store the audit log entries if serial audit logging format is used. If concurrent audit logging format is used this file will be used as an index, and contain a record of all audit log files created.
This file is open on startup when the server typically still runs as root. You should not allow non-root users to have write privileges for this file or for the directory it is stored in.
Default ABCFHZ.
Available audit log parts:
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)
D - RESERVED for intermediary response
headers, not implemented yet.
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).
G – RESERVED for the actual response body,
not implemented yet.
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.
J - RESERVED. This part, when implemented,
will contain information about the files uploaded using
multipart/form-data encoding.
Z – final boundary, signifies the end of
the entry (mandatory)
At this time ModSecurity does not log response bodies of stock
Apache responses (e.g. 404), or the
Server and Date response
headers.
Configures which response status code is to be considered relevant for the purpose of audit logging. The parameter is a regular expression.
Configures the storage directory where concurrent audit log entries are to be stored. It must be writable by the web server user as new files are generated at runtime.
Possible values are:
Serial - all audit log entries will be
stored in the main audit logging file. This is more convenient for
casual use but it is slower as only one audit log entry can be
written to the file at any one file.
Concurrent - audit log entries will be
stored in a file each.
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.
Path where persistent data (e.g. IP address data, session data, etc) is to be stored. Must be writable by the web server user.
Possible values are:
0 - no logging.
1 - errors (intercepted requests)
only.
2 - warnings.
3 - notices.
4 - details of how transactions are
handled.
5 - as above, but including information
about each piece of information handled.
9 - log everything, including very detailed
debugging information.
Levels 1-3 are always sent
to the Apache error log. Therefore you can always use level
0 as the default logging level in production. Level
5 is useful when debugging. It is not advisable to
use higher logging levels in production as excessive logging can slow
down server significantly.
Defines the default action to take on a rule match. The default value is:
SecDefaultAction log,auditlog,deny,status:403,phase:2,\
t:lowercase,t:replaceNulls,t:compressWhitespaceIntegration hook for httpd-guardian (see http://www.apachesecurity.net/tools/).
For example:
SecGuardianLog |/path/to/httpd-guardian
Configures whether request bodies will be buffered and processed by ModSecurity by default. Possible values are:
On - access request bodies.
Off - do not attempt to access request
bodies.
Configures the maximum request body size ModSecurity will accept for buffering. Anything over this limit will be rejected with status code 413 Request Entity Too Large.
Configures the maximum request body size ModSecurity will store in memory. By default the limit is 128 KB:
# Store up to 128 KB in memory SecRequestBodyInMemoryLimit 131072
Configures the maximum response body size that will be accepted for buffering. Anything over this limit will be rejected with status code 500 Internal Server Error. This setting will not affect the responses with MIME types that are not marked for buffering. By default this limit is configured to 512 KB:
# Buffer response bodies of up to 512 KB in length SecResponseBodyLimit 524288
There is a hard limit of 1 GB.
Configures which MIME types are to be
considered for response body buffering. The default value is
text/plain text/html:
SecResponseBodyMimeType text/plain text/html
Multiple SecResponseBodyMimeType directives can
be used to add MIME types.
Clears the list of MIME types considered for
response body buffering, allowing you to start populating the list from
scratch.
Configures whether response bodies are to be buffer and analysed or not. Possible values are:
On - access response bodies (but only if
the MIME type matches, see above).
Off - do not attempt to access response
bodies.
SecRule is the main ModSecurity directive. It
is used to analyse data and perform actions based on the results. In
general, the format of this rule is as follows:
SecRule VARIABLES OPERATOR [ACTIONS]
The second part, OPERATOR, specifies how they
are going to be checked. The third (optional) part,
ACTIONS, specifies what to do whenever the operator
used performs a successful match against a variable.
The first part, VARIABLES, specifies which
variables are to be checked. For example, the following rule will
reject a transaction that has the word dirty in
the URI:
SecRule REQUEST_URI dirty
Each rule can specify one or more variables:
SecRule REQUEST_URI|QUERY_STRING dirty
So far we have used only simple variables in our rules. Some variables are actually collections, which are expanded into more variables at runtime. The following example will examine all request arguments:
SecRule ARGS dirty
Sometimes, however, you will want to look only at parts of a
collection. This can be achieved with the help of the
selection operator (colon). The following example
will only look at the arguments named p (do note
that, in general, requests can contain multiple arguments with the
same name):
SecRule ARGS:p dirty
It is also possible to specify exclusions. The following will
examine all request arguments for the word dirty,
except the ones named z (again, there can be zero
or more arguments named z):
SecRule ARGS|!ARGS:z dirty
There is a special operator that allows you to count how many variables there are in a collection. The following rule will trigger if there is more than zero arguments in the request (ignore the second parameter for the time being):
SecRule &ARGS !^0$
And sometimes you need to look at an array of parameters, each
with a slightly different name. In this case you can specify a regular
expression in the selection operator itself. The following rule will
look into all arguments whose names begin with
id_:
SecRule ARGS:/^id_/ dirty
There is a third format supported by the selection operator - XPath expression. XPath expressions can only used against the special variable XML, which is available only of the request body was processed as XML.
SecRule XML:/xPath/Expression dirty
As you have just seen, not all collections support all selection operator format types. You should refer to the documentation of each collection to determine what is and isn't supported.
In the simplest possible case you will use a regular expression
pattern as the second rule parameter. This is what we've done in the
examples above. If you do this ModSecurity assumes you want to use the
rx operator. You can explicitly specify the
operator you want to use by using @ as the first
character in the second rule parameter:
SecRule REQUEST_URI "@rx dirty"
Note how we had to use double quotes to delimit the second rule parameter. This is because the second parameter now has a whitespace in it. Any number of whitespace characters can follow the name of the operator. If there are any non-whitespace characters there, they will all be treated as a special parameter to the operator. In the case of the regular expression operator the special parameter is the pattern that will be used for comparison.
The @ can be the second character if you are using negation to negate the result returned by the operator:
SecRule &ARGS "!@rx ^0$"
The third parameter, ACTIONS, can be omitted
only because there is a helper feature that specifies the default
action list. If the parameter isn't omitted the actions specified in
the parameter will be merged with the default action list to create
the actual list of actions that will be processed on a rule
match.
Configures whether the current context will inherit rules from the parent context (configuration options are inherited in most cases - you should look up the documentation for every directive to determine if it is inherited or not). Possible values are:
On - inherit rules from the parent
context.
Off - do not inherit rules from the parent
context.
Resource-specific contexts (e.g. Location,
Directory, etc) cannot override phase
1 rules configured in the main server or in the virtual
server. This is because phase 1 is run early in the request processing
process, before Apache maps request to resource. Virtual host context
can override phase 1 rules configured in the main server.
Configures whether or not the ModSecurity Rule Engine will process transactions or not. Possible values are:
On - process rules.
Off - do not process rules.
DetectionOnly - process rules but never
intercept transactions, even when rules are configured to do
so.
Removes matching rules from the parent contexts. This directive supports multiple parameters, where each parameter can either be a rule ID, or a range. Parameters that contain spaces must be delimited using double quotes.
SecRuleRemoveById 1 2 5 10-20 "400 - 556" 673
Removes matching rules from the parent contexts. This directive
supports multiple parameters. Each parameter is a regular expression
that will be applied to the message (specified using the
msg action).
Instructs ModSecurity to change web server signature.
SecServerSignature MyServer/1.0
Configures the directory where intercepted files will be stored.
This directory must be on the same filesystem as the temporary directory
defined with SecTmpDir.
Configures whether or not the intercepted files will be kept after transaction is processed. Possible values are:
On -
Off -
RelevantOnly -
This directive requires the storage directory to be defined (using
SecUploadDir).
Creates a partition on the server that belongs to one web
application. Partitions are used to avoid collisions between session IDs
and user IDs. This directive must be used if there are multiple
applications deployed on the same server. If it isn't a collision
between session IDs might occur. The default value is
default.
SecWebAppId "Intranet"