The Rule Language is implemented using 9 directives
規則語言如下：
SecAction Performs an unconditional action. This directive is essentially a rule that alwaysmatches.
SecDefaultAction Specifies the default action list, which will be used in the rules that follow.
SecMarker Creates a marker that can be used in conjunction with the skipAfter action. Amarker creates a rule that does nothing, but has an ID assigned to it.
SecRule Creates a rule.
SecRuleInheritance Controls whether rules are inherited in a child configuration context.
SecRuleRemoveById Removes the rule with the given ID.
SecRuleRemoveByMsg Removes the rule whose message matches the given regular expression.
SecRuleScript Creates a rule implemented using Lua.
SecRuleUpdateActionById Replaces the action list of the rule with the given ID with the supplied action
list.
規則格式：
Every rule defined by SecRule conforms to the same format, as below:
SecRule VARIABLES OPERATOR [TRANSFORMATION_FUNCTIONS, ACTIONS]
Variables
Identify parts of a HTTP transaction each rule works with. ModSecurity will extractinformation from every transaction and make it available, through variables, torules
to use. The important thing about variables to remember is that they are binarystrings, meaning they can contain special characters and bytes of any value. Yoursites may be restricting
themselves to using only text in parameters, but that does notmean your adversaries will. In fact, your adversaries will use whatever helps themachieve their goals. A rule must specify
one or more variables.
Operators
Specify how is a (transformed) variable to be analyzed. Regular expressions are themost popular choice, but ModSecurity supports many other operators, and you areeven
able to write your own. Only one operator is allowed per rule.
Transformation functions
A list of transformation functions that can be specified for every rule gives ModSecurityinstructions how each variable is to be changed before analysis can be done.Transformation
functions are commonly used to counter evasion, but they can alsobe used to uncover data that was
Variables
In ModSecurity, variables are used to identify the exact place you want to look at in a HTTP transaction. One of the main features of ModSecurity is the fact that it pre-process raw transaction data and makes it easy for the rules to focus on the logic of detection.
There are77 variables in the most recent version of ModSecurity; they are listed in Table 5.2, “Request variables”.
變量類型
Regular variables
正則變量
Contain only one piece of information, or one string. For example, REMOTE_ADDR, always contains the IP address of the client.
Collections
集合
Groups of regular variables. Some collections (e.g., ARGS) allow enumeration, making
it possible to use its every member in a rule. Some other collections (e.g., ENV) 68 Chapter 5: Rule Language Overview are not as flexible, but there is always going to be some way to extract individual regular variables out of them.
Read-only collections
只讀集合
Many of the collections point to some data that cannot be modified, in which case the collection itself will be available only for reading.
Read/write collections
讀寫集合
When a collection is not based on immutable data ModSecurity will allow you to modify it.A good example of a read/write collection is TX, which a collection that starts empty and exists only as long as the currently processed transaction
exists.
Special collections
特定集合
Sometimes a collection is just a handy mechanism to retrieve information from something that is not organised as a collection but it can seem that way. This is the case with the XML collection, which takes an XPath expression as a (mandatory) parameter and
allows you to extract values out of an XML file.
Persistent collections
持久化集合
Some collections can be stored and retrieved later. This feature allows you to adopt a
wider view of
Request variables
Request variables are those extracted from the request part of the transaction that is being inspected. The variables that describe the request line (request method, URI and protocolinformation) and the request headers become available as early as phase 1
and the complete information will be available for phase 2.
ARGS Request parameters (read-only collection)
ARGS_COMBINED_SIZE Total size of all request parameters combined 參數總大小
ARGS_NAMES Request parameters’ names (collection) 請求參數的名字
ARGS_GET Query string parameters (read-only collection) 查詢字符串
ARGS_GET_NAMES Query string parameters’ names (read-only collection) 查詢字符串名字
ARGS_POST Request body parameters (read-only collection) post參數
ARGS_POST_NAMES Request body parameters’ names (read-only collection) post參數名字
FILES File names (read-only collection)
FILES_COMBINED_SIZE Combined size of all uploaded files
FILES_NAMES File parameter names (read-only collection)
FILES_SIZES A list of file sizes (read-only collection)
FILES_TMPNAMES A list of temporary file names (read-only collection)
PATH_INFO Extra path information
QUERY_STRING Request query string 查詢字符串
REMOTE_USER Remote user
REQUEST_BASENAME Request URI basename
REQUEST_BODY Request body
REQUEST_COOKIES Request cookies (read-only collection) 請求cookie值
REQUEST_COOKIES_NAMES Request cookies’ names (read-only collection) 請求cookie名字
REQUEST_FILENAME Request URI filename/path
REQUEST_HEADERS Request headers (collection, read-only) 頭部值
REQUEST_HEADERS_NAMES Request headers’ names (read-only collection) 頭部名字
REQUEST_LINE Request line
REQUEST_METHOD Request method 請求方法
REQUEST_PROTOCOL Request protocol
REQUEST_URI Request URI, convert to exclude hostname 請求的url
REQUEST_URI_RAW Request URI, as it was presented in the request
Server variables
Server variables contain the pieces of information available to the server, most of them valid only for the transaction being processed at the moment they are evaluated
AUTH_TYPE Authentication type
REMOTE_ADDR Remote address
REMOTE_HOST Remote host
REMOTE_PORT Remote port
SCRIPT_BASENAME Script basename
SCRIPT_FILENAME Script filename/path
SCRIPT_GID Script group ID
SCRIPT_GROUPNAME Script group name
SCRIPT_MODE Script permissions
SCRIPT_UID Script user ID
SCRIPT_USERNAME Script user name
SERVER_ADDR Server address
SERVER_NAME Server name
SERVER_PORT Server port
Response variables
響應變量
Response variables are those extracted from the response part of the transaction that is being inspected. Most response variables will be available in phase 3. The arguably most important response variable, RESPONSE_BODY, is only available in phase
4 (the phase is also called
RESPONSE_BODY).
RESPONSE_BODY Response body 響應體
RESPONSE_CONTENT_LENGTH Response content length
RESPONSE_CONTENT_TYPE Response content type
RESPONSE_HEADERS Response headers (read-only collection)
RESPONSE_HEADERS_NAMES Response headers’ names (read-only collection)
RESPONSE_PROTOCOL Response protocol
RESPONSE_STATUS Response status code
Miscellaneous variables 其他變量
Miscellaneous variables are exactly what they are called: they are the variables that couldn’tfit in any other category.
HIGHEST_SEVERITY Highest severity encountered
MATCHED_VAR Contents of the last variable that matched
MATCHED_VAR_NAME Name of the last variable that match
MODSEC_BUILD ModSecurity build version (e.g., 02050102)
SESSIONID Session ID associated with current transaction
USERID User ID associated with current transaction
WEBAPPID Web application ID associated with current transaction
WEBSERVER_ERROR_LOG Error messages generated by Apache during current transaction
Parsing flags
Parsing flags are used by ModSecurity to signal important parsing events. The idea is toavoid taking implicit action (e.g., blocking in response to an invalid request), but allow the rules to decide what to do.
MULTIPART_BOUNDARY_QUOTED Multipart parsing error: quoted boundary encountered
MULTIPART_BOUNDARY_WHITESPACE Multipart parsing error: whitespace in boundary
MULTIPART_CRLF_LF_LINES Multipart parsing error: mixed line endings used
MULTIPART_DATA_BEFORE Multipart parsing error: seen data before first boundary
MULTIPART_DATA_AFTER Multipart parsing error: seen data after last boundary
MULTIPART_HEADER_FOLDING Multipart parsing error: header folding used
MULTIPART_LF_LINE Multipart parsing error: LF line ending detected
MULTIPART_SEMICOLON_MISSING Multipart parsing error: missing semicolon before boundary
MULTIPART_STRICT_ERROR At least one multipart error except MULTIPART_UNMATCHED_BOUNDARYoccurred
MULTIPART_UNMATCHED_BOUNDARY Multipart parsing error: unmatched boundary detected (prone to false positives)
REQBODY_PROCESSOR Request processor that handled request body
REQBODY_PROCESSOR_ERROR Request processor error flag (0 or 1)
REQBODY_PROCESSOR_ERROR_MSG Request processor error message
Collections
Collections are the special kind of variables that can contain other variables. With exception of the persistent collections, all collections are essentially one-offs, special variables that give access to the information to which ModSecurity has access.
ENV Environment variables (read-only collection, although it’s possible to use setvar
to change it)
GEO Geo lookup information from the last @geoLookup invocation (read-only collection)
GLOBAL Global information, shared by all processes (read/write collection)
IP IP address data storage (read/write collection)
TX Transient transaction data (read/write collection)
RULE Current rule metadata (read-only collection)
SESSION Session data storage (read/write collection)
USER User data storage (read/write collection)
XML XML DOM tree (read-only collection)
Time variables
Time variables all represent the moment in time when the transaction that ModSecurity is
processing began.
Table 5.8. Time variables
Variable Description
TIME Time (HH:MM:SS)
TIME_DAY Day of the month (1-31)
TIME_EPOCH Seconds since January 1, 1970 (e.g., 1251029017)
TIME_HOUR Hour of the day (0-23)
TIME_MIN Minute of the hour (0-59)
TIME_MON Month of the year (0-11)
TIME_SEC Second of the minute (0-59)
TIME_WDAY Week day (0-6)
TIME_YEAR Year
下文繼續