WAF中记录和阻止之间的平衡

Informatec Digital »资源» WAF 中的日志记录与阻止平衡

在Web应用防火墙（WAF）中，如何平衡日志记录和拦截已成为安全和运维团队最头疼的问题之一。Web应用防火墙可以阻止非常严重的攻击，但如果配置过于激进，则可能拦截合法的购买、访问或API调用。如果配置过于宽松，则几乎沦为摆设。关键在于谨慎调整日志记录的时机、统计流量的时机、允许的时机和拦截的时机。

本文将深入探讨如何利用现代 Web 应用防火墙 (WAF) 的功能（例如允许列表、基于频率的规则、学习模式、SIEM 集成、机器学习等）来实现这种平衡，并提供来自AWS WAF、ModSecurity、云端 WAF 和本地部署解决方案的具体示例。您将了解如何在不降低防护级别的前提下减少误报，如何按应用程序组织策略，以及如何将日志记录作为助力而非持续不断的、难以管理的噪音源。

什么是WAF？为什么注册如此重要？

Web应用防火墙充当用户和服务器之间的智能层，实时分析HTTP/HTTPS流量。与监控端口和IP地址的传统网络防火墙不同，WAF的监控范围更广：它会分析URL、参数、请求体、请求头、Cookie、HTTP方法等等。

它的任务是检测并阻止典型的第七层攻击：SQL注入、跨站脚本攻击 (XSS)、本地文件包含/远程文件包含 (LFI/RFI)、访问控制攻击、API滥用、恶意爬虫、暴力破解，甚至某些应用层DDoS攻击模式。为此，它依赖于不断更新的规则集、签名和安全策略。

日志记录是硬币的另一面。WAF 的每一个决策——允许、阻止或仅计数——都可以在日志中记录详细的事件信息。这些日志可以用于：

• 调查事件：重构事件经过以及利用漏洞的尝试过程。
• 调整规则：通过查看 WAF 阻止了哪些合法请求来检测误报。
• 遵守规章制度证明存在有效的控制措施（PCI DSS、GDPR、内部审计等）。
• 向安全信息和事件管理 (SIEM) 系统提供数据将应用程序攻击与网络、系统、身份等事件关联起来。

问题在于，配置不当的WAF会将日志充斥着成千上万条无关事件，导致无法找到真正重要的信息，而且还会不合理地拒绝合法流量。这就需要我们巧妙地运用日志记录、计数和阻止模式。

WAF 中的安全模型：阻止列表、允许列表和混合方法

大多数现代Web应用防火墙（WAF）都结合了多种过滤方法，这直接影响请求的日志记录和拦截方式。总的来说，我们可以识别出两种经典理念，以及一种非常常见的混合模型。

基于黑名单的Web应用防火墙（WAF）遵循负面安全模型。其核心原则是：“除了已知恶意行为之外，我允许一切行为通过。” 它的工作原理是利用已知攻击（例如SQL注入、XSS、僵尸网络模式等）的特征码以及定义可疑行为的规则。这种模型部署起来比较容易，但完全依赖它可能会导致新的攻击途径或变种绕过检测。

带有允许列表的Web 应用防火墙 (WAF) 的工作原理恰恰相反：“阻止除明确允许的流量之外的所有流量”。它基于积极的安全模型。只有符合已定义合法行为（路由、方法、参数、格式、大小等）的流量才会被接受。这种方式安全性更高，但需要大量的微调，并且如果准备不当，最初可能会产生误报。

由于每种方法各有优缺点，结合允许列表和阻止列表的混合模型正变得越来越普遍。在这种方案中，会定义预期流量特征（例如，正常的登录或支付请求），并同时应用签名和启发式方法来检测典型的恶意模式。就日志记录而言，这种混合方法允许：

• 标记为 高风险事件 违反允许物品清单的物品。
• 视为 中/低​​优先级警报 通用黑名单模式。
• 使用“计数”模式查看哪些操作会违反规则，然后再激活阻止功能。

网络、主机和云端中的WAF：对日志记录和锁定的影响

WAF部署模型极大地影响着流量日志记录和拦截的处理方式。在网络设备上记录请求与在服务器内部代理或托管云服务上记录请求是截然不同的。

基于网络的Web应用防火墙（WAF）通常以物理或虚拟设备的形式部署在基础设施中，位于互联网和应用程序之间。这是F5等厂商采用的经典方法。它具有高性能和精细控制的优势，但配置和管理可能较为复杂。日志通常会发送到syslog或中央安全信息和事件管理（SIEM）系统，因此必须仔细过滤保存的日志内容，以避免存储和分析工具过载，并有助于诊断IP和DNS网络中的问题。

基于主机的Web应用防火墙（WAF）运行在应用程序所在的同一服务器（或容器）上，通常以模块或代理的形式存在（例如，集成到Nginx或Apache中的ModSecurity；将其与使用SELinux的Linux加固相结合可以提升安全性）。这种模型允许更丰富的应用程序上下文信息，并为每个服务设置高度具体的规则，但代价是会消耗本地资源，并且需要更分布式的日志管理。日志可以存储在本地文件中并转发，也可以与集中式日志服务集成。

基于云的Web 应用防火墙(WAF) （例如 Cloudflare、Akamai、Imperva Cloud、AWS WAF 等）可与负载均衡器、内容分发网络 (CDN) 或虚拟网络集成。服务提供商通常提供控制面板，并支持将日志导出到 S3、BigQuery、远程系统日志或安全信息和事件管理 (SIEM) 系统。虽然它们的设置通常更简便，但您必须根据服务提供商的模型调整日志记录策略，例如事件类型、保留期限、严重性筛选器等。

选择哪种模型不仅仅是一个技术决定，还取决于您希望如何平衡日志记录和锁定：云管理服务简化了许多方面，但由于合规性或保密性策略，您可能希望对日志的存储位置拥有绝对控制权，这会促使您选择本地部署或混合模型。

条款、规则和 Web ACL：WAF 如何决定是阻止、允许还是仅注册

无论制造商是谁，所有现代 Web 应用防火墙 (WAF) 都基于访问条件、规则和策略的概念。理解这一点是成功在生产环境中使用计数、日志记录和锁定模式的关键。

这些条件描述了要检查请求的哪些部分：源 IP、特定 HTTP 标头（Host、User-Agent、Accept、Content-Type 等）、查询参数、请求正文、Cookie、HTTP 方法、来源国家/地区等。例如，在 AWS WAF Classic 中，您可以定义一个包含最多 10.000 个地址或范围的 IP 条件，或者定义一个 URL 部分字符串匹配条件。

规则结合一个或多个条件，并赋予其一个意图：允许、阻止或计数。当规则包含多个条件时，通常使用逻辑“与”进行判断：所有条件都必须满足，规则才会触发。实际上，没有条件的普通规则无法匹配任何内容，其操作也永远不会被触发。

许多Web应用防火墙（WAF），包括AWS WAF，都具备基于速率的规则。这些规则会统计在特定时间段内（例如五分钟）来自特定IP地址（或满足特定条件的一组IP地址）的请求数量。如果超过阈值（例如五分钟内超过1.000个请求），则规则生效：要么阻止请求，要么仅进行计数。这对于以下情况非常有用：

• 控制 对登录表单进行暴力破解.
• 限制恶意抓取或无礼的机器人。
• 在应用层缓解某些类型的DDoS攻击。

下一层是Web 访问控制列表 (ACL)。在这里，规则被分组，并定义了评估顺序和默认操作（允许或阻止）。请求会按顺序逐条规则进行评估；如果匹配到某条规则，则执行相应的操作，并停止对其余规则的评估。如果请求不匹配任何规则，则执行 ACL 中定义的默认操作。

在平衡日志记录和阻止流量方面，ACL 用于决定系统默认是宽松的（仅允许特定规则阻止流量）还是严格的（除特殊情况外全部阻止）。此外，许多解决方案允许您在 ACL 中设置“计数”模式的规则，这样它们会记录匹配项但不阻止流量——这非常适合调优阶段。

日志中的白名单和降噪

允许列表是减少日志中误报和噪声的基本工具。其原理很简单：在特定情况下，您可以指示 WAF 不要将指令或规则集应用于您已归类为可信流量或您知道虽然合法但超出常规范围的特定流量。

例如，在 AWS WAF 中，您可以创建允许列表规则，以便如果请求来自特定的 IP 地址或地址范围，或者匹配已知的 URL 模式和 HTTP 方法，则不会应用某些签名检查。这有助于：

• 防止内部 API 使用“奇怪”的模式 产生持续的误报.
• 减少对您已认为可信的流量进行深度检测所带来的延迟。
• 减少WAF日志中不必要的记录数量。

在 ModSecurity 等平台上，推荐的做法不是修改标准规则（例如 OWASP 核心规则集），而是根据规则 ID为特定参数、路径或用户创建特定的排除项。这样既能保持整体防护，又不会因为禁用整个站点的规则而造成巨大的安全漏洞。

关键在于对允许列表进行精准设置，而不是一刀切。与其全局禁用规则 X，不如排除特定的组合（例如 URL Z 中的规则 X + 参数 Y）。这样既能保证日志记录的有效性，又能避免造成不必要的盲点。

协议规则和限制：何时阻止，何时发出警告

许多Web应用防火墙（WAF）都集成了一套HTTP协议清理规则，作为对格式错误或可疑流量的第一道过滤。这些规则会检查必需的标头、方法、参数大小等，如果理解不当，它们既能提供有效的保护，也容易导致误报。

一些非常常见的例子：

• 缺少 Accept 标头 （缺少 Accept 标头）：这严格来说并不违反 RFC 规范，但很多缺少此标头的请求都来自自动化工具或编写不佳的脚本。这可能会影响自定义 API 或不发送此标头的客户端。在许多情况下，记录日志并进行计数比直接阻止请求更可取。
• 缺少主机头根据 HTTP/1.1 标准，Host 标头是必需的。WAF 也需要它来确定应用哪种策略。通常情况下，阻止此类请求是合理的，但在测试期间或由于内部流量配置错误，可能会产生误报；建议在启用严格阻止之前监控日志。
• 缺少 User-Agent 标头这条规则旨在遏制基础机器人和未识别流量。问题在于，许多合法的 API 可能不会发送 User-Agent。最明智的做法通常是记录日志，如果检测到持续且合法的 API， 将其 IP 地址或模式添加到允许列表中.
• GET/HEAD 验证与主体虽然 RFC 并未严格禁止在 GET 或 HEAD 请求中发送请求体，但这并非常见做法，并且可能表明存在规避行为。在许多情况下，第一步是记录所有这些请求，如果发现可疑异常，则应将其阻止。
• 缺少包含 body 的 Content-Type如果请求体存在但没有 Content-Type 信息，则明显表明协议使用不当或试图逃避分析。在这种情况下，采取更严格的拦截措施通常是合理的，尤其是在面向互联网的环境中。

除了这些协议规则之外，参数限制通常也用于防止应用层洪水攻击和拒绝服务攻击。例如：

• 每个请求的最大参数数（在某些 WAF 中默认值为 255）。
• 单个参数的最大长度（例如，400 个字符）。
• 所有参数的总大小（例如，64.000 字节）。

这些值对于许多应用场景来说都是合理的，但在某些情况下——例如复杂的表单上传、高级筛选、大型 JSON 加载——可能会出现误报。在这些情况下，最谨慎的做法是先记录并统计访问次数，检查哪些端点超出了限制，然后仅针对这些路由进行调整，而不是解除整个网站的所有限制。

假阳性：如何检测它们而不至于白费力气

误报是指WAF将合法请求识别为恶意请求并进行拦截或标记为攻击。误报难以避免，尤其是在启用OWASP CRS等全面规则集的情况下，但可以通过专业管理避免成为日常烦恼。

检测误报首先要仔细审查日志。这包括检查哪些请求被阻止、触发这些请求的规则以及请求发生的上下文（URL、参数、用户、来源等）。可视化工具和仪表板可以帮助识别 403 错误激增或异常模式。

云服务提供商和 ModSecurity 社区都强烈推荐使用模拟模式或计数模式。在这种模式下，您要测试的规则会记录每次匹配，但不会进行任何阻止。例如，这样您就可以在正式启用新的 SQL 注入规则之前，查看它会阻止多少合法的请求。

在接收真实或模拟流量的测试环境或预生产环境中测试规则也是一个好主意。OWASP ZAP 等工具或流量重放脚本可以帮助您模拟合法模式和已知攻击，从而测试 WAF 的行为。

此外，必须重视误报对运营和声誉的影响：支付中断、用户注册失败、关键 API 调用无故失败——所有这些都可能直接导致收入和品牌形象受损。过多的误报还会让安全团队疲于应对大量无价值的警报，从而难以识别真正的安全事件。

调整规则和智能利用注册表的策略

管理误报并非是关闭规则直到“一切正常”，而是要像外科手术一样精准地微调 Web 应用框架 (WAF)。以下这些良好实践正是在此发挥作用：

首先，避免全局禁用规则。最好创建非常具体的例外：仅针对特定路由、特定参数或内部流量排除规则 ID。这样，既能保证应用程序其他部分的安全，又能保留有用的日志。

其次，在实施阻止之前，利用计数模式。最初仅在日志模式下激活新规则，可以让你衡量有多少合法请求会受到影响。你可以结合 SIEM 中的警报功能，快速检测规则是否产生了异常数量的匹配项。

第三，将WAF与SIEM或集中式日志平台集成。这样可以更轻松地将WAF事件与其他指标关联起来，例如异常系统活动、大规模身份验证失败、可疑的配置更改等。此外，它还有助于根据事件的严重性和频率确定优先调整哪些规则。

第四，务必记录每一次变更：调整了哪条规则，针对哪个端点，依据什么理由，以及提供了哪些证据。查阅服务器手册会很有帮助。这份文档不仅有助于维护内部控制，而且在安全审计和审查中也至关重要，因为它可以证明控制措施并非轻易禁用。

WAF 中的自动化、机器学习和自适应规则

随着应用程序的增长和流量的日益复杂，手动管理WAF变得越来越不现实。这时，自动化、高级日志分析以及在某些情况下机器学习就派上了用场。

首先，与 SIEM 的集成允许您构建关联规则和自动响应：例如，如果一组 IP 反复触发注入或 XSS 规则，您可以生成自动操作，将这些 IP 添加到临时黑名单或加强检查级别。

其次，一些WAF集成了机器学习模式，用于在设定的时间段内观察合法流量。基于这些数据，它们会提出或调整正常行为的阈值、模式和特征。这有助于在规则切换到阻止模式时减少误报，并检测后续的流量偏差。

在研究和实验室环境中，监督学习技术已被用于训练区分合法流量和恶意流量的模型，从而改进策略，这些策略随后会被应用于生产环境中。虽然这种方法并非万能，但它可以帮助发现传统基于特征码的规则难以检测到的细微模式。

最后，持续自动化测试（使用 OWASP ZAP 等工具、自定义脚本或 CI/CD 流水线）可以验证对 WAF 的更改不会破坏关键功能或留下明显的漏洞。将这些测试集成到部署周期中，使安全性成为开发流程的自然组成部分，而不是临时修补。

每个应用程序的策略设计和每个服务的黑名单

在复杂的环境中——例如托管服务提供商或互联网服务提供商——单一的Web应用防火墙（WAF）策略是不够的，尤其是在涉及影子IT的情况下。通常情况下，同一个负载均衡器后面会运行多个域或应用程序，而每个域或应用程序都有不同的安全需求和流量特征。因此，设计针对特定服务的策略和列表至关重要。

一个典型的例子是，HTTP/S 负载均衡器充当反向代理，为多个站点（例如 www.company1.com 和 www.company2.com）提供流量，这些站点都位于同一个虚拟 IP 地址之后。在这种情况下，WAF 可以配置为在请求到达时立即评估 Host 标头和源 IP 地址，甚至在请求到达负载均衡模块之前就进行评估。

其逻辑大致如下：WAF 检查SERVER_NAME（主机名）和客户端 IP的组合是否与特定站点的黑名单匹配。如果该 IP 在 www.company2.com 的黑名单中被屏蔽，但在 www.company1.com 的黑名单中未被屏蔽，则仅在前者的情况下发送 403 Forbidden 响应。然后，该“正常”流量被传递给负载均衡模块，由该模块决定由哪个后端服务器处理请求。

这样一来，就可以维护例如特定域的黑名单，而不是为整个接入点使用单一的全局黑名单。在日志级别，每次拒绝都会记录在系统日志中，其中包含规则 ID、匹配条件、URL、主机和客户端 IP 地址等详细信息，从而便于后续分析以及扩展或调试这些黑名单。

这个故事告诉我们，策略划分得越细（按应用程序、环境、用户类型），就越能更好地在日志记录和阻止之间取得平衡：例如，你可以对管理门户网站非常严格，而对信息网站则稍微灵活一些，但始终要在日志中记录每个决定的原因。

超越传统WAF：WAAP和API保护

威胁形势瞬息万变。如今，许多应用程序都是云原生应用，采用微服务架构，并暴露公共和私有 API，这使得它们成为攻击者的主要目标。传统的 Web 应用防火墙 (WAF) 已演变为更广泛的平台，称为 Web 应用和 API 保护 (WAAP) 或 Web 应用和 API 安全 (WAAS)。

这些解决方案不仅可以自动发现 Web 应用程序，还可以识别 API 端点，接受 OpenAPI 或 Swagger 等规范，并使用该定义来检查请求的合规性：预期数据类型、允许的参数、大小限制等。根据端点的不同（例如，处理高度敏感数据的端点），可以应用更高级别的审查和阻止措施。

在日志级别，WAAP 倾向于生成包含丰富上下文的事件：具体是哪个 API 端点受到了攻击，使用了哪个操作（GET、POST、PUT 等），涉及了哪个用户或令牌，违反了规范的哪一部分等等。这使得我们可以做出更精确的阻止决策，而不是仅仅依赖于通用的有效载荷模式。

此外，许多WAAP工具都包含针对特定应用程序和API的DoS防护、地理位置过滤、IP信誉管理、机器人和爬虫检测，以及针对每个服务自定义警报级别的选项。再次强调，关键在于能够灵活地决定哪些方面需要更强大的防护措施，哪些方面需要优先考虑流畅运行，同时又不牺牲可靠的日志数据库以用于事件调查。

综合来看，一个经过良好调校的 WAF（无论是传统的、基于 WAAP 的，还是集成到云生态系统中的）都成为了现代应用程序和 API 防御的重要组成部分，能够结合详细的日志记录、智能阻止和对不断变化的威胁形势的持续适应。