Unconditional rules
無條件規則
The actions you specify in a SecRule execute when a match occurs, but you can use the SecAction directive to do something unconditionally. This directive accepts only one parameter, identical the third parameter of SecRule, and it’s a list of actions you want to be executed:
SecAction nolog,pass,setvar:tx.counter=10The SecAction directive is useful in the following cases:
• To initialize one or more variables before the rules that use them are processed
• To initialize a persistent collection, most often using a client’s IP address
• In combination with skip, to implement an if-then-else construct
Using transformation functions
使用轉換函數
You already know that rules typically work by taking some data, determined by a variable name, and applying an operator to it. But direct matching like that only happens in the simplest case. In a general case, the data processed by a rule will be
transformed by one or more transformation functions before it is fed to an operator. The transformation functions are often referred to as a transformation pipeline. As an example, take the following rule, which transforms input by converting all characters into
lowercase, then compressing multiple consecutive whitespace characters:
作爲一個例子，採取下面的規則，轉換所有字符轉換輸入爲小寫，然後壓縮多個連續的空格字符：
SecRule ARGS "@contains delete from" \
phase:2,t:lowercase,t:compressWhitespace,block
然後會匹配到如下的信息
As a result, the rule will match all the following forms of input:
delete from
DELETE FROM
deLeTe fRoM
Delete From
DELETE\tFROM -- \t represents a TAB character
Note
It is a good practice to always begin the list of transformation functions witht:none, which clears the transformation pipeline to start from scratch. If you don’t do that then you, as a rule writer, can never be completely sure that your user didn’t specify
a transformation function in his SecDefaultAction directive (on purpose or by mistake), in which case your rule will probably malfunction. Using t:none ensures your rule always uses the correct set of transformation functions.
提示：一個好的做法是在開始加上 t:none， 這樣做能保證你的規則進行正確的轉換
There are several reasons why you might want to do apply operators to something else thanthe original variable values:
• Your input is not available in a form that is useful to you. For example, it might be base64-encoded, in which case you won’t be able to do anything useful with it. By applying the transformation function that decodes base64 data (t:base64Decode), you “open”
up the data for inspection.
• Similarly, you may need a piece of data in some other form. If you have some binary data, which you need to record in a user-friendly manner, you will probably encode it as hex characters using t:hexEncode.
• Sometimes rules are difficult or impossible to write to deal with input in its original form. Take, for example, case sensitivity. Most ModSecurity operators are case sensitive,but there are many cases where case does not matter. If you attempt to matcha
non-trivial string using a case sensitive matching function, you will soon discover that you will either need to write a number or rules (each with a different combination of lowercase and uppercase letters) or a rule with a very ugly and difficult to decipher regular
expression. You deal with this particular problem by transforming input into lowercase before matching.
• In the majority of cases, however, you will use transformation functions to counter evasion. Evasion is a technique often used by attackers to bypass existing detection and protection mechanism. They will take advantage of the specific context in which attack
payload data is processed to modify it in such a way to evade detection, but remain
effective.
Adding meta data
附加元數據
While some rules are simple and do not require much thought to understand them, many aren’t. Also, even when the rule itself is simple, that does not meant that it will be easy to understand what it does and why it does it. ModSecurity will generally
try to add as much meta data to alerts as possible. Consider the following rule, which gets the job done:
SecRule REQUEST_METHOD "!^(GET|HEAD)$" \
phase:1,t:none,log,block
It restricts request methods to either GET or HEAD, which is suitable only for a static web site.
The rule will, on a match, produce the following alert:
[Thu Dec 03 20:02:50 2009] [error] [client 127.0.0.1] ModSecurity: …
Warning. Match of "rx ^(GET|HEAD)$" against "REQUEST_METHOD" required.…
[file "/home/ivanr/apache/conf/httpd.conf"] [line "464"]…
[hostname "192.168.3.100"] [uri "/"] [unique_id "SxgbacCoA2QAABC7HMgAAAAB"]
Alert messages contain quite a lot of information by default, but they do not provide enough. For example, the default message generated by ModSecurity gives you some idea about what the rule looks like, but it doesn’t tell you what the rule writer wanted to
accomplish. This is where meta data actions come into play. They are primarily used to document rules and make them easier to handle. Here is the same rule as above, but with additional meta data:
SecRule REQUEST_METHOD "!^(GET|HEAD)$" \
"phase:1,t:none,log,block,id:1001,rev:2,\
severity:WARNING,msg:'Request method is not allowed'"
I have added four meta data actions:
• The id action assigns a unique identifier to the rule, making it possible to match an alert to the rule that caused it. The addition of the ID also makes it possible for the rule to be manipulated, either at configuration-time or at run-time. The IDs are
very important because they allow rule sets to be customised while leaving the originalconfiguration files intact (for example, using the SecRuleUpdateById and SecRuleRemoveById directives), which, in turn, allows for the automated upgrades of rule sets.
• The rev action (short for revision) is essentially a change counter, or a serial number: it starts at one and increments by one every time a rule changes. The idea is to make it possible to determine, at a glance, if a rule changed and, even better, to make it
possible for a program (who wouldn’t be able to understand the differences between two rule versions anyway) to do that.
• The severity action tells you how serious a detected problem is. ModSecurity adopted the syslog system of severities, which are listed in Table 14.1, “Severity values”. The least serious severity is DEBUG (7) and the most serious one is EMERGENCY (1). That aside,
there are no clear guidelines how to assign severities to rules, leaving each author
常見的 Severity有：
0 EMERGENCY
1 ALERT
2 CRITICAL
3 ERROR
4 WARNING
5 NOTICE
6 INFO
7 DEBUG
to adopt his or her own system.
• Finally, the msg action adds another message to the rule, which should explain the goal of a rule, or its result.