modsecurity系列五：白名单

Whitelisting mechanics

Whitelisting rules need to be executed before all your other detection rules, which means they should always follow your configuration and system rules. It is a good idea to have a special file for this category of rule alone. That will make them easy to find, after a simple glance at the list of your configuration files. Most whitelisting rules will look at the remote address first, so let’s do just that. Let’s assume that there is a trusted employee to whom you want to give unrestricted access to your web site. The IP address of his workstation is 192.168.1.1. The whitelisting rule is as follows:
SecRule REMOTE_ADDR "@streq 192.168.1.1" \
phase:1,t:none,nolog,allow
Because you only need to work with one IP address you use the @streq operator. Upon detecting a request from the employee’s IP address, the allow action will interrupt the operation of the rule engine, skipping all phases except phase 5. ModSecurity does not have an operator designed specifically to work with IP addresses, so you’ll need to be creative if you are given several IP addresses to whitelist. Suppose you are given three IP addresses. You could write three seperate rules, but that is not only inelegant,but inefficient too. In most such cases, the @rx operator will do the job. For example:
SecRule REMOTE_ADDR "@rx ^192\.168\.1\.(1|5|10)$" \
phase:1,t:none,nolog,allow

The above example whitelists three IP addresses: 192.168.1.1, 192.168.1.5 and 192.168.1.10. As previously discussed, you should avoid using the allow action whenever you can. It is recommended to swith the rule engine to detection-only instead:
SecRule REMOTE_ADDR "@streq 192.168.1.1" \
phase:1,t:none,nolog,pass,ctl:ruleEngine=DetectionOnly

In the above rule, I replaced allow with pass (which won’t do anything else but move to the next rule once the current rule is done), and added an invocation of the ctl action with the instruction to change the operating mode of the rule engine. If you want to take my advice and require some form of authentication in order to activate your whitelisting rules, consider the following example where I also require a correct password to be placed in the User-Agent request header:
SecRule REMOTE_ADDR "@streq 192.168.1.1" \
phase:1,t:none,nolog,pass,ctl:ruleEngine=DetectionOnly,chain
SecRule REQUEST_HEADERS:User-Agent "@contains SECRET_PASSWORD"