Difference between revisions of "ModSecurity: Write Rules"

From OnnoWiki
Jump to navigation Jump to search
 
Line 1: Line 1:
 
Sumber: https://support.kemptechnologies.com/hc/en-us/articles/209635223-How-to-write-a-WAF-rule-Modsecurity-Rule-Writing
 
Sumber: https://support.kemptechnologies.com/hc/en-us/articles/209635223-How-to-write-a-WAF-rule-Modsecurity-Rule-Writing
  
 +
The ModSecurity Reference Manual should be consulted in any cases where questions arise relating to the syntax of commands:
  
 
+
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual
 
 
 
 
2ModSecurity Rule Writing
 
 
 
The ModSecurity Reference Manual should be consulted in any cases where questions arise relating to the syntax of commands: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual
 
  
 
In terms of rule writing, the main directive to know is SecRule, which is used to create rules and thus does most of the work.
 
In terms of rule writing, the main directive to know is SecRule, which is used to create rules and thus does most of the work.
 
 
Every rule defined by SecRule conforms to the same format, as below:
 
Every rule defined by SecRule conforms to the same format, as below:
  
SecRule VARIABLES OPERATOR \ [TRANSFORMATION_FUNCTIONS,ACTIONS]
+
SecRule VARIABLES OPERATOR \ [TRANSFORMATION_FUNCTIONS,ACTIONS]
 
 
Figure 2‑1: Rule Syntax
 
  
 
The rule consists of four parts:
 
The rule consists of four parts:
  
    VARIABLES: Tells the WAF engine where to look in the transactional data.
+
VARIABLES: Tells the WAF engine where to look in the transactional data.
    OPERATOR: Tells the WAF engine how to process the variable data.
+
OPERATOR: Tells the WAF engine how to process the variable data.
    TRANSFORMATION_FUNCTIONS: Tells the WAF engine how to normalize data before an operator is applied.
+
TRANSFORMATION_FUNCTIONS: Tells the WAF engine how to normalize data before an operator is applied.
    ACTIONS: Tells the WAF engine what to do if a rule matches.
+
ACTIONS: Tells the WAF engine what to do if a rule matches.
  
 
The four parts are explained in the sections below.
 
The four parts are explained in the sections below.
2.1Variables
+
 
 +
==Variables==
  
 
This specifies which places to check in a HTTP transaction. Examples of variables include:
 
This specifies which places to check in a HTTP transaction. Examples of variables include:
  
    ARGS – all arguments including the POST payload
+
ARGS – all arguments including the POST payload
    REQUEST_METHOD – request method used in the transaction
+
REQUEST_METHOD – request method used in the transaction
    REQUEST_HEADERS – can be used as either a collection of all of the request headers or can be used to inspect selected headers
+
REQUEST_HEADERS – can be used as either a collection of all of the request headers or can be used to inspect selected headers
    Etc. The full list of variables is available here: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Variables
+
Etc. The full list of variables is available here: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Variables
 +
 
 +
==Operator==
 +
 
 +
This specifies a regular expression, pattern or keyword to be checked in the variable(s). Operators begin with the @ character. The full list of operators is available here:
  
2.2Operator
+
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Operators
  
This specifies a regular expression, pattern or keyword to be checked in the variable(s). Operators begin with the @ character. The full list of operators is available here: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Operators
+
==Transformation Functions==
2.3Transformation Functions
 
  
 
There are a number of transformation functions that can be performed, for example:
 
There are a number of transformation functions that can be performed, for example:
  
    Anti-evasion (such as lowercase, normalisePath, removeNulls, replaceComments, compressWhitespace)
+
Anti-evasion (such as lowercase, normalisePath, removeNulls, replaceComments, compressWhitespace)
    Decoding (such as base64Decode, hexDecode, jsDecode, urlDecodeUni)
+
Decoding (such as base64Decode, hexDecode, jsDecode, urlDecodeUni)
    Encoding (such as base64Encode, hexEncode)
+
Encoding (such as base64Encode, hexEncode)
    Hashing (such as sha1, md5)
+
Hashing (such as sha1, md5)
  
2.4Actions
+
==Actions==
  
 
This specifies what to do if the rule matches. Actions are defined in seven categories, listed below:
 
This specifies what to do if the rule matches. Actions are defined in seven categories, listed below:
  
    Disruptive – used to allow ModSecurity to take an action, for example allow or block
+
Disruptive – used to allow ModSecurity to take an action, for example allow or block
    Flow – affect the flow, for example skip
+
Flow – affect the flow, for example skip
    Meta-data – used to provide more information about rules
+
Meta-data – used to provide more information about rules
    Variable – used to set, change and remove variables
+
Variable – used to set, change and remove variables
    Logging – used to influence the way logging takes place
+
Logging – used to influence the way logging takes place
    Special – used to provide access to another class of functionality
+
Special – used to provide access to another class of functionality
    Miscellaneous – contain actions that do not belong in any other groups.
+
Miscellaneous – contain actions that do not belong in any other groups.
  
 
If no actions are provided, default actions apply as per SecDefaultAction (phase:2,log,auditlog,pass). The full list of actions are available here:
 
If no actions are provided, default actions apply as per SecDefaultAction (phase:2,log,auditlog,pass). The full list of actions are available here:
  
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Actions
+
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Actions
  
 
When constructing the rules, you can specify at what phase the rule should run. Specifying the correct phase can be beneficial in order to reduce CPU processing.
 
When constructing the rules, you can specify at what phase the rule should run. Specifying the correct phase can be beneficial in order to reduce CPU processing.
2.5Rule Syntax
+
 
 +
==Rule Syntax==
  
 
The following rule looks at the request Uniform Resource Identifier (URI) and tries to match the regular expression pattern <script> against it. The double quotes are used because the second parameter contains a space:
 
The following rule looks at the request Uniform Resource Identifier (URI) and tries to match the regular expression pattern <script> against it. The double quotes are used because the second parameter contains a space:
  
SecRule REQUEST_URI “@rx <script>”
+
SecRule REQUEST_URI “@rx <script>”
  
 
To split a long line into two, use a single backslash character, followed by a new line:
 
To split a long line into two, use a single backslash character, followed by a new line:
  
SecRule ARGS KEYWORD \
+
SecRule ARGS KEYWORD \
 
+
phase:1,t:none,block
phase:1,t:none,block
 
  
 
Multiple variables can be used in a rule as long as they are separated using the pipe character, for example:
 
Multiple variables can be used in a rule as long as they are separated using the pipe character, for example:
  
SecRule REQUEST_URI|REQUEST_PROTOCOL <script>
+
SecRule REQUEST_URI|REQUEST_PROTOCOL <script>
  
 
The SecDefaultAction directive is used if no actions are defined for a rule. For example, the following rule:
 
The SecDefaultAction directive is used if no actions are defined for a rule. For example, the following rule:
  
SecRule ARGS D1
+
SecRule ARGS D1
  
 
Is equivalent to:
 
Is equivalent to:
  
SecRule ARGS D1 phase2:log:auditlog,pass
+
SecRule ARGS D1 phase2:log:auditlog,pass
2.5.1Rule Example 1 – Cross Site Scripting (XSS) Attack
+
 
 +
 
 +
===Rule Example 1 – Cross Site Scripting (XSS) Attack===
  
 
The following rule is used to avoid XSS attacks by checking for a <script> pattern in the request parameters and header and generates an ‘XSS Attack’ message with a 404 status response.
 
The following rule is used to avoid XSS attacks by checking for a <script> pattern in the request parameters and header and generates an ‘XSS Attack’ message with a 404 status response.
  
SecRule ARGS|REQUEST_HEADERS “@rx <script>” id:101,msg: ‘XSS Attack’,severity:ERROR,deny,status:404
+
SecRule ARGS|REQUEST_HEADERS “@rx <script>” id:101,msg: ‘XSS Attack’,severity:ERROR,deny,status:404
2.5.1.1Variables
+
 
 +
====Variables====
  
 
Details about the variables in this rule example are in the table below:
 
Details about the variables in this rule example are in the table below:
Line 97: Line 97:
 
Variable
 
Variable
 
 
 
 
Definition
 
Definition
 
 
ARGS
 
ARGS
 
 
 
 
Request parameters
 
Request parameters
 
 
REQUEST_HEADERS
 
REQUEST_HEADERS
 
 
  
 
All of the request headers
 
All of the request headers
2.5.1.2Operator
+
 
 +
====Operator====
  
 
“@rx <script>” – Performs a regular expression match of the pattern (in this case <script>) provided as a parameter.
 
“@rx <script>” – Performs a regular expression match of the pattern (in this case <script>) provided as a parameter.
2.5.1.3Actions
+
 
 +
 
 +
====Actions====
  
 
Details of the actions contained in this rule example are provided in the table below:
 
Details of the actions contained in this rule example are provided in the table below:
Line 118: Line 117:
 
Action(s)
 
Action(s)
 
 
 
 
Description
 
Description
 
+
id, msg, severity, deny, status
id, msg, severity, deny, status
 
 
  
 
These are all of the actions to be performed if the pattern is matched.
 
These are all of the actions to be performed if the pattern is matched.
 
 
id:101
 
id:101
 
 
  
 
The unique ID that is assigned to the rule (or chain) in which it appears.
 
The unique ID that is assigned to the rule (or chain) in which it appears.
 
 
msg: “XSS Attack”
 
msg: “XSS Attack”
 
 
Line 136: Line 130:
 
The custom message (i.e. XSS Attack) assigned to the rule (or chain) in which it appears.
 
The custom message (i.e. XSS Attack) assigned to the rule (or chain) in which it appears.
  
Severity:ERROR
+
Severity:ERROR
 
 
  
Line 142: Line 136:
  
 
EMERGENCY (0)
 
EMERGENCY (0)
 
 
ALERT (1)
 
ALERT (1)
 
 
CRITICAL (2)
 
CRITICAL (2)
 
 
ERROR (3)
 
ERROR (3)
 
 
WARNING (4)
 
WARNING (4)
 
 
NOTICE (5)
 
NOTICE (5)
 
 
INFO (6)
 
INFO (6)
 
 
DEBUG (7)
 
DEBUG (7)
  
Line 164: Line 151:
 
status:404
 
status:404
 
 
 +
This specifies the response status code (404) with actions deny and redirect.
  
This specifies the response status code (404) with actions deny and redirect.
+
===Rule Example 2 – Whitelist IP Address===
2.5.2Rule Example 2 – Whitelist IP Address
 
  
 
The following example shows how to whitelist an IP address to bypass the ModSecurity engine:
 
The following example shows how to whitelist an IP address to bypass the ModSecurity engine:
  
SecRule REMOTE_ADDR “@ipMatch 192.168.1.101” \
+
SecRule REMOTE_ADDR “@ipMatch 192.168.1.101” \
 +
id:102,phase:1,t:none,nolog,pass,ctl:ruleEngine=off
  
id:102,phase:1,t:none,nolog,pass,ctl:ruleEngine=off
+
====Variables====
2.5.2.1Variables
 
  
 
Variable Name:REMOTE_ADDR
 
Variable Name:REMOTE_ADDR
 +
Variable Definition: The IP address of the remote client
  
Variable Definition: The IP address of the remote client
+
====Operator====
2.5.2.2Operator
 
  
 
“@ipMatch 192.168.1.101” – Performs an IPv4 or IPv6 match of the REMOTE_ADDR variable data. In this care – this is the whitelisted IP address.
 
“@ipMatch 192.168.1.101” – Performs an IPv4 or IPv6 match of the REMOTE_ADDR variable data. In this care – this is the whitelisted IP address.
2.5.2.3Actions
+
 
 +
====Actions====
  
 
Action(s)
 
Action(s)
 
 
 
 
Description
 
Description
 
 
id:101
 
id:101
 
  
 
The unique ID that is assigned to the rule (or chain) in which it appears.
 
The unique ID that is assigned to the rule (or chain) in which it appears.
Line 195: Line 180:
 
phase:1
 
phase:1
 
 
 
 
Places the rule (or chain) in Phase 1 processing. There are five phases, including:
 
Places the rule (or chain) in Phase 1 processing. There are five phases, including:
  
Request Headers (1)
+
Request Headers (1)
 
+
Request Body (2)
Request Body (2)
+
Response Headers (3)
 
+
Response Body (4)
Response Headers (3)
+
Logging (5)
 
 
Response Body (4)
 
 
 
Logging (5)
 
  
 
t:none
 
t:none
 
 
 
 
Indicates that no action is used to transform the value of the variable used in the rule before matching. For example, t:utf8toUnicode converts all UTF-8 character sequences to Unicode to assist in input normalization.
 
Indicates that no action is used to transform the value of the variable used in the rule before matching. For example, t:utf8toUnicode converts all UTF-8 character sequences to Unicode to assist in input normalization.
  
Line 219: Line 198:
  
 
pass
 
pass
 
 
 
Continues processing with the next rule in spite of a successful match.
 
Continues processing with the next rule in spite of a successful match.
  
Line 227: Line 204:
  
 
This action changes ModSecurity configuration on a transient, per-transaction basis. This only affects the transaction in which the action is executed. In this case, the ModSecurity rule engine is turned off.
 
This action changes ModSecurity configuration on a transient, per-transaction basis. This only affects the transaction in which the action is executed. In this case, the ModSecurity rule engine is turned off.
2.5.3Rule Example 3 – Chaining Rules
+
 
 +
====Rule Example 3 – Chaining Rules====
  
 
Chained rules allow for more complex rule matches where a number of different VARIABLES are used to create a better rule and to help prevent false positives. In programming language concepts – think of chained rules as somewhat similar to AND conditional statements. The actions specified in the first portion of the chained rule will only be triggered if all of the variable checks return positive hits. If one aspect of the chained rule is negative, then the entire rule chain is negative. The most unique portion should be specified on the first line – this will reduce the number of “normal” requests that will have to be evaluated against the rest of the chained rule set.
 
Chained rules allow for more complex rule matches where a number of different VARIABLES are used to create a better rule and to help prevent false positives. In programming language concepts – think of chained rules as somewhat similar to AND conditional statements. The actions specified in the first portion of the chained rule will only be triggered if all of the variable checks return positive hits. If one aspect of the chained rule is negative, then the entire rule chain is negative. The most unique portion should be specified on the first line – this will reduce the number of “normal” requests that will have to be evaluated against the rest of the chained rule set.
Line 233: Line 211:
 
In addition to using a number of different VARIABLES in the one rule, it is also possible to chain more than one rule. Below is an example of chaining two rules. In this example, the first rule checks if the username (ARGS:username) for the string admin (streq admin) using a string comparison. If the first rule holds true, the second rule is activated which denies all requests that are not from the REMOTE_ADDR 192.168.1.111 IP Address (!streq 192.168.1.111).
 
In addition to using a number of different VARIABLES in the one rule, it is also possible to chain more than one rule. Below is an example of chaining two rules. In this example, the first rule checks if the username (ARGS:username) for the string admin (streq admin) using a string comparison. If the first rule holds true, the second rule is activated which denies all requests that are not from the REMOTE_ADDR 192.168.1.111 IP Address (!streq 192.168.1.111).
  
SecRule ARGS:username “@streq admin” chain,deny
+
SecRule ARGS:username “@streq admin” chain,deny
 +
SecRule REMOTE_ADDR “!streq 192.168.1.111”
  
SecRule REMOTE_ADDR “!streq 192.168.1.111”
 
 
2.5.4Rule Example 4 – Shellshock Bash Attack
 
2.5.4Rule Example 4 – Shellshock Bash Attack
  
 
This section shows an example of the rules requires to mitigate the Shellshock Bash attack. There are two rules needed in this case. Details of both rules are provided in the sections below.
 
This section shows an example of the rules requires to mitigate the Shellshock Bash attack. There are two rules needed in this case. Details of both rules are provided in the sections below.
 +
 
2.5.4.1First Rule
 
2.5.4.1First Rule
  
 
This is the first rule:
 
This is the first rule:
  
SecRule REQUEST_LINE|REQUEST_HEADERS|REQUEST_HEADERS_NAMES "@contains () {" "phase:1,id:'2100080',block,t:none,t:utf8toUnicode,t:urlDecodeUni,t:compressWhitespace,msg:'SLR: Bash ENV Variable Injection Attack',tag:'CVE-2014-6271',tag:'http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271',tag:'https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/'"
+
SecRule REQUEST_LINE|REQUEST_HEADERS|REQUEST_HEADERS_NAMES "@contains () {" "phase:1,id:'2100080',block,t:none,t:utf8toUnicode,t:urlDecodeUni,t:compressWhitespace,msg:'SLR: Bash ENV Variable Injection Attack',tag:'CVE-2014-6271',tag:'http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271',tag:'https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/'"
 +
 
 
2.5.4.1.1Variables
 
2.5.4.1.1Variables
  
Line 283: Line 263:
  
 
Request Headers (1)
 
Request Headers (1)
 
 
Request Body (2)
 
Request Body (2)
 
 
Response Headers (3)
 
Response Headers (3)
 
 
Response Body (4)
 
Response Body (4)
 
 
Logging (5)
 
Logging (5)
  
id:'2100080'
+
id:'2100080'
 
 
  
Line 327: Line 303:
 
The custom message (i.e. XSS Attack) assigned to the rule (or chain) in which it appears.
 
The custom message (i.e. XSS Attack) assigned to the rule (or chain) in which it appears.
  
tag:'http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271'
+
tag:'http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271'
 
+
tag:'https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/'
tag:'https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/'
 
 
 
  
 
Assigns a tag (category) to a rule (or chain). This is metadata allows easy automated categorization of events. Multiple tags can be specified on the same rule.
 
Assigns a tag (category) to a rule (or chain). This is metadata allows easy automated categorization of events. Multiple tags can be specified on the same rule.
 +
 
2.5.4.2Second Rule
 
2.5.4.2Second Rule
  
 
The second rule is as follows:
 
The second rule is as follows:
  
SecRule REQUEST_BODY "@contains () {" "phase:2,id:'2100081',block,t:none,t:utf8toUnicode,t:urlDecodeUni,t:compressWhitespace,msg:'SLR: Bash ENV Variable Injection Attack',tag:'CVE-2014-6271',tag:'http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271',tag:'https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/'"
+
SecRule REQUEST_BODY "@contains () {" "phase:2,id:'2100081',block,t:none,t:utf8toUnicode,t:urlDecodeUni,t:compressWhitespace,msg:'SLR: Bash ENV Variable Injection Attack',tag:'CVE-2014-6271',tag:'http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271',tag:'https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/'"
 +
 
 
2.1.4.2.1Variables
 
2.1.4.2.1Variables
  
Line 359: Line 336:
  
 
Request Headers (1)
 
Request Headers (1)
 
 
Request Body (2)
 
Request Body (2)
 
 
Response Headers (3)
 
Response Headers (3)
 
 
Response Body (4)
 
Response Body (4)
 
 
Logging (5)
 
Logging (5)
  
Line 403: Line 376:
 
The custom message (i.e. XSS Attack) assigned to the rule (or chain) in which it appears.
 
The custom message (i.e. XSS Attack) assigned to the rule (or chain) in which it appears.
  
tag:'http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271'
+
tag:'http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271'
 
+
tag:'https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/'
tag:'https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/'
 
 
 
  
 
Assigns a tag (category) to a rule (or chain). This is metadata which allows easy automated categorization of events. Multiple tags can be specified on the same rule.
 
Assigns a tag (category) to a rule (or chain). This is metadata which allows easy automated categorization of events. Multiple tags can be specified on the same rule.
 +
 
2.6KEMP WUI Settings
 
2.6KEMP WUI Settings
  
Line 436: Line 409:
 
SecDefaultAction phase:2,deny,id:101,status:403,log,auditlog
 
SecDefaultAction phase:2,deny,id:101,status:403,log,auditlog
  
SecRule ARGS attack2 phase:2,pass,id:103
+
SecRule ARGS attack2 phase:2,pass,id:103
 
+
SecRule ARGS attack1 phase:2,block,id:102
SecRule ARGS attack1 phase:2,block,id:102
 
  
 
   
 
   
Line 448: Line 420:
 
By using the SecRuleUpdateActionById against rule Id 1 and indicating block, we are associating the first rule action to that of the SecDefaultAction which is pass. So in the case, the first rule would pass based on meeting the successful conditions associated with the rule; it would not deny.
 
By using the SecRuleUpdateActionById against rule Id 1 and indicating block, we are associating the first rule action to that of the SecDefaultAction which is pass. So in the case, the first rule would pass based on meeting the successful conditions associated with the rule; it would not deny.
  
SecDefaultAction phase:2,pass,log,auditlog
+
SecDefaultAction phase:2,pass,log,auditlog
 
+
SecRule ARGS attack1 phase:2,deny,id:1
SecRule ARGS attack1 phase:2,deny,id:1
+
SecRuleUpdateActionById 1 block
  
SecRuleUpdateActionById 1 block
 
 
3Managing Custom WAF Rules in the LoadMaster
 
3Managing Custom WAF Rules in the LoadMaster
 
3.1Add a Custom Rule
 
3.1Add a Custom Rule

Latest revision as of 13:25, 1 June 2017

Sumber: https://support.kemptechnologies.com/hc/en-us/articles/209635223-How-to-write-a-WAF-rule-Modsecurity-Rule-Writing

The ModSecurity Reference Manual should be consulted in any cases where questions arise relating to the syntax of commands:

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

In terms of rule writing, the main directive to know is SecRule, which is used to create rules and thus does most of the work. Every rule defined by SecRule conforms to the same format, as below:

SecRule VARIABLES OPERATOR \ [TRANSFORMATION_FUNCTIONS,ACTIONS]

The rule consists of four parts:

VARIABLES: Tells the WAF engine where to look in the transactional data.
OPERATOR: Tells the WAF engine how to process the variable data.
TRANSFORMATION_FUNCTIONS: Tells the WAF engine how to normalize data before an operator is applied.
ACTIONS: Tells the WAF engine what to do if a rule matches.

The four parts are explained in the sections below.

Variables

This specifies which places to check in a HTTP transaction. Examples of variables include:

ARGS – all arguments including the POST payload
REQUEST_METHOD – request method used in the transaction
REQUEST_HEADERS – can be used as either a collection of all of the request headers or can be used to inspect selected headers
Etc. The full list of variables is available here: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Variables

Operator

This specifies a regular expression, pattern or keyword to be checked in the variable(s). Operators begin with the @ character. The full list of operators is available here:

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

Transformation Functions

There are a number of transformation functions that can be performed, for example:

Anti-evasion (such as lowercase, normalisePath, removeNulls, replaceComments, compressWhitespace)
Decoding (such as base64Decode, hexDecode, jsDecode, urlDecodeUni)
Encoding (such as base64Encode, hexEncode)
Hashing (such as sha1, md5)

Actions

This specifies what to do if the rule matches. Actions are defined in seven categories, listed below:

Disruptive – used to allow ModSecurity to take an action, for example allow or block
Flow – affect the flow, for example skip
Meta-data – used to provide more information about rules
Variable – used to set, change and remove variables
Logging – used to influence the way logging takes place
Special – used to provide access to another class of functionality
Miscellaneous – contain actions that do not belong in any other groups.

If no actions are provided, default actions apply as per SecDefaultAction (phase:2,log,auditlog,pass). The full list of actions are available here:

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

When constructing the rules, you can specify at what phase the rule should run. Specifying the correct phase can be beneficial in order to reduce CPU processing.

Rule Syntax

The following rule looks at the request Uniform Resource Identifier (URI) and tries to match the regular expression pattern <script> against it. The double quotes are used because the second parameter contains a space:

SecRule REQUEST_URI “@rx <script>”

To split a long line into two, use a single backslash character, followed by a new line:

SecRule ARGS KEYWORD \
phase:1,t:none,block

Multiple variables can be used in a rule as long as they are separated using the pipe character, for example:

SecRule REQUEST_URI|REQUEST_PROTOCOL <script>

The SecDefaultAction directive is used if no actions are defined for a rule. For example, the following rule:

SecRule ARGS D1

Is equivalent to:

SecRule ARGS D1 phase2:log:auditlog,pass


Rule Example 1 – Cross Site Scripting (XSS) Attack

The following rule is used to avoid XSS attacks by checking for a <script> pattern in the request parameters and header and generates an ‘XSS Attack’ message with a 404 status response.

SecRule ARGS|REQUEST_HEADERS “@rx <script>” id:101,msg: ‘XSS Attack’,severity:ERROR,deny,status:404

Variables

Details about the variables in this rule example are in the table below:

Variable

Definition ARGS

Request parameters REQUEST_HEADERS


All of the request headers

Operator

“@rx <script>” – Performs a regular expression match of the pattern (in this case <script>) provided as a parameter.


Actions

Details of the actions contained in this rule example are provided in the table below:

Action(s)

Description id, msg, severity, deny, status

These are all of the actions to be performed if the pattern is matched. id:101


The unique ID that is assigned to the rule (or chain) in which it appears. msg: “XSS Attack”


The custom message (i.e. XSS Attack) assigned to the rule (or chain) in which it appears.

Severity:ERROR


The severity of the rule. Severities include:

EMERGENCY (0) ALERT (1) CRITICAL (2) ERROR (3) WARNING (4) NOTICE (5) INFO (6) DEBUG (7)

deny


This stops rule processing and intercepts transaction. This is a disruptive action.

status:404

This specifies the response status code (404) with actions deny and redirect.

Rule Example 2 – Whitelist IP Address

The following example shows how to whitelist an IP address to bypass the ModSecurity engine:

SecRule REMOTE_ADDR “@ipMatch 192.168.1.101” \
id:102,phase:1,t:none,nolog,pass,ctl:ruleEngine=off

Variables

Variable Name:REMOTE_ADDR Variable Definition: The IP address of the remote client

Operator

“@ipMatch 192.168.1.101” – Performs an IPv4 or IPv6 match of the REMOTE_ADDR variable data. In this care – this is the whitelisted IP address.

Actions

Action(s)

Description id:101

The unique ID that is assigned to the rule (or chain) in which it appears.

phase:1

Places the rule (or chain) in Phase 1 processing. There are five phases, including:

Request Headers (1)
Request Body (2)
Response Headers (3)
Response Body (4)
Logging (5)

t:none

Indicates that no action is used to transform the value of the variable used in the rule before matching. For example, t:utf8toUnicode converts all UTF-8 character sequences to Unicode to assist in input normalization.

nolog


Prevents rule matches from appearing in both the error and audit logs.

pass Continues processing with the next rule in spite of a successful match.

ctl:ruleEngine=off


This action changes ModSecurity configuration on a transient, per-transaction basis. This only affects the transaction in which the action is executed. In this case, the ModSecurity rule engine is turned off.

Rule Example 3 – Chaining Rules

Chained rules allow for more complex rule matches where a number of different VARIABLES are used to create a better rule and to help prevent false positives. In programming language concepts – think of chained rules as somewhat similar to AND conditional statements. The actions specified in the first portion of the chained rule will only be triggered if all of the variable checks return positive hits. If one aspect of the chained rule is negative, then the entire rule chain is negative. The most unique portion should be specified on the first line – this will reduce the number of “normal” requests that will have to be evaluated against the rest of the chained rule set.

In addition to using a number of different VARIABLES in the one rule, it is also possible to chain more than one rule. Below is an example of chaining two rules. In this example, the first rule checks if the username (ARGS:username) for the string admin (streq admin) using a string comparison. If the first rule holds true, the second rule is activated which denies all requests that are not from the REMOTE_ADDR 192.168.1.111 IP Address (!streq 192.168.1.111).

SecRule ARGS:username “@streq admin” chain,deny
SecRule REMOTE_ADDR “!streq 192.168.1.111”

2.5.4Rule Example 4 – Shellshock Bash Attack

This section shows an example of the rules requires to mitigate the Shellshock Bash attack. There are two rules needed in this case. Details of both rules are provided in the sections below.

2.5.4.1First Rule

This is the first rule:

SecRule REQUEST_LINE|REQUEST_HEADERS|REQUEST_HEADERS_NAMES "@contains () {" "phase:1,id:'2100080',block,t:none,t:utf8toUnicode,t:urlDecodeUni,t:compressWhitespace,msg:'SLR: Bash ENV Variable Injection Attack',tag:'CVE-2014-6271',tag:'http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271',tag:'https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/'"

2.5.4.1.1Variables

Details about the variables in this example rule are provided in the table below:

Variable


Definition

REQUEST_LINE


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

REQUEST_HEADERS


All of the request headers

REQUEST_HEADERS_NAMES


All of the names of the request headers. 2.5.4.1.2Operator

"@contains () {" – Checks the REQUEST_LINE|REQUEST_HEADERS|REQUEST_HEADERS_NAMES variables for the string ‘() {’ and returns true if found. 2.5.4.1.3Actions

Action(s)


Description

phase:1


Places the rule (or chain) in Phase 1 processing. There are five phases, including:

Request Headers (1) Request Body (2) Response Headers (3) Response Body (4) Logging (5)

id:'2100080'


The unique ID that is assigned to this rule (or chain) in which it appears.

block


This performs the disruptive action defined by the previous SecDefaultAction. This allows rule writers to request a blocking action without specifying how the blocking is to be done. The SecRuleUpdateActionById directive allows you to override how a rule handles blocking. Please refer to Rule Block Function for further details.

t:none


Indicates that no action is used to transform the value of the variable used in the rule before matching.

t:utf8toUnicode


Converts all UTF-8 character sequences to Unicode to assist in input normalization.

t:urlDecodeUni


Decodes a URL-encoded input string with support for the Microsoft-specific %u encoding.

t: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.

msg:'SLR: Bash ENV Variable Injection Attack',tag:'CVE-2014-6271'


The custom message (i.e. XSS Attack) assigned to the rule (or chain) in which it appears.

tag:'http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271'
tag:'https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/'


Assigns a tag (category) to a rule (or chain). This is metadata allows easy automated categorization of events. Multiple tags can be specified on the same rule.

2.5.4.2Second Rule

The second rule is as follows:

SecRule REQUEST_BODY "@contains () {" "phase:2,id:'2100081',block,t:none,t:utf8toUnicode,t:urlDecodeUni,t:compressWhitespace,msg:'SLR: Bash ENV Variable Injection Attack',tag:'CVE-2014-6271',tag:'http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271',tag:'https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/'"

2.1.4.2.1Variables

Variable Name:REQUEST_BODY

Variable Definition: All of the request body. 2.1.4.2.2Operator

"@contains () {" – Checks the REQUEST_BODY variable for the string ‘() {’ and returns true if found. 2.1.4.2.3Actions

Action(s)


Description

phase:2


Places the rule (or chain) in Phase 2 processing. There are five phases, including:

Request Headers (1) Request Body (2) Response Headers (3) Response Body (4) Logging (5)

id:'2100081'


The unique ID that is assigned to this rule (or chain) in which it appears.

block


This performs the disruptive action defined by the previous SecDefaultAction. This allows rule writers to request a blocking action, but without specifying how the blocking is to be done. The SecRuleUpdateActionById directive allows you to override how a rule handles blocking. Please refer to Rule Block Function for further details.

t:none


Indicates that no action is used to transform the value of the variable used in the rule before matching.

t:utf8toUnicode


Converts all UTF-8 character sequences to Unicode to assist in input normalization.

t:urlDecodeUni


Decodes a URL-encoded input string with support for the Microsoft-specific %u encoding.

t: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.

msg:'SLR: Bash ENV Variable Injection Attack',tag:'CVE-2014-6271'


The custom message (i.e. XSS Attack) assigned to the rule (or chain) in which it appears.

tag:'http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271'
tag:'https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/'


Assigns a tag (category) to a rule (or chain). This is metadata which allows easy automated categorization of events. Multiple tags can be specified on the same rule.

2.6KEMP WUI Settings

In the LoadMaster Web User Interface (WUI), WAF settings can be configured for each individual Virtual Service.

Figure 2‑2: WAF Options

In the WAF Options section of the Virtual Service modify screen (Virtual Services > View/Modify Services > Modify), there is a drop-down list called Default Operation. The Default Operation can be set to Audit Only or Block Mode.

The Audit Only mode of operation sets the SecDefaultAction to phase:2,log,auditlog,pass.

The Block Mode of operation sets the SecDefaultAction to phase:2,log,auditlog,block,drop. 2.7Rule Block Function

The rule block function is quite complicated. This section offers further explanation of the rule block function. The following example has been taken from https://github.com/Spiderlabs/ModSecurity/wiki/Reference-Manual#block and further explanatory text has been added.

The block action is essentially a placeholder that is intended to be used by rule writes to request a blocking action, but without specifying how the blocking is to be done. The SecDefaultAction command specifies how the blocking is to be done. The block action is a placeholder that will be replaced by the action from the last SecDefaultAction in the same context.



Block Example 1

The following example shows the SecDefaultAction set to deny. The second rule will “deny” because the SecDefaultAction is set to deny.

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

SecRule ARGS attack2 phase:2,pass,id:103
SecRule ARGS attack1 phase:2,block,id:102


Block Example 2

The following example shows the usage of the SecRuleUpdateActionById command to override how a rule handles blocking. The SecRuleUpdateActionById command allows a rule to be reverted back to the previous SecDefaultAction. In this example, the first rule (SecRule ARGS attack1 phase:2,deny,id:1) would deny based on meeting the successful conditions associated with the rule.

By using the SecRuleUpdateActionById against rule Id 1 and indicating block, we are associating the first rule action to that of the SecDefaultAction which is pass. So in the case, the first rule would pass based on meeting the successful conditions associated with the rule; it would not deny.

SecDefaultAction phase:2,pass,log,auditlog
SecRule ARGS attack1 phase:2,deny,id:1
SecRuleUpdateActionById 1 block

3Managing Custom WAF Rules in the LoadMaster 3.1Add a Custom Rule

Follow the steps below to find out how to add custom WAF rules in the Web User Interface (WUI) of the LoadMaster:

   In the main menu, select Virtual Services > WAF Settings.

Figure 3‑1: WAF Rule Management

   To upload custom rules, click Choose File in the Installed Rules section.

Individual rules can be uploaded as .conf files, or you can load a package of rules in a tar.gz file.

   Browse to and select the rules to be uploaded.
   To upload any additional data files, click Choose File in the Custom Rule Data section.

The additional files are for the rules’ associated data files. If using a Tarball, the rules and data files can be packaged together.

   Browse to and select the additional data files.
   Click Add Ruleset.

The rules will now be available to assign within the Virtual Services modify screen (Virtual Services > View/Modify Services > Modify). Refer to the Section 4 to find out how to configure the Virtual Service. 3.2Delete/Download a Custom Rule or Data File

Figure 3‑2: Custom Rules

Custom rules and data files can be deleted or downloaded by clicking the relevant buttons.

If a rule is assigned to a Virtual Service, it will not be available for deletion. 4Assigning Custom Rules to a Virtual Service

Custom rules can be assigned as needed to each individual Virtual Service. Follow the steps below to assign.

   In the main menu of the LoadMaster WUI, select Virtual Services >View/Modify Services.

Figure 4‑1: Section of the Virtual Services screen

   Click Modify on the relevant Virtual Service.
   Expand the WAF Options section.

Figure 4‑2: WAF Options

   Select Enabled.

A message will be displayed next to the Enabled check box displaying how many WAF-enabled Virtual Services exist and it will also display the maximum number of WAF-enabled Virtual Services that can exist. If the maximum number of WAF-enabled Virtual Services have been reached, the Enabled check box will be greyed out.

   Assign rulesets by ticking them in the Available Rulesets section.
   Individual rules can be enabled/disabled per ruleset by ticking/unticking them in the box on the right.Rules can be filtered by entering a filter term in the Rule Filter text box.Clicking Clear All will disable all rules for the selected ruleset.Clicking Set All will enable all rules for the selected ruleset.Clicking the Reset button will disable all rules and rulesets.
   When finished enabling/disabling the relevant rulesets and rules, click the Apply button.

4.1WAF Misconfigured State

Figure 4‑3: WAF Misconfigured status

On the View/Modify Services screen in the LoadMaster WUI, the Status of each Virtual Service is displayed. If the WAF for a particular Virtual Service is misconfigured, for example if there is an issue with a rule file, the status changes to WAF Misconfigured and turns to red. If the Virtual Service is in this state, all traffic is blocked. WAF can be disabled for that Virtual Service to stop the traffic being blocked, if required, while troubleshooting the problem. 5Backing Up and Restoring WAF Configuration

Figure 5‑1: Back Up and Restore

A backup of the LoadMaster configuration can be taken by going to System Administration > Backup/Restore and clicking Create Backup File.

The configuration can be restored from this screen also. Please keep in mind that the Virtual Service settings can be restored by selecting VS Configuration and the rules can be restored by selecting LoadMaster Base Configuration.

A WAF configuration can only be restored onto a LoadMaster with an WAF license.



Referensi