前言

在cloudflare系列教程的"筑基"三部曲(CF整体方案、流量序列、边缘网络及回源)完成后，CF系列教程终于要开始介绍具体功能及配置了，那么第一个功能选择哪一个呢？思来想去，我决定选择CF WAF。

之所以选择这个，是因为相对于其他功能来说，CF WAF基本上是每个使用服务器建站的个人站长都绕不过去的坎(采用静态站点且托管在国外免费云上的站长请无视～)，因为其他一些提供商提供的一些基础功能(例如国内CDN提供商的防盗链功能)在CF是由WAF来实现的，更别说其他的功能：比如允许主流搜索引擎爬虫而禁止其他非法爬虫(包括AI爬虫)、允许或者禁止访问特定的URI等等功能都是WAF来实现的，并且，DDOS的配置也会涉及一些WAF部分的功能，所以，第一个介绍的功能选WAF完全没毛病。

另："CF WAF的特点"部分主要是讲CF WAF的理论，会比较枯燥，不感兴趣理论而只关心实操的朋友可以直接从"CF WAF的配置"部分开始看。

CF WAF的特点

CF WAF和一般的WAF有何不同？

CF的 WAF(Web 应用防火墙)与其他品牌的 WAF 有一些不同的设计理念，这导致了它没有传统WAF都具有的一个共有特征：攻击签名库，原因有如下几点：

1. 智能规则集：CF使用了一种基于机器学习和行为分析的智能规则集来检测和阻止攻击。相较于传统的静态攻击库，这种方法可以更灵活地应对新出现的威胁。
2. 实时更新：CF的 WAF 规则是动态更新的。这意味着它们能够快速响应新发现的威胁，而不需要等待攻击库的更新和分发。
3. 集成性：CF的 WAF 与其整体网络架构紧密集成(例如文章：中提到的流量序列)，可以利用全球的威胁情报和网络流量模式进行实时分析，这种集成性使得CF能够更有效地识别和防御攻击。
4. 定制规则：虽然CF没有一个专门的攻击库，但它允许用户创建自定义的 WAF 规则，以满足特定的安全需求，这种灵活性使得用户可以针对自己特有的威胁场景进行防护。
5. 用户友好性：CF强调简化用户体验，减少了对复杂配置和手动更新的需求。通过自动化和智能化的防护机制，用户无需花费大量时间管理攻击库。

综合来看，CF的设计理念是通过智能化、动态化的防护机制来应对不断变化的安全威胁，而不是依赖传统的、静态的攻击签名库。

CF WAF相较于传统的基于攻击签名库的WAF的有自己的优缺点，要明白这些优势需要先从传统的基于攻击签名库的WAF的优缺点说起。

基于攻击签名库的传统WAF的优缺点

传统基于攻击签名库的WAF有自己的优缺点。

优点：

1. 即时防护：
   基于签名库的 WAF 可以立即识别并阻止已知的攻击类型，因为这些攻击的特征已经记录在签名库中。这种方法对已知威胁提供了快速、有效的防护。
2. 广泛覆盖：
   签名库通常包含大量已知的攻击模式和威胁类型，覆盖范围广泛，包括 SQL 注入、跨站脚本 (XSS)、文件包含漏洞等常见攻击。
3. 易于理解和管理：
   管理人员可以清楚地看到哪些攻击签名被启用或禁用，并了解每个签名的具体作用。这使得 WAF 的配置和管理变得更加透明和直观。
4. 成熟度高：
   由于基于签名的 WAF 技术已经发展多年，很多产品都具有成熟的攻击库，经过多次迭代和优化，可靠性和稳定性较高。

缺点：

1. 依赖更新：
   签名库需要不断更新以应对新的攻击手段。如果签名库更新不及时，新的攻击可能无法被识别和阻止，这使得 WAF 在面对新兴威胁时可能会有滞后性。
2. 误报率高：
   基于签名的检测方法往往会产生较高的误报率，因为它们仅基于特定模式匹配，可能会将合法流量误判为攻击。这会影响正常用户的体验。
3. 难以应对零日攻击：
   对于未知的零日攻击，由于没有对应的签名，WAF可能无法进行有效检测和防护，攻击者可以利用未被识别的新漏洞绕过防护。
4. 性能瓶颈：
   签名匹配过程需要对每个请求进行检查，当签名库规模庞大时，会增加处理时间和资源消耗，影响 WAF 的性能和网站的响应速度。
5. 管理复杂性：
   随着时间的推移，签名库会变得越来越大和复杂，管理和维护这些签名变得更加困难，需要专业知识和额外的管理工作。

所以，传统基于签名库的 WAF 在防护已知威胁方面具有明显优势，但在面对新兴威胁、零日攻击和误报问题时存在一定的局限性，所以现代 WAF 产品通常结合多种检测技术，以弥补传统方法的不足。

CF WAF的优缺点

相对于传统基于攻击签名库的 WAF，CF 的 WAF具有独特的优缺点。

优点

1. 行为分析和机器学习：
   CF WAF 使用行为分析和机器学习来检测和阻止攻击，这使其能够识别未知和新兴的攻击模式。通过实时分析流量模式和行为，可以更有效地应对动态和复杂的威胁。
2. 全球威胁情报共享：
   CF利用其全球网络收集和分析威胁情报，并将这些信息应用于 WAF 规则中。这意味着CF的 WAF 能够快速响应新的攻击模式和威胁，提供及时和有效的防护。
3. 灵活的规则创建和管理：
   用户可以根据自己的需求创建和调整 WAF 规则，提供更大的灵活性和定制性。这种灵活性允许针对特定的应用场景和威胁进行优化。
4. 减少误报：
   通过智能规则和行为分析，CF WAF 可以减少误报率，确保合法流量不被误判和拦截，提升用户体验。
5. 高性能和可扩展性：
   CF的分布式架构和高效的处理能力，使其能够处理大量流量而不影响性能。缓存和内容优化等功能也进一步提高了网站的响应速度和性能。
6. 易于管理和部署：
   CF 提供简单的用户界面和 API，用户可以轻松配置和管理 WAF 规则，而不需要深入了解复杂的攻击签名库。

缺点

1. 对高级用户的定制需求：
   尽管CF提供灵活的规则创建功能，但某些高级用户可能会发现缺少特定的攻击签名库限制了对特定攻击的精确防护。
2. 依赖于CF的基础设施：
   CF WAF 的有效性依赖于其全球网络和基础设施。如果用户的服务不完全在CF上运行，可能会面临集成和覆盖问题。
3. 潜在的学习曲线：
   尽管界面和 API 设计简洁易用，对于没有经验的用户来说，充分利用CF WAF 的灵活性和自定义功能可能需要一定的学习和适应时间。
4. 隐私和数据控制：
   将所有流量通过CF的基础设施处理，可能会引起一些用户对隐私和数据控制的担忧，特别是对敏感数据的处理和存储。

所以总的来说，CF的WAF其实主要适合那些大规模使用CF基础设施来构建应用的用户，有其局限性：如果用户服务不全是部署在CF上，则还是需要依靠传统的WAF类方案。

注：一些优秀的安全产品其实已经完全集成了传统的WAF和CF WAF的优点，比如Palo Alto防火墙。

CF WAF功能介绍(Free计划)

在 Cloudflare 的 Free 计划中，WAF 的功能是有限的。具体来说，Free 计划提供了基础的安全防护功能，但不包括智能规则集和高级 WAF 功能。

Free 计划中 WAF的一些基本特点如下：

1. 基础规则集：Free 计划中包含了一些基础的 WAF 规则，可以防护常见的威胁和攻击类型，如 SQL 注入、跨站脚本攻击（XSS）等。
2. 手动规则管理：用户可以手动添加和管理一些基本的防护规则，但这些规则相对简单，缺乏智能化和动态更新的特性。
3. 有限的定制化：虽然 Free 计划允许用户创建自定义的 WAF 规则，但这些规则的复杂度和数量有限，不如付费计划中的功能全面。
4. 基本的防护级别：Free 计划主要提供基础级别的防护，不包含高级的威胁情报和机器学习驱动的智能规则。

其中，基础规则集的主要内容包含如下：

1. SQL 注入防护：
   • 检测和阻止通过 SQL 查询语句注入恶意代码的攻击行为。
2. 跨站脚本 (XSS) 防护：
   • 阻止恶意脚本注入网页，从而保护用户数据和浏览器安全。
3. 本地文件包含 (LFI) 和远程文件包含 (RFI) 防护：
   • 防止攻击者通过包含文件的漏洞执行恶意代码。
4. 跨站请求伪造 (CSRF) 防护：
   • 阻止攻击者通过伪造的请求强制用户执行不必要的操作。
5. 命令注入防护：
   • 检测和阻止通过命令行参数注入恶意代码的攻击行为。
6. 路径遍历防护：
   • 阻止攻击者访问和操作服务器上的任意文件。
7. 文件上传漏洞防护：
   • 检测和阻止通过文件上传功能进行恶意文件注入的攻击。
8. 暴力破解防护：
   • 阻止频繁和重复的登录尝试，防止账户被暴力破解。
9. 恶意爬虫和自动化工具防护：
   • 识别和阻止恶意爬虫和自动化工具的访问请求，保护网站内容和资源。
10. DDoS 攻击缓解：
    • 自动检测和缓解大规模的分布式拒绝服务 (DDoS) 攻击，确保网站可用性。

这些基础规则集和具体防护内容构成了 Cloudflare WAF 的核心保护机制，帮助用户有效抵御各种网络攻击和安全威胁。

CF WAF的配置

CF WAF区域可配置功能介绍

在上一节我提到Free计划中CF WAF的基础功能，其实对于CF WAF的具体配置来说，还是很简单的，基础规则集是默认生效：

所以在WAF部分可以配置的也就3项，自定义规则：

速率限制(这部分内容后续我在讲DDOS功能的时候说)：

工具：

CF WAF自定义规则

自定义规则简述

自定义规则的配置逻辑是基于用户定义的条件和相应的操作来检测和防护特定类型的流量：基于CF提供的"传入请求匹配条件"和"可选操作"，用户自己进行恰当的规则配置以及运用逻辑符号(or、and)，再结合CF的自动化程序、DDOS防护等，就可以"组合"起来实现多种实用功能：例如允许主流搜索引擎的爬虫而拦截其他爬虫、拦截异常的UA、防盗链等等，Free计划提供的5条WAF规则正常情况下已经足够满足个人站长的需要了。

自定义规则支持的条件类型非常多：

最后还有一个cookie值的字段，我就不单独在浪费一张截图了，而支持的操作如下：

自定义规则支持的操作

托管质询

托管质询是一种自动化的安全检查机制，通过向访问者提出一系列验证请求来确定其是否为合法用户。这些质询通常用于检测和阻止恶意机器人（bots）、爬虫以及其他自动化攻击，同时确保合法用户能够正常访问网站。

"托管质询"处理流程如下：

1. 触发条件：
   • 托管质询会在请求满足特定条件（如某些规则、阈值或检测到的可疑行为）时触发。触发条件可以包括 IP 地址、请求频率、请求头内容、地理位置等。
2. 质询类型：
   • CAPTCHA：显示一个图形验证码，要求用户输入以验证他们是人类。
   • JavaScript 挑战：通过让用户的浏览器执行一段 JavaScript 代码来验证请求的合法性。如果浏览器成功执行该代码，则表明请求来自真实用户。
   • 行为挑战：基于用户行为的分析来确定其合法性，例如鼠标移动、点击等人类行为特征。
3. 用户响应：
   • 访问者需要完成质询，如输入验证码或等待 JavaScript 挑战完成。如果成功通过质询，则请求被允许继续；否则请求被阻止。
4. 结果处理：
   • 成功通过质询的请求将继续被处理，允许访问网站或资源。
   • 未能通过质询的请求将被阻止，访问者会收到相应的提示或错误信息。

托管质询主要用于以下场景：
• 防止 DDoS 攻击：通过质询机制减缓大量恶意请求，保护服务器资源。
• 阻止恶意机器人：防止自动化脚本和恶意爬虫的访问，保护网站内容和数据。
• 提高网站安全性：减少恶意流量，提高网站整体的安全性和稳定性。

JS质询

JS 质询是一种通过执行 JavaScript 代码来验证请求是否来自真实用户而不是自动化程序（如恶意机器人）的安全检查机制。这个机制主要用于区分人类用户和自动化脚本，以确保只有合法用户能够访问网站。

"JS质询"处理流程如下：

1. 触发条件：
   • JS 质询会在请求满足特定条件（如某些规则、阈值或检测到的可疑行为）时触发。触发条件可以包括 IP 地址、请求频率、请求头内容、地理位置等。
2. 质询过程：
   • 当请求触发 JS 质询时，CF会向客户端浏览器发送一段 JavaScript 代码。
   • 浏览器必须执行这段 JavaScript 代码。这个过程通常是透明的，用户不会察觉到。
3. 验证请求：
   • 执行 JavaScript 代码后，浏览器会自动将执行结果发送回 CF。
   • CF验证执行结果。如果结果正确，则表明请求来自真实用户；如果结果不正确或浏览器未能执行代码，则请求可能来自自动化程序。
4. 结果处理：
   • 通过质询：如果验证通过，请求将被允许继续，用户可以正常访问网站。
   • 未通过质询：如果验证未通过，请求将被阻止，用户会收到相应的错误信息或提示。

JS质询和托管质询使用的场景一致。

交互式质询

交互式质询是一种通过要求用户完成特定的交互操作（如验证码、点击确认按钮等）来验证请求是否来自真实用户的安全检查机制。这个机制主要用于区分人类用户和自动化程序（如恶意机器人），确保只有合法用户能够访问网站。

"交互式质询"处理流程如下：

1. 触发条件：
   • 交互式质询会在请求满足特定条件（如某些规则、阈值或检测到的可疑行为）时触发。触发条件可以包括 IP 地址、请求频率、请求头内容、地理位置等。
2. 质询过程：
   • 当请求触发交互式质询时，Cloudflare 会向客户端展示一个交互式验证页面。
   • 该页面通常包含一个验证码（如 reCAPTCHA）或其他形式的交互式挑战（如点击确认按钮、拖动滑块等）。
3. 用户响应：
   • 用户需要完成页面上显示的交互操作，例如输入验证码或完成滑块验证。
   • 完成操作后，验证结果会发送回 Cloudflare。
4. 验证请求：
   • Cloudflare 验证用户的响应。如果响应正确，则表明请求来自真实用户；如果响应不正确或用户未能完成操作，则请求可能来自自动化程序。
5. 结果处理：
   • 通过质询：如果验证通过，请求将被允许继续，用户可以正常访问网站。
   • 未通过质询：如果验证未通过，请求将被阻止，用户会收到相应的错误信息或提示。

交互式质询和JS质询以及托管质询使用的场景一致。

跳过

“跳过”操作允许你根据特定条件指定某些请求不受特定 WAF 规则或整个 WAF 的限制。这意味着这些请求会直接绕过定义的 WAF 检查，继续其处理流程。这对于一些合法的请求，但可能会触发误报或不需要进行严格检查的场景，提供了一种灵活性。

"跳过"处理流程如下：

1. 触发条件：
   • 配置跳过操作时，需要设置特定的条件。当请求满足这些条件时，跳过操作会被执行。触发条件可以包括 IP 地址、请求方法、URI 路径、请求头内容、地理位置等。
2. 配置跳过规则：
   • 在 Cloudflare WAF 设置中，创建或编辑一条防火墙规则，选择"跳过"作为操作，并指定应跳过的规则或检查。
3. 跳过处理：
   • 当一个请求满足配置的条件时，该请求将跳过指定的 WAF 规则或检查，不会触发相应的防护措施。请求将直接通过，进入下一个处理阶段。

"跳过"主要用于以下场景：
• 误报处理：如果某些合法请求频繁触发 WAF 规则导致误报，可以使用跳过操作避免这些请求被阻止。
• 特定流量优化：对于某些可信任的流量源（如内部系统、可信 IP 等），可以配置跳过操作，减少不必要的检查，提高处理效率。
• 调试和测试：在开发和测试过程中，可以使用跳过操作绕过某些 WAF 规则，以便更快地进行调试和验证。

阻止

"阻止"操作指示WAF 在检测到符合特定条件的请求时，立即拒绝该请求，防止其继续传递到网站服务器。这是防护措施中的一个关键步骤，用于保护网站免受各种攻击和恶意行为的影响。

"阻止"处理流程如下：

1. 触发条件：
   • 配置阻止操作时，需要设置特定的条件。当请求满足这些条件时，阻止操作会被执行。触发条件可以包括 IP 地址、请求方法、URI 路径、请求头内容、地理位置、查询字符串、用户代理等。
2. 配置阻止规则：
   • 在 Cloudflare WAF 设置中，创建或编辑一条防火墙规则，选择“Block”作为操作，并指定应阻止的条件或规则。
3. 阻止处理：
   • 当一个请求满足配置的条件时，Cloudflare WAF 会拒绝该请求，返回相应的 HTTP 状态码（通常是 403 Forbidden 或 406 Not Acceptable）。请求将不会到达目标服务器。

"阻止"主要用于以下场景：
• 防止攻击：阻止已知的攻击模式，如 SQL 注入、跨站脚本（XSS）、跨站请求伪造（CSRF）等。
• 阻止恶意流量：拦截来自恶意 IP 地址、恶意机器人或爬虫的请求，保护网站资源和数据。
• 强化安全防护：防止特定类型的恶意请求，提升网站的安全性和可靠性。

托管质询、jS质询和交互式质询各自的优劣势及使用优先级

托管质询）、JS 质询和交互式质询是三种不同的安全验证机制，它们各有优劣势，适用于不同的场景。

托管质询：
优势
• 自动更新：由CF管理和更新，无需用户手动配置。
• 高效防护：能够有效防御多种类型的攻击，包括 DDoS 和恶意机器人。
• 用户友好：在必要时展示验证，不会过多打扰用户。
劣势
• 潜在误报：可能会误拦截合法用户，尤其是在挑战机制较为严格时。
• 依赖 CF配置：用户对具体质询形式的控制较少。

JS 质询：
优势
• 无缝体验：大多数情况下，用户不会察觉到质询的存在，体验流畅。
• 自动化阻断：有效阻止没有 JavaScript 支持的自动化工具和机器人。
劣势
• 脚本依赖：依赖浏览器支持 JavaScript，对于不支持 JavaScript 的设备和浏览器可能无效。
• 可能绕过：高级攻击者可能会编写脚本绕过 JavaScript 质询。

交互式质询：
优势
• 高准确性：通过人类难以模拟的互动操作，有效区分真实用户和机器人。
• 强力防护：适用于高风险场景，提供更高的安全性。
劣势
• 用户体验影响：需要用户进行手动操作，可能会影响用户体验，特别是在频繁出现时。
• 适应性差：对用户设备和网络环境的适应性要求较高，可能在某些情况下不便使用。

这3种质询方式适用的场景及配置优先级建议如下：
• 托管质询优先级较高，因为它由CF管理，可以根据最新的威胁情报动态调整，适用于大多数场景下的常规防护，适合想要简化配置并依赖CF专业管理的用户
• JS 质询优先于交互式质询，因为它对用户体验影响较小，适用于希望在不影响用户体验的情况下阻止大部分自动化攻击的场景。
• 交互式质询优先级最低，但在高风险情况下，可能被直接触发，以提供最强的安全保障，适用于高安全性要求的场景，如登录页面、敏感数据访问等，防止高级自动化攻击。

总的来说，这三种质询操作可以灵活结合使用(对于一般用户，使用托管质询即可)，根据具体需求和安全策略进行配置，以达到最佳的防护效果。

自定义规则配置实践示例

讲了那么多理论，总要有点干货，下面我将一些常用的需求及自定义规则对应配置方式整理出来，大家按需选择即可。

允许经过CF验证的自动化程序抓取网站信息

这应该是个人博主都需要的，在允许包括主流搜索引擎在内的自动化程序收录网站的同时，拦截掉其他恶意的爬虫，通过"and"可以添加限定条件，如下图：

注："要跳过的WAF组件"是必选的，不过具体选哪几个大家可以根据自己的需要选择，我是选的前3个。

上图中，如果不加"and"就是对托管二级域名下的所有子域名都生效；通过添加"and"可以限定只允许认证的自动化程序(搜索引擎爬虫等)对主机名"blog.tangwudi.com"对应的网站进行访问。

这条规则只是显式允许了合法的自动化程序的访问，并未拒绝恶意爬虫，需要结合后面的针对非法自动程序进行"托管质询"规则一起来实现既放行合法自动化程序同时阻止恶意自动化程序的功能。

注1：将上述规则中的"跳过"改为"阻止"，就可以阻止主流搜索引擎机器人对网站的访问

注2：已知自动化程序包含很多类别，如有需要是可以针对这些类别进行精细化控制的，这主要是通过"已通过验证自动程序类别"字段来控制。例如，您可以单独阻止人工智能 (AI) 机器人、爬虫在未经您允许的情况下爬取你的网站内容并训练大型语言模型 (LLM) 然后重新生成内容，这条规则需要位于"允许已知自动程序"的规则之前，具体配置如下：

对异常流量(主要是恶意爬虫)进行托管质询

规则配置如下：

这条规则结合前面允许"已知自动程序"的规则，其实就实现了对非CF认证的自动程序(包括恶意爬虫)开启著名的CF"5秒盾"，当然，也有破CF"5秒盾"的方法，不过，起码提高了恶意爬虫的爬取门槛，能拦下绝大部分恶意爬虫就算成功。

允许对网站特定URI的访问

为啥有这个需求？其实CF是可以识别并放行非恶意自动化程序，不过这需要花钱升级pro：

对于Free计划的用户而言，就只能手动放行对特定URI路径的访问，例如，博客有RSS功能，就需要开放各种RSS相关自动化程序对博客RSS的周期性访问：

API接口访问也是一样的处理方式。

通过UA允许特定自动化程序的访问

这种主要是针对UA(UserAgent)的判定，如果一些自动化程序有自己特定的UA关键字，就可以使用该方式，比如，通过UA控制允许google机器人访问，当然，也可以通过"and"添加其他限制条件，例如谷歌的ASN号：

注1：上图只是以谷歌机器人举例，实际要允许谷歌机器人访问只需要前面讲到的允许"已知自动程序"访问即可。

注2：如果只是针对有明确UA内容(且无其他额外判定条件)的请求进行限制，后面的用户代理阻止功能更方便。

防盗链

防盗链功能主要是对"引用方"(http头部中的referer)字段内容的判断，例如，通过google搜索引擎搜到你的网站地址并点击访问过来的请求，referer里就有google的关键字，同理，其他搜索引擎搜索过来的访问请求也一样(通过其他网站上的链接访问过来也一样)。

以我的博客地址为例，假如我只允许google和bing搜索引擎以及友站"abc.example.com"友链过来的访问，而禁止其他任何站点的链接，那么规则如下：

自定义规则部分总结

其实，上面介绍的实践示例只是我觉得最常用的，字段部分还有很多项目，比如：cookie、国家/地区、IP源地址、请求方法、http版本、威胁分数等等，这些项目通过"and"和"or"可以产生非常多的组合，实现非常灵活的功能，大家可以根据自己实际的需求来配置，我就不多说了，免得说我像个老婆婆一样啰里啰嗦。

由于Free计划只有5条自定义规则的额度，所以创建规则的时候，大家尽量把优先级相同且操作相同的规则合并成一条：比如操作都是"跳过"、"阻止"、"托管质询"等，这样除了少数优先级要求非常高的规则(比如禁止AI机器人爬网那种)，其他的都进行合并后，5条自定义规则的额度足够了。

另外，要配置CF WAF的自定义规则，需要配置人员对字段中的各种概念有一定程度的了解，比如ASN、引用方(referer)、用户代理(UserAgent)的含义和实际流量中对应的内容，比如，openai机器人的UA内容是这样：

需要先知道其UA是这个内容，才能够知道如何利用自定义规则的用户代理字段去匹配，否则，你想要配置规则都会不知道如何下手～。

IP访问规则

其实，IP访问规则不应该在WAF部分来写，因为在流量序列中，IP访问规则是位于WAF功能之前的：

不过该功能很简单，且在CF控制台中，也是位于WAF部分：

所以干脆在这里一起写了，另外还有一个"用户代理阻止"的功能，也打包一起说了。

那么，IP访问规则主要作用是什么呢？顾名思义，让你可以控制哪些IP地址(或者IP地址范围)或者ASN号可以访问你的网站，哪些不能。

注：通过国家/地区控制是企业版功能，Free计划不支持。

比如我想要允许某个IP范围(假设为192.168.100.0/24)访问我的网站，同时禁止谷歌(AS15169)和微软(AS8075)的IP来访问我的网站，则设置如下：

所以，虽然使用自定义规则也可以实现这个功能，不过如果目标明确(通过IP或者ASN就能够直接锁定的)，使用IP访问规则比使用自定义规则更方便快捷。

用户代理阻止

CF的 WAF提供了两种主要的方法来阻止特定的用户代理(UserAgent)：通过前面讲过的自定义规则以及工具部分的用户代理阻止：

尽管这两者看似有重叠，但它们有不同的用途和灵活性：

1. 自定义规则：
   • 灵活性：自定义规则允许你根据各种条件（如 IP 地址、ASN、地理位置、请求路径等）来创建复杂的防火墙规则，包括阻止特定的用户代理。你可以定义规则的逻辑和优先级，满足更细致的需求。
   • 应用场景：适合需要复杂条件的防护场景。例如，你可能需要结合多个条件（如用户代理和请求路径）来阻止某些恶意流量。
2. 用户代理阻止功能：
   • 专门化：这个功能专门用于阻止特定的用户代理。它提供了一个简化的界面和操作方式，使得管理用户代理变得更直接和便捷。
   • 应用场景：适合需要快速、简单地阻止某些用户代理的情况。例如，你发现某些爬虫或恶意工具使用特定的用户代理，你可以快速添加这些用户代理到阻止列表中。

所以，其实和前面的IP访问规则类似，用户代理阻止的功能也可以使用自定义规则来实现，只是自定义规则提供了更大的灵活性和细粒度的控制，而专门的用户代理阻止功能则提供了一个简单、快速的方式来处理用户代理相关的拦截需求，两者可以根据具体的防护需求和操作复杂性来选择使用。

总结

终于把CF WAF的功能讲完了，其实这部分内容配置起来并不复杂，常用的操作也就那3种(跳过、阻止、托管质询)，但是要从整体脉络上讲清楚CF WAF的特点以及和传统WAF相比的优劣势，却需要涉及很多专业知识，并且这样才能真正了解"自定义规则"的不同之处。

对CF WAF的一句话总结：和CF全球网络无缝集成，利用人工智能和机器学习，结合 DDoS 保护、Bot 管理和安全分析，以自定义规则为补充，完成对实时流量的监控和防护，并自动检测和应对各种网络攻击。

所以，其实单独把CF WAF拿出来讲没啥意义，因为它本来就是CF众多功能模块聚合在一起的总体效果的体现。