This section displays all the settings available for the current WAF rule set, organized into three tabs: Global, Rules, and Farms. Remember to click the Apply button to save any changes.

Global Settings WAF Rule Set #

This configuration manages the behavior of all rules contained in the set.

Name. A label that easily identifies a rule. The name you choose for your ruleset will not be modifiable.
Check Request Body. A flag that determines if the body of HTTP requests is analyzed. If disabled, the body will be skipped, and rule matches against request body parameters will not be processed.
Request Body Limit. The maximum number of bytes of the request body saved for inspection. If set to 0, the WAF will save the content-length size completely. It is recommended to set a limit.
Check Response Body. A flag that determines if the body of HTTP responses is analyzed. If disabled, the body will be skipped, and rule matches against response body parameters will not be processed. Responses greater than 524288 bytes (512KB) will be ignored.
Default Action. The default resolution when no resolution is specified in a rule. Here are the possible actions.

• Allow. The WAF will continue processing until the HTTP transaction is complete.
• Pass. The WAF will evaluate the next rule without interrupting the HTTP transaction.
• Deny. The current HTTP transaction will be terminated. No further rules will be evaluated. If the rule matches in phase 1 or 2 (request analysis), the request will not reach the backend. If it matches in phase 3 or 4 (response analysis), the response will not reach the client.
• Redirect. The HTTP transaction will be halted, and an HTTP redirect will be sent to the client.

Redirect url. The URL sent to the client when a rule matches and a redirect resolution is set up.
Default phase. The default phase when no phase is specified in a rule. Phases are HTTP steps where a WAF rule can be hooked. The defined phases are:

• Request headers are received. Executed once all request headers from the client are read by the load balancer.
• Request body is received. Executed when the complete request body from the client is buffered in the load balancer.
• Response readers are received. Executed once all response headers from the server are read by the load balancer.
• Response body is received. Executed when the complete response body from the server is read by the load balancer.
• Before than logging. Executed when the WAF process finishes the logging task.

Default log. The default log action used if no action is specified in the rule settings.
Only logging. If enabled, the resolution parameter of the rules in the set will never be executed. This mode is only available when the set is running.

Disable Rules #

These tables allow you to disable rules within the set without modifying them.

Enabled Rules. A list of rules currently enabled in the set, identified by their rule id and description.
Disabled Rules. A list of rules currently disabled in the set.

List of WAF Rules #

The Rules section allows you to create and modify WAF rules that detect and protect against HTTP attacks.

These rules are evaluated sequentially, in the order they appear on this screen. To sort the rules, enable the Sort button and drag and drop them into the desired position.

Rule Parameters #

The following are the possible parameters for the rules:

ID. Identifies the rule within the rule set. This identifier corresponds to the rule’s position in the set.
Rule ID. A unique identifier for the rule. A farm cannot be linked to a WAF set containing duplicate rule IDs.
Description. A descriptive message to identify the rule, which will be logged upon a successful match.
Phase. The HTTP request step where the rule will be executed. Possible phases include:

• Request headers are received. Executed once all request headers from the client are read by the load balancer.
• Request body is received. Executed when the complete request body from the client is buffered in the load balancer.
• Response readers are received. Executed once all response headers from the server are read by the load balancer.
• Response body is received. Executed when the complete response body from the server is read by the load balancer.
• Before than logging. Executed when the WAF process finishes the logging task.

Resolution. The action chosen to execute if all match conditions are met. Options include:

• Allow. Stops evaluating further rules for the current HTTP transaction if a match occurs.
• Pass. Continues evaluating the next rule without interrupting the HTTP transaction.
• Deny. Terminates the current HTTP transaction, preventing further rule evaluations. If matched in phase 1 or 2 (request analysis), the request will not reach the backend. If matched in phase 3 or 4 (response analysis), the response will not reach the client.
• Redirect. Halts the HTTP transaction and sends an HTTP redirect to the client.
• Default action. The resolution set when none is applied, usually set to Allow.

Redirect URL. The URL where the client will be redirected if a rule with a redirect resolution is executed.
Skip. If all match conditions are met, the rule will skip the number of rules specified in this field.
Skip After. If all match conditions are met, the rule will jump to another firewall position. The rule can jump to a ‘mark’ or another rule ID, and the rule ID executed after a jump will be in the same phase as the current rule.
Execute. The path to an LUA script that will be executed once the first match is achieved. The script must be previously uploaded to the load balancer.
Log. If enabled, the rule will be logged when the first match is achieved.

Editing a WAF rule in raw #

If the form doesn’t adequately describe a given WAF rule and the administrator is unfamiliar with the SecLang syntax, it is possible to create rules or a batch of rules through the edit option. This field accepts any instructions. If the instructions and parameters are supported by the SecLang syntax, the parameters that are expressed in the form will not be shown. However, they will be visible in the edit form and processed at runtime.

Here are examples in both form mode and raw mode.

Form Mode #

This mode is more user-friendly for editing a WAF rule.

Raw Mode #

This mode is for more advanced users.

Creating a WAF rule #

When a new rule is added, it will be appended to the other rules in the set. There are three ways to create a new rule:

Rule type:

• Action. Creates a basic rule using a form. The parameters of the form are explained in the List of WAF Rules section. If the execution of the rule is conditional, click on the Add Condition button to set the execution conditions.
  
• Mark. Sets a firewall mark used once a match condition is achieved. The expected parameter is the name that identifies the mark.
  
• Custom. Accepts rules (or a batch of rules) in SecLang syntax. For more information about the SecLang syntax, visit the libmodsecurity project documentation.
  

List of Conditions #

The table in the image below shows a list of conditions that the HTTP parsed packet must match for the rule to be applied. All matches will be executed in the phase defined in the rule. The matches will be checked sequentially, and the rule will be applied if all of them are accomplished.

To evaluate the match, the WAF will execute an operation (parameters Operator and Operating) against a list of variables. If some variables in the list comply with the operation, they will be considered successful. For example, in the following image, the header IMAGES is looked for in the list of request headers sent by the client. First, it decodes every 64 bases of each header and then converts the headers to lowercase characters. When the transformation of the variables is completed, a regular expression is applied, looking for the string images in the list of transformed variables. The multi-match option will try a match for each transformation operation (after base 64 decoding and after lowercase conversion).

Creating Conditions #

The match builds a condition that must be met to execute the WAF rule. To evaluate the match, the WAF will execute an operation (parameters Operator and Operating) against a list of variables. If there is a match between the operations and the variables in the list, the match is taken as successful. For example, to look for the localhost (127.0.0.1) in the request headers list and in the virtual host HTTP field, it can be evaluated with the following configuration.

These are the configuration parameters for setting conditions:

Variable. This indicates which part of the HTTP transaction the rule will try to match. You can select from the listed variables, and the matches will be valid if some of them match. A drop-down menu will appear when you click through the variables field. Information about the variable configuration can be found in the Creating variables section.
Transformations. This is a list of modifications applied to variables. Transformations are applied sequentially, in the order shown in the field. It is possible to try a match for each transformation applied using the multi-match option. Transformations do not modify any information in the HTTP transaction; they are saved in temporary contexts and removed once the operation has concluded. A list of the transformations can be found here. This parameter is used to remove anti-avoidance techniques or to remove codification data.
Operator. This defines how the rule tries to match. This parameter is usually combined with Operating. A list of operators can be found here.
Operating. This defines what the rules try to match. This parameter is usually combined with the operator. The type of the expected value must align with the operator.
Multi-Match. This parameter is used when more than one transformation is configured. The rule will try to match the variables, the Operator, and the Operating for each value of the transformations. The possible values are true (enables multi-match) or false (disables the multi-match feature).
Not Match. If this checkbox is enabled, the result of the match will be negated, converting to true when the result is false and vice versa.

Creating variables #

Variables are mandatory parameters in a match condition. They specify the part of the HTTP request/response to search for information.

Variables. This parameter indicates which field of the HTTP request/response to examine (e.g., time, server).

Variable’s argument. When a variable is selected, it may be necessary to specify a particular element within it. For example, the image below shows how the request header host is checked.

Count elements of variables. This checkbox counts the number of elements in the variable. This feature is useful when the variable is a list.

Ignore this variable for the match. If this checkbox is enabled, the variable will not be checked in the match. This feature is useful when a variable contains a list of values, but one of them needs to be excluded from the check.

Table of Variables #

Variable	Description
ARGS	Collection of argument values in a request.
ARGS_JSON	Collection of argument values in a JSON request. Available when WAF parses JSON arguments; requires enabling the rule set REQUEST-901-INITIALIZATION.
ARGS_COMBINED_SIZE	Total size of request parameters excluding files.
ARGS_NAMES	Collection of argument names in a request.
FILES	File names in the user file system. Only applicable for multipart/form-data requests.
FILES_COMBINED_SIZE	Total size of files in a request. Only applicable for multipart/form-data requests.
FILES_NAMES	List of file names used to upload files. Only applicable for multipart/form-data requests.
FILES_SIZES	List of individual file sizes. Only applicable for multipart/form-data requests.
REQBODY_ERROR	Indicates if the request body format is incorrect for JSON or XML (1 if true, 0 if false).
REQUEST_BODY	Raw request body. If the request does not have the application/x-www-form-urlencoded header, it is necessary to use ctl:forceRequestBodyVariable in the REQUEST_HEADER phase.
REQUEST_BODY_LENGTH	Number of bytes in the request body.
REQUEST_COOKIES	List of all request cookie values.
REQUEST_COOKIES_NAMES	List of all request cookie values.
REQUEST_HEADERS	All request headers.
REQUEST_HEADERS_NAMES	List of request header names.
REQUEST_METHOD	Request method (e.g., GET, POST).
REQUEST_PROTOCOL	HTTP version protocol of the request.
REQUEST_URI	URI request path excluding virtual host.
PATH_INFO	Information before the URI path.
FULL_REQUEST	Full request content.
FULL_REQUEST_LENGTH	Number of bytes in the full request.
RESPONSE_BODY	Raw response body.
RESPONSE_CONTENT_LENGTH	Number of bytes in the response body.
RESPONSE_HEADERS	All response headers.
RESPONSE_HEADERS_NAMES	List of response header names.
RESPONSE_PROTOCOL	HTTP version protocol of the response.
RESPONSE_STATUS	HTTP response status code.
REMOTE_ADDR	IP address of the client.
REMOTE_PORT	Port where the client initiated the connection.
REMOTE_USER	Authenticated user name.
TIME	Server time in hours:minutes:seconds format.
DURATION	Duration of the current transaction in milliseconds from initiation time.
MULTIPART_FILENAME	Filename field in a multipart request.
MULTIPART_NAME	Field name in a multipart request.
MATCHED_VAR	Value matched in the last match operation. Replaced in each match operation without needing capture option.
MATCHED_VARS	List of all matched values.
SERVER_ADDR	Server’s IP address.
SERVER_NAME	Virtual host obtained from request URI.
ENV	WAF’s environment variables.
TX	Collection of variables for the current transaction. Removed when transaction ends. Variables TX:0-TX:9 store values captured with strRegex or phrases operators.

Table of Operators #

The operators can be categorized into different contexts, each indicated by a prefix such as int for integer, IP for IP operations, str for strings, or validate for data validation.

Variable	Description
strBegins	Matches if any variable begins with the specified operating value.
strContains	Matches if any variable contains the specified operating value.
strContainsWord	Matches if any variable contains the specified word or value of the operating.
strEnd	Matches if any variable ends with the specified operating value.
strWithin	Matches if any variable starts with the specified operating value.
strMatch	Matches if any variable matches any of the strings in the operating list (split by the character |).
strEq	Matches if any variable is identical to the specified operating value.
strRegex	Matches if any variable matches the regular expression specified in the operating.
strPhrases	Matches if any variable matches any value in the list specified in the operating.
strPhrasesFromFile	Similar to strPhrases, but the list of phrases is defined in a file specified in the operating.
intEQ	Matches if any variable is equal to the specified number in the operating.
intGE	Matches if any variable is greater than or equal to the specified number in the operating.
intGT	Matches if any variable is greater than the specified number in the operating.
intLE	Matches if any variable is less than or equal to the specified number in the operating.
intLT	Matches if any variable is less than the specified number in the operating.
detectSQLi	Detects SQL injection in the list of variables.
detectXSS	Detects XSS (Cross-Site Scripting) injection in the list of variables.
ipMatch	Attempts to match IP addresses or network segments specified in the operating with the list of variables. Use comma as a separator for multiple IPs or segments.
ipMatchFromFile	Similar to ipMatch, but reads the IPs and network segments from a file specified in the operating.
validateByteRange	Ensures that the number of bytes in the variables falls within the range specified in the operating (e.g., “10, 13, 32-126”).
validateUrlEncoding	Validates encoded data. Use only for data that doesn’t commonly encode or for data that’s encoded multiple times.
validateUtf8Encoding	Validates UTF-8 encoded variables.
verifyCreditCard	Verifies if variables are valid credit card numbers using the regular expression specified in the operating.
verifySSN	Verifies if variables are valid US Social Security Numbers using the regular expression specified in the operating.
matchAllways	Always returns true, forcing a match regardless of other conditions.
matchNever	Always returns false, forcing a non-match regardless of other conditions.

Table of Transformation #

Here’s the table describing transformations:

Transformation	Description
base64Decode	Decodes a Base64-encoded string.
base64DecodeExt	Decodes a Base64-encoded string ignoring invalid characters.
sqlHexDecode	Decodes SQL hex data.
base64Encode	Encodes using Base64 encoding.
cmdLine	Avoids problems associated with escaped command lines.
compressWhitespace	Converts whitespace characters (0x20, \f, \t, \n, \r, \v, 0xa0) to spaces (ASCII 0x20), compressing multiple consecutive spaces into one.
cssDecode	Decodes characters encoded using the CSS 2.x escape rules. This function uses only up to two bytes in the decoding process, meaning that it is used to uncover ASCII characters encoded using CSS encoding (that wouldn’t normally be encoded), or to counter evasion, which is a combination of a backslash and non-hexadecimal characters (e.g., ja\vascript is equivalent to javascript).
escapeSeqDecode	Decodes ANSI C escape sequences: \a, \b, \f, \n, \r, \t, \v, \\, \?, \’, \”, \xHH (hexadecimal), \0OOO (octal). Invalid encodings are left in the output.
hexDecode	Decodes a string that has been encoded using the same algorithm as the one used in hexEncode (see following entry).
hexEncode	Encodes string (possibly containing binary characters) by replacing each input byte with two hexadecimal characters (e.g., xyz is encoded as 78797a).
htmlEntityDecode	Decodes characters encoded as HTML entities.
jsDecode	Decodes JavaScript escape sequences.
length	Retrieves the length of the input string in bytes.
lowercase	Converts all characters to lowercase using the current C locale.
md5	Calculates an MD5 hash from the input data. The computed hash is in a raw binary form and may need to be encoded into the text to be printed (or logged). Hash functions are commonly used in combination with hexEncode.
none	Removes previous transformation functions associated with the current rule.
normalizePath	Removes multiple slashes, directory self-references, and directory back-references from the input string (except when at the beginning of the input).
normalizePathWin	Similar to normalizePath, but converts backslash characters to forward slashes first.
parityEven7bit	Calculates even parity of 7-bit data, replacing the 8th bit of each target byte with the calculated parity bit.
parityOdd7bit	Calculates odd parity of 7-bit data, replacing the 8th bit of each target byte with the calculated parity bit.
parityZero7bit	Calculates zero parity of 7-bit data, replacing the 8th bit of each target byte with a zero-parity bit, which allows inspection of even/odd parity 7-bit data as ASCII7 data.
removeNulls	Removes all NUL bytes from input.
removeWhitespace	Removes all whitespace characters from input.
replaceComments	Replaces occurrences of C-style comments (/* … */) with a single space (multiple consecutive occurrences of which will not be compressed). Unterminated comments will also be replaced with space (ASCII 0x20). However, a standalone termination of a comment (*/) will not be acted upon.
removeCommentsChar	Removes common comment characters from input (/*, */, –, #).
replaceNulls	Replaces NUL bytes in input with space characters (ASCII 0x20).
urlDecode	Decodes a URL-encoded input string. Invalid encodings (i.e., the ones that use non-hexadecimal characters, or the ones that are at the end of the string and have one or two bytes missing) are not converted, but no error is raised.
uppercase	Converts all characters to uppercase using the current C locale.
urlDecodeUni	Decodes URL-encoded input with support for Microsoft-specific encoding (like urlDecode, but with support for the Microsoft-specific %, u encoding).
urlEncode	Encodes input string using URL encoding.
utf8toUnicode	Converts UTF-8 character sequences to Unicode. This helps input normalization, especially for non-English languages minimizing false positives and false negatives.
sha1	Calculates a SHA1 hash from the input data. The computed hash is in a raw binary form and may need to be encoded into the text to be printed (or logged). Hash functions are commonly used in combination with hexEncode.
trimLeft	Removes whitespace from the left side of the input string.
trimRight	Removes whitespace from the right side of the input string.
trim	Removes whitespace from both sides of the input string.

Farms WAF Settings #

This section allows you to assign the current WAF rule set to HTTP(s) farms.

Here, you can select one or more farms (hold down the Shift key to select multiple) to assign or remove the WAF rule set. Use the double arrow buttons to assign or remove the rule set from all available farms.