UWAF Rules
UWAF itself contains multiple types (protocol violations, injection attacks, cross-site scripting, vulnerability attacks, command execution etc.) of default protection rules. In addition to the existing rules in these types, you can also add custom rules to achieve precise interception of attacks and release some requests.
For the priority of various rules, see Rule Priority.
Rule List
Rules have different priorities. The default rules are at the lowest priority and cannot adjust the priority, but they can choose to turn on or off the rule judgment of a certain type. The priority of custom rules can be adjusted. The rules at the top of the list have the highest priority, and the priority of downward rules decreases in turn.
- The priority of rules can be raised or lowered. The priority of the rules at the top of the list is higher than that of the rules below;
- If the rule with a higher priority conflicts with the rule with a lower priority, the rule with a higher priority will prevail;
- The default rule priority of the system is the lowest and cannot be adjusted.
Adding Rules
The rule is composed of rule name, matching action, risk level, risk type, and matching conditions. In blocking mode and alarm mode, if the matching action of the rule is interception, requests hitting any custom rule will record an attack log, and the log details can be viewed in Attack Details; If the matching action of the rule is to let go, requests that hit this rule will not generate attack logs. In alarm mode, blocking requests will only record attack logs, but will not block requests.
Rule Parameter Description
Parameter | Description |
---|---|
Rule Name | The name of the custom rule, which can be any Chinese and English characters |
Action Match | Intercept or let go. Intercept will record attack logs, and let go will not record attack logs |
Risk Level | High risk, medium risk, or low risk, used to identify the risk level of the rule |
Risk Type | Identifies the type of rules, optional values are: Malicious Scans, Protocol Distortions, Unauthorized Access, Information Leaks, WebShell, Vulnerability Attacks, Cross-Site Scripts, CC Attacks, Injection Attacks, Command Execution, Other Attacks |
Match Condition | It consists of matching fields, logic symbols, matching content, and parameter decoding. The logic between multiple conditions is and, that is, when all conditions are met, the rule can be hit. For detailed explanation, see Matching Condition Description at the bottom of the document. |
Match Condition Description
The description of the matching field and its corresponding relationship with the logical symbol is as follows:
Matching Fields | Description | Logic Symbol |
---|---|---|
Source IP | The source IP of the request client. If [Are there proxies before WAF] is turned on, the IP in the specified field is used as the source IP | Belongs to, does not belong to (CIDR format); equal to, not equal to |
Referer | When jumping between different web pages, the link address of the source page is attached to tell the server where the page is linked from | Contains, does not contain; equal to, not equal to; length is greater than, less than; does not exist; regular; multi-line, non-multi-line match |
Request UA | A string used to identify the request client, that is, the User-Agent field of the HTTP request | Contains, does not contain; equal to, not equal to; length is greater than, less than; regular; multi-line, non-multi-line match |
Request Path | The client submits a request route to access a specified resource on the server, such as the request path for the homepage is / | Contains, does not contain; equal to, not equal to; length is greater than, less than; regular; multi-line, non-multi-line match |
Request Method | Methods of request, such as GET , POST | Contains, does not contain; equal to, not equal to; length is greater than, less than; regular; multi-line, non-multi-line match |
Request Content | The content of the Body part of the request | Contains, does not contain; equal to, not equal to; length is greater than, less than; regular; multi-line, non-multi-line match |
URL Query Params* | Parameters in the URL, for example, ?a=1&b=2 , then the URL query parameters are a, b , and the parameter values are 1, 2 | Contains, does not contain; equal to, not equal to; length is greater than, less than; does not exist; regular; multi-line, non-multi-line match |
Request Cookie* | The Cookie of the client request, Cookies are used to record some page configurations or identify identities to the server | Contains, does not contain; equal to, not equal to; length is greater than, less than; does not exist; regular; multi-line, non-multi-line match |
Request Params* | Includes parameters in URL, Cookie, and Body | Contains, does not contain; equal to, not equal to; length is greater than, less than; does not exist; regular; multi-line, non-multi-line match |
Custom Request Headers* | Other fields in the client request other than Referer, User-Agent, Cookie, can also be custom fields | Contains, does not contain; equal to, not equal to; length is greater than, less than; does not exist; regular; multi-line, non-multi-line match |
Fields marked with * indicate that they are key-value structures. The matching content of these fields can accept a JSON string to match the value of a single key, key name, value name or all key, value name. If an ordinary string or a string that does not conform to the JSON format is entered, it is defaulted to match all key names and values. If the operator corresponding to the key-value structure matching field is longer than/smaller than, it will compare the total number of keys/values if nospecific key value is specified.
Matching Content Type | Usage Example | Description |
---|---|---|
Specific Key Value | {"pattern": "string", "specific": "specific-key"} | Matches the value of a certain key specific-key in the key-value structure. For example: for Custom Request Header, check whether the value of the specific-key field in the request matches string ; for URL Query Parameters, if it is ?specific-key=xxx , check whether xxx matches string |
All Key Names | {"pattern": "string", "keys": true} | Traverse and match all key names in the key-value structure. For example: URL query parameter is ?a=1&b=2 , it will check whether the keys a and b match string respectively, trigger the rule if any key matches |
All Values | {"pattern": "string", "values": true} | Traverse and match all values in the key-value structure. For example: URL query parameter is ?a=1&b=2 , it will check whether the values 1 and 2 match string respectively, trigger the rule if any value matches |
All Key Names and Values | {"pattern": "string", "all": true} | Traverse and match all key names and values in the key-value structure. For example: URL query parameter, if it is ?a=1&b=2 , it will check whether the key values a , b , 1 and 2 match string respectively, triggering the rule if any key/value matches |
All Key Names, Values | string | Will be parsed as {"pattern": "string", "all": true} |
Parameter Decoding Description
Can decode the matching content, support multiple selection, including:
- URL decoding
- HTML decoding
- BASE64 decoding
- Remove comments
Remove/*
and*/
and the characters between them in the matching content - Spaces compressed
Compress multiple whitespace characters (including spaces) into a single space character
Source IP cannot undergo parameter decoding and will be ignored if selected.
Rule Examples
- If the business domain
example.com
domain has 2 UWAF rules:
- Rule 1: If the request path contains
.php
, then intercept - Rule 2: If the source IP contains
192.168.1.1
, then let it go Rule 1 has a higher priority than Rule 2 (sorted order).
Situation (1): When the client’s IP address is 192.168.1.1, if it sends a request with a URL of http://example.com/123.php
, it will trigger Rule 1 to be intercepted.
Situation (2): When the client’s IP address is 192.168.1.1, if it sends a request with a URL of http://example.com/?i=<script>alert(/1/)</script>
, it will trigger Rule 2 to be released.
-
If the business domain
example.com
has a back-end management login portal/admin.php
, it needs to use UWAF to configure the access restriction of the source IP address, and it cannot completely open the rule detection for these source IP addresses. Rule example:- Rule name: Back-end interface access restriction
- Match action: Block
- Risk level: High risk
- Risk type: Unauthorized access
- Match conditions:
- Source IP does not belong to
12.34.5.0/24
(permitted access IP or IP segment) - Request path contains
/admin.php
(back-end management portal)
- Source IP does not belong to
Situation (1): When the client’s IP address is 12.34.5.6, if it visits http://example.com/admin.php
, it will not trigger this rule, but it will be checked by other subsequent rules.
Situation (2): When the client’s IP address is 65.43.2.1, if it visits http://example.com/admin.php
, it will trigger this rule and be intercepted.
-
If a component of the technology stack used by a certain business domain has a vulnerability, as long as the value of the name
jam
in the request’s Cookie is longer than 9, this vulnerability can be exploited (for examplejam=0123456789
, the length of the value is 10), before the relevant patch is released, it is necessary to use UWAF to protect this vulnerability. Rule example:- Rule name: Protection against cookie-jam vulnerability
- Matching action: Interception
- Risk level: High risk
- Risk type: Vulnerability attack
- Matching conditions: Request Cookies length is greater than
{"specific": "jam", "pattern": "9"}
Situation (1): When some normal client sends a request with the Cookie field value of username=Alice;jam=true
, it will not trigger this rule, but it will be checked by other subsequent rules.
Situation (2): When a malicious client sends a request with the Cookie field value of username=Mallory;jam=overflowattack
, it will trigger this rule and be intercepted.