The following example shows how to allow-list an IP address to bypass the ModSecurity engine by switching the engine off for connections from that IP address:

SecRule REMOTE_ADDR "@ipMatch 192.168.1.101" \

    "id:102,\

    phase:1,\

    pass,\

    t:none,\

    nolog,\

    ctl:ruleEngine=off"

Variables

Variable Name: REMOTE_ADDR

Variable Definition: The IP address of the remote client

Note: Rules listing IP addresses with the /32 subnet mask are not supported and will not upload successfully.

Operator

“@ipMatch 192.168.1.101” – Performs an IPv4 or IPv6 match of the REMOTE_ADDR variable data. In this case, this is the allow-listed 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.