Preface

After completing the "foundation-building" trilogy of the CloudFlare series of tutorials (CF overall solution, traffic sequence, edge network and back-to-origin), the CF series of tutorials is finally going to start introducing specific functions and configurations. So which one should I choose as the first function? After much deliberation, I decided to choose CF WAF.

The reason for choosing this is that compared with other functions, CF WAF is basically a hurdle that every individual webmaster who uses a server to build a website cannot avoid (webmasters who use static sites and host them on foreign free clouds please ignore it~), because some basic functions provided by other providers (such as the anti-hotlink function of domestic CDN providers) are implemented by WAF in CF, not to mention other functions: for example, allowing mainstream search engine crawlers and prohibiting other illegal crawlers (including AI crawlers), allowing or prohibiting access to specific URIs, etc. are all implemented by WAF, and the configuration of DDOS will also involve some functions of WAF. Therefore, there is nothing wrong with choosing WAF as the first function introduced.

In addition: The "Features of CF WAF" section mainly talks about the theory of CF WAF, which is relatively boring. Friends who are not interested in theory and only care about practical operations can start directly from the "Configuration of CF WAF" section.

Features of CF WAF

How is CF WAF different from general WAF?

CF's WAF (Web Application Firewall) has some different design concepts from other brands of WAF, which results in it not having a common feature of traditional WAFs: attack signature library. The reasons are as follows:

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

In general, the design concept of CF is to respond to ever-changing security threats through intelligent and dynamic protection mechanisms, rather than relying on traditional, static attack signature libraries.

CF WAF has its own advantages and disadvantages compared to traditional WAF based on attack signature library. To understand these advantages, we need to first talk about the advantages and disadvantages of traditional WAF based on attack signature library.

Advantages and disadvantages of traditional WAF based on attack signature library

Traditional WAF based on attack signature library has its own advantages and disadvantages.

advantage:

1. Instant protection:
   A signature-based WAF can immediately identify and block known attack types because the characteristics of these attacks have been recorded in the signature library. This approach provides fast and effective protection against known threats.
2. Wide coverage:
   Signature libraries usually contain a large number of known attack patterns and threat types, covering a wide range of common attacks, including SQL injection, cross-site scripting (XSS), file inclusion vulnerabilities, etc.
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 WAF configuration and management more transparent and intuitive.
4. High maturity:
   Since signature-based WAF technology has been developed for many years, many products have mature attack libraries and have undergone multiple iterations and optimizations, with high reliability and stability.

shortcoming:

1. Dependency Updates:
   The signature library needs to be constantly updated to cope with new attack methods. If the signature library is not updated in time, new attacks may not be identified and blocked, which may cause WAF to lag behind in facing emerging threats.
2. High false positive rate:
   Signature-based detection methods tend to have a high false positive rate because they are based only on specific pattern matching and may misjudge legitimate traffic as attacks. This affects the experience of normal users.
3. Difficult to deal with zero-day attacks:
   For unknown zero-day attacks, WAF may not be able to effectively detect and protect against them due to the lack of corresponding signatures, and attackers can exploit unidentified new vulnerabilities to bypass protection.
4. Performance bottleneck:
   The signature matching process requires checking each request. When the signature library is large, it will increase processing time and resource consumption, affecting the performance of WAF and the response speed of the website.
5. Managing complexity:
   Over time, signature libraries can become larger and more complex, and managing and maintaining these signatures becomes more difficult, requiring specialized knowledge and additional administrative work.

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

Pros and Cons of CF WAF

Compared with traditional WAF based on attack signature library, CF's WAF has unique advantages and disadvantages.

advantage

1. Behavioral analysis and machine learning:
   CF WAF uses behavioral analysis and machine learning to detect and block attacks, which enables it to identify unknown and emerging attack patterns. By analyzing traffic patterns and behaviors in real time, dynamic and complex threats can be more effectively addressed.
2. Global threat intelligence sharing:
   CF uses its global network to collect and analyze threat intelligence and apply this information to WAF rules. This means that 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. Reduce false positives:
   Through intelligent rules and behavioral analysis, CF WAF can reduce false positive rates, ensure that legitimate traffic is not misjudged and blocked, and improve user experience.
5. High performance and scalability:
   CF's distributed architecture and efficient processing capabilities enable it to handle large amounts of traffic without affecting performance. Features such as caching and content optimization also further improve the website's responsiveness 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 having to have an in-depth understanding of complex attack signature libraries.

shortcoming

1. Customization requirements for advanced users:
   Although CF provides flexible rule creation capabilities, some advanced users may find that the lack of a specific attack signature library limits precise protection against specific attacks.
2. Depends on CF's infrastructure:
   The effectiveness of CF WAF relies on its global network and infrastructure. If your services do not run entirely on CF, you 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, taking full advantage of the flexibility and customization capabilities 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 about privacy and data control, especially for the processing and storage of sensitive data.

So in general, CF's WAF is actually mainly suitable for users who use CF infrastructure on a large scale to build applications. It has its limitations: if user services are not all deployed on CF, they still need to rely on traditional WAF solutions.

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

CF WAF Function Introduction (Free Plan)

In Cloudflare's Free plan, WAF features are 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 not as comprehensive as those in the paid plans.
4. Basic level of protection: The Free plan mainly provides basic level protection and does not include advanced threat intelligence and machine learning-driven intelligent rules.

The main contents of the basic rule set include:

1. SQL injection protection:
   • Detect and block attacks that inject malicious code through SQL queries.
2. Cross-site scripting (XSS) protection:
   • Block malicious scripts from being injected into web pages, protecting user data and browser security.
3. Local File Inclusion (LFI) and Remote File Inclusion (RFI) protection:
   • Prevent attackers from executing malicious code through included file vulnerabilities.
4. Cross-site request forgery (CSRF) protection:
   • Prevent attackers from forging requests to force users to perform unwanted actions.
5. Command injection protection:
   • Detect and block attacks that inject malicious code through command line parameters.
6. Path traversal protection:
   • Prevent attackers from accessing and manipulating arbitrary files on the server.
7. File upload vulnerability protection:
   • Detect and block malicious file injection attacks through file upload functionality.
8. Brute force protection:
   • Block frequent and repeated login attempts to prevent brute force attacks on accounts.
9. Malicious crawlers 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 CF WAF zone configurable functions

In the previous section, I mentioned the basic features of CF WAF in the Free plan. In fact, the specific configuration of CF WAF is still very simple. The basic rule set is effective by default:

Therefore, there are only three items that can be configured in the WAF section, custom rules:

Rate Limitation (I will talk about this later when I talk about the DDOS function):

tool:

CF WAF custom rules

Custom rules overview

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

Custom rules support many types of conditions:

Finally, there is a field for cookie values, so I won’t waste a separate screenshot. The supported operations are as follows:

Operations supported by custom rules

Custody Inquiry

A hosted challenge is an automated security check that asks a visitor a series of verification requests to determine if they are legitimate users. These challenges are often used to detect and block malicious robots (bots), crawlers, and other automated attacks while ensuring that legitimate users can access the website normally.

The process of handling "custodial inquiry" is as follows:

1. Triggering conditions:
   • Managed challenges are triggered when a request meets certain conditions, such as certain rules, thresholds, or detected suspicious behavior. Trigger conditions can include IP address, request frequency, request header content, geographic location, and more.
2. Type of inquiry:
   • CAPTCHA: Displays a graphic verification code that requires user input to verify that they are human.
   • JavaScript Challenge: Verify 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 proves that the request is from a genuine user.
   • Behavioral challenge: Determine legitimacy based on analysis of user behavior, such as mouse movements, clicks, and other human behavior characteristics.
3. User Response:
   • The visitor needs to complete a challenge, such as entering a captcha or waiting for a 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 resource.
   • Requests that fail the challenge will be blocked and the visitor will receive an appropriate prompt or error message.

The managed challenge is mainly used in the following scenarios:
• Prevent DDoS attacks: Use the challenge mechanism to mitigate large numbers of malicious requests and protect server resources.
• Block malicious robots: Prevent access by automated scripts and malicious crawlers, protecting website content and data.
• Improve website security: Reduce malicious traffic and improve the overall security and stability of the website.

JS Question

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

The "JS Question" processing flow is as follows:

1. Triggering conditions:
   • JS Challenges are triggered when a request meets certain 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. Questioning process:
   • When a request triggers a JS challenge, CF sends a piece of JavaScript code to the client browser.
   • The browser must execute the JavaScript code. This process is usually transparent and the user does not notice it.
3. Verify the request:
   • After executing the JavaScript code, the browser will automatically send the execution results 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 authentication passes, the request is allowed to proceed and the user can access the website normally.
   • Failed the challenge: If the verification fails, the request will be blocked and the user will receive an appropriate error message or prompt.

The scenarios in which JS challenge and managed challenge are used are the same.

Interactive Questioning

Interactive challenge is a security check mechanism that verifies whether the request is from a real user by requiring the user to complete specific interactive operations (such as verification code, clicking a confirmation button, etc.). This mechanism is mainly used to distinguish between human users and automated programs (such as malicious robots) to ensure that only legitimate users can access the website.

The "interactive questioning" process is as follows:

1. Triggering conditions:
   • Interactive challenges are triggered when a request meets certain conditions, such as certain rules, thresholds, or detected suspicious behavior. Trigger conditions can include IP address, request frequency, request header content, geographic location, and more.
2. Questioning process:
   • When a request triggers an interactive challenge, Cloudflare presents an interactive verification page to the client.
   • The page usually contains a verification code (such as reCAPTCHA) or other form of interactive challenge (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 verification code or completing a slider verification.
   • Once completed, the verification results are sent back to Cloudflare.
4. Verify the request:
   • Cloudflare verifies the user’s response. If the response is correct, the request came from a real user; if the response is incorrect or the user fails to complete the action, the request may have come from an automated program.
5. Result processing:
   • Pass the challenge: If the authentication passes, the request is allowed to proceed and the user can access the website normally.
   • Failed the challenge: If the verification fails, the request will be blocked and the user will receive an appropriate error message or prompt.

The scenarios for interactive questioning, JS questioning, and hosted questioning are the same.

jump over

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

The "skip" processing flow is as follows:

1. Triggering conditions:
   • When configuring a skip action, you need to set specific conditions. When a request meets these conditions, the skip action will be executed. Trigger conditions can include IP address, request method, URI path, request header content, geographic location, etc.
2. Configure skip rules:
   • In Cloudflare WAF settings, create or edit a firewall rule, select "Skip" as the action, and specify the rule or check 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 protection measures. The request will pass directly to the next processing stage.

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

Prevent

The "Block" action instructs the WAF to immediately reject a request if it detects a request that meets certain criteria, preventing it from being passed on to the website server. This is a critical step in the defense against a variety of attacks and malicious behavior.

The "block" process is as follows:

1. Triggering conditions:
   • When configuring a blocking action, you need to set specific conditions. When a request meets these conditions, the blocking action is executed. Trigger conditions can include IP address, request method, URI path, request header content, geographic location, query string, user agent, etc.
2. Configure blocking rules:
   • In 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 appropriate HTTP status code (usually 403 Forbidden or 406 Not Acceptable). The request will not reach the target 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 robots or crawlers to protect website resources and data.
• Enhanced security protection: Prevents specific types of malicious requests and improves the security and reliability of the website.

Advantages and disadvantages of hosted query, jS query and interactive query and their usage priorities

Hosted challenge), JS challenge and interactive challenge are three different security verification mechanisms, each with its own advantages and disadvantages and suitable for different scenarios.

Custody Inquiry:
Advantage
• Automatic update: managed and updated by CF, no manual configuration required by the user.
• Efficient protection: It can effectively defend against many types of attacks, including DDoS and malicious robots.
• User-Friendly: Show verification when necessary without interrupting the user too much.
Disadvantages
• Potential false positives: Legitimate users may be blocked by mistake, especially if the challenge mechanism is strict.
• Dependence on CF configuration: Users have less control over the exact form of the challenge.

JS Question:
Advantage
• Seamless experience: In most cases, users will not be aware of the questioning and the experience will be smooth.
• Automation Blocking: Effectively blocks automation tools and bots without JavaScript support.
Disadvantages
• Script dependency: Relies on the browser to support JavaScript, and may not work on devices and browsers that do not support JavaScript.
• Bypass possible: An advanced attacker could potentially write a script to bypass the JavaScript challenge.

Interactive Questioning:
Advantage
• High accuracy: Effectively distinguish between real users and robots through interactive operations that are difficult for humans to simulate.
• Strong protection: Suitable for high-risk scenarios and provides higher security.
Disadvantages
• User experience impact: Requires users to perform manual operations, which may affect the user experience, especially when it occurs frequently.
• Poor adaptability: It has high requirements on the adaptability of user equipment and network environment, and may be inconvenient to use in some cases.

The scenarios and configuration priorities for these three query methods are as follows:
• Managed queries have a higher priority because they are managed by CF and can be dynamically adjusted based on the latest threat intelligence. They are suitable for general protection in most scenarios and for users who want to simplify configuration and rely on CF professional management.
• JS challenge is preferred over interactive challenge because it has less impact on user experience and is 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 protection. It is suitable for scenarios with high security requirements, such as login pages, sensitive data access, etc., to prevent advanced automated attacks.

In general, these three query operations can be used in combination flexibly (for general users, you can use managed query) and configured according to specific needs and security policies to achieve the best protection effect.

Example of custom rule configuration practice

After talking about so much theory, there must be some practical content. Below I have sorted out some common requirements and corresponding configuration methods of custom rules, and you can choose according to your needs.

Allow CF-verified automated programs to crawl website information

This should be what all personal bloggers need. While allowing automated programs including mainstream search engines to index the website, it blocks other malicious crawlers. You can add limiting conditions through "and", as shown below:

Note: "WAF components to skip" are mandatory, but you can choose which ones to choose according to your needs. I chose the first 3.

In the above figure, if "and" is not added, it will take effect on all subdomains under the hosted second-level domain name; by adding "and", it can be limited to only authorized automated programs (search engine crawlers, etc.) to access the website corresponding to the host name "blog.tangwudi.com".

This rule only explicitly allows access to legitimate automated programs, and does not reject malicious crawlers. It needs to be combined with the subsequent "hosting query" rule for illegal automated programs to achieve the function of allowing legitimate automated programs while blocking malicious automated programs.

Note 1: Changing "skip" in the above rule to "block" will prevent mainstream search engine robots from accessing your website.

Note 2: Known automated programs include many categories. If necessary, you can fine-tune these categories. This is mainly controlled by the "Verified automated program category" field. For example, you can block artificial intelligence (AI) robots and crawlers from crawling your website content and training large language models (LLM) without your permission and then regenerating content. This rule needs to be placed before the "Allow known automated programs" rule. The specific configuration is as follows:

Conduct hosting inquiries on abnormal traffic (mainly malicious crawlers)

The rule configuration is as follows:

This rule, combined with the previous rule that allows "known automated programs", actually enables the famous CF "5-second shield" for non-CF certified automated programs (including malicious crawlers). Of course, there are ways to break the CF "5-second shield", but at least it raises the crawling threshold for malicious crawlers, and it can be considered a success if most malicious crawlers can be blocked.

Allow access to specific URIs on a website

Why is there such a demand? In fact, CF can identify and release non-malicious automated programs, but this requires a cost-effective upgrade to pro:

For users of the Free plan, they can only manually allow access to specific URI paths. For example, if a blog has an RSS function, it is necessary to allow various RSS-related automated programs to periodically access the blog RSS:

API interface access is handled in the same way.

Allow access to specific automated programs through UA

This method is mainly for UA (UserAgent) judgment. If some automated programs have their own specific UA keywords, this method can be used. For example, UA control allows Google robots to access. Of course, other restrictions can also be added through "and", such as Google's ASN number:

Note 1: The above picture only takes Google Robot as an example. To actually allow Google Robot to access, you only need to allow "known automatic programs" to access as mentioned above.

Note 2: If you only restrict requests with clear UA content (and no other additional judgment conditions), the following user agent blocking function is more convenient.

Anti-hotlink

The anti-hotlink function mainly determines the content of the "referrer" (referrer in the http header) field. For example, if your website address is searched through the Google search engine and a request is made to visit, the referer will contain the Google keyword. Similarly, the access requests from other search engines are the same (the same is true for access requests through links on other websites).

Take my blog address as an example. If I only allow access from Google and Bing search engines and links from the friendly site "abc.example.com", and prohibit links from any other sites, then the rules are as follows:

Summary of Custom Rules

In fact, the practical examples introduced above are just the most commonly used ones. There are many other items in the field part, such as: cookies, country/region, IP source address, request method, http version, threat score, etc. These items can produce a lot of combinations through "and" and "or" to achieve very flexible functions. You can configure them according to your actual needs. I won't say more, lest you say I'm as long-winded as an old woman.

Since the Free plan only has a quota of 5 custom rules, when creating rules, try to merge rules with the same priority and the same operation into one: for example, if the operations are all "skip", "block", "hosting query", etc., except for a few rules with very high priority requirements (such as prohibiting AI robots from crawling the web), after merging all the others, the quota of 5 custom rules is sufficient.

In addition, to configure custom rules for CF WAF, the configuration personnel need to have a certain degree of understanding of the various concepts in the fields, such as the meaning of ASN, referer, and user agent and the corresponding content in actual traffic. For example, the UA content of the openai robot is as follows:

You need to know the UA first before you can know how to use the user agent field of the custom rule to match. Otherwise, you will not know where to start if you want to configure the rule.

IP Access Rules

In fact, IP access rules should not be written in the WAF part, because in the traffic sequence, IP access rules are located before the WAF function:

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

So I just wrote them all here. There is also a "user agent blocking" function, which I also packaged together.

So, what is the main function 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: Control by country/region is an Enterprise Edition feature and is not supported by the Free plan.

For example, I want to allow a certain IP range (let's say 192.168.100.0/24) to access my website, while prohibiting Google (AS15169) and Microsoft (AS8075) to access my website, the settings are as follows:

Therefore, although this function can also be achieved using custom rules, if the target is clear (it can be directly locked by 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 for blocking specific user agents: through custom rules as described above and user agent blocking in the tools section:

Although the two may seem to overlap, they have different uses 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 Scenario：Suitable for protection scenarios that require complex conditions. For example, you may need to combine multiple conditions (such as user agent and request path) to block certain malicious traffic.
2. User Agent Blocking:
   • Specialization：This feature is specifically used to block specific user agents. It provides a simplified interface and operation method, making the management of user agents more direct and convenient.
   • Application Scenario：Suitable for situations where you need to quickly and easily block certain user agents. For example, if you find that some crawlers or malicious tools use specific user agents, you can quickly add these user agents to the block list.

Therefore, similar to the previous IP access rules, the user agent blocking function can also be implemented using custom rules. Custom rules provide greater flexibility and fine-grained control, while the dedicated user agent blocking function provides a simple and fast way to handle user agent-related interception needs. Both can be selected based on specific protection needs and operational complexity.

Summarize

Finally, I have finished talking about the functions of CF WAF. In fact, this part is not complicated to configure, and there are only three commonly used operations (skip, block, and managed query). However, to explain the characteristics of CF WAF and its advantages and disadvantages compared with traditional WAF from the overall context, it requires a lot of professional knowledge, and only in this way can you truly understand the difference of "custom rules".

A one-sentence summary of CF WAF: It is seamlessly integrated with the CF global network, uses artificial intelligence and machine learning, combines DDoS protection, Bot management and security analysis, and is supplemented by custom rules to monitor and protect real-time traffic, and automatically detect and respond to various network attacks.

Therefore, it actually doesn’t make much sense to talk about CF WAF alone, because it is the embodiment of the overall effect of the aggregation of many functional modules of CF.