Configuring Basic Web Protection to Defend Against Common Web Attacks
After this function is enabled, WAF can defend against common web attacks, such as SQL injections, XSS, remote overflow vulnerabilities, file inclusions, Bash vulnerabilities, remote command execution, directory traversal, sensitive file access, and command/code injections. You can also enable other checks in basic web protection, such as web shell detection, deep inspection against evasion attacks, and header inspection.
If you have enabled enterprise projects, ensure that you have all operation permissions for the project where your WAF instance locates. Then, you can select the project from the Enterprise Project drop-down list and configure protection policies for the domain names in the project.
Prerequisites
- You have added the website you want to protect to WAF or added a protection policy.
- For cloud CNAME access mode, see Connecting a Website to WAF (Cloud Mode - CNAME Access).
- For cloud load balancer access mode, see Connecting Your Website to WAF (Cloud Mode - Load Balancer Access).
- For dedicated mode, see Connecting Your Website to WAF (Dedicated Mode).
- If you use a dedicated WAF instance, ensure that it has been upgraded to the latest version. For details, see Managing Dedicated WAF Engines.
Constraints
- Basic web protection has two modes: Block and Log only.
- If you select Block for Basic Web Protection, you can configure access control criteria for a known attack source. WAF will block requests matching the configured IP address, cookie, or params for a length of time configured as part of the rule.
- Currently, the deep inspection and header inspection are supported in CN-Hong Kong, CN North-Beijing1, CN North-Beijing4, CN East-Shanghai1, CN East-Shanghai2, CN South-Guangzhou, CN South-Shenzhen, CN Southwest-Guiyang1, and AP-Bangkok.
- Currently, Shiro decryption check is supported in CN North-Beijing4 and CN-Hong Kong.
Enabling Basic Web Protection Rules
- Log in to the management console.
- Click in the upper left corner of the management console and select a region or project.
- Click in the upper left corner and choose Web Application Firewall under Security & Compliance.
- In the navigation pane on the left, choose Policies.
- Click the name of the target policy to go to the protection configuration page.
- Click the Basic Web Protection configuration area and toggle it on or off if needed.
- : enabled.
- : disabled.
- Configure a basic web protection rule, as shown in Figure 1.
- General Check is enabled by default. WAF defends against attacks such as SQL injections, XSS, file inclusions, Bash vulnerabilities, remote command execution, directory traversal, sensitive file access, and command/code injections. SQL injection attacks are mainly detected based on semantics.
- Select a protection level.
There are three protection levels: Default rule set (loose), Default rule set (medium), and Default rule set (tight). Default rule set (medium) is selected by default.
Table 1 Protection levels Protection Level
Description
Default rule set (loose)
WAF only blocks the requests with obvious attack signatures.
If a large number of false alarms are reported, the loose one is recommended.
Default rule set (medium)
This one is selected by default. It meets a majority of web protection requirements.
Default rule set (tight)
At this level, WAF provides the finest granular protection and can intercept attacks with complex bypass features, such as Jolokia cyber attacks, common gateway interface (CGI) vulnerability detection, and Druid SQL injection attacks.
To let WAF defend against more attacks but make minimum effect on normal requests, observe your workloads for a period of time first. Then, configure a global protection whitelist rule and select the tight level.
Click View Rule Set Details to view details about all basic web protection rules. You can know which rules are loose, which are medium, and which are tight.Click to search for a rule by CVE ID, Risk Severity, Application Type, or Protection Type.
Table 2 Protection rule description Parameter
Description
Rule ID
The protection rule ID, which is generated automatically.
Rule Description
Details of attacks the protection rule is configured for.
CVE ID
Common Vulnerabilities & Exposures (CVE) ID, which corresponds to the protection rule. For non-CVE vulnerabilities, a double dash (--) is displayed.
Risk Severity
The severity of the vulnerability, including:
- High
- Medium
- Low
Application Type
The application type the protection rule is used for. For details about applications types WAF can protect, see Application Types WAF Can Protect.
Protection Type
The type of the protection rule. WAF can discover SQL injection, command injection, XSS attacks, XML external entity (XXE) injection, Expression Language (EL) Injection, SSRF, local file inclusion, remote file inclusion, website Trojans, malicious crawlers, session fixation attacks, deserialization vulnerabilities, remote command execution, information leakage, DoS attacks, source code/data leakage.
- Enable the check items in Detection Scope based on service requirements.
Table 3 Check item description Type
Description
Deep Inspection
Identifies and blocks evasion attacks, such as the ones that use homomorphic character obfuscation, command injection with deformed wildcard characters, UTF7, data URI scheme, and other techniques.
NOTE:If you enable Deep Inspection, WAF detects and defends against evasion attacks in depth.
Header Inspection
This function is disabled by default. When it is disabled, General Check will check some of the header fields, such as User-Agent, Content-type, Accept-Language, and Cookie.
NOTE:If you enable this function, WAF checks all header fields in the requests.
Shiro Decryption Check
This function is disabled by default. After this function is enabled, WAF uses AES and Base64 to decrypt the rememberMe field in cookies and checks whether this field is attacked. There are hundreds of known leaked keys included and checked for.
NOTE:If your website uses Shiro 1.2.4 or earlier, or your website uses Shiro 1.2.5 or later but no AES keys are not configured, it is strongly recommended that you enable Shiro decryption detection to prevent attackers from using leaked keys to construct attacks.
- Configure Webshell Detection.
If you enable Webshell Detection, WAF detects web page Trojan horses inserted through the upload interface.
- Configure a protective action. You can select:
- Block: WAF blocks and logs detected attacks.
If you select Block, you can select a known attack source rule to let WAF block requests accordingly. For details, see Configuring a Known Attack Source Rule to Block Specific Visitors for a Specified Duration.
- Log only: WAF only logs detected attacks.
- Block: WAF blocks and logs detected attacks.
Suggestions
- If you are not clear about your service traffic characteristics, you are advised to switch to the Log only mode first and observe the WAF protection for a period of time. Generally, you need to observe service running for one to two weeks, and then analyze the attack logs.
- If no record of blocking legitimate requests is found, switch to the Block mode.
- If legitimate requests are blocked, adjust the protection level or configure global protection whitelist rules to prevent legitimate requests from being blocked.
- Note the following points in your operations:
- Do not transfer the original SQL statement or JavaScript code in a legitimate HTTP request.
- Do not use special keywords (such as UPDATE and SET) in a legitimate URL. For example, https://www.example.com/abc/update/mod.php?set=1.
- Use Object Storage Service (OBS) or other secure methods to upload files that exceed 50 MB rather than via a web browser.
Protection Effect
If General Check is enabled and Mode is set to Block for your domain name, to verify WAF is protecting your website (www.example.com) against general check items:
- Clear the browser cache and enter the domain name in the address bar to check whether the website is accessible.
- If the website is inaccessible, connect the website domain name to WAF by following the instructions in Website Settings.
- If the website is accessible, go to 2.
- Clear the browser cache and enter http://www.example.com?id=1%27%20or%201=1 in the address box of the browser to simulate an SQL injection attack.
- Return to the WAF console. In the navigation pane, click Events. On the displayed page, view the event log.
Example - Blocking SQL Injection Attacks
If domain name www.example.com has been connected to WAF, perform the following steps to verify that WAF can block SQL injection attacks.
- Enable General Check in Basic Web Protection and set the protection mode to Block.
Figure 2 Enabling General Check
- Enable WAF basic web protection.
Figure 3 Basic Web Protection configuration area
- Clear the browser cache and enter a simulated SQL injection (for example, http://www.example.com?id=' or 1=1) in the address box.
WAF blocks the access request. Figure 4 shows an example block page.
- Go to the WAF console. In the navigation pane on the left, choose Events. View the event on the Events page.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot