ModSecurity: Write Rules
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.