ModSecurity web application firewall (WAF) Research - .Little Hann

转载地址：http://bluereader.org/article/97681813
catalog

1. 引言
2. OWASP ModSecurity Core Rule Set (CRS) Project
3. Installation mod_security for Apache
4. Installation mod_security for nginx
5. Installation mod_security for IIS
6. mod_security Configuration Directives
7. Processing Phases
8. Variables
9. Transformation functions
10. Actions
11. Operators

12. A Recommended Base Configuration

13. 引言

ModSecurity is an open source, cross-platform web application firewall (WAF) module. Known as the “Swiss Army Knife” of WAFs, it enables web application defenders to gain visibility into HTTP(S) traffic and provides a power rules language and API to implement advanced protections.

0x1: Introduction

ModSecurity is a web application firewall (WAF). With over 70% of attacks now carried out over the web application level, organisations need all the help they can get in making their systems secure. WAFs are deployed to establish an increased external security layer to detect and/or prevent attacks before they reach web applications. ModSecurity provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure.

0x2: HTTP Traffic Logging

Web servers are typically well-equipped to log traffic in a form useful for marketing analyses, but fall short logging traffic to web applications. In particular, most are not capable of logging the request bodies. Your adversaries know this, and that is why most attacks are now carried out via POST requests, rendering your systems blind. ModSecurity makes full HTTP transaction logging possible, allowing complete requests and responses to be logged. Its logging facilities also allow fine-grained decisions to be made about exactly what is logged and when, ensuring only the relevant data is recorded. As some of the request and/or response may contain sensitive data in certain fields, ModSecurity can be configured to mask these fields before they are written to the audit log.

0x3: Real-Time Monitoring and Attack Detection

In addition to providing logging facilities, ModSecurity can monitor the HTTP traffic in real time in order to detect attacks. In this case, ModSecurity operates as a web intrusion detection tool, allowing you to react to suspicious events that take place at your web systems.
modsecurity定制了一套rule规则格式，安全人员可以通过外部文件的方式灵活地修改防御规则

0x4: Attack Prevention and Virtual Patching

ModSecurity can also act immediately to prevent attacks from reaching your web applications. There are three commonly used approaches

1. Negative security model(black list)
   A negative security model monitors requests for anomalies, unusual behaviour, and common web application attacks. It keeps anomaly scores for each request, IP addresses, application sessions, and user accounts. Requests with high anomaly scores are either logged or rejected altogether.
2. Positive security model(white list)
   When a positive security model is deployed, only requests that are known to be valid are accepted, with everything else rejected. This model requires knownledge of the web applications you are protecting. Therefore a positive security model works best with applications that are heavily used but rarely updated so that maintenance of the model is minimized.
3. Known weaknesses and vulnerabilities(vul rule)
   Its rule language makes ModSecurity an ideal external patching tool. External patching (sometimes referred to as Virtual Patching) is about reducing the window of opportunity. Time needed to patch application vulnerabilities often runs to weeks in many organisations. With ModSecurity, applications can be patched from the outside, without touching the application source code (and even without any access to it), making your systems secure until a proper patch is applied to the application.

0x5: Flexible Rule Engine

A flexible rule engine sits in the heart of ModSecurity. It implements the ModSecurity Rule Language, which is a specialised programming language designed to work with HTTP transaction data. The ModSecurity Rule Language is designed to be easy to use, yet flexible:

1. common operations are simple while complex operations are possible.
2. Certified ModSecurity Rules, included with ModSecurity, contain a comprehensive set of rules that implement general-purpose hardening, protocol validation and detection of common web application security issues.
3. Heavily commented, these rules can be used as a learning tool.

0x6: Embedded-mode Deployment

ModSecurity is an embeddable web application firewall, which means it can be deployed as part of your existing web server infrastructure provided your web servers are either Apache, IIS7 or Nginx. This deployment method has certain advantages:

1. No changes to existing network. It only takes a few minutes to add ModSecurity to your existing web servers. And because it was designed to be completely passive by default, you are free to deploy it incrementally and only use the features you need. It is equally easy to remove or deactivate it if required.
2. No single point of failure. Unlike with network-based deployments, you will not be introducing a new point of failure to your system.
3. Implicit load balancing and scaling. Because it works embedded in web servers, ModSecurity will automatically take advantage of the additional load balancing and scalability features. You will not need to think of load balancing and scaling unless your existing system needs them.
4. Minimal overhead. Because it works from inside the web server process there is no overhead for network communication and minimal overhead in parsing and data exchange.
   No problem with encrypted or compressed content. Many IDS systems have difficulties analysing SSL traffic. This is not a problem for ModSecurity because it is positioned to work when the traffic is decrypted and decompressed.

Relevant Link:

https://www.modsecurity.org/download.html
http://www.onlamp.com/pub/a/onlamp/2005/06/09/wss_security.html

1. OWASP ModSecurity Core Rule Set (CRS) Project

0x1: Overview

ModSecurity is a web application firewall engine that provides very little protection on its own. In order to become useful, ModSecurity must be configured with rules. In order to enable users to take full advantage of ModSecurity out of the box, Trustwave’s SpiderLabs created the OWASP ModSecurity Core Rule Set (CRS) Project. Unlike intrusion detection and prevention systems, which rely on signatures specific to known vulnerabilities, the CRS provide generic protection from unknown vulnerabilities often found in web applications, which are in most cases custom coded. The CRS is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity.

0x2: Core Rules Content

In order to provide generic web applications protection, the CRS use some of the following example techniques:

1. HTTP protection - detecting violations of the HTTP protocol and a locally defined usage policy.
2. Common Web Attacks Protection - detecting common web application security attack.
3. Automation detection - Detecting bots, crawlers, scanners and other surface malicious activity.
4. Trojan Protection - Detecting access to Trojans horses.
5. Error Hiding - Disguising error messages sent by the server.

Relevant Link:

https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

1. Installation mod_security for Apache

2. mkdir D:\wamp\bin\apache\apache2.4.9\modules\mod_security2

3. 下载mod_security二进制分发版本: http://www.apachelounge.com/download/VC14/modules/mod_security-2.9.0-win64-VC14.zip
4. 解压缩: modsecurity-2.9.0.tar.gz
5. copy mod_security2.so to D:\wamp\bin\apache\apache2.4.9\modules\mod_security2
6. 配置mod_security配置文件: modsecurity.conf
   /*

– Rule engine initialization ———————————————-

SecRuleEngine On
SecDefaultAction “deny,phase:2,status:403”

– Request body handling —————————————————

Allow ModSecurity to access request bodies. If you don’t, ModSecurity

won’t be able to see any POST parameters, which opens a large security

hole for attackers to exploit.

#
SecRequestBodyAccess On

Enable XML request body parser.

Initiate XML Processor in case of xml content-type

#
SecRule REQUEST_HEADERS:Content-Type “text/xml” \
“id:’200000’,phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML”

Enable JSON request body parser.

Initiate JSON Processor in case of JSON content-type; change accordingly

if your application does not use ‘application/json’

#
SecRule REQUEST_HEADERS:Content-Type “application/json” \
“id:’200001’,phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON”

Maximum request body size we will accept for buffering. If you support

file uploads then the value given on the first line has to be as large

as the largest file you are willing to accept. The second value refers

to the size of data, with files excluded. You want to keep that value as

low as practical.

#
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072

Store up to 128 KB of request body data in memory. When the multipart

parser reachers this limit, it will start using your hard disk for

storage. That is slow, but unavoidable.

#
SecRequestBodyInMemoryLimit 131072

What do do if the request body size is above our configured limit.

Keep in mind that this setting will automatically be set to ProcessPartial

when SecRuleEngine is set to DetectionOnly mode in order to minimize

disruptions when initially deploying ModSecurity.

#
SecRequestBodyLimitAction Reject

Verify that we’ve correctly processed the request body.

As a rule of thumb, when failing to process a request body

you should reject the request (when deployed in blocking mode)

or log a high-severity alert (when deployed in detection-only mode).

#
SecRule REQBODY_ERROR “!@eq 0” \
“id:’200002’, phase:2,t:none,log,deny,status:400,msg:’Failed to parse request body.’,logdata:’%{reqbody_error_msg}’,severity:2”

By default be strict with what we accept in the multipart/form-data

request body. If the rule below proves to be too strict for your

environment consider changing it to detection-only. You are encouraged

not to remove it altogether.

#
SecRule MULTIPART_STRICT_ERROR “!@eq 0” \
“id:’200003’,phase:2,t:none,log,deny,status:400, \
msg:’Multipart request body failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_MISSING_SEMICOLON}, \
IQ %{MULTIPART_INVALID_QUOTING}, \
IP %{MULTIPART_INVALID_PART}, \
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
FL %{MULTIPART_FILE_LIMIT_EXCEEDED}’”

Did we see anything that might be a boundary?

#
SecRule MULTIPART_UNMATCHED_BOUNDARY “!@eq 0” \
“id:’200004’,phase:2,t:none,log,deny,msg:’Multipart parser detected a possible unmatched boundary.’”

PCRE Tuning

We want to avoid a potential RegEx DoS condition

#
SecPcreMatchLimit 1000
SecPcreMatchLimitRecursion 1000

Some internal errors will set flags in TX and we will need to look for these.

All of these are prefixed with “MSC_”. The following flags currently exist:

#

MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.

#
SecRule TX:/^MSC_/ “!@streq 0” \
“id:’200005’,phase:2,t:none,deny,msg:’ModSecurity internal error flagged: %{MATCHED_VAR_NAME}’”

– Response body handling ————————————————–

Allow ModSecurity to access response bodies.

You should have this directive enabled in order to identify errors

and data leakage issues.

Do keep in mind that enabling this directive does increases both

memory consumption and response latency.

#
SecResponseBodyAccess On

Which response MIME types do you want to inspect? You should adjust the

configuration below to catch documents but avoid static files

(e.g., images and archives).

#
SecResponseBodyMimeType text/plain text/html text/xml

Buffer response bodies of up to 512 KB in length.

SecResponseBodyLimit 524288
SecRule ARGS “../” “t:normalisePathWin,id:99999,severity:4,msg:’Drive Access’”

What happens when we encounter a response body larger than the configured

limit? By default, we process what we have and let the rest through.

That’s somewhat less secure, but does not break any legitimate pages.

#
SecResponseBodyLimitAction ProcessPartial

– Filesystem configuration ————————————————

The location where ModSecurity stores temporary files (for example, when

it needs to handle a file upload that is larger than the configured limit).

This default setting is chosen due to all systems have /tmp available however,

this is less than ideal. It is recommended that you specify a location that’s private.

#
SecTmpDir D:/wamp/bin/apache/apache2.4.9/logs/modsecurity/

The location where ModSecurity will keep its persistent data. This default setting

is chosen due to all systems have /tmp available however, it

too should be updated to a place that other users can’t access.

#
SecDataDir D:/wamp/bin/apache/apache2.4.9/logs/modsecurity/

– File uploads handling configuration ————————————-

The location where ModSecurity stores intercepted uploaded files. This

location must be private to ModSecurity. You don’t want other users on

the server to access the files, do you?

#

SecUploadDir D:/wamp/bin/apache/apache2.4.9/logs/modsecurity/

By default, only keep the files that were determined to be unusual

in some way (by an external inspection script). For this to work you

will also need at least one file inspection rule.

#

SecUploadKeepFiles RelevantOnly

– Audit log configuration ————————————————-

Log the transactions that are marked by a rule, as well as those that

trigger a server error (determined by a 5xx or 4xx, excluding 404,

level response status codes).

#
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus “^(?:5|4(?!04))”

Log everything we know about a transaction.

SecAuditLogParts ABIJDEFHZ

Use a single file for logging. This is much easier to look at, but

assumes that you will use the audit log only ocassionally.

#
SecAuditLogType Serial
SecAuditLog D:/wamp/bin/apache/apache2.4.9/logs/modsecurity/modsec_audit.log

Specify the path for concurrent audit logging.

SecAuditLogStorageDir D:/wamp/bin/apache/apache2.4.9/logs/modsecurity/

Improve the quality of ModSecurity by sharing information about your

current ModSecurity version and dependencies versions.

The following information will be shared: ModSecurity version,

Web Server version, APR version, PCRE version, Lua version, Libxml2

version, Anonymous unique id for host.

SecStatusEngine On

禁止url中出现”../”字符串

SecRule ARGS “../” “t:normalizePathWin,id:50904,severity:4,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,msg:’Drive Access’”
*/
6. 配置httpd.conf
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule security2_module modules/mod_security2.so
Include conf/modsecurity.conf
7. 重启apache
8. 访问: http://localhost/?abc=../..
9. Forbidden 403错误

访问其他url则正常运行

Relevant Link:

http://www.apachelounge.com/download/VC10/
http://www.zdbase.com/content/detail.aspx?OID=750334B5-4E24-49C2-9252-F7A1CCC9B955
http://mewbies.com/how_to_install_mod_security_for_apache_tutorial.htm
https://sysengineers.wordpress.com/2008/12/17/enabling-mod_security-under-apache-2x-for-windows/
http://netsecurity.51cto.com/art/201409/452807_all.htm

1. Installation mod_security for nginx

0x1: 技术方案

1. 安装基础库
   yum install -y gcc make automake autoconf libtool
   yum install -y pcre pcre-devel libxml2 libxml2-devel curl curl-devel httpd-devel
2. 查看当前nginx的编译参数
   /usr/local/nginx1/sbin/nginx -V
   nginx version: nginx/1.2.3
   built by gcc 4.1.2 20080704 (Red Hat 4.1.2-54)
   configure arguments: –prefix=/usr/local/nginx1 –sbin-path=/usr/local/nginx1/sbin/nginx –conf-path=/usr/local/nginx1/conf/nginx.conf –error-log-path=/usr/local/nginx1/logs/error.log –http-log-path=/usr/local/nginx1/logs/access.log –pid-path=/usr/local/nginx1/var/nginx.pid –lock-path=/usr/local/nginx1/var/nginx.lock –user=www –group=www –without-select_module –without-poll_module –with-http_realip_module –with-http_sub_module –with-http_gzip_static_module –with-http_stub_status_module –without-http_ssi_module –without-http_userid_module –without-http_geo_module –without-http_memcached_module –without-http_map_module –without-mail_pop3_module –without-mail_imap_module –without-mail_smtp_module –add-module=module
3. 编译、安装mod_security
   cd /usr/local/
   git clone https://github.com/SpiderLabs/ModSecurity.git mod_security
   cd mod_security
   ./autogen.sh
   ./configure –enable-standalone-module
   make
4. 重新编译nginx、附加mod_security模块
   cd /usr/local/nginx/nginx-master
   ./auto/configure –add-module=/usr/local/mod_security/nginx/modsecurity
   make
   make install
5. 向nginx配置文件中增加mod_security配置
   The ModSecurity configuration file must be definded at nginx.conf file
   cp /usr/local/mod_security/modsecurity.conf-recommended /usr/local/nginx/conf/modsecurity.conf
   /*

– Rule engine initialization ———————————————-

Enable ModSecurity, attaching it to every transaction. Use detection

only to start with, because that minimises the chances of post-installation

disruption.

#
SecRuleEngine On
SecDefaultAction “deny,phase:2,status:403”

– Request body handling —————————————————

Allow ModSecurity to access request bodies. If you don’t, ModSecurity

won’t be able to see any POST parameters, which opens a large security

hole for attackers to exploit.

#
SecRequestBodyAccess On

Enable XML request body parser.

Initiate XML Processor in case of xml content-type

#
SecRule REQUEST_HEADERS:Content-Type “text/xml” \
“id:’200000’,phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML”

Enable JSON request body parser.

Initiate JSON Processor in case of JSON content-type; change accordingly

if your application does not use ‘application/json’

#
SecRule REQUEST_HEADERS:Content-Type “application/json” \
“id:’200001’,phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON”

Maximum request body size we will accept for buffering. If you support

file uploads then the value given on the first line has to be as large

as the largest file you are willing to accept. The second value refers

to the size of data, with files excluded. You want to keep that value as

low as practical.

#
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072

Store up to 128 KB of request body data in memory. When the multipart

parser reachers this limit, it will start using your hard disk for

storage. That is slow, but unavoidable.

#
SecRequestBodyInMemoryLimit 131072

What do do if the request body size is above our configured limit.

Keep in mind that this setting will automatically be set to ProcessPartial

when SecRuleEngine is set to DetectionOnly mode in order to minimize

disruptions when initially deploying ModSecurity.

#
SecRequestBodyLimitAction Reject

Verify that we’ve correctly processed the request body.

As a rule of thumb, when failing to process a request body

you should reject the request (when deployed in blocking mode)

or log a high-severity alert (when deployed in detection-only mode).

#
SecRule REQBODY_ERROR “!@eq 0” \
“id:’200002’, phase:2,t:none,log,deny,status:400,msg:’Failed to parse request body.’,logdata:’%{reqbody_error_msg}’,severity:2”

By default be strict with what we accept in the multipart/form-data

request body. If the rule below proves to be too strict for your

environment consider changing it to detection-only. You are encouraged

not to remove it altogether.

#
SecRule MULTIPART_STRICT_ERROR “!@eq 0” \
“id:’200003’,phase:2,t:none,log,deny,status:400, \
msg:’Multipart request body failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_MISSING_SEMICOLON}, \
IQ %{MULTIPART_INVALID_QUOTING}, \
IP %{MULTIPART_INVALID_PART}, \
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
FL %{MULTIPART_FILE_LIMIT_EXCEEDED}’”

Did we see anything that might be a boundary?

#
SecRule MULTIPART_UNMATCHED_BOUNDARY “!@eq 0” \
“id:’200004’,phase:2,t:none,log,deny,msg:’Multipart parser detected a possible unmatched boundary.’”

PCRE Tuning

We want to avoid a potential RegEx DoS condition

#
SecPcreMatchLimit 1000
SecPcreMatchLimitRecursion 1000

Some internal errors will set flags in TX and we will need to look for these.

All of these are prefixed with “MSC_”. The following flags currently exist:

#

MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.

#
SecRule TX:/^MSC_/ “!@streq 0” \
“id:’200005’,phase:2,t:none,deny,msg:’ModSecurity internal error flagged: %{MATCHED_VAR_NAME}’”

– Response body handling ————————————————–

Allow ModSecurity to access response bodies.

You should have this directive enabled in order to identify errors

and data leakage issues.

Do keep in mind that enabling this directive does increases both

memory consumption and response latency.

#
SecResponseBodyAccess On

Which response MIME types do you want to inspect? You should adjust the

configuration below to catch documents but avoid static files

(e.g., images and archives).

#
SecResponseBodyMimeType text/plain text/html text/xml

Buffer response bodies of up to 512 KB in length.

SecResponseBodyLimit 524288

What happens when we encounter a response body larger than the configured

limit? By default, we process what we have and let the rest through.

That’s somewhat less secure, but does not break any legitimate pages.

#
SecResponseBodyLimitAction ProcessPartial

– Filesystem configuration ————————————————

The location where ModSecurity stores temporary files (for example, when

it needs to handle a file upload that is larger than the configured limit).

This default setting is chosen due to all systems have /tmp available however,

this is less than ideal. It is recommended that you specify a location that’s private.

#
SecTmpDir /tmp/

The location where ModSecurity will keep its persistent data. This default setting

is chosen due to all systems have /tmp available however, it

too should be updated to a place that other users can’t access.

#
SecDataDir /tmp/

– File uploads handling configuration ————————————-

The location where ModSecurity stores intercepted uploaded files. This

location must be private to ModSecurity. You don’t want other users on

the server to access the files, do you?

#

SecUploadDir /opt/modsecurity/var/upload/

By default, only keep the files that were determined to be unusual

in some way (by an external inspection script). For this to work you

will also need at least one file inspection rule.

#

SecUploadKeepFiles RelevantOnly

Uploaded files are by default created with permissions that do not allow

any other user to access them. You may need to relax that if you want to

interface ModSecurity to an external program (e.g., an anti-virus).

#

SecUploadFileMode 0600

– Debug log configuration ————————————————-

The default debug log configuration is to duplicate the error, warning

and notice messages from the error log.

#

SecDebugLog /opt/modsecurity/var/log/debug.log

SecDebugLogLevel 3

– Audit log configuration ————————————————-

Log the transactions that are marked by a rule, as well as those that

trigger a server error (determined by a 5xx or 4xx, excluding 404,

level response status codes).

#
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus “^(?:5|4(?!04))”

Log everything we know about a transaction.

SecAuditLogParts ABIJDEFHZ

Use a single file for logging. This is much easier to look at, but

assumes that you will use the audit log only ocassionally.

#
SecAuditLogType Serial
SecAuditLog /var/log/modsec_audit.log

Specify the path for concurrent audit logging.

SecAuditLogStorageDir /opt/modsecurity/var/audit/

– Miscellaneous ———————————————————–

Use the most commonly used application/x-www-form-urlencoded parameter

separator. There’s probably only one application somewhere that uses

something else so don’t expect to change this value.

#
SecArgumentSeparator &

Settle on version 0 (zero) cookies, as that is what most applications

use. Using an incorrect cookie version may open your installation to

evasion attacks (against the rules that examine named cookies).

#
SecCookieFormat 0

Improve the quality of ModSecurity by sharing information about your

current ModSecurity version and dependencies versions.

The following information will be shared: ModSecurity version,

Web Server version, APR version, PCRE version, Lua version, Libxml2

version, Anonymous unique id for host.

SecStatusEngine On
*/
vim /usr/local/nginx/conf/nginx.conf
//编译增加(如果已存在location /则添加下列内容到原始的location{}内)
http{
..
server {
..
ModSecurityEnabled on;
ModSecurityConfig modsecurity.conf;
..
location / {
include modsecurity_crs_41_sql_injection_attacks.conf
}
}
}6. 重启nginx
/usr/local/nginx/sbin/nginx -s stop
/usr/local/nginx/sbin/nginx

0x2: 在不中断业务的情况下配置nginx增加mod_security支持

1. 准备一个标准纯净编译环境
   http://112.124.110.206/
   Linux iZ236zqeepwZ 2.6.18-308.el5 #1 SMP Tue Feb 21 20:06:06 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
   CentOS release 5.8 (Final)
   //考虑到Glibc的向下兼容性，编译环境尽量使用低版本的glibc、gcc进行编译，这样编译得到的各种版本的binary在各种linux分发版本上都能得到尽可能高的兼容性
2. 初始化基础库环境
   yum install -y gcc make automake autoconf libtool httpd-dev apr-util-devel apr-devel
   yum install -y pcre pcre-devel libxml2 libxml2-devel curl curl-devel httpd-devel
   yum -y install gcc gcc-c++ autoconf libjpeg libjpeg-devel libpng libpng-devel freetype freetype-devel libxml2 libxml2-devel zlib zlib-devel glibc glibc-devel glib2 glib2-devel bzip2 bzip2-devel ncurses ncurses-devel curl curl-devel e2fsprogs e2fsprogs-devel krb5 krb5-devel libidn libidn-devel openssl openssl-devel openldap openldap-devel nss_ldap openldap-clients openldap-servers cmake
3. 编译mod_security
   cd /usr/local/
   git clone https://github.com/SpiderLabs/ModSecurity.git mod_security
   cd mod_security
   ./autogen.sh
   ./configure –enable-standalone-module
   make
   /*
   如果在centos5.8等低版本linux分发版本中使用autoconf、automake失败，可以尝试使用源码编译的方式
   yum install libxml2-devel
   yum install httpd-devel
   yum -y install python-devel
   wget ftp://xmlsoft.org/libxml2/libxml2-2.9.2.tar.gz
   tar -xzvf libxml2-2.9.2.tar.gz
   cd libxml2-2.9.2
   ./configure –prefix=/usr/local/libxml2
   make
   make install
   wget ‘https://www.modsecurity.org/tarball/2.8.0/modsecurity-2.8.0.tar.gz’
   tar -zxvf modsecurity-2.8.0.tar.gz
   cd modsecurity-2.8.0
   ./configure –enable-standalone-module –disable-mlogc
   make
   */
4. 查看目标服务器上运行中的nginx的编译参数
   /usr/local/nginx1/sbin/nginx -V
   nginx version: nginx/1.2.3
   built by gcc 4.1.2 20080704 (Red Hat 4.1.2-54)
   configure arguments: –prefix=/usr/local/nginx1 –sbin-path=/usr/local/nginx1/sbin/nginx –conf-path=/usr/local/nginx1/conf/nginx.conf –error-log-path=/usr/local/nginx1/logs/error.log –http-log-path=/usr/local/nginx1/logs/access.log –pid-path=/usr/local/nginx1/var/nginx.pid –lock-path=/usr/local/nginx1/var/nginx.lock –user=www –group=www –without-select_module –without-poll_module –with-http_realip_module –with-http_sub_module –with-http_gzip_static_module –with-http_stub_status_module –without-http_ssi_module –without-http_userid_module –without-http_geo_module –without-http_memcached_module –without-http_map_module –without-mail_pop3_module –without-mail_imap_module –without-mail_smtp_module
   //最安全稳定的做法是根据每个目标服务器nginx相同的编译参数，在编译机上进行重编译，这样不容易产生业务中断风险
5. 重新编译nginx、附加mod_security模块(基于目标服务器上ningx的原始编译参数)(包括主、次版本号都必须一样)
   cd /tmp
   mkdir nginx
   cd nginx
   wget http://nginx.org/download/nginx-1.2.3.tar.gz
   tar -zvxf nginx-1.2.3.tar.gz
   cd nginx-1.2.3
   ./configure –prefix=/usr/local/nginx1 –sbin-path=/usr/local/nginx1/sbin/nginx –conf-path=/usr/local/nginx1/conf/nginx.conf –error-log-path=/usr/local/nginx1/logs/error.log –http-log-path=/usr/local/nginx1/logs/access.log –pid-path=/usr/local/nginx1/var/nginx.pid –lock-path=/usr/local/nginx1/var/nginx.lock –user=www –group=www –without-select_module –without-poll_module –with-http_realip_module –with-http_sub_module –with-http_gzip_static_module –with-http_stub_status_module –without-http_ssi_module –without-http_userid_module –without-http_geo_module –without-http_memcached_module –without-http_map_module –without-mail_pop3_module –without-mail_imap_module –without-mail_smtp_module –add-module=/usr/local/mod_security/nginx/modsecurity
   make
   make install
   //这样编译得到的nginx是可以直接替换目标服务器上正在运行的nginx的
6. 将编译得到的nginx、配置文件、以及规则文件提供下载
   cp objs/nginx /var/www/html/nginx
   http://112.124.110.206/nginx
   http://112.124.110.206/modsecurity.conf
   http://112.124.110.206/modsecurity_crs_20_protocol_violations.conf
   http://112.124.110.206/modsecurity_crs_21_protocol_anomalies.conf
   http://112.124.110.206/modsecurity_crs_23_request_limits.conf
   http://112.124.110.206/modsecurity_crs_30_http_policy.conf
   http://112.124.110.206/modsecurity_crs_35_bad_robots.conf
   http://112.124.110.206/modsecurity_crs_40_generic_attacks.conf
   http://112.124.110.206/modsecurity_crs_41_sql_injection_attacks.conf
   http://112.124.110.206/modsecurity_crs_41_xss_attacks.conf
   http://112.124.110.206/modsecurity_crs_42_tight_security.conf
   http://112.124.110.206/modsecurity_crs_45_trojans.conf
   http://112.124.110.206/modsecurity_crs_47_common_exceptions.conf
   http://112.124.110.206/modsecurity_crs_49_inbound_blocking.conf
   http://112.124.110.206/modsecurity_crs_50_outbound.conf
   http://112.124.110.206/modsecurity_crs_59_outbound_blocking.conf
   http://112.124.110.206/modsecurity_crs_60_correlation.conf
7. 在目标服务器上进行nginx替换
   cd /tmp/nginx
   wget http://112.124.110.206/nginx
   /usr/local/nginx1/sbin/nginx -s stop;chmod 755 ./nginx;cp ./nginx /usr/local/nginx1/sbin/nginx;/usr/local/nginx1/sbin/nginx
8. 回滚方案
   cp ./nginx_bak_20151020 /usr/local/nginx1/sbin/nginx;/usr/local/nginx1/sbin/nginx
9. 配置目标服务器mod_security开关
   vim /usr/local/nginx1/conf/nginx.conf
   //编译增加(如果已存在location /则添加下列内容到原始的location{}内)
   http{
   ..
   server {
   ..
   ModSecurityEnabled on;
   ModSecurityConfig modsecurity.conf;
   ..
   location / {
   include modsecurity_crs_20_protocol_violations.conf
   include modsecurity_crs_20_protocol_violations.conf
   include modsecurity_crs_21_protocol_anomalies.conf
   include modsecurity_crs_23_request_limits.conf
   include modsecurity_crs_30_http_policy.conf
   include modsecurity_crs_35_bad_robots.conf
   include modsecurity_crs_40_generic_attacks.conf
   include modsecurity_crs_41_sql_injection_attacks.conf
   include modsecurity_crs_41_xss_attacks.conf
   include modsecurity_crs_42_tight_security.conf
   include modsecurity_crs_45_trojans.conf
   include modsecurity_crs_47_common_exceptions.conf
   include modsecurity_crs_49_inbound_blocking.conf
   include modsecurity_crs_50_outbound.conf
   include modsecurity_crs_59_outbound_blocking.conf
   include modsecurity_crs_60_correlation.conf
   }
   }
   }
10. 下载mod_security配置、规则文件
    cd /usr/local/nginx1/conf
    wget http://112.124.110.206/modsecurity.conf
    wget http://112.124.110.206/modsecurity_crs_20_protocol_violations.conf
    wget http://112.124.110.206/modsecurity_crs_21_protocol_anomalies.conf
    wget http://112.124.110.206/modsecurity_crs_23_request_limits.conf
    wget http://112.124.110.206/modsecurity_crs_30_http_policy.conf
    wget http://112.124.110.206/modsecurity_crs_35_bad_robots.conf
    wget http://112.124.110.206/modsecurity_crs_40_generic_attacks.conf
    wget http://112.124.110.206/modsecurity_crs_41_sql_injection_attacks.conf
    wget http://112.124.110.206/modsecurity_crs_41_xss_attacks.conf
    wget http://112.124.110.206/modsecurity_crs_42_tight_security.conf
    wget http://112.124.110.206/modsecurity_crs_45_trojans.conf
    wget http://112.124.110.206/modsecurity_crs_47_common_exceptions.conf
    wget http://112.124.110.206/modsecurity_crs_49_inbound_blocking.conf
    wget http://112.124.110.206/modsecurity_crs_50_outbound.conf
    wget http://112.124.110.206/modsecurity_crs_59_outbound_blocking.conf
    wget http://112.124.110.206/modsecurity_crs_60_correlation.conf

由于modsecurity是一个较新的服务器扩展模块，在centos5.8(nginx+mod_security)下编译很困难，会遇到很多库依赖方面的问题，在contos6下则基本没问题

Relevant Link:

http://www.yunwei8.com/lnmp201210
http://www.nginxtips.com/how-to-install-mod_security-on-nginx/
http://nginx.org/download/

1. Installation mod_security for IIS

Relevant Link:

https://github.com/SpiderLabs/ModSecurity/wiki/IIS-Troubleshooting
http://jesscoburn.com/archives/2013/05/14/installing-modsecurity-on-iis7-x/
http://blogs.technet.com/b/srd/archive/2012/07/26/announcing-the-availability-of-modsecurity-extension-for-iis.aspx
https://cyberoperations.wordpress.com/class-archives/2013-class/07-iis-7-5-on-windows-2008-r2-with-modsecurity-2-7-2/

1. mod_security Configuration Directives

在完成了mod_security的配置、以及实现了最简单的规则配置之后，我们接下来深入学习OWASP的mod_security core rule，逐步了解如何将一个漏洞分解为mod的规则格式

0x1: SecAction

1. Description: Unconditionally processes the action list it receives as the first and only parameter. The syntax of the parameter is identical to that of the third parameter of SecRule.
2. Syntax: SecAction “action1,action2,action3,…“
3. Scope: Any
4. Version: 2.0.0
   //This directive is commonly used to set variables and initialize persistent collections using the initcol action.
5. For example: SecAction nolog,phase:1,initcol:RESOURCE=%{REQUEST_FILENAME}

0x2: SecArgumentSeparator

1. Description: Specifies which character to use as the separator for application/x-www-form- urlencoded content.
2. Syntax: SecArgumentSeparator character
3. Default: &
4. Scope: Main(
5. Version: 2.0.0
   //This directive is needed if a backend web application is using a nonstandard argument separator. Applications are sometimes (very rarely) written to use a semicolon separator. You should not change the default setting unless you establish that the application you are working with requires a different separator. If this directive is not set properly for each web application, then ModSecurity will not be able to parse the arguments appropriately and the effectiveness of the rule matching will be significantly decreased.

0x3: SecAuditEngine

1. Description: Configures the audit logging engine.
2. Syntax: SecAuditEngine RelevantOnly
3. Default: Off
4. Scope: Any
5. Version: 2.0.0
   The SecAuditEngine directive is used to configure the audit engine, which logs complete transactions. ModSecurity is currently able to log most, but not all transactions. Transactions involving errors (e.g., 400 and 404 transactions) use a different execution path, which ModSecurity does not support.
   The possible values for the audit log engine are as follows:
   1) On: log all transactions
   2) Off: do not log any transactions
   3) RelevantOnly: only the log transactions that have triggered a warning or an error, or have a status code that is considered to be relevant (as determined by the SecAuditLogRelevantStatus directive)
   Note : If you need to change the audit log engine configuration on a per-transaction basis (e.g., in response to some transaction data), use the ctl action.
   The following example demonstrates how SecAuditEngine is used:
   /*
   SecAuditEngine RelevantOnly
   SecAuditLog logs/audit/audit.log
   SecAuditLogParts ABCFHZ
   SecAuditLogType concurrent
   SecAuditLogStorageDir logs/audit
   SecAuditLogRelevantStatus ^(?:5|4(?!04))
   */

0x4: SecAuditLog

1. Description: Defines the path to the main audit log file (serial logging format) or the concurrent logging index file (concurrent logging format). When used in combination with mlogc (only possible with concurrent logging), this directive defines the mlogc location and command line.
2. Syntax: SecAuditLog /path/to/audit.log
3. Scope: Any Version: 2.0.0
   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. If you are planning to use concurrent audit logging to send your audit log data off to a remote server you will need to deploy the ModSecurity Log Collector (mlogc), like this:
   /*
   SecAuditLog “|/path/to/mlogc /path/to/mlogc.conf”
   Note : This audit log file is opened 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.
   */

0x5: SecAuditLogDirMode

1. Description: Configures the mode (permissions) of any directories created for the concurrent audit logs, using an octal mode value as parameter (as used in chmod).
2. Syntax: SecAuditLogDirMode octal_mode|”default”
3. Default: 0600
4. Scope: Any
5. Version: 2.5.10
   The default mode for new audit log directories (0600) only grants read/write access to the owner (typically the account under which Apache is running, for example apache). If access from other accounts is needed (e.g., for use with mpm-itk), then you may use this directive to grant additional read and/or write privileges. You should use this directive with caution to avoid exposing potentially sensitive data to unauthorized users. Using the value default as parameter reverts the configuration back to the default setting. This feature is not available on operating systems not supporting octal file modes.
6. Example: SecAuditLogDirMode 02750

0x6: SecAuditLogFileMode

1. Description: Configures the mode (permissions) of any files created for concurrent audit logs using an octal mode (as used in chmod). See SecAuditLogDirMode for controlling the mode of created audit log directories.
2. Syntax: SecAuditLogFileMode octal_mode|”default”
3. Default: 0600
4. Scope: Any
5. Version: 2.5.10
6. Example Usage: SecAuditLogFileMode 00640
   //This feature is not available on operating systems not supporting octal file modes. The default mode (0600) only grants read/write access to the account writing the file. If access from another account is needed (using mpm-itk is a good example), then this directive may be required. However, use this directive with caution to avoid exposing potentially sensitive data to unauthorized users. Using the value “default” will revert back to the default setting.

0x7: SecAuditLogParts

1. Description: Defines which parts of each transaction are going to be recorded in the audit log. Each part is assigned a single letter; when a letter appears in the list then the equivalent part will be recorded. See below for the list of all parts.
2. Syntax: SecAuditLogParts PARTLETTERS
3. Example Usage: SecAuditLogParts ABCFHZ
4. Scope: Any Version: 2.0.0
5. Default: ABCFHZ Note
   The format of the audit log format is documented in detail in the Audit Log Data Format Documentation.
   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: This part contains information about the files uploaded using multipart/form-data encoding.
   K: This part contains a full list of every rule that matched (one per line) in the order they were matched. The rules are fully qualified and will thus show inherited actions and default operators. Supported as of v2.5.0.
   Z: Final boundary, signifies the end of the entry (mandatory).
   */

0x8: SecAuditLogRelevantStatus

1. Description: Configures which response status code is to be considered relevant for the purpose of audit logging.
2. Syntax: SecAuditLogRelevantStatus REGEX
3. Example Usage: SecAuditLogRelevantStatus “^(?:5|4(?!04))”
4. Scope: Any
5. Version: 2.0.0

Dependencies/Notes: Must have SecAuditEngine set to RelevantOnly. Additionally, the auditlog action is present by default in rules, this will make the engine bypass the ‘SecAuditLogRelevantStatus’ and send rule matches to the audit log regardless of status. You must specify noauditlog in the rules manually or set it in SecDefaultAction.
The main purpose of this directive is to allow you to configure audit logging for only the transactions that have the status code that matches the supplied regular expression. The example provided would log all 5xx and 4xx level status codes, except for 404s. Although you could achieve the same effect with a rule in phase 5, SecAuditLogRelevantStatus is sometimes better, because it continues to work even when SecRuleEngine is disabled.

0x9: SecAuditLogStorageDir

1. Description: Configures the directory where concurrent audit log entries are to be stored.
2. Syntax: SecAuditLogStorageDir /path/to/storage/dir
3. Example Usage: SecAuditLogStorageDir /usr/local/apache/logs/audit
4. Scope: Any
5. Version: 2.0.0

This directive is only needed when concurrent audit logging is used. The directory must already exist and must be writable by the web server user. Audit log entries are created at runtime, after Apache switches to a non-root account. As with all logging mechanisms, ensure that you specify a file system location that has adequate disk space and is not on the main system partition.

0x10: SecAuditLogType

1. Description: Configures the type of audit logging mechanism to be used.
2. Syntax: SecAuditLogType Serial|Concurrent
3. Example Usage: SecAuditLogType Serial
4. Scope: Any
5. Version: 2.0.0
   The possible values are:
   1) Serial : Audit log entries will be stored in a single file, specified by SecAuditLog. This is convenient for casual use, but it can slow down the server, because only one audit log entry can be written to the file at any one time.
   2) Concurrent: One file per transaction is used for audit logging. This approach is more scalable when heavy logging is required (multiple transactions can be recorded in parallel). It is also the only choice if you need to use remote logging.

0x11: SecDefaultAction

1. Description: Defines the default list of actions, which will be inherited by the rules in the same configuration context.
2. Syntax: SecDefaultAction “action1,action2,action3“
3. Example Usage: SecDefaultAction “phase:2,log,auditlog,deny,status:403,tag:’SLA 24/7’“
4. Scope: Any
5. Version: 2.0.0
6. Default: phase:2,log,auditlog,pass
   //Every rule following a previous SecDefaultAction directive in the same configuration context will inherit its settings unless more specific actions are used. Every SecDefaultAction directive must specify a disruptive action and a processing phase and cannot contain metadata actions.

0x12: SecRequestBodyAccess

1. Description: Configures whether request bodies will be buffered and processed by ModSecurity.
2. Syntax: SecRequestBodyAccess On|Off
3. Example Usage: SecRequestBodyAccess On
4. Scope: Any
5. Version: 2.0.0
   //This directive is required if you want to inspect the data transported request bodies (e.g., POST parameters). Request buffering is also required in order to make reliable blocking possible. The possible values are:
   1) On: buffer request bodies
   2) Off: do not buffer request bodies

0x13: SecRequestBodyInMemoryLimit

1. Description: Configures the maximum request body size that ModSecurity will store in memory.
2. Syntax: SecRequestBodyInMemoryLimit LIMIT_IN_BYTES
3. Example Usage: SecRequestBodyInMemoryLimit 131072
4. Scope: Any
5. Version: 2.0.0
6. Default: 131072 (128 KB)
   //When a multipart/form-data request is being processed, once the in-memory limit is reached, the request body will start to be streamed into a temporary file on disk.

0x14: SecResponseBodyMimeType

1. Description: Configures which MIME types are to be considered for response body buffering.
2. Syntax: SecResponseBodyMimeType MIMETYPE MIMETYPE …
3. Example Usage: SecResponseBodyMimeType text/plain text/html text/xml
4. Scope: Any
5. Version: 2.0.0
6. Default: text/plain text/html
   //Multiple SecResponseBodyMimeType directives can be used to add MIME types. Use SecResponseBodyMimeTypesClear to clear previously configured MIME types and start over.

这个指令可以用来进行”网站敏感静态资源防泄漏”的防护，类似安全狗的静态资源保护功能

0x15: SecRule

1. Description: Creates a rule that will analyze the selected variables using the selected operator.
2. Syntax: SecRule VARIABLES OPERATOR [ACTIONS] (AXTIONS代表按照此顺序去应用规则，Mod的HTTP生命周期)
3. Example Usage: SecRule ARGS “@rx attack” “phase:1,log,deny,id:1”
4. Scope: Any
   5 Version: 2.0.0
   //Every rule must provide one or more variables along with the operator that should be used to inspect them. If no actions are provided, the default list will be used. (There is always a default list, even if one was not explicitly set with SecDefaultAction.) If there are actions specified in a rule, they will be merged with the default list to form the final actions that will be used. (The actions in the rule will overwrite those in the default list.)

这个规则指令是mod_security的核心，所有的WAF防护能力都通过这个指令实现

Relevant Link:

https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#ModSecurityreg_Reference_Manual

1. Processing Phases

ModSecurity 2.x allows rules to be placed in one of the following five phases of the Apache request cycle:

1. phase1: Request headers (REQUEST_HEADERS)
2. phase2: Request body (REQUEST_BODY)
3. phase3: Response headers (RESPONSE_HEADERS)
4. phase4: Response body (RESPONSE_BODY)
5. phase5: Logging (LOGGING)

In order to select the phase a rule executes during, use the phase action either directly in the rule or in using the SecDefaultAction directive:

SecDefaultAction “log,pass,phase:2,id:4”
//or
SecRule REQUEST_HEADERS:Host “!^$” “deny,phase:1,id:5”

Note : The data available in each phase is cumulative. This means that as you move onto later phases, you have access to more and more data from the transaction.
Note : Keep in mind that rules are executed according to phases, so even if two rules are adjacent in a configuration file, but are set to execute in different phases, they would not happen one after the other. The order of rules in the configuration file is important only within the rules of each phase. This is especially important when using the skip and skipAfter actions.
apache 2.0后的模块扩展机制已经充分考虑了第三方扩展的灵活性，在整个HTTP处理声明周期中都暴露了Hook点(类似Netfilter)

/* 1. Connection processing hooks */
ap_hook_process_connection(hook_connection_early, NULL, NULL, APR_HOOK_FIRST);
/* 2. Transaction processing hooks (Phase Request Headers) */
ap_hook_post_read_request(hook_request_early, postread_beforeme_list, postread_afterme_list, APR_HOOK_REALLY_FIRST);
ap_hook_fixups(hook_request_late, fixups_beforeme_list, NULL, APR_HOOK_REALLY_FIRST);
/* 3. Logging */
ap_hook_error_log(hook_error_log, NULL, NULL, APR_HOOK_MIDDLE);
ap_hook_log_transaction(hook_log_transaction, NULL, transaction_afterme_list, APR_HOOK_MIDDLE);
/* 4. Filter hooks */
ap_hook_insert_filter(hook_insert_filter, NULL, NULL, APR_HOOK_FIRST);
ap_hook_insert_error_filter(hook_insert_error_filter, NULL, NULL, APR_HOOK_FIRST);
//5.
ap_register_input_filter(“MODSECURITY_IN”, input_filter, NULL, AP_FTYPE_CONTENT_SET);
/* Ensure that the output filter runs before other modules so that
* we get a request that has a better chance of not being modified:
*
* Currently:
* mod_expires = -2
* mod_cache = -1
* mod_deflate = -1
* mod_headers = 0
*/
//6.
ap_register_output_filter(“MODSECURITY_OUT”, output_filter, NULL, AP_FTYPE_CONTENT_SET - 3);

0x1: Phase Request Headers

Rules in this phase are processed immediately after Apache completes reading the request headers (post-read-request phase). At this point the request body has not been read yet, meaning not all request arguments are available.
Rules should be placed in this phase if you need to have them run early (before Apache does something with the request), to do something before the request body has been read, determine whether or not the request body should be buffered, or decide how you want the request body to be processed (e.g. whether to parse it as XML or not).

0x2: Phase Request Body

This is the general-purpose input analysis phase. Most of the application-oriented rules should go here. In this phase you are guaranteed to have received the request arguments (provided the request body has been read). ModSecurity supports three encoding types for the request body phase:

1. application/x-www-form-urlencoded - used to transfer form data
2. multipart/form-data - used for file transfers
3. text/xml - used for passing XML data
4. Other encodings are not used by most web applications.
   //Note : In order to access the Request Body phase data, you must have SecRequestBodyAccess set to On.

0x3: Phase Response Headers

This phase takes place just before response headers are sent back to the client.
Run here if you want to observe the response before that happens, and if you want to use the response headers to determine if you want to buffer the response body.
Note that some response status codes (such as 404) are handled earlier in the request cycle by Apache and my not be able to be triggered as expected. Additionally, there are some response headers that are added by Apache at a later hook (such as Date, Server and Connection) that we would not be able to trigger on or sanitize. This should work appropriately in a proxy setup or within phase:5 (logging).

0x4: Phase Response Body

This is the general-purpose output analysis phase. At this point you can run rules against the response body (provided it was buffered, of course). This is the phase where you would want to inspect the outbound HTML for information disclosure, error messages or failed authentication text.
//Note : In order to access the Response Body phase data, you must have SecResponseBodyAccess set to On

0x5: Phase Logging

This phase is run just before logging takes place. The rules placed into this phase can only affect how the logging is performed. This phase can be used to inspect the error messages logged by Apache. You cannot deny/block connections in this phase as it is too late. This phase also allows for inspection of other response headers that weren’t available during phase:3 or phase:4. Note that you must be careful not to inherit a disruptive action into a rule in this phase as this is a configuration error in ModSecurity 2.5.0 and later versions

Relevant Link:

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#ModSecurityreg_Reference_Manual

1. Variables

0x1: ARGS

ARGS is a collection and can be used on its own (means all arguments including the POST Payload), with a static parameter (matches arguments with that name), or with a regular expression (matches all arguments with name that matches the regular expression).

SecRule ARGS “dirty” “t:normalisePathWin,id:99998,severity:4,msg:’Drive Access’”

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 “t:normalisePathWin,id:99998,severity:4,msg:’Drive Access’”

It is also possible to specify exclusions. The following will examine all request arguments for the word dirty, except the ones named z

SecRule ARGS|!ARGS:z dirty “t:normalisePathWin,id:99998,severity:4,msg:’Drive Access’”

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

SecRule &ARGS !^0$ “t:normalisePathWin,id:99998,severity:4,msg:’Drive Access’”

And sometimes you need to look at an array of parameters(id[0]=xx、id[1]..), 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 “t:normalisePathWin,id:99998,severity:4,msg:’Drive Access’”

0x2: ARGS_COMBINED_SIZE

Contains the combined size of all request parameters. Files are excluded from the calculation. This variable can be useful, for example, to create a rule to ensure that the total size of the argument data is below a certain threshold. The following rule detects a request whose para- meters are more than 2500 bytes long:

SecRule ARGS_COMBINED_SIZE “@gt 2500” “id:12”

0x3: ARGS_GET

RGS_GET is similar to ARGS, but contains only query string parameters.

0x4: ARGS_GET_NAMES

ARGS_GET_NAMES is similar to ARGS_NAMES, but contains only the names of query string parameters.

0x5: ARGS_NAMES

Contains all request parameter names. You can search for specific parameter names that you want to inspect. In a positive policy scenario, you can also whitelist (using an inverted rule with the exclamation mark) only the authorized argument names. This example rule allows only two argument names: p and a:

SecRule ARGS_NAMES “!^(p|a)$” “t:normalisePathWin,id:99998,severity:4,msg:’Drive Access’”

0x6: ARGS_POST

ARGS_POST is similar to ARGS, but only contains arguments from the POST body.

0x7: AUTH_TYPE

This variable holds the authentication method used to validate a user, if any of the methods built into HTTP are used. In a reverse-proxy deployment, this information will not be available if the authentication is handled in the backend web server.

SecRule AUTH_TYPE “Basic” “id:14”

0x8: FILES

Contains a collection of original file names (as they were called on the remote user’s filesys- tem). Available only on inspected multipart/form-data requests.

SecRule FILES “@rx .conf$” “id:17”

0x9: FILES_NAMES

Contains a list of form fields that were used for file upload. Available only on inspected multipart/form-data requests.

SecRule FILES_NAMES “^upfile$” “id:19”

0x10: FULL_REQUEST

Contains the complete request: Request line, Request headers and Request body (if any). The last available only if SecRequestBodyAccess was set to On. Note that all properties of SecRequestBodyAccess will be respected here, such as: SecRequestBodyLimit.

SecRule FULL_REQUEST “Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36” “t:normalisePathWin,id:99998,severity:4,msg:’Drive Access’”

0x11: PATH_INFO

Contains the extra request URI information, also known as path info. (For example, in the URI /index.php/123, /123 is the path info.) Available only in embedded deployments.

SecRule PATH_INFO “^/(bin|etc|sbin|opt|usr)” “t:normalisePathWin,id:99998,severity:4,msg:’Drive Access’”

0x12: QUERY_STRING

Contains the query string part of a request URI. The value in QUERY_STRING is always provided raw, without URL decoding taking place.(取自未规范化、未解码前的URL请求数据)

SecRule QUERY_STRING “attack” “id:34”

0x13: REQUEST_BASENAME

This variable holds just the filename part of REQUEST_FILENAME (e.g., index.php).

SecRule REQUEST_BASENAME “^login.php$” phase:2,id:42,t:none,t:lowercase

0x14: REQUEST_BODY

Holds the raw request body. This variable is available only if the URLENCODED request body processor was used, which will occur by default when the application/x-www-form-urlencoded content type is detected, or if the use of the URLENCODED request body parser was forced.

SecRule REQUEST_BODY “^username=\w{25,}\&password=\w{25,}\&Submit\=login$” “id:43”

0x15: REQUEST_COOKIES

This variable is a collection of all of request cookies (values only). Example: the following example is using the Ampersand special operator to count how many variables are in the collection. In this rule, it would trigger if the request does not include any Cookie headers.

ecRule &REQUEST_COOKIES “@eq 0” “id:44”

0x16: REQUEST_LINE

This variable holds the complete request line sent to the server (including the request method and HTTP version information).

Allow only POST, GET and HEAD request methods, as well as only

the valid protocol versions

SecRule REQUEST_LINE “!(^((?:(?:POS|GE)T|HEAD))|HTTP/(0.9|1.0|1.1)$)” “phase:1,id:49,log,block,t:none”

0x17: REQUEST_METHOD

This variable holds the request method used in the transaction.

SecRule REQUEST_METHOD “^(?:CONNECT|TRACE)$” “id:50,t:none”

0x18: REQUEST_PROTOCOL

This variable holds the request protocol version information.

SecRule REQUEST_PROTOCOL “!^HTTP/(0.9|1.0|1.1)$” “id:51”

0x19: REQUEST_URI

This variable holds the full request URL including the query string data (e.g., /index.php? p=X). However, it will never contain a domain name, even if it was provided on the request line.

SecRule REQUEST_URI “attack” “phase:1,id:52,t:none,t:urlDecode,t:lowercase,t:normalizePath”

0x20: REQUEST_URI_RAW

Same as REQUEST_URI but will contain the domain name if it was provided on the request line (e.g., http://www.example.com/index.php?p=X).

SecRule REQUEST_URI_RAW “http:/” “t:normalisePathWin,id:99998,severity:4,msg:’Drive Access’”

0x21: RESPONSE_BODY

This variable holds the data for the response body, but only when response body buffering is enabled.

0x22: SCRIPT_BASENAME

This variable holds just the local filename part of SCRIPT_FILENAME.

SecRule SCRIPT_BASENAME “^login.php$” “id:60”

0x23: STREAM_INPUT_BODY

This variable give access to the raw request body content. This variable is best used for two use-cases:

1. For fast pattern matching - using @pm/@pmf to prequalify large text strings against any kind of content-type data. This is more performant vs. using REQUEST_BODY/ARGS_POST/ARGS_POST_NAMES as it happens before ModSecurity parsing in phase:2 variable population.
2. For data substitution - using @rsub against this variable allows you to manipulate live request body data. Example - to remove offending payloads or to substitute benign data.

0x24: TX

This is the transient transaction collection, which is used to store pieces of data, create a transaction anomaly score, and so on. The variables placed into this collection are available only until the transaction is complete.

Increment transaction attack score on attack

SecRule ARGS attack “phase:2,id:82,nolog,pass,setvar:TX.score=+5”

Block the transactions whose scores are too high

SecRule TX:SCORE “@gt 20” “phase:2,id:83,log,deny”

Some variable names in the TX collection are reserved and cannot be used:

1. TX:0: the matching value when using the @rx or @pm operator with the capture action
2. TX:1-TX:9: the captured subexpression value when using the @rx operator with capturing parens and the capture action
3. TX:MSC_.*: ModSecurity processing flags
4. MSC_PCRE_LIMITS_EXCEEDED: Set to nonzero if PCRE match limits are exceeded. See SecPcreMatchLimit and SecPcreMatchLimitRecursion for more information.

Relevant Link:

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#ModSecurityreg_Reference_Manual

1. Transformation functions

Transformation functions are used to alter input data before it is used in matching. The input data is never modified, actually—whenever you request a transformation function to be used, ModSecurity will create a copy of the data, transform it, and then run the operator against the result. mod_security虽然是串行在apache的处理流程中，但是从数据层面上来说，mod_security是通过镜像了一份HTTP流量，以此为数据基础进行规则检测的
In the following example, the request parameter values are converted to lowercase before matching:

SecRule ARGS “xp_cmdshell” “t:lowercase,severity:4,msg:’Drive Access’,id:99998”

Multiple transformation actions can be used in the same rule, forming a transformation pipeline. The transformations will be performed in the order in which they appear in the rule.
In most cases, the order in which transformations are performed is very important. In the following example, a series of transformation functions is performed to counter evasion. Performing the transformations in any other order would allow a skillful attacker to evade detection:

SecRule ARGS “(asfunction|javascript|vbscript|data|mocha|livescript):” “id:92,t:none,t:htmlEntityDecode,t:lowercase,t:removeNulls,t:removeWhitespace”

0x1: base64Decode

Decodes a Base64-encoded string.

SecRule REQUEST_HEADERS:Authorization “^Basic ([a-zA-Z0-9]+=*) ”“phase:1,id:93,capture,chain,logdata:SecRuleTX:1(\w+):t:base64Decode,capture,chainSecRuleTX:1(admin|root|backup)

0x2: sqlHexDecode

Decode sql hex data. Example (0x414243) will be decoded to (ABC).

0x3: cmdLine

In Windows and Unix, commands may be escaped by different means, such as:

1. c^ommand /c …
2. “command” /c …
3. command,/c …
4. backslash in the middle of a Unix command

The cmdLine transformation function avoids this problem by manipulating the variable contend in the following ways:

1. deleting all backslashes []
2. deleting all double quotes [“]
3. deleting all sigle quotes [‘]
4. deleting all carets [^]
5. deleting spaces before a slash /
6. deleting spaces before an open parentesis [(]
7. replacing all commas [,] and semicolon [;] into a space
8. replacing all multiple spaces (including tab, newline, etc.) into one space
9. transform all characters to lowercase

Example Usage:

SecRule ARGS “(?:command(?:.com)?|cmd(?:.exe)?)(?:/.*)?/[ck]” “phase:2,id:94,t:none, t:cmdLine”

0x4: compressWhitespace

Converts any of the whitespace characters (0x20, \f, \t, \n, \r, \v, 0xa0) to spaces (ASCII 0x20), compressing multiple consecutive space characters into one.

0x5: escapeSeqDecode

Decodes ANSI C escape sequences: \a, \b, \f, \n, \r, \t, \v, \, \?, \’, \”, \xHH (hexadecimal), \0OOO (octal). Invalid encodings are left in the output.

0x6: htmlEntityDecode

Decodes the characters encoded as HTML entities. The following variants are supported:

1. HH and HH; (where H is any hexadecimal number)
2. DDD and DDD; (where D is any decimal number)
3. “and”
4.  and

Allow unrestricted access from 192.168.1.100

SecRule REMOTE_ADDR “^192.168.1.100$” phase:1,id:95,nolog,allow

Prior to ModSecurity 2.5 the allow action would only affect the current phase. An allow in phase 1 would skip processing the remaining rules in phase 1 but the rules from phase 2 would execute. Starting with v2.5.0 allow was enhanced to allow for fine-grained control of what is done. The following rules now apply:

1. If used one its own, like in the example above, allow will affect the entire transaction, stopping processing of the current phase but also skipping over all other phases apart from the logging phase. (The logging phase is special; it is designed to always execute.)
2. If used with parameter “phase”, allow will cause the engine to stop processing the current phase. Other phases will continue as normal.
3. If used with parameter “request”, allow will cause the engine to stop processing the current phase. The next phase to be processed will be phase RESPONSE_HEADERS.

Examples:

Do not process request but process response.

SecAction phase:1,allow:request,id:96

Do not process transaction (request and response).

SecAction phase:1,allow,id:97
If you want to allow a response through, put a rule in phase RESPONSE_HEADERS and simply use allow on its own:

Allow response through.

SecAction phase:3,allow,id:98

0x3: append

1. Description: Appends text given as parameter to the end of response body. Content injection must be enabled (using the SecContentInjection directive). No content type checks are made, which means that before using any of the content injection actions, you must check whether the content type of the response is adequate for injection.
2. Action Group: Non-disruptive
3. Processing Phases: 3 and 4.
4. Example:
   SecRule RESPONSE_CONTENT_TYPE “^text/html” “nolog,id:99,pass,append:’

   ---

   Footer’”

0x4: auditlog

1. Description: Marks the transaction for logging in the audit log.
2. Action Group: Non-disruptive
3. Example:
   SecRule REMOTE_ADDR “^192.168.1.100$” auditlog,phase:1,id:100,allow

0x5: block

1. Description: Performs the disruptive action defined by the previous SecDefaultAction.
2. Action Group: Disruptive
   //This action is essentially a placeholder that is intended to be used by rule writers to request a blocking action, but without specifying how the blocking is to be done. The idea is that such decisions are best left to rule users, as well as to allow users, to override blocking if they so desire. In future versions of ModSecurity, more control and functionality will be added to define “how” to block.
3. Examples:

Specify how blocking is to be done

SecDefaultAction phase:2,deny,id:101,status:403,log,auditlog

Detect attacks where we want to block

SecRule ARGS attack1 phase:2,block,id:102

Detect attacks where we want only to warn

SecRule ARGS attack2 phase:2,pass,id:103

It is possible to use the SecRuleUpdateActionById directive to override how a rule handles blocking. This is useful in three cases:

1. If a rule has blocking hard-coded, and you want it to use the policy you determine
2. If a rule was written to block, but you want it to only warn
3. If a rule was written to only warn, but you want it to block

The following example demonstrates the first case, in which the hard-coded block is removed in favor of the user-controllable block:

Specify how blocking is to be done

SecDefaultAction phase:2,deny,status:403,log,auditlog,id:104

Detect attacks and block

SecRule ARGS attack phase:2,id:99998,deny

Change how rule ID 1 blocks

SecRuleUpdateActionById 1 block

0x6: capture

1. Description: When used together with the regular expression operator (@rx), the capture action will create copies of the regular expression captures and place them into the transaction variable collection.
2. Action Group: Non-disruptive
3. Example:
   SecRule REQUEST_BODY “^username=(\w{25,})” phase:2,capture,t:none,chain,id:105
   SecRule TX:1 “(?:(?:a(dmin|nonymous)))”
   Up to 10 captures will be copied on a successful pattern match, each with a name consisting of a digit from 0 to 9. The TX.0 variable always contains the entire area that the regular expression matched. All the other variables contain the captured values, in the order in which the capturing parentheses appear in the regular expression.

0x7: chain

1. Description: Chains the current rule with the rule that immediately follows it, creating a rule chain. Chained rules allow for more complex processing logic.
2. Action Group: Flow
3. Example:

Refuse to accept POST requests that do not contain Content-Length header.

(Do note that this rule should be preceded by a rule

that verifies only valid request methods are used.)

SecRule REQUEST_METHOD “^POST$” phase:1,chain,t:none,id:105
SecRule &REQUEST_HEADERS:Content-Length “@eq 0” t:none

The following directives can be used in rule chains:

1. SecAction
2. SecRule
3. SecRuleScript

Special rules control the usage of actions in chained rules:

1. Any actions that affect the rule flow (i.e., the disruptive actions, skip and skipAfter) can be used only in the chain starter. They will be executed only if the entire chain matches.
2. Non-disruptive rules can be used in any rule; they will be executed if the rule that contains them matches and not only when the entire chain matches.
3. The metadata actions (e.g., id, rev, msg) can be used only in the chain starter.

0x8: deny

1. Description: Stops rule processing and intercepts transaction.
2. Action Group: Disruptive
3. Example: SecRule REQUEST_HEADERS:User-Agent “nikto” “log,deny,id:107,msg:’Nikto Scanners Identified’”

0x9: msg

1. Description: Assigns a custom message to the rule or chain in which it appears. The message will be logged along with every alert.
2. Action Group: Meta-data
3. Example: SecRule &REQUEST_HEADERS:Host “@eq 0” “log,id:60008,severity:2,msg:’Request Missing a Host Header’”

0x10: phase

1. Description: Places the rule or chain into one of five available processing phases. It can also be used in SecDefaultAction to establish the rule defaults.
2. Action Group: Meta-data
3. Example:

Initialize IP address tracking in phase 1

SecAction phase:1,nolog,pass,id:126,initcol:IP=%{REMOTE_ADDR}

Starting in ModSecurity version v2.7 there are aliases for some phase numbers:

2 - request
4 - response
5 - logging
Example: SecRule REQUEST_HEADERS:User-Agent “Test” “phase:request,log,deny,id:127”

0x11: severity

1. Description: Assigns severity to the rule in which it is used.
2. Action Group: Meta-data
3. Example:
   SecRule REQUEST_METHOD “^PUT$” “id:340002,rev:1,severity:CRITICAL,msg:’Restricted HTTP function’”

Severity values in ModSecurity follows the numeric scale of syslog (where 0 is the most severe). The data below is used by the OWASP ModSecurity Core Rule Set (CRS):

0 - EMERGENCY: is generated from correlation of anomaly scoring data where there is an inbound attack and an outbound leakage.
1 - ALERT: is generated from correlation where there is an inbound attack and an outbound application level error.
2 - CRITICAL: Anomaly Score of 5. Is the highest severity level possible without correlation. It is normally generated by the web attack rules (40 level files).
3 - ERROR: Error - Anomaly Score of 4. Is generated mostly from outbound leakage rules (50 level files).
4 - WARNING: Anomaly Score of 3. Is generated by malicious client rules (35 level files).
5 - NOTICE: Anomaly Score of 2. Is generated by the Protocol policy and anomaly files.
6 - INFO
7 - DEBUG
//It is possible to specify severity levels using either the numerical values or the text values, but you should always specify severity levels using the text values, because it is difficult to remember what a number stands for. The use of the numerical values is deprecated as of version 2.5.0 and may be removed in one of the subsequent major updates.

0x12: t

1. Description: This action is used to specify the transformation pipeline to use to transform the value of each variable used in the rule before matching.
2. Action Group: Non-disruptive
3. Example:
   SecRule ARGS “(asfunction|javascript|vbscript|data|mocha|livescript):” “id:146,t:none,t:htmlEntityDecode,t:lowercase,t:removeNulls,t:removeWhitespace”
   //Any transformation functions that you specify in a SecRule will be added to the previous ones specified in SecDefaultAction. It is recommended that you always use t:none in your rules, which prevents them depending on the default configuration.

Relevant Link:

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#ModSecurityreg_Reference_Manual

1. Operators

0x1: beginsWith

1. Description: Returns true if the parameter string is found at the beginning of the input. Macro expansion is performed on the parameter string before comparison.
2. Example:

Detect request line that does not begin with “GET”

SecRule REQUEST_LINE “!@beginsWith GET” “id:99998,deny”

0x2: contains

1. Description: Returns true if the parameter string is found anywhere in the input. Macro expansion is performed on the parameter string before comparison.
2. Example:

Detect “.php” anywhere in the request line

SecRule REQUEST_LINE “@contains .php” “id:99998,deny”

0x3: detectSQLi

1. Description: Returns true if SQL injection payload is found. This operator uses LibInjection to detect SQLi attacks.
2. Example:

Detect SQL Injection inside request uri data”

SecRule REQUEST_URI “@detectSQLi” “id:99998,deny”

0x4: detectXSS

1. Description: Returns true if XSS injection is found. This operator uses LibInjection to detect XSS attacks.
2. Version: 2.8.0
3. Example:

Detect XSS Injection inside request body

SecRule REQUEST_BODY “\@detectXSS” “id:12345,log,deny”

0x5: fuzzyHash

1. Description: The fuzzyHash operator uses the ssdeep, which is a program for computing context triggered piecewise hashes (CTPH). Also called fuzzy hashes, CTPH can match inputs that have homologies. Such inputs have sequences of identical bytes in the same order, although bytes in between these sequences may be different in both content and length.
   //For further information on ssdeep, visit its site: http://ssdeep.sourceforge.net/
2. Version: v2.9.0-RC1+
3. Example:
   SecRule REQUEST_BODY “\@fuzzyHash /path/to/ssdeep/hashes.txt 6” “id:192372,log,deny”

0x6: eq

1. Description: Performs numerical comparison and returns true if the input value is equal to the provided parameter. Macro expansion is performed on the parameter string before comparison.
2. Example:

Detect exactly 15 request headers

SecRule &REQUEST_HEADERS_NAMES “@eq 15” “id:153”

0x7: ge

1. Description: Performs numerical comparison and returns true if the input value is greater than or equal to the provided parameter. Macro expansion is performed on the parameter string before comparison.
2. Example:

Detect 15 or more request headers

SecRule &REQUEST_HEADERS_NAMES “@ge 15” “id:154”

0x8: pm

1. Description: Performs a case-insensitive match of the provided phrases against the desired input value. The operator uses a set-based matching algorithm (Aho-Corasick), which means that it will match any number of keywords in parallel. When matching of a large number of keywords is needed, this operator performs much better than a regular expression.
2. Example:

Detect suspicious client by looking at the user agent identification

SecRule REQUEST_HEADERS:User-Agent “@pm WebZIP WebCopier Webster WebStripper … SiteSnagger ProWebWalker CheeseBot” “id:166”

0x9: rx

1. Description: Performs a regular expression match of the pattern provided as parameter. This is the default operator; the rules that do not explicitly specify an operator default to @rx.
2. Examples:

Detect Nikto

SecRule REQUEST_HEADERS:User-Agent “@rx nikto” phase:1,id:173,t:lowercase

Detect Nikto with a case-insensitive pattern

SecRule REQUEST_HEADERS:User-Agent “@rx (?i)nikto” phase:1,id:174,t:none

Detect Nikto with a case-insensitive pattern

SecRule REQUEST_HEADERS:User-Agent “(?i)nikto” “id:175”

Relevant Link:

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#ModSecurityreg_Reference_Manual

1. A Recommended Base Configuration

0x1: Impedance Mismatch(避免误拦截)

Web application firewalls have a difficult job trying to make sense of data that passes by, without any knowledge of the application and its business logic. The protection they provide comes from having an independent layer of security on the outside. Because data validation is done twice, security can be increased without having to touch the application. In some cases, however, the fact that everything is done twice brings problems. Problems can arise in the areas where the communication protocols are not well specified, or where either the device or the application do things that are not in the specification. In such cases it may be possible to design payload that will be interpreted in one way by one device and in another by the other device. This problem is better known as Impedance Mismatch. It can be exploited to evade the security devices.
While we will continue to enhance ModSecurity to deal with various evasion techniques the problem can only be minimized, but never solved. With so many different application backend chances are some will always do something completely unexpected. The only solution is to be aware of the technologies in the backend when writing rules, adapting the rules to remove the mismatch.

0x2: Impedance Mismatch with PHP Apps

When writing rules to protect PHP applications you need to pay attention to the following facts:

1. When “register_globals” is set to “On” request parameters are automatically converted to script variables. In some PHP versions it is even possible to override the $GLOBALS array.
2. Whitespace at the beginning of parameter names is ignored. (This is very dangerous if you are writing rules to target specific named variables.)
3. The remaining whitespace (in parameter names) is converted to underscores. The same applies to dots and to a “[“]if the variable name does not contain a matching closing bracket. (Meaning that if you want to exploit a script through a variable that contains an underscore in the name you can send a parameter with a whitespace or a dot instead.)
4. Cookies can be treated as request parameters.
5. The discussion about variable names applies equally to the cookie names.
6. The order in which parameters are taken from the request and the environment is EGPCS (environment, GET, POST, Cookies, built-in variables). This means that a POST parameter will overwrite the parameters transported on the request line (in QUERY_STRING).
7. When “magic_quotes_gpc” is set to “On” PHP will use backslash to escape the following characters: single quote, double quote, backslash, and the nul byte.
8. If “magic_quotes_sybase” is set to “On” only the single quote will be escaped using another single quote. In this case the “magic_quotes_gpc” setting becomes irrelevant. The “magic_quotes_sybase” setting completely overrides the “magic_quotes_gpc” behaviour but “magic_quotes_gpc” still must be set to “On” for the Sybase-specific quoting to be work.
9. PHP will also automatically create nested arrays for you. For example “p[x][y]=1” results in a total of three variables.

Relevant Link:

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#ModSecurityreg_Reference_Manual

Copyright (c) 2015 LittleHann All rights reserved