如何结合请求日志核验物理机硬件防火墙应对DDoS与CC的应用层防护边界？

交付验收时，硬件防火墙面板显示“已拦截大量攻击流量”，并不能直接证明物理机上的业务已经抵御了应用层攻击。DDoS 可能在三层、四层耗尽链路、连接表或设备处理能力，CC 则可能以正常的 TCP、TLS 和 HTTP 请求进入源站；两者同时发生时，仅看带宽、丢包数或防火墙告警，容易把“网络层有拦截”误判为“应用层已防护”。

更可靠的核验方式，是把防火墙会话与策略日志、入口或反向代理请求日志、物理机资源监控、应用和数据库指标放到同一时间轴上对照。请求日志能够回答“哪些请求真正到达了 HTTP 层、访问了什么资源、耗时如何”，但不能单独证明链路上没有被丢弃的攻击流量；防火墙计数器能够证明网络层处理结果，却不能仅凭端口和连接状态判断一次请求是否会消耗数据库、搜索或业务接口资源。

一、先明确验收中的“挡住”指什么

1. 按防护层次拆分判断标准

硬件防火墙是否达到预期，不能只设置一个“攻击是否成功”的结论。至少应分别核对以下四层结果：

例如，防火墙阻断了大量 SYN 包，且源站没有明显资源抖动，这可以作为四层防护有效的证据。但如果同时有大量 HTTPS 请求完成握手并进入 /search、/login 或订单查询接口，源站数据库连接池持续占满，那么四层拦截结果不能代表 CC 防护已经覆盖。

2. 先核对设备实际启用的能力

验收前应把采购配置、交付配置和实际运行模式逐项对应。硬件防火墙的“吞吐量”通常不是所有防护功能同时开启时的统一指标，以下能力应分别核实：

• 状态检测吞吐量；
• 小包处理能力，即 PPS；
• 新建连接速率，即 CPS；
• 最大并发会话数；
• SYN 防护、连接速率限制和源地址限速；
• TLS 终止或解密检查能力；
• HTTP 解析、WAF 规则或应用识别能力；
• 应用层请求速率限制、验证码、挑战或行为策略；
• 日志写入能力、日志采样方式和日志保留期限；
• 启用上述功能后设备的CPU、内存和会话表上限。

厂商资料中的状态检测吞吐量，可能是在较大报文、单一策略和不启用深度检测的条件下测得。启用 TLS 检查、WAF 规则、详细日志或高并发连接后，设备能够承受的有效请求量可能明显变化。因此，验收应以“实际型号、固件版本、授权模块、当前策略和真实拓扑”为准，而不是只引用产品参数页中的一个吞吐数字。

3. 先确认流量是否经过能够观察HTTP的节点

请求日志的来源决定了核验结论的范围。常见拓扑和边界如下：

如果 TLS 在防火墙上只是透传，防火墙无法根据URL、请求参数、业务身份或接口耗时判断请求是否昂贵。即使设备具有“应用识别”名称，也应确认该功能是否实际部署在当前流量路径上，是否对HTTPS解密，以及是否有对应授权。

二、核对前先冻结时间、拓扑和基线

1. 固定验收时间窗口

交付验收不应只截取一张实时面板截图。应固定一个完整时间窗口，例如连续5分钟、10分钟或按一次测试事件的开始和结束时间记录，并同时保存：

• 防火墙开始和结束时间；
• 物理机操作系统时间；
• 代理和应用日志时间；
• 监控系统时间；
• 流量测试平台时间；
• 策略变更、设备重启和日志切割时间。

所有系统应统一时区。若一台设备使用UTC、另一台服务器使用本地时间，5分钟的偏移就足以让攻击请求和防火墙丢弃记录无法对应。时间对齐后，才有必要计算同一窗口内的请求数、拦截数和源站资源变化。

2. 记录“攻击前”基线

没有基线，就无法判断某个请求量是否异常。基线不必追求长期精确统计，但至少应记录业务正常时段的典型值：

• 平均和峰值HTTP请求速率；
• 常见URL、HTTP方法和状态码分布；
• 正常的P95或P99请求耗时；
• 物理机CPU、内存、网卡流量；
• TCP并发连接和应用连接池使用量；
• 数据库连接数、慢查询和缓存命中率；
• IPv4、IPv6以及主要入口的流量占比。

例如，正常业务峰值为每秒200个请求，验收窗口内达到每秒3000个请求，不能只因为部分请求返回了200就判定服务正常。还需要观察这些请求是否集中访问缓存未命中的接口，是否触发了数据库和外部依赖。

3. 固定入口和信任的客户端地址

请求日志中的客户端IP必须先判断来源是否可信：

• 物理机直接接收用户流量时，通常以连接对端地址为基础；
• 流量经过反向代理时，应确认代理是否覆盖写入转发头；
• 不能直接把客户端提交的 X-Forwarded-For 当作真实来源；
• 只信任已明确登记的代理地址，并记录代理链；
• NAT、企业出口和移动网络会让多个真实用户共用一个公网IP；
• IPv4和IPv6应分开统计，不能在同一排名中简单合并。

如果没有完成这一步，按IP限速的效果、Top IP占比和“攻击源是否分散”的结论都可能失真。

三、按顺序对照请求日志与防火墙记录

1. 先看防火墙是否已在网络层达到容量边界

第一轮不看URL，而是查看防火墙和上联接口的原始计数：

• 入方向和出方向字节数；
• PPS和小包占比；
• SYN速率、TCP新建连接速率；
• 当前会话数和会话创建失败数；
• 丢弃包总数以及按策略、接口、原因分类的丢弃数；
• TCP重置、半连接、超时和异常协议包；
• 设备CPU、内存、会话表和日志队列；
• 是否发生接口丢包、队列溢出或设备保护模式。

这里要区分十进制带宽和字节数量。若某个日志窗口内记录了1.8 GB的HTTP响应字节，窗口为300秒，则仅按响应字节估算：

1.8 × 8 × 1000 ÷ 300 = 48 Mbps

这个48 Mbps不是链路入口带宽，也不是DDoS总流量，因为它没有包含被防火墙丢弃的包、请求头、TCP/IP开销、未完成请求以及其他协议流量。它只能帮助判断“已经到达应用日志层的响应量”。

如果上联接口已经接近线路容量，物理机上的防火墙即使规则配置正确，也可能无法处理新增流量。链路被占满后，本地设备没有机会对尚未到达的报文进行应用层判断，此时需要把上游清洗、运营商侧封堵或更高位置的流量牵引纳入验收边界。

2. 再确认哪些流量真正到达HTTP层

请求日志至少应具备以下字段，字段名称可以按Nginx、Apache、应用网关或自研服务实际格式调整：

如果访问日志只有“时间、IP、状态码”三个字段，仍可以做数量统计，但不足以完成CC防护验收。尤其在HTTP/2或HTTP/3场景中，一个连接可以承载多个并行请求，连接数和请求数不能互相替代。

3. 计算请求速率和请求分布

在一个固定窗口内，基本计算方式是：

请求速率 = 窗口内有效请求条数 ÷ 窗口秒数

例如，5分钟内入口日志出现900,000条请求：

900,000 ÷ 300 = 3,000 req/s

这只是HTTP层请求速率，不是防火墙的PPS，也不是物理网卡的Mbps。需要继续按以下维度分组：

• URI或路由；
• HTTP方法；
• 状态码；
• 客户端IP或可信代理后的来源；
• User-Agent；
• Host和公网入口；
• 是否命中缓存；
• 请求耗时区间；
• 是否进入上游应用；
• 是否触发限速、挑战或WAF规则。

CC常见的日志特征不一定是大量错误码。攻击请求可能全部返回200或302，但集中访问缓存未命中的搜索、登录、商品筛选、报表和查询接口；也可能大量返回401、403或404，仍然消耗了认证、路由和日志资源。因此，状态码不能单独作为“请求无害”的依据。

4. 观察请求是否真正消耗了源站资源

请求日志应与物理机和应用指标放在同一时间轴上。重点观察：

• 请求量升高时，CPU是否同步升高；
• 请求耗时增加是在入口、代理还是上游应用；
• 数据库连接数是否先于HTTP错误上升；
• 连接池是否耗尽；
• 缓存命中率是否下降；
• 单个接口的P95、P99是否明显高于其他接口；
• 物理网卡流量不高时，应用是否仍然出现排队；
• 物理机是否有大量TLS握手、进程上下文切换或文件描述符消耗。

如果请求日志中的数量不高，但数据库连接数持续满载，可能存在日志漏记、内部调用、异步任务或其他入口。此时不能因为访问日志“看起来平稳”就判定防护有效。

5. 将防火墙动作、请求结果和源站状态串成事件链

一次完整的事件链至少应包含以下关系：

1. 防火墙在某个时间窗口观察到流量、连接或策略命中；
2. 其中一部分流量被丢弃、拒绝、限速或转发；
3. 另一部分流量到达TLS、代理或HTTP层；
4. 请求日志记录了具体接口、结果和耗时；
5. 源站监控反映了这些请求对CPU、连接池、缓存和数据库的影响；
6. 防护动作解除后，业务指标是否恢复。

如果只具备第1步和第2步，只能说明防火墙进行了网络层处理；具备第3步和第4步，才能判断请求是否穿透到应用入口；具备第5步，才能进一步判断CC是否造成业务资源消耗。

四、根据组合结果解释防护边界

1. 常见结果及下一步判断

2. 区分“网络型DDoS”和“应用型CC”

网络型DDoS通常首先体现在带宽、PPS、SYN、连接建立和设备会话表上。大量报文可能在HTTP层之前就被丢弃，因此请求日志很少并不异常。

CC则常常具有以下组合特征：

• TCP连接能够建立；
• TLS握手可以完成；
• HTTP请求能够获得响应；
• 请求集中访问高成本接口；
• 来源IP分布可能很广；
• 请求参数、User-Agent或访问间隔可能有规律，也可能刻意变化；
• HTTP状态码看起来正常，但上游耗时和数据库压力增加。

两种攻击也可能混合出现。例如，部分流量用小包和连接消耗防火墙资源，另一部分使用正常HTTPS请求消耗应用资源。此时，防火墙对前一部分有效，不代表后一部分已经被识别。

3. 用示例数据判断，而不是套用单一阈值

下面是一组用于说明判断方法的示例数据，并非固定验收标准：

• 5分钟内防火墙入方向流量约1.2 Gbps；
• SYN速率和新建连接速率明显高于正常基线；
• HTTP访问日志为900,000条，即约3,000 req/s；
• 其中约70%集中访问一个缓存未命中的查询接口；
• Top 1来源IP只占总请求的0.2%，来源IP数量较多；
• 应用返回200和429为主，数据库连接池使用率达到90%以上；
• 源站CPU长期在85%至95%之间，接口P95耗时从正常的200毫秒升至2秒以上。

这组数据说明，防火墙可能已经拦截了部分网络层流量，但仍有大量请求穿透至应用层，并且已经对数据库和接口耗时产生影响。此时不能用“防火墙拦截了多少包”替代CC防护结论，应继续核查：

• 防火墙是否具备并启用了TLS解密和HTTP规则；
• WAF或应用网关是否位于正确的流量路径；
• 限速策略是否只按单IP，是否能处理分散来源；
• 查询接口是否有缓存、分页上限和查询成本控制；
• 是否应将上游清洗或应用层防护放置在物理机之前。

4. 不要把来源IP数量当成唯一判断依据

单一来源IP占比高，可能适合进行精确限速；但来源IP分散，并不代表一定是高质量用户流量。还应结合：

• 同一URI和参数结构；
• 请求间隔和并发模式；
• Cookie、会话和认证状态；
• TLS指纹或代理侧连接特征；
• 请求耗时和缓存命中情况；
• 正常业务路径是否被遵循；
• 失败认证、无效参数和不存在资源的比例。

这些信号应作为组合判断。仅按User-Agent、单个IP段或某个国家地区进行拦截，可能误伤真实访问，也无法稳定解决分布式来源的CC流量。

五、验收中发现异常时如何留证

1. 先排除时间和日志完整性问题

“防火墙有记录但请求日志没有”是验收中最常见的争议之一。应依次确认：

• 防火墙记录的是入口接口、转发接口还是回源接口；
• 请求日志记录的是原始入口、反向代理还是应用进程；
• 设备和服务器是否存在时间偏移；
• 日志是否按比例采样；
• 日志是否异步写入，攻击时是否出现队列堆积；
• 日志轮转是否覆盖了事件开始部分；
• 多个VIP或IPv6入口是否未纳入统计；
• 防火墙计数器是否因重启、策略加载或接口重置而归零。

在适用的Linux systemd服务器上，可以使用只读命令记录时间状态；命令输出应与设备导出的时间一并保存：

date -Is
timedatectl show -p TimeUSec -p NTPSynchronized

如果系统不是systemd发行版，应使用该系统对应的时间核验方式，不要仅凭终端当前时间判断日志已经对齐。

2. 保存原始证据而不是只保留截图

一次完整的验收证据包应包括：

• 防火墙配置导出和策略版本；
• 实际型号、固件版本、授权模块和运行模式；
• 接口流量、PPS、会话、丢弃原因和设备资源曲线；
• 原始访问日志、WAF日志、代理日志和应用日志；
• 数据库、连接池、缓存和物理机资源曲线；
• 拓扑图，标明TLS终止点、日志采集点和回源路径；
• 测试开始结束时间、测试入口和授权范围；
• 变更记录、设备重启记录和日志轮转记录；
• 异常请求的脱敏样本及其请求ID。

对重要日志可以计算哈希，证明后续分析使用的是同一份文件。例如：

sha256sum access.log firewall-export.csv

该命令只读取文件并输出摘要，不会修改原始日志。日志中可能包含IP、Cookie、Token、手机号或业务参数，留存和共享前应进行访问控制、脱敏和最小化处理，不能把完整认证信息作为验收附件传播。

3. 对典型异常保留“前后文”

只保留单条恶意请求通常不足以支持结论。每个异常至少应记录：

• 事件前的正常基线；
• 事件发生时的5分钟或10分钟窗口；
• 事件结束后的恢复过程；
• 同一请求ID在代理、应用和数据库侧的对应记录；
• 防火墙策略动作及命中原因；
• 源站资源曲线；
• 是否发生策略变更或设备重启。

如果发现WAF日志显示“已阻断”，但应用仍出现同一请求，应确认两个日志记录的是不是同一阶段。有些设备会记录“检测到并标记”，代理才负责实际拒绝；也有设备分别记录入口请求、回源请求和响应动作。没有明确日志阶段，不能仅根据“blocked”这个字段下结论。

六、复核：用受控场景验证边界是否与交付承诺一致

复核应在获得授权的测试窗口内进行，使用可控速率、可停止的测试流量，不应直接对公网任意目标施压。测试目标不是制造不可控的攻击，而是验证流量经过哪些节点、哪些请求会被放行，以及源站资源是否在约定范围内。

1. 至少准备四类测试场景

场景一：网络层处理能力

使用受控的连接和报文测试，观察防火墙的PPS、CPS、会话数、丢弃策略和设备资源。验收重点是计数器是否增长、策略是否命中、日志是否完整，以及设备是否在实际功能开启后保持稳定。

场景二：TLS透传与TLS终止对照

分别核对TLS透传和TLS终止时的可见字段。透传模式下，设备通常不能直接看到URL和HTTP方法；终止模式下，则要确认解密后的请求是否经过WAF或应用层限速模块，而不是仅完成了TLS卸载。

场景三：普通接口与高成本接口对照

选择一个静态或缓存命中接口，再选择一个经过授权、可控且不会修改真实数据的查询接口。比较两者的请求速率、缓存命中、上游耗时、数据库连接和防护动作。若两类请求都被当作普通TCP流量放行，说明硬件防火墙的应用层边界有限。

场景四：来源分散的请求对照

在受控测试源范围内模拟多个来源，观察策略是否只依赖单IP计数。若单IP限速有效，但来源分散后仍能让同一接口达到高请求量，则需要补充会话、接口、身份、设备指纹或全局资源维度的控制。

2. 将验收条件写成可复核的结果

验收条件应在测试前确定，不要在异常发生后临时改变口径。可以包括：

• 网络层丢弃策略命中率和记录完整性；
• 允许流量与源站访问日志数量是否能够对应；
• 受保护接口的请求速率、P95耗时和错误率；
• 物理机CPU、连接池、数据库和缓存是否在约定阈值内；
• TLS透传和终止两种模式下的可见能力；
• 防护动作是否产生可关联的请求ID或事件ID；
• 解除测试后业务是否恢复；
• 正常客户端是否出现明显误拦截；
• 日志是否能支持事后还原完整事件链。

阈值应根据业务SLA、物理机配置和正常基线设定。比如，若正常接口P95为200毫秒，验收可以规定在某一受控请求量下不得持续超过预先约定范围；不能直接套用其他网站的通用数值。

3. 对不通过的结果给出对应处理方向

• 链路已接近饱和：本地防火墙无法解决尚未到达设备的流量，应评估上游清洗、运营商侧策略或更靠前的流量防护。
• 设备会话表或CPU先达到上限：检查实际启用的日志、TLS和WAF功能，重新核对特性容量，而不是只增加规则数量。
• 大量HTTP请求穿透且源站变慢：补充应用层网关、WAF、缓存、接口级限速和业务成本控制。
• TLS透传无法识别URL：明确硬件防火墙只能提供网络和传输层防护，应用层判断应由能够终止TLS的可信节点承担。
• 日志无法关联：补充统一时间源、请求ID、代理动作日志和完整性留存。
• 只按单IP限速效果有限：增加接口、会话、身份、全局并发和资源消耗等维度，避免把分布式请求简单归为单源问题。
• 防护有效但误拦截明显：复核可信代理、NAT、IPv6和正常业务基线，先修正识别链路，再调整策略。

交付验收的最终文件不应只有“防火墙已开启防DDoS”的勾选项，而应保留一条可复核的证据链：哪一类流量在什么位置被处理、哪些请求到达了HTTP层、哪些接口消耗了源站资源、设备和应用分别在哪个容量边界上出现变化，以及下一轮复测需要保留哪些配置和日志。这样才能把硬件防火墙的网络层能力、应用层防护能力和物理机本身的承载边界区分开，避免把部分拦截结果误认为完整的CC防护。