This section shows all the settings available for the current WAF rule set organized in three tabs, Global, Rules, and Farms. Keep in mind that changes in this section have to be applied by clicking on the Apply button.
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 label you choose to name your ruleset will not be modifiable.
Check Request Body. It is a flag that sets if the body of the HTTP requests is to be analyzed. If this flag is disabled, the body will be skipped and the rule matches against the request body parameters will not be processed.
Request Body Limit. It is the maximum number of bytes of the request body saved to inspect the body request. If this parameter has the value 0, the WAF will save the content-length size completely. It is recommended to set any limit value.
Check Response Body. It is a flag to set if the body of the HTTP response is to be analyzed. If this flag is disabled, the body will be skipped and rule matches against response body parameters will not be processed. A response greater than 524288 (512KB) will be ignored.
Default Action. This select box is used as the default resolution when no resolution is specified in a rule. All matches of the rule are a success. Here is a brief description of each action.
- Allow. Will enable processing of the current WAF till it finishes to complete the HTTP transaction
- Pass. WAF will continue evaluating the next rule without cutting the HTTP transaction.
- Deny. Finish the current HTTP transaction. Evaluation of more rules will not be allowed. If the rule matches in phase 1 or 2 (analyzing the request), the request will not be delivered to the backend. If the rule matches in phase 3 or 4 (analyzing the response), the response will not be delivered to the client.
- Redirect. The HTTP transaction will be halted and an HTTP redirect will be sent to the client.
Redirect url. It is the URL sent to the client when a rule matches. This URL has a redirect resolution set up.
Default phase. This select-box is used as the default phase when no phase is specified in a rule. A phase is an HTTP step that allows you to hook a WAF rule. These are the defined phases:
- Request headers are received. The rule will be executed once all request headers from the client are read by the load balancer.
- Request body is received. The rule will be executed when the complete request body from the client is buffered in the load balancer.
- Response readers are received. The rule will be executed once all response headers from the server are read by the load balancer.
- Response body is received. The rule will be executed when the complete response body from the server is read by the load balancer.
- Before than logging. The rule is executed when the WAF process finishes the logging task.
Default log. It is a log default action. This value is used if no action about logs is specified in the rule settings.
Only logging. If this checkbox is enabled, the resolution parameter of the rules in the set will never be executed. This working mode is only available when the set is running.
Disable Rules
Those tables allow disabling rules of the set without modifying them.
Enabled Rules. It is the list of rules currently enabled in the set. The rules are identified by its rule id and its description parameters.
Disabled Rules. It is the list of rules currently disabled in the set.
List of WAF Rules
The Rules section permits creating and modifying WAF rules that detect and protect against HTTP attacks.
Those rules are directives that are evaluated sequentially, i.e. In the same order that is shown on this screen. If it is necessary to sort the rules, enable the Sort button then and drag and drop in the requested position.
The possible parameters for the rules have been described below.
ID. It is an identifier to identify the rule inside the rule set. This identifier corresponds with the rule position in the set.
Rule ID. It is a unique identifier of the rule. It is not possible to link a farm to a waf set that contains two rules with the same rule ID.
Description. It is a descriptive message to identify the rule. This message will be logged in a successful match.
Phase. The phase represents the step of the HTTP request where a rule will be executed. The possible phases are:
- Request headers are received. The rule will be executed once all request headers from the client are read by the load balancer.
- Request body is received. The rule will be executed when the complete request body from the client is buffered in the load balancer.
- Response readers are received. The rule will be executed once all response headers from the server are read by the load balancer.
- Response body is received. The rule will be executed when the complete response body from the server is read by the load balancer.
- Before than logging. The rule is executed when the WAF process finishes the logging task.
Resolution. This select box is the action chosen to execute if all the match conditions are achieved.
- Allow. No more rules will be evaluated (for the current HTTP transaction) if a rule with this action matches.
- Pass. WAF will continue evaluating the next rule without cutting the HTTP transaction.
- Deny. Finish the current HTTP transaction. There will be no more evaluation of rules. If the rule matches in phase 1 or 2 (analyzing the request), the request will not be delivered to the backend. If the rule matches in phase 3 or 4 (analyzing the response), the response will not be delivered to the client.
- Redirect. The HTTP transaction will be halted and an HTTP redirect will be sent to the client.
- Default action. The resolution will be set if you don’t apply any. Usually, it will be the Allow resolution
Redirect URL. It is the URL where the client will be redirected in the case that rule will execute a redirect. This parameter will appear when a redirect is chosen in the resolution field.
Skip. If all matches are achieved, the rule will skip the number of rules specifies in this field.
Skip After. If all matches are achieved, the rule will jump to another firewall position. The rule can jump to a ‘mark’ or another rule ID. The rule ID executes after a jump and will be in the same phase as the current rule.
Execute. It is the path to an LUA script. The script has to be previously uploaded to the load balancer. It will be executed once the first match is achieved.
Log. If this parameter is 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 not familiar 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 shown in the edit form and processed in the running time.
Here are the examples in both form mode and raw mode.
Form Mode
This is mode is more user-friendly to edit 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 added by appending it to the other rules of the sets. To create a new rule, there are three ways to create a new rule.
Rule type:
- Action. It will create a basic rule using a form. The parameters of the form are the same 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. It sets a firewall mark. These marks are used once a match condition is achieved. The expected parameter is the name that identifies the mark.
- Custom. This form accepts rules (and a batch of rules) of 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 to the rule that will be applied. All of these 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 are 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 low case 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 low case conversion).
Creating Conditions
The match builds a condition that has to be achieved 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 of the list, the match is taken as successful. For example, to look for the local host (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. It suggests which part of the HTTP transaction the rule will try to match. You can select from the variables listed, and the matches will be taken as 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. The transformation is a list of modifications applied to variables. Transformations are applied sequentially, in the same order shown in the field, and it is possible to try a match for each transformation applied using the multi-match option. Transformation does not modify any information of the HTTP transaction, they are saved in temporal contexts and removed once the operation has concluded. Here is a list of the transformations. This parameter is used to remove anti-avoid techniques or to remove codification data.
Operator. This is how the rule tries the match. This parameter is usually combined with the Operating. Here is a list of operators.
Operating. This is what the rules try in the match. The parameter is usually combined with the operator. The type of the expected value has to 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 transformations. The possible values are: true, which enables multi-match, or false which disables the multi-match feature.
Not Match. If this check-box is enabled, the result of the match will be negated, converting to true when the result is false or converting to false when the result is true.
Creating variables
The variables are mandatory parameters in a match condition. They select the part of the HTTP request/response to look for the information.
Variables. This parameter specifies the field of the HTTP request/response to look for the information (time, server…)
Variable’s argument. When a variable is selected, it is sometimes necessary to specify an element from it. For example, the image below shows how the request header host is selected 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 that contains a list of values is going to be checked, but also required to exclude one of them.
Table of Variables
| Variable | Description |
|---|---|
| ARGS | It is a collection of the values of arguments in a request. |
| ARGS_JSON | It is a collection with the values of arguments in a JSON request. This variable will be available in the case that WAF parses the JSON arguments. The rule set REQUEST-901-INITIALIZATION should be enabled. |
| ARGS_COMBINED_SIZE | total size of the request parameters. The files are excluded. |
| ARGS_NAMES | It is a collection of the names of the arguments in a request. |
| FILES | It contains the file names in the user filesys. Only when the data is multipart/form-data. |
| FILES_COMBINED_SIZE | It is the total size of the files in a request. Only when the data is multipart/form-data. |
| FILES_NAMES | It is a list of file names used to upload the files. Only when the data is multipart/form-data. |
| FILES_SIZES | It contains a list of individual file sizes. Only when the data is multipart/form-data. |
| REQBODY_ERROR | This variable is 1 if the request body format is not correct for a JSON or XML, else it has the value 0. |
| REQUEST_BODY | It is the raw body request. 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 | It is the number of bytes of the request body. |
| REQUEST_COOKIES | It is a list with all request cookie values. |
| REQUEST_COOKIES_NAMES | It is a list with all request cookie names. |
| REQUEST_HEADERS | This variable has all request headers. |
| REQUEST_HEADERS_NAMES | This variable has a list with the request header names. |
| REQUEST_METHOD | It is the request method. |
| REQUEST_PROTOCOL | This variable holds the request HTTP version protocol. |
| REQUEST_URI | It is the URI request path. The virtual host is excluded. |
| PATH_INFO | It is the information before the URI path. |
| FULL_REQUEST | It is the full request. |
| FULL_REQUEST_LENGTH | It is the number of bytes that a full request can have. |
| RESPONSE_BODY | It is the raw body response. |
| RESPONSE_CONTENT_LENGTH | It is the number of bytes of the response body. |
| RESPONSE_HEADERS | This variable has all response headers. |
| RESPONSE_HEADERS_NAMES | This variable has a list with the response header names. |
| RESPONSE_PROTOCOL | This variable holds the response HTTP version protocol. |
| RESPONSE_STATUS | It is the response HTTP code. |
| REMOTE_ADDR | It is the IP address of the client. |
| REMOTE_PORT | It is the port where the client initializes the connection. |
| REMOTE_USER | It is the name of the authenticated user. |
| TIME | It is the server time. The format is hours:minutes:seconds. |
| DURATION | It is the number of milliseconds starting from the initiation time of the current transaction. |
| MULTIPART_FILENAME | It is the field filename in a multipart request. |
| MULTIPART_NAME | It is the field name in a multipart request. |
| MATCHED_VAR | It is the matched value in the last match operation. This value does not need the capture option but it is replaced in each match operation. |
| MATCHED_VARS | It is a list of all matched values. |
| SERVER_ADDR | It is the IP address of the server. |
| SERVER_NAME | It is the virtual host it gets from the request URI. |
| ENV | It is the environment variables of the WAF. |
| TX | It is a collection of variables for the current transaction. These variables will be removed when the transaction ends. The variables TX:0-TX:9 save the values captured with the strRegex or phrases operators. |
Table of Operators
The operators can have different contexts. This context is indicated by a prefix, such as an int for integer, IP for IP operations, str for strings or validate to validate data.
| Variable | Description |
|---|---|
| strBegins | The rule will match if any of the variables begin with the value of operating. |
| strContains | The rule will match if any of the variables contain the value of operating. |
| strContainsWord | The rule will match if any of the variables contain the word or the value of the operating. |
| strEnd | The rule will match if any of the variables end with the value of operating. |
| strWithin | The rule will match if any of the variables start with the value of operating. |
| strMatch | The rule will match if any of the variables match the value of operating. This operating can be a list of strings split by the character | |
| strEq | The rule will match if any of the variables is identical to the value of the operating. |
| strRegex | The rule will match if any of the variables match the regular expression used in operating. |
| strPhrases | The rule will match if any of the variables match any of the values of the list operating. |
| strPhrasesFromFile | Almost similar to the operator strPhrases but the operating is where it will be defined as a list of phrases. |
| intEQ | The rule will match if any of the variables is equal to the number used in operating. |
| intGE | The rule will match if any of the variables is greater or equal to the number used in operating. |
| intGT | The rule will match if any of the variables is greater than the number used in operating. |
| intLE | The rule will match if any of the variables is lower or equal to the number used in operating. |
| intLT | The rule will match if any of the variables is lower than the number used in operating. |
| detectSQLi | Detects an SQL injection on the list of variables. This operator does not expect any operating. |
| detectXSS | Applies the detection of XSS injection to the list of variables. This operator does not expect any operating. |
| ipMatch | Attempts matching the IP or network segments of operating with the list of variables. |
| ipMatchFromFile | It is the same as the operator ipMatch, but this tries the match of the variables against a file with a list of IPs and network segments. |
| validateByteRange | It ensures that the number of bytes of the variables is in one of the operating values. An example of operating is “10, 13, 32-126”. |
| validateUrlEncoding | It validates encoded data. This operator must be used only for data that does not encode data commonly or for data that are encoded several times. |
| validateUtf8Encoding | It validates variables that are UTF-8. This operator does not expect any operating. |
| verifyCreditCard | It verifies if variables are credit card numbers. This parameter accepts a regular expression as operating. If it matches, then it will successfully verify the card. |
| verifySSN | It verifies if variables are a US Social Security Number. This parameter accepts a regular expression as operating, if it matches then it applies the SSN verify. |
| matchAllways | It always returns true, forcing a match. |
| matchNever | It always returns false, forcing a non-match. |
Table of Transformation
| 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 the problems associated with the escaped command line. |
| 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. |
| 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., javascript is equivalent to javascript). |
| escapeSeqDecode | Decodes ANSI C escape sequences: a, b, f, n, r, t, v, \, ?, ‘, “, xHH (hexadecimal), �OOO (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. For example, xyz is encoded as 78797a. |
| htmlEntityDecode | Decodes the characters encoded as HTML entities. |
| jsDecode | Decodes JavaScript escape sequences. |
| length | Looks up the length of the input string in bytes, placing it (as string) in the output. |
| lowercase | Converts all characters to lowercase using the current C locale. |
| md5 | Calculates an MD5 hash from the data input. 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 | Not an actual transformation function, but an instruction to remove previous transformation functions associated with the current rule. |
| normalizePath | Removes multiple slashes, directory self-references, and directory back-references (except when at the beginning of the input) from the input string. |
| normalizePathWin | Same as normalizePath, but first converts backslash characters to forward slashes. |
| 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 the input. |
| replaceComments | Replaces each occurrence of a C-style comment (/* … */) 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 comments chars (/*, */, –, #). |
| 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 | Like urlDecode, but with support for the Microsoft-specific %, u encoding. |
| urlEncode | Encodes input string using URL encoding. |
| utf8toUnicode | Converts all UTF-8 characters 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 string. 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 the left and right sides of the input string. |
Farms WAF Settings
This section allows assigning the current WAF rule set to the HTTP(s) farms.
In this section, it will be possible to select one or more than one farm (by maintaining the shift keyboard button pressed) and then assign the WAF rule set or remove them. It is also possible to assign or remove it from all the available farms with the double arrow buttons.
