Whitelist an IP using WAF - ModSecurity Whitelisting IP's

The ModSecurity Reference Manual should be used in all cases where questions arise over 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 [ACTIONS]

The three parts have the following meanings:

  1. The VARIABLES specify which places to check in an 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 under https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Variables

 

  1. The OPERATOR specifies a regular expression, pattern or keyword to be checked in the variable(s). Operators begin with the @ character.

 

The full list is of operators is available under https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Operators

 

  1. The ACTIONS specify what to do if the rule matches. Actions are defined into seven categories Disruptive (used to allow ModSecurity take an action e.g. allow, block etc), Flow (affect the flow e.g. 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) and Special (used to provide access to another class of functionality) and Miscellaneous (contain actions that don’t belong in any of the other groups) actions. If no ACTIONS are provided, default actions apply as per SecDefaultAction (phase:2,log,auditlog,pass).

 

The full list of actions is available under https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Actions

 

There are multiple ways to facilitate the whitelisting of an IP address within the ModSecurity engine. This document looks at three approaches, outlines the rule syntax and the associated details.

Rule Example 1

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

SecRule REMOTE_ADDR “@ipMatch 192.168.1.101” \

id:101,phase:1,t:none,log,allow

VARIABLES

REMOTE_ADDR – The IP address of the remote client.

OPERATOR

“^192\.168\.1\.101$” – Performs an IPv4 or IPv6 match of the REMOTE_ADDR variable data, in this case this is the IP address to be whitelisted.

ACTIONS

id:101 – The unique id that is assigned to this rule (or chain) in which it appears.

phase:1 – Places the rule (or chain) in Phase 1 processing. There are 5 phases including Request Headers (1), Request Body (2), Response Headers (3), Response Body (4) and 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.

log – Successful rule matches needs to appear in both the error and audit logs.

allow – Stops rule processing and affects the entire transaction, stopping processing of the current phase and also skipping over all other phases. . In this case, the ModSecurity rule engine is turned off. Please refer to the following link for fuller information

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

 

Rule Example 2

The following example shows how to whitelist an IP address to bypass the ModSecurity engine. This is seen as less performant than Rule Example 1 above.

SecRule REMOTE_ADDR “@ipMatch 192.168.1.101” \

id:102,phase:1,t:none,nolog,pass,ctl:ruleEngine=off

VARIABLES

REMOTE_ADDR – 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 case this is the IP address to be whitelisted.

ACTIONS

id:101 – The unique id that is assigned to this rule (or chain) in which it appears.

phase:1 – Places the rule (or chain) in Phase 1 processing. There are 5 phases including Request Headers (1), Request Body (2), Response Headers (3), Response Body (4) and 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 transient, per-transaction basis. This will affect only the transaction in which the action is executed. In this case, the ModSecurity rule engine is turned off.

 

Rule Example 3

The following example shows how to whitelist an IP address. This assumes that there is a rule associated with an IP / range of IPs or file of IPs that are being blocked and one of these subsequently needs to be whitelisted.

SecRule REMOTE_ADDR “@ipMatch 192.168.1.101” \

id:101,phase:1,t:none,log,pass,ctl:ruleRemoveById=1234

VARIABLES

REMOTE_ADDR – 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 case this is the IP address to be whitelisted.

ACTIONS

id:101 – The unique id that is assigned to this rule (or chain) in which it appears.

phase:1 – Places the rule (or chain) in Phase 1 processing. There are 5 phases including Request Headers (1), Request Body (2), Response Headers (3), Response Body (4) and 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.

log – Successful rule matches needs to appear in both the error and audit logs.

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

ctl:ruleRemoveById=1234 – This action changes ModSecurity configuration on transient, per-transaction basis. This will affect only the transaction in which the action is executed. The ruleRemoveByID action is triggered at run time, it should be specified before the rule in which it is disabling.

Was this article helpful?

0 out of 0 found this helpful

Comments