Contents
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 clicking on the SUBMIT button.
Global Settings WAF Rule Set
This configuration manages the behavior of all rules contained in the set.
Name: should be self-explained in order to be easily found and recognizable. The value of this field is set up when the set is created and it is not modifiable.
Check Request Body: is a flag to set if the body of the HTTP requests will be analyzed. If this flag is disabled, the body will be skipped and rule matches against request body parameters will not process them.
Request Body Limit: is the maximum number of bytes of the request body saved in order 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 Request Body: is a flag to set if the body of the HTTP response will be analyzed. If this flag is disabled, the body will be skipped and rule matches against response body parameters will not process them. The response greater than 524288(512KB) will be ignored.
Default Action: This select-box is used as default resolution when no resolution is specified in a rule and the all matches of the rule are a success. The possible actions are:
- 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 cut the HTTP transaction.
- Deny. Finish the current HTTP transaction. No evaluate any more rules. If the rule matches in phase 1 or 2 (analyzing the request), the request is not 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 and it has the 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 where it is possible to hook a WAF rule. The defined 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.
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.
Enable Rules. It is the list of rules currently enabled in the set. The rules are identified by its rule id and its description parameters.
Enable Rules. It is the list of rules currently disabled in the set.
List of WAF Rules
The Rules section permits create and modify WAF rules that detect and protect against HTTP attacks.
Those rules are directives that are evaluated sequentially, in the same order that are shown in this screen. If it is needed to sort the rules, enable the button Sort and drag and drop in the requested position.
The rules possible parameters are:
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 to a farm to waf set that contains two rules with the same rule ID.
Description: It is a descriptive message to identifier the rule. This message will be logged in a successful match.
Log: If this parameter is enabled, the rule will be logged when the first match condition will be achieved.
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.
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.
Resolution: This select-box is the action chosen to execute if all the matches 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 cut the HTTP transaction.
- Deny. Finish the current HTTP transaction. No evaluate any more rules. If the rule matches in phase 1 or 2 (analyzing the request), the request is not 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.
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 to another rule ID. The rule ID executes after a jump, will be in the same phase than the current rule.
Execution: It is the path to an LUA script. The script has to be previously uploaded to the load balancer. It will be executed when the first match condition will be achieved.
Editing a WAF rule in raw
If the rule form is not enough to parametrize the de WAF rule and the administrator is familiarized with the SecLang syntax, it is possible to create rules or batch of rules through the edit option. This field accepts any directive if the directive and parameter are supported by the SecLang syntax. The SecLang parameters that do not are expressed in the form, they will not be shown in it, but they will be shown in the edit form and processed in the running time.
Creating a WAF rule
When a new rule is added, it will be added appending of the other rules of the sets. To create a new rule, there are three ways to create a new rule.
Mark: It sets a firewall mark. These marks are useful to jump once a match condition is achieved. The expected parameter is the name to identifier the mark.
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 must be conditional, click on the ADD CONDITION button to set the execution conditions.
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
This table shows a list of conditions that the HTTP parsed packet has to match to the rule 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 successfully accomplished.
To evaluate the match, the WAF will execute an operation (parameters operator and operating) against a variables list. If some variables of the list comply with the operation, the match is taken as 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 in 64 bases each header and next, it converts the headers to low case characters. When the transformation about the variables is completed, a regular expression is applied, looking for the string “images” in the list of transformed variables. The multi mach 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 variables list. If it exists some match between the operation 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.
The configuration parameter to set in a condition are:
Variables: It is against which part of the HTTP transaction the rule will try the match. The possible values are in this table. Several variables can be added, the match will be taken as valid if some of them match. A creating menu will appear the more is clicked it. Information about the variable configuration can be found in the Creating variables section.
Transformations: The transformation is a list of modifications for applying to the variables before than apply them the operator and operating. Transformations are applied sequentiality, in the same order shown in the field, and it is possible to try a match for each transformation applied using the multimach option. Transformation does not modify any information of the HTTP transaction, they are saved in temporality contexts and removed once the operation has concluded. Here, there is a list of the transformation. This parameter is useful to remove anti-avoid techniques or to remove codification data.
Operator: It is how the rule tries the match. This parameter is used combined with operating. Here, there is a list of operators.
Operating: It is what the rules try in the match. The parameter is used combined with the operator. The type of expected value has to be according to the operator.
Multi-Match: This parameter is used when more than one transformations are configured. The rule will try a match of the variables, the operator and the operating for each value of transformations. The possible values are: true, enables multi-match; or false disables the multi-match feature.
Not Match: If this check-box is enabled, the result of the match will be negate, convirting in true when the result will be false or convirting false when the result will be true.
Creating variables
The variables are a mandatory parameter in a match condition, it selects the part of the HTTP request/response where to look for the information.
Variables: This parameter specifies the field of the HTTP request/response of the information (time, server…) of the transaction where looking for the information.
Variable’s argument: When a variable is selected, sometimes it is necessary to specify an element of it. For example, in the image is shown how the request header host is selected checked.
Count elements of variables: This check-box 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 check-box 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 it is required to exclude one of them.
Table of Variables
| Variable | Description |
|---|---|
| ARGS | It is a collection with 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, for it, 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 with the names of the of 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 has not 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 cookies values. |
| REQUEST_COOKIES_NAMES | It is a list with all request cookies names. |
| REQUEST_HEADERS | This variable has all request headers. |
| REQUEST_HEADERS_NAMES | This variable has a list with the request headers 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 than the URI path. |
| FULL_REQUEST | It is the full request. |
| FULL_REQUEST_LENGTH | It is the number of bytes that 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 headers 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 since the beginning 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 saves the values captured with the strRegex or strPhrases operators. |
Table of Operators
The operators can have different contexts. This context is indicated by a prefix, as 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 of the value of operating. |
| strEnds | 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 begin with the value of operating. |
| strMatch | The rule will match if any of the variables match with 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 operating. |
| strRegex | The rule will match if any of the variables matches in the regular expression used in operating. |
| strPhrases | The rule will match if any of the variables match in any of the values of the list operating. |
| strPhrasesFromFile | It the same that the operator strPhrases but the operating is a file where it is defined 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 | It applies the detection of SQL injection to the list of variables. This operator does not expect any operating. |
| detectXSS | It applies the detection of XSS injection to the list of variables. This operator does not expect any operating. |
| ipMatch | Try to match the IP or network segments of operating with the list of variables. |
| ipMatchFromFile | It is the same than the operator ipMatch, but this tries the match of the variables against a file with a list of IPs and network segments. |
| validateByteRange | It checks that the number of byte of the variables are 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 are encoded several times. |
| validateUtf8Encoding | It validate that variables are UTF-8. This operator does not expect any operating. |
| verifyCreditCard | It verifies if variables are a credit card number. This parameter accepts a regular expression as operating, if it matches then it applies the credit card verified. |
| 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 returns true always, forcing a match. |
| matchNever | It returns false always, 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 problem related 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 useful 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. 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 output. |
| lowercase | Converts all characters to lowercase using the current C locale. |
| md5 | Calculates an MD5 hash from the data in 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 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 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 help 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 farms (by maintaining shift keyboard button pressed) and assign the WAF rule set to them or remove them from. It is also possible to assign or remove it from all the available farms with the double arrow buttons.