Preface

After completing the "foundation-building" trilogy of the Cloudflare tutorial series (CF overall solution, traffic sequence, edge network, and origin return), the CF tutorial series is finally going to start introducing specific features and configurations. So, which feature should be chosen first? After much thought, I decided to choose CF WAF.

The reason for choosing this is that, compared to other features, CF WAF is basically an unavoidable hurdle for every individual webmaster who builds a website using a server (webmasters using static sites hosted on free foreign clouds can ignore this~). This is because some basic features provided by other providers (such as the hotlink protection feature of domestic CDN providers) are implemented by WAF in CF, let alone other features: for example, allowing mainstream search engine crawlers while banning other illegal crawlers (including AI crawlers), allowing or banning access to specific URIs, etc., are all implemented by WAF. Furthermore, DDoS configuration also involves some features of the WAF section, so choosing WAF as the first feature to introduce is absolutely spot on.

Note: The "Features of CF WAF" section mainly discusses the theory of CF WAF, which can be quite dry. Friends who are not interested in theory and only care about practical operations can start reading directly from the "Configuration of CF WAF" section.

Features of CF WAF

How does CF WAF differ from general WAFs?

CF's WAF (Web Application Firewall) has some different design concepts compared to other brands of WAF, which results in it lacking a common feature that traditional WAFs all have: an attack signature database. The reasons are as follows:

1. Intelligent Rule Sets: CF uses an intelligent rule set based on machine learning and behavioral analysis to detect and block attacks. Compared to traditional static attack databases, this approach can respond to emerging threats more flexibly.
2. Real-time Updates: CF's WAF rules are dynamically updated. This means they can quickly respond to newly discovered threats without waiting for the update and distribution of attack databases.
3. Integration: CF's WAF is tightly integrated with its overall network architecture (such as the traffic sequence mentioned in the article: ), allowing it to utilize global threat intelligence and network traffic patterns for real-time analysis. This integration enables CF to identify and defend against attacks more effectively.
4. Custom Rules: Although CF does not have a dedicated attack database, it allows users to create custom WAF rules to meet specific security needs. This flexibility enables users to protect against their own unique threat scenarios.
5. User Friendliness: CF emphasizes simplifying the user experience, reducing the need for complex configurations and manual updates. Through automated and intelligent protection mechanisms, users do not need to spend a lot of time managing attack databases.

Overall, CF's design philosophy is to cope with changing security threats through intelligent and dynamic protection mechanisms, rather than relying on traditional, static attack signature databases.

CF WAF has its own pros and cons compared to traditional WAFs based on attack signature databases. To understand these advantages, we must first start with the pros and cons of traditional WAFs based on attack signature databases.

Pros and cons of traditional WAFs based on attack signature databases

Traditional WAFs based on attack signature databases have their own pros and cons.

Advantages：

1. Immediate Protection：
   Signature-based WAFs can immediately identify and block known attack types because the characteristics of these attacks are already recorded in the signature database. This approach provides fast and effective protection against known threats.
2. Broad Coverage：
   Signature databases typically contain a large number of known attack patterns and threat types, offering broad coverage that includes common attacks such as SQL injection, cross-site scripting (XSS), and file inclusion vulnerabilities.
3. Easy to Understand and Manage：
   Administrators can clearly see which attack signatures are enabled or disabled and understand the specific role of each signature. This makes the configuration and management of the WAF more transparent and intuitive.
4. High Maturity：
   Since signature-based WAF technology has been developed for many years, many products have mature attack databases. After multiple iterations and optimizations, they offer high reliability and stability.

Disadvantages：

1. Reliance on Updates：
   Signature databases need to be constantly updated to cope with new attack methods. If the signature database is not updated in a timely manner, new attacks may not be identified and blocked, which makes WAF potentially lag behind when facing emerging threats.
2. High false positive rate：
   Signature-based detection methods often generate high false positive rates because they are based solely on specific pattern matching, which may misidentify legitimate traffic as attacks. This affects the experience of normal users.
3. Difficult to cope with zero-day attacks：
   For unknown zero-day attacks, due to the lack of corresponding signatures, WAF may not be able to perform effective detection and protection, and attackers can exploit unidentified new vulnerabilities to bypass protection.
4. Performance bottlenecks：
   The signature matching process requires checking every request. When the signature database is massive, it increases processing time and resource consumption, affecting WAF performance and website response speed.
5. Management complexity：
   Over time, signature databases become larger and more complex, making the management and maintenance of these signatures more difficult, requiring professional knowledge and additional management effort.

Therefore, traditional signature-based WAFs have clear advantages in protecting against known threats, but have certain limitations when facing emerging threats, zero-day attacks, and false positive issues. Thus, modern WAF products usually combine multiple detection technologies to make up for the shortcomings of traditional methods.

Pros and cons of CF WAF

Compared to traditional attack signature-based WAFs, CF's WAF has unique advantages and disadvantages.

Advantages

1. Behavioral analysis and machine learning：
   CF WAF uses behavioral analysis and machine learning to detect and block attacks, enabling it to identify unknown and emerging attack patterns. By analyzing traffic patterns and behaviors in real time, it can more effectively cope with dynamic and complex threats.
2. Global threat intelligence sharing：
   CF leverages its global network to collect and analyze threat intelligence, applying this information to WAF rules. This means CF's WAF can quickly respond to new attack patterns and threats, providing timely and effective protection.
3. Flexible rule creation and management：
   Users can create and adjust WAF rules according to their needs, providing greater flexibility and customization. This flexibility allows optimization for specific application scenarios and threats.
4. Reducing false positives：
   Through smart rules and behavioral analysis, CF WAF can reduce false positive rates, ensuring that legitimate traffic is not misidentified and intercepted, thereby improving user experience.
5. High performance and scalability：
   CF's distributed architecture and efficient processing capabilities enable it to handle large volumes of traffic without affecting performance. Features like caching and content optimization also further improve website response speed and performance.
6. Easy to manage and deploy：
   CF provides a simple user interface and API, allowing users to easily configure and manage WAF rules without needing a deep understanding of complex attack signature databases.

Disadvantages

1. Customization needs for advanced users：
   Although CF provides flexible rule creation features, some advanced users may find that the lack of specific attack signature databases limits precise protection against specific attacks.
2. Dependence on CF's infrastructure：
   The effectiveness of CF WAF depends on its global network and infrastructure. If a user's services do not run entirely on CF, they may face integration and coverage issues.
3. Potential learning curve：
   Although the interface and API are designed to be simple and easy to use, for inexperienced users, fully utilizing the flexibility and customization features of CF WAF may require some learning and adaptation time.
4. Privacy and data control：
   Processing all traffic through CF's infrastructure may raise concerns among some users regarding privacy and data control, especially regarding the processing and storage of sensitive data.

Therefore, overall, CF's WAF is actually mainly suitable for users who build applications using CF's infrastructure on a large scale, and it has its limitations: if user services are not entirely deployed on CF, they still need to rely on traditional WAF-like solutions.

Note: Some excellent security products have actually fully integrated the advantages of traditional WAF and CF WAF, such as Palo Alto firewalls.

Introduction to CF WAF features (Free plan)

In Cloudflare's Free plan, WAF functionality is limited. Specifically, the Free plan provides basic security protection features but does not include smart rule sets and advanced WAF features.

Some basic features of WAF in the Free plan are as follows:

1. Basic Rule Set: The Free plan includes some basic WAF rules that can protect against common threats and attack types, such as SQL injection, cross-site scripting (XSS), etc.
2. Manual rule management: Users can manually add and manage some basic protection rules, but these rules are relatively simple and lack intelligent and dynamic update features.
3. Limited customization: Although the Free plan allows users to create custom WAF rules, the complexity and number of these rules are limited, and they are not as comprehensive as the features in paid plans.
4. Basic protection level: The Free plan mainly provides a basic level of protection and does not include advanced threat intelligence and machine learning-driven smart rules.

Among them, the main content of the basic rule set includes the following:

1. SQL injection protection：
   • Detect and block attack behaviors that inject malicious code through SQL query statements.
2. Cross-site scripting (XSS) protection：
   • Block malicious scripts from being injected into web pages, thereby protecting user data and browser security.
3. Local File Inclusion (LFI) and Remote File Inclusion (RFI) protection：
   • Prevent attackers from executing malicious code through file inclusion vulnerabilities.
4. Cross-Site Request Forgery (CSRF) protection：
   • Prevent attackers from forcing users to perform unwanted actions through forged requests.
5. Command Injection Protection：
   • Detect and block attacks that inject malicious code through command-line arguments.
6. Path Traversal Protection：
   • Prevent attackers from accessing and manipulating arbitrary files on the server.
7. File Upload Vulnerability Protection：
   • Detect and block attacks that inject malicious files through file upload functions.
8. Brute Force Protection：
   • Block frequent and repeated login attempts to prevent accounts from being brute-forced.
9. Malicious Crawler and Automated Tool Protection：
   • Identify and block access requests from malicious crawlers and automated tools to protect website content and resources.
10. DDoS Attack Mitigation：
    • Automatically detect and mitigate large-scale Distributed Denial of Service (DDoS) attacks to ensure website availability.

These basic rule sets and specific protection contents constitute the core protection mechanism of Cloudflare WAF, helping users effectively defend against various network attacks and security threats.

Configuration of CF WAF

Introduction to configurable features in the CF WAF section

In the previous section, I mentioned the basic functions of CF WAF in the Free plan. In fact, the specific configuration of CF WAF is very simple, and the basic rule sets are enabled by default:

Therefore, there are only 3 items that can be configured in the WAF section, Custom Rules:

Rate Limiting (I will talk about this part later when discussing the DDoS feature):

Tools:

CF WAF custom rules

Brief description of custom rules

The configuration logic of custom rules is based on user-defined conditions and corresponding actions to detect and protect specific types of traffic: based on the "incoming request matching conditions" and "optional actions" provided by CF, users can configure appropriate rules themselves and use logical symbols (or, and), combined with CF's automated programs, DDoS protection, etc., to "combine" them to achieve various practical functions: for example, allowing crawlers of mainstream search engines while blocking other crawlers, blocking abnormal UAs, hotlink protection, etc. The 5 WAF rules provided by the Free plan are normally sufficient to meet the needs of individual webmasters.

Custom rules support a wide variety of condition types:

Finally, there is a cookie value field, which I won't waste another screenshot on, and the supported actions are as follows:

Supported actions for custom rules

Managed Challenge

Managed challenge is an automated security check mechanism that determines whether a visitor is a legitimate user by presenting a series of verification requests to them. These challenges are typically used to detect and block malicious bots, crawlers, and other automated attacks, while ensuring that legitimate users can access the website normally.

"The "Managed Challenge" processing flow is as follows:

1. Trigger conditions:
   • Managed challenges are triggered when a request meets specific conditions (such as certain rules, thresholds, or detected suspicious behavior). Trigger conditions can include IP address, request frequency, request header content, geographic location, etc.
2. Challenge types:
   • CAPTCHA: Displays a graphical verification code, requiring the user to input it to verify they are human.
   • JavaScript Challenge: Verifies the legitimacy of the request by having the user's browser execute a piece of JavaScript code. If the browser successfully executes the code, it indicates that the request comes from a real user.
   • Behavioral Challenge: Determines legitimacy based on the analysis of user behavior, such as mouse movements, clicks, and other human behavioral characteristics.
3. User response:
   • Visitors need to complete the challenge, such as entering a verification code or waiting for the JavaScript challenge to complete. If the challenge is successfully passed, the request is allowed to proceed; otherwise, the request is blocked.
4. Result processing:
   • Requests that successfully pass the challenge will continue to be processed, allowing access to the website or resources.
   • Requests that fail to pass the challenge will be blocked, and visitors will receive corresponding prompts or error messages.

Managed challenges are mainly used in the following scenarios:
• Prevent DDoS attacks: Slow down a large number of malicious requests through the challenge mechanism to protect server resources.
• Block malicious bots: Prevent access by automated scripts and malicious crawlers to protect website content and data.
• Improve website security: Reduce malicious traffic to improve the overall security and stability of the website.

JS Challenge

JS challenge is a security check mechanism that verifies whether a request comes from a real user rather than an automated program (such as a malicious bot) by executing JavaScript code. This mechanism is mainly used to distinguish human users from automated scripts to ensure that only legitimate users can access the website.

"The "JS Challenge" processing flow is as follows:

1. Trigger conditions:
   • JS challenges are triggered when a request meets specific conditions (such as certain rules, thresholds, or detected suspicious behavior). Trigger conditions can include IP address, request frequency, request header content, geographic location, etc.
2. Challenge process:
   • When a request triggers a JS challenge, CF will send a piece of JavaScript code to the client browser.
   • The browser must execute this JavaScript code. This process is usually transparent, and the user will not notice it.
3. Verify request:
   • After executing the JavaScript code, the browser will automatically send the execution result back to CF.
   • CF verifies the execution result. If the result is correct, it indicates that the request comes from a real user; if the result is incorrect or the browser fails to execute the code, the request may come from an automated program.
4. Result processing:
   • Pass the challenge: If the verification is passed, the request will be allowed to continue, and the user can access the website normally.
   • Fail to pass the challenge: If the verification is not passed, the request will be blocked, and the user will receive corresponding error messages or prompts.

JS challenges and managed challenges are used in the same scenarios.

Interactive Challenge

Interactive challenge is a security check mechanism that verifies whether a request comes from a real user by requiring the user to complete specific interactive operations (such as CAPTCHAs, clicking confirmation buttons, etc.). This mechanism is mainly used to distinguish human users from automated programs (such as malicious bots), ensuring that only legitimate users can access the website.

"The "Interactive Challenge" processing flow is as follows:

1. Trigger conditions:
   • Interactive challenges are triggered when a request meets specific conditions (such as certain rules, thresholds, or detected suspicious behavior). Trigger conditions can include IP addresses, request frequency, request header content, geographic location, etc.
2. Challenge process:
   • When a request triggers an interactive challenge, Cloudflare displays an interactive verification page to the client.
   • The page typically contains a CAPTCHA (such as reCAPTCHA) or other forms of interactive challenges (such as clicking a confirmation button, dragging a slider, etc.).
3. User response:
   • Users need to complete the interactive operations displayed on the page, such as entering a CAPTCHA or completing slider verification.
   • After completing the operation, the verification result is sent back to Cloudflare.
4. Verify request:
   • Cloudflare validates the user's response. If the response is correct, it indicates that the request comes from a real user; if the response is incorrect or the user fails to complete the operation, the request may come from an automated program.
5. Result processing:
   • Pass the challenge: If the verification is passed, the request will be allowed to continue, and the user can access the website normally.
   • Fail to pass the challenge: If the verification is not passed, the request will be blocked, and the user will receive corresponding error messages or prompts.

Interactive challenges are used in the same scenarios as JS challenges and managed challenges.

Skip

“The ”Skip" action allows you to specify that certain requests are not restricted by specific WAF rules or the entire WAF based on specific conditions. This means these requests will directly bypass the defined WAF checks and continue their processing flow. This provides flexibility for some legitimate requests that might otherwise trigger false positives or do not require strict inspection.

"The "Skip" processing flow is as follows:

1. Trigger conditions:
   • When configuring a skip action, specific conditions need to be set. When a request meets these conditions, the skip action will be executed. Trigger conditions can include IP addresses, request methods, URI paths, request header content, geographic location, etc.
2. Configure skip rules:
   • In the Cloudflare WAF settings, create or edit a firewall rule, select "Skip" as the action, and specify the rules or checks that should be skipped.
3. Skip processing:
   • When a request meets the configured conditions, the request will skip the specified WAF rules or checks and will not trigger the corresponding protective measures. The request will pass directly and enter the next processing stage.

"Skip" is mainly used in the following scenarios:
• False positive handling: If certain legitimate requests frequently trigger WAF rules resulting in false positives, the skip action can be used to prevent these requests from being blocked.
• Specific traffic optimization: For certain trusted traffic sources (such as internal systems, trusted IPs, etc.), skip actions can be configured to reduce unnecessary checks and improve processing efficiency.
• Debugging and testing: During development and testing, skip actions can be used to bypass certain WAF rules for faster debugging and verification.

Block

"The "Block" action instructs the WAF to immediately reject a request when it detects that the request meets specific conditions, preventing it from continuing to the website server. This is a key step in protective measures used to protect the website from various attacks and malicious behaviors.

"The "Block" processing flow is as follows:

1. Trigger conditions:
   • When configuring a block action, specific conditions need to be set. When a request meets these conditions, the block action will be executed. Trigger conditions can include IP addresses, request methods, URI paths, request header content, geographic location, query strings, user agents, etc.
2. Configure block rules:
   • In the Cloudflare WAF settings, create or edit a firewall rule, select “Block” as the action, and specify the conditions or rules that should be blocked.
3. Block processing:
   • When a request meets the configured conditions, Cloudflare WAF will reject the request and return the corresponding HTTP status code (usually 403 Forbidden or 406 Not Acceptable). The request will not reach the origin server.

"Block" is mainly used in the following scenarios:
• Prevent attacks: Block known attack patterns, such as SQL injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), etc.
• Block malicious traffic: Intercept requests from malicious IP addresses, malicious bots, or crawlers to protect website resources and data.
• Strengthen security protection: Prevent specific types of malicious requests to enhance the security and reliability of the website.

Pros, cons, and usage priorities of Managed Challenge, JS Challenge, and Interactive Challenge

Managed Challenge), JS Challenge, and Interactive Challenge are three different security verification mechanisms, each with its own advantages and disadvantages, suitable for different scenarios.

Managed Challenge:
Advantages
• Automatic updates: Managed and updated by CF, requiring no manual configuration by the user.
• Efficient protection: Effectively defends against multiple types of attacks, including DDoS and malicious bots.
• User-friendly: Displays verification only when necessary, without overly disturbing users.
Disadvantages
• Potential false positives: May mistakenly block legitimate users, especially when the challenge mechanism is strict.
• Dependence on CF configuration: Users have less control over the specific form of the challenge.

JS Challenge:
Advantages
• Seamless experience: In most cases, users will not notice the existence of the challenge, providing a smooth experience.
• Automated blocking: Effectively blocks automated tools and bots that do not support JavaScript.
Disadvantages
• Script dependency: Relies on browser support for JavaScript, and may be ineffective for devices and browsers that do not support JavaScript.
• Potential bypass: Advanced attackers may write scripts to bypass JavaScript challenges.

Interactive Challenge:
Advantages
• High accuracy: Effectively distinguishes real users from bots through interactive operations that are difficult for humans to simulate.
• Strong protection: Suitable for high-risk scenarios, providing higher security.
Disadvantages
• Impact on user experience: Requires manual operations by the user, which may affect the user experience, especially when it occurs frequently.
• Poor adaptability: High requirements for adaptability to user devices and network environments, which may make it inconvenient to use in some cases.

The applicable scenarios and configuration priority recommendations for these three challenge methods are as follows:
• Managed Challenge has a higher priority because it is managed by CF and can be dynamically adjusted based on the latest threat intelligence. It is suitable for routine protection in most scenarios and is ideal for users who want to simplify configuration and rely on CF's professional management.
• JS challenge takes precedence over interactive challenge because it has less impact on user experience, making it suitable for scenarios where you want to block most automated attacks without affecting user experience.
• Interactive challenge has the lowest priority, but in high-risk situations, it may be triggered directly to provide the strongest security guarantee, making it suitable for scenarios with high security requirements, such as login pages, sensitive data access, etc., to prevent advanced automated attacks.

Overall, these three challenge actions can be flexibly combined and used (for general users, Managed Challenge is sufficient), configured according to specific needs and security policies to achieve the best protection effect.

Practical examples of custom rule configuration

Having discussed so much theory, it's time for some practical stuff. Below, I have compiled some common requirements and their corresponding custom rule configurations, so you can choose according to your needs.

Allow CF-verified automated programs to crawl website information

This is probably something every individual blogger needs: allowing automated programs, including mainstream search engines, to index the website while blocking other malicious crawlers. You can add limiting conditions using "and", as shown in the figure below:

Note: "WAF components to skip" is mandatory, but you can choose which specific ones to select based on your needs; I chose the first three.

In the figure above, if "and" is not added, it will apply to all subdomains under the managed second-level domain; by adding "and", you can restrict access to the website corresponding to the hostname "blog.tangwudi.com" to only verified automated programs (search engine crawlers, etc.).

This rule only explicitly allows access from legitimate automated programs and does not reject malicious crawlers. It needs to be combined with the subsequent "Managed Challenge" rule for unauthorized automated programs to achieve the function of both allowing legitimate automated programs and blocking malicious ones.

Note 1: Changing "Skip" to "Block" in the above rule will block mainstream search engine bots from accessing the website.

Note 2: Known automated programs contain many categories. If needed, you can perform fine-grained control over these categories, which is mainly controlled through the "Verified Bot Category" field. For example, you can individually block artificial intelligence (AI) bots and crawlers from scraping your website content without your permission to train large language models (LLMs) and regenerate content. This rule needs to be placed before the "Allow Known Bots" rule, with the specific configuration as follows:

Apply Managed Challenge to abnormal traffic (mainly malicious crawlers)

The rule configuration is as follows:

This rule, combined with the previous rule that allows "Known Bots", actually implements the famous CF "5-second shield" (Managed Challenge) for non-CF-verified automated programs (including malicious crawlers). Of course, there are ways to bypass the CF "5-second shield", but at least it raises the threshold for malicious crawlers, and blocking the vast majority of them is considered a success.

Allow access to specific URIs of the website

Why is there such a need? Actually, CF can identify and allow non-malicious automated programs, but this requires paying to upgrade to Pro:

For Free plan users, they can only manually allow access to specific URI paths. For example, if a blog has an RSS feature, it is necessary to open up periodic access to the blog's RSS for various RSS-related automated programs:

API interface access is handled in the same way.

Allow access of specific automated programs via UA

This is mainly based on UA (UserAgent) determination. If some automated programs have their own specific UA keywords, this method can be used. For example, allowing Google bots to access via UA control. Of course, other limiting conditions can also be added via "and", such as Google's ASN:

Note 1: The figure above only uses Google bot as an example. In practice, to allow Google bot access, you only need to allow "Known Bots" access as mentioned earlier.

Note 2: If you only want to restrict requests with specific UA content (and no other additional conditions), the User Agent Blocking feature mentioned later is more convenient.

Hotlink protection

The hotlink protection feature mainly judges the content of the "Referer" field (in the HTTP header). For example, for a request that comes from searching your website address on the Google search engine and clicking to visit, the referer will contain the Google keyword. Similarly, the same applies to access requests searched from other search engines (as well as visits via links on other websites).

Taking my blog address as an example, if I only allow access referred from Google and Bing search engines, as well as the friendly link from the partner site "abc.example.com", while blocking links from any other sites, the rule is as follows:

Summary of the custom rules section

Actually, the practical examples introduced above are just the ones I find most commonly used. There are many other items in the fields section, such as cookies, country/region, source IP address, request method, HTTP version, threat score, etc. These items can produce a vast number of combinations through "and" and "or" to achieve highly flexible functions. You can configure them according to your actual needs, so I won't say too much more, lest I sound like a nagging old lady.

Since the Free plan only has a quota of 5 custom rules, when creating rules, try to merge rules with the same priority and action into one: for example, if the actions are all "Skip", "Block", "Managed Challenge", etc. This way, except for a few rules with very high priority requirements (such as banning AI bot scraping), after merging the rest, the quota of 5 custom rules is more than enough.

In addition, to configure CF WAF custom rules, the configuration personnel need to have a certain level of understanding of various concepts in the fields, such as the meaning of ASN, referer, and UserAgent, and their corresponding content in actual traffic. For example, the UA content of the OpenAI bot is like this:

You need to know its UA content first to know how to use the User Agent field of custom rules to match it; otherwise, you won't even know where to start when you want to configure the rules.

IP Access Rules

Actually, IP access rules shouldn't be written in the WAF section, because in the traffic sequence, IP access rules are located before the WAF functions:

However, this feature is very simple, and in the CF console, it is also located in the WAF section:

So I might as well write about it here together, and also bundle in another feature called "User Agent Blocking".

So, what is the main purpose of IP access rules? As the name suggests, it allows you to control which IP addresses (or IP address ranges) or ASN numbers can access your website, and which cannot.

Note: Controlling by country/region is an Enterprise plan feature and is not supported in the Free plan.

For example, if I want to allow a certain IP range (assuming 192.168.100.0/24) to access my website, while blocking IPs from Google (AS15169) and Microsoft (AS8075) from accessing my website, the settings are as follows:

Therefore, although custom rules can also achieve this function, if the target is clear (can be directly locked down via IP or ASN), using IP access rules is more convenient and faster than using custom rules.

User Agent Blocking

CF's WAF provides two main methods to block specific User Agents (UserAgent): through the custom rules mentioned earlier, and the User Agent Blocking in the Tools section:

Although these two seem to overlap, they have different purposes and flexibility:

1. Custom Rules：
   • Flexibility: Custom rules allow you to create complex firewall rules based on various conditions (such as IP address, ASN, geographic location, request path, etc.), including blocking specific user agents. You can define the logic and priority of the rules to meet more detailed needs.
   • Application Scenarios: Suitable for protection scenarios that require complex conditions. For example, you might need to combine multiple conditions (such as user agent and request path) to block certain malicious traffic.
2. User Agent Blocking Feature：
   • Specialization: This feature is specifically designed to block specific user agents. It provides a simplified interface and operation, making the management of user agents more direct and convenient.
   • Application Scenarios: Suitable for situations where you need to quickly and easily block certain user agents. For example, if you find that certain crawlers or malicious tools use specific user agents, you can quickly add these user agents to the block list.

Therefore, similar to the IP access rules mentioned earlier, the User Agent Blocking feature can also be implemented using custom rules. However, custom rules offer greater flexibility and fine-grained control, while the dedicated User Agent Blocking feature provides a simple and fast way to handle user agent-related blocking needs. You can choose between the two based on specific protection requirements and operational complexity.

Summary

Finally, I've finished explaining the features of CF WAF. Actually, configuring this part is not complicated, and the commonly used actions are just those three (Skip, Block, Managed Challenge). However, to clearly explain the characteristics of CF WAF and its advantages and disadvantages compared to traditional WAFs from an overall perspective, a lot of professional knowledge is required, and only in this way can you truly understand the differences in "custom rules".

A one-sentence summary of CF WAF: Seamlessly integrated with CF's global network, it leverages artificial intelligence and machine learning, combines DDoS protection, Bot management, and security analytics, supplemented by custom rules, to monitor and protect real-time traffic, and automatically detect and respond to various cyberattacks.

Therefore, it actually makes little sense to talk about CF WAF in isolation, because it is inherently a reflection of the overall effect of aggregating CF's many functional modules.