modsecurity系列四：规则实战2

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=10
The 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.