Block Website Scans
最終更新日：2026-08-27 17:15:24
Reading time: About 7 minutes
Prerequisites: The hostname has been onboarded, and the WAF policy is enabled.
Background: Why Websites Are Scanned
Before launching a precise attack, attackers typically use automated tools to conduct reconnaissance scans of the target website for issues such as unpatched CVEs, misconfigured admin paths, and endpoints vulnerable to SQL injection. Common scanning methods include:
| Scanning Method | Typical Behavior | Example Tools |
|---|---|---|
| Vulnerability scanning | Sends a large number of requests containing attack payloads to probe known vulnerabilities one by one | AWVS, Nessus, AppScan, sqlmap |
| Directory enumeration | Enumerates common paths (such as /admin/ and /backup/) to find exposed entry points |
dirbuster, gobuster |
| Rule probing | Repeatedly varies payloads to trigger different WAF rule types and test the protection boundary | Manual or scripted fuzzing |
Defense approach: layered blocking — identify and stop scanning behavior at the reconnaissance stage of the attack chain, reducing the success rate of subsequent precise attacks.
Why can’t the managed rules fully block scanning? WAF Managed Rules identify requests based on the characteristics of a single request, while scanners can constantly change request content and rotate source IPs to make individual requests look “normal.” Scan Protection determines whether scanning is taking place based on access behavior (such as request frequency, the number of rule types triggered, and the proportion of requests to nonexistent directories), complementing the managed rules.
Coverage of Scan Protection: Scan Protection targets scanning behavior from a single source (IP or IP + JA3), covering high-/low-frequency scanning from a single source and high-frequency scanning from multiple sources. If a large number of different sources each scan at low frequency and slow speed, this has become distributed Bot behavior, which is outside the scope of Scan Protection. In such cases, use Bot Management instead.
Defense Strategy Overview
| Defense Layer | Capability | Use When |
|---|---|---|
| WAF Managed Rules | Blocks known attack payloads, covering the OWASP Top 10 | Baseline protection for all websites (enable by default) |
| Scan Protection | Identifies scanning tool signatures and behavioral patterns, blocking the scanning behavior itself | You have experienced scanning attacks or want proactive defense |
| IP/Geo Firewall | Blocks access from known malicious IPs or non-business regions | Additional blocking after discovering scanning from concentrated sources |
Why should managed rules be combined with Scan Protection? Managed rules identify individual requests, while Scan Protection judges based on the behavior of a source. A single scan repeatedly triggers different rule types and accesses a large number of nonexistent directories — behavioral characteristics that are difficult to identify from a single request alone, which is why Scan Protection is needed as a complement.
Principle: First enable WAF Managed Rules in Monitor mode and Scan Protection sub-features with the Log action. Observe for 3–7 days, and after confirming no false positives, gradually switch them to Block and Deny.
Step 1: Enable WAF Managed Rules
- Go to Security Settings > Policies > [Target Hostname] > WAF
- Set the Protection Mode to Monitor. For the first-time onboarding domains, we recommend running in Monitor mode for 3–7 days. After confirming there are no false positives, change the protection mode to Block.
- Confirm the actions of the following rule groups are set to Deny, so that the platform can analyze the denied requests:
| Rule Group | Attack Types Covered |
|---|---|
| SQL Injection Protection | SQL injection probing |
| Cross-Site Scripting Protection | Cross-site scripting probing |
| Command Injection | System command injection probing |
| Scan Detection | Vulnerability scanner signatures |
- Click Deploy to apply the configuration.
Why do the managed rules need to be switched to Deny first? Repeated Violation Detection within Scan Protection relies on records of requests blocked by WAF Managed Rules to identify scanning behavior. If all managed rules are set to Log (which only records and does not block), no blocking records are generated, so Repeated Violation Detection cannot identify any behavior. Therefore, before using Scan Protection, you need to set the core attack rule groups to Deny.
For detailed configuration steps, see Configuring WAF Managed Rules
Step 2: Configure Scan Protection
Scan Protection consists of three independent sub-features. We recommend using all three together to cover different dimensions of scanning behavior:
| Sub-Feature | Detection Principle | Blocking Effect |
|---|---|---|
| Scanning Tool Detection | Identifies characteristic requests of common scanning tools | Directly blocks common scanning tools |
| Repeated Violation Detection | Counts a single target’s repeated triggering of WAF rules within a period | Blocks systematic vulnerability probing |
| Directory Probing Detection | Counts a single target’s access to a large number of nonexistent paths (high 404 ratio) | Blocks path enumeration behavior |
Configuration
- Go to Security Settings > Policies > [Target Hostname] > WAF > Scan Protection
- Set the action of all three sub-features to Log
- Click Deploy to apply the configuration, then observe for 3–7 days and judge whether any requests would be incorrectly blocked based on the triggered detections
Recommended Threshold Settings
| Configuration Item | Recommended Starting Value | Tuning Direction |
|---|---|---|
| Repeated Violation Detection — Rule Type Threshold | 3–5 types | Lower (more sensitive) / raise (more lenient) |
| Repeated Violation Detection — Request Count Threshold | 10–20 requests | Adjust based on the peak QPS of normal business |
| Directory Probing — Request Count Threshold | 50 requests | Raise for high-traffic sites |
| Directory Probing — 404 Ratio Threshold | 50%–70% | Lower (more sensitive) / raise (more lenient) |
How to choose the statistical target? If many users share the same egress IP (for example, an office network), we recommend selecting IP + JA3 fingerprint so that different clients behind the same egress IP can be distinguished, reducing false positives.
Tip: The suggested values above are initial starting points. Tune them based on the peak QPS of your normal business traffic. For the full list of configurable parameters, see Configure Scan Protection.
Step 3: Observe and Tune
During the observation and validation phase, focus on checking the following false positive scenarios:
| False Positive Signal | Investigation Direction | How to Handle |
|---|---|---|
| Internal security scanning tool IP gets matched | Verify whether it is known internal penetration testing | Add an exception and allow the IP |
| Partner API calls trigger a rule | Confirm the API’s request format | Add an exception for the rule on the specific interface |
| Large volumes of normal user requests are misjudged as scanning | Check whether the Repeated Violation Detection thresholds are too low | Raise the thresholds or narrow the statistical target scope |
Check frequency during the observation period: Review Attack Logs once a day, focusing on IPs with high Scan Protection hit counts.
Step 4: Switch to Deny
After confirming there are no false positives:
- Switch the actions of the three Scan Protection sub-features to Deny one by one
- We recommend switching in this order: Scanning Tool Detection → Directory Probing Detection → Repeated Violation Detection
- After each switch, observe for 24 hours and move on to the next only after confirming there are no anomalies
- Click Deploy to apply the configuration, and continue to monitor the Attack Logs
Recommended Switch Order
| Priority | Sub-Feature | Reason for This Order |
|---|---|---|
| ① Switch first | Scanning Tool Detection | Based on clear tool signatures; lowest false positive rate |
| ② Switch next | Directory Probing Detection | High-404 behavior is rarely triggered by normal users |
| ③ Switch last | Repeated Violation Detection | Depends on threshold tuning and needs sufficient validation |