Note:
If your Web Rule Library supports 25 attack types, refer to this document to set protection rules.
This document introduces how to set protection rules through Web Application Firewall (WAF) to protect against web attacks.
Background
The Converge Cloud WAF rule protection engine provides expert rule sets based on Converge Cloud security Web threats and intelligence accumulation, automatically protecting against OWASP TOP10 attacks. Currently, the protection targets 25 common types of Web attacks, including SQL injection, XSS attack, command injection attack, server-side request forgery, Trojan Horse attack, etc. The newly upgraded rule engine supports more granular rule category management and finer operational capability. Optimizations include:
- Rule engine protection latency reduced, access experience optimized;
- Rule engine categorization is more granular, leveraging refined security operation;
- Rule protection rule allowlist is more granular, supporting scheduled and periodic effect.
Operation Steps
Managing the Rules
- Log in to the Web Application Firewall console, and at the top of the left sidebar, switch the console to the instance location.
- Select Protection Policies > Basic Security in the left sidebar.
- On the basic security page, select the target domain name, click Web Security, and select Regex Engine. The Web security page shows different attack type rule set conditions in an integrated way and provides a uniform configuration management feature. Details are as follows:
- Number of enabled rules: Displays the total number of rules in the corresponding attack type rule set and the current number of enabled rules. This helps users understand the current security protection status and modify rules as needed. By default, all are enabled.
- Action: Supports one-click selection of Observe/Block mode to improve management efficiency. Defaults to Block mode.
- Protection level: Supports selecting different protection level rules, including loose, normal, strict, or super strict. The normal level includes loose rules, the strict level includes normal and loose rules, and the super strict level includes all rules. Defaults to strict.
- On/Off: Supports users to configure with one click whether specific attack type rule sets take effect, suitable for rapid security policy adjustment as needed.
- Click in the upper right corner Batch configuration, select rule sets as needed to batch configure protection mode and protection level, then click Apply to successfully configure.
- Click View Details to check corresponding attack type rule set info and set the status of individual rules, supporting disable, enable, or observation only.
Observation only means attack delivery to the attack log when a rule is triggered, without performing other actions. Single rule status has a higher priority than sub-type and global settings. Once set, it will be locked but can be manually unlocked. After unlocking, it synchronizes with sub-type or global setting status. All rules are enabled by default.
- Users can enter "Rule ID, Rule description, CVE number" to search rule sets, view specific rules and perform operations. Meanwhile, click in the upper left corner Batch Switch Rule Status to alter multiple rule statuses at the same time.
Rule Allowlist
For related operations on rule allowlist, see Rule Allowlist.
Viewing Rule Categories
- Log in to the Web Application Firewall console, and at the top of the left sidebar, switch the console to the instance location.
- Select Service Management > System Settings > Web Rule Library in the left sidebar.
The attacks against which the WAF currently protects are classified as follows:
| Attack Classification | Attack Description |
|---|---|
| XSS Attack / XSS Attack (Extended) | Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page. |
| SQL Injection Attack / SQL Injection Attack (Extended) | A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands. |
| Known Exploits / Known Exploits (Extended) | Known Exploits are mainly used to detect remote arbitrary code execution vulnerabilities, remote arbitrary command execution vulnerabilities, path traversal vulnerabilities, open redirect vulnerabilities, unauthorized access vulnerabilities, etc. in various applications, web servers, middleware, etc. |
| File Upload Attack / File Upload Attack (Extended) | The file upload attack exploits vulnerabilities in an application's inadequate validation of uploaded file types, content, or paths to upload malicious files (such as WebShells, trojans, etc.), thereby gaining control over the server. |
| Server-Side template injection vulnerability / Server-Side template injection vulnerability (Extended) | Prevents attackers from exploiting vulnerabilities in server access request APIs to initiate malicious requests. |
| Unauthorized access vulnerability / Unauthorized access vulnerability (Extended) | Some management backends and debugging pages don't verify the permissions of users sending requests. Therefore, attackers can use some system features to get sensitive information and execute code. |
| Trojan Horse Attack / Trojan Horse Attack (Extended) | A WebShell is a malicious script implanted on a web server to enable remote control by attackers. Attackers upload WebShell scripts (e.g., PHP, ASP files) via file upload vulnerabilities or other exploits, allowing them to execute commands, steal data, or establish persistence for further attacks. |
| XML Injection Attack / XML Injection Attack (Extended) | XXE (XML External Entity) attacks exploit vulnerabilities in XML parsers by crafting malicious XML documents to read local files, initiate remote requests, or cause denial of service. Attackers inject external entity definitions to access restricted resources or probe internal network information. |
| Non-Compliant protocol / Non-Compliant protocol (Extended) | Attackers launch attacks by crafting malformed HTTP request packets. |
| Invalid access to core files / Invalid access to core files (Extended) | Arbitrary file read/download vulnerabilities allow attackers to bypass application restrictions by crafting specific paths or parameters to read or download arbitrary files (e.g., configuration files, database credentials). This is typically caused by insufficient validation of user-supplied file paths. |
| Command Injection Attack / Command Injection Attack (Extended) | The attacker crafts malicious inputs (such as system commands or code) to exploit vulnerabilities in how the target program processes user inputs. This causes the system to improperly execute the injected code or commands. Such attacks may result in data breaches, service disruptions, or even complete compromise of system control. |
| Server-Side request forgery | Prevents attackers from exploiting vulnerabilities in server access request APIs to initiate malicious requests. |
| Bad Robot | Bad Robot detection is mainly used to detect malicious tools such as web scanners and script batch acquisition tools. |
| LDAP Injection Attack | LDAP Injection attacks involve inserting malicious LDAP query statements into input data from the client to manipulate predefined LDAP query logic. Successful LDAP injection can lead to unauthorized access to sensitive information in directory services (e.g., user credentials, permissions) or even modification/deletion of directory data. |
Note:
The expansion rule set for each attack type has a wider detection range, broader detection content, and stronger detection ability compared with the standard rule set, but it requires tolerating certain rule false positives.