Working with rules

Edit online

Web application firewall rules are authored as ModSecurity rules. This page provides a brief introduction to how rules are constructed and how new rules can be added to the environment.

Note: IBM Verify Identity Access includes version 3 of the ModSecurity engine, which has different behavior to version 2. When using reference material, check that it has been authored for version 3.

Authoring ModSecurity rules

The ModSecurity Reference Manual contains a full description of the syntax of rules. The basic syntax and fields of a rule is:

SecRule VARIABLES OPERATOR [ACTIONS]

Table 1. Fields within a ModSecurity rule
Element	Description	Reference Documentation
`VARIABLES`	The variables which are used in the rule, for example the request URL.	https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v3.x%29#Variables
`OPERATOR`	This specifies a regular expression, pattern, or keyword to be checked in the variable(s). Operators begin with the ‘@’ character.	https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v3.x%29#Operators
`ACTIONS`	This specifies what to do if the rule matches.	https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v3.x%29#Actions

An example rule:

SecRule REQUEST_LINE|REQUEST_HEADERS|REQUEST_HEADERS_NAMES \
  "@contains () {" \ 
  "id:420008,\
  phase:2,\
  t:none,\
  t:lowercase,\
  deny,\
  status:500,\
  log,\
  msg: Bash ENV Variable Injection Attack'"

Note: Refer to the Limitations section for actions and operators which are not available when running on Verify Identity Access.

Interventions

An ‘intervention’ is a ModSecurity term for a disruptive action which needs to be taken for a particular request. The possible interventions include:

Logging a message
Redirecting the client to a URL specified in the rule
Sending a response with non-200 status to the client.
- When a non-200 status code is specified by the rule a corresponding Reverse Proxy generated page for that status code will be returned to the client.

Adding new rules to the environment

New rules can be added to the environment using the local management interface, see Managing the Web Application Firewall rules for more details.

A single rules file can contain multiple rules. It is not recommended to directly modify any of the provided rule files from the Core Rule Set as this will make it more difficult to import future updates of the Core Rule Set distribution.

Note: A single set of rule files is used for the entire environment and will apply to all WebSEAL instances

Updating the Core Rule Set

The Core Rule Set (CRS), available for download from GitHub, is updated periodically. IBM Verify Identity Access currently embeds v3.3.2 of the CRS. If a new version of the CRS is released on GitHub this can be applied to the environment by downloading the release zip file from GitHub and then importing this zip file by selecting the Import Zip capability described on the Managing the Web Application Firewall rules page.

Note: The CRS distribution typically includes a crs-setup.conf.example file. This file should be manually updated and imported into the environment to replace crs-setup.conf separately the zip file.

Ordering of rules

The Reverse Proxy always loads rules into the ModSecurity engine in the following order:

The instance-specific WAF configuration file
- Managed on the Reverse Proxy page, see Configuring Web Application Firewall for details.
The appliance-wide crs-setup.conf
- Managed using the crs-setup.conf menu on the Web Application Firewall page, see Managing the Web Application Firewall rules for details.
The appliance-wide rules files which end with the extension .conf
- Managed using the Web Application Firewall page, see Managing the Web Application Firewall rules for details.