遭遇DDoS与CC双重攻击，物理机硬件防火墙为何难过滤HTTPS恶意请求？

很多人会把“硬件防火墙”理解成能够识别并拦截所有恶意流量的设备，但它首先是一个位于网络路径上的流量检查与转发系统，并不天然等同于 WAF、反向代理或应用防护平台。遭遇 DDoS 与 CC 双重攻击时，前者可能先消耗入口带宽、数据包处理能力和连接表，后者则通过看起来正常的 HTTPS 请求继续消耗 TLS、Web 服务、业务接口和数据库资源。

HTTPS 场景下，传统硬件防火墙通常只能稳定看到源 IP、目标 IP、TCP 端口、连接状态和部分 TLS 握手元数据。真正决定请求是否恶意的 URL、HTTP 方法、请求头、Cookie、参数和请求体，通常要等 TLS 在反向代理、负载均衡或应用服务器上终止后才可见。因此，防火墙能够放行或阻断“访问 443 端口的连接”，却未必能判断其中某个 /login、/search 或 API 请求是否正在制造应用层压力。

先把“挡不住”拆成三个问题

“硬件防火墙挡不住”可能对应三种完全不同的故障现象：

所以，问题并不单纯是“物理设备性能不够”。更准确的判断是：攻击流量处于哪一层，防火墙位于哪一个位置，设备启用了哪些检查能力，以及设备是否能在当前流量规模下完成这些检查。

设备形态不等于防护层级

“硬件防火墙”描述的是设备形态或部署方式，不等于它已经具备完整的应用识别能力。独立安全设备、物理服务器上的安全模块、下一代防火墙、入侵防御设备和 WAF，虽然都可能以硬件设备形式存在，但处理对象并不相同。

可以把它们粗略分为以下几层：

• 网络层防护：根据 IP、协议、端口、路由和包特征进行处理。
• 传输层防护：检查 TCP 连接、SYN、连接速率、会话状态和并发数。
• TLS 检查：终止客户端 TLS，解密后再建立到后端的加密连接。
• 应用层防护：识别 HTTP 方法、URL、参数、Cookie、请求体和业务行为。
• 业务风控：根据账号、会话、设备、验证码、接口调用频率和业务结果判断风险。

只有明确支持 TLS 终止、HTTP 检查、WAF 规则或相应的应用防护模块，设备才可能分析 HTTPS 内部内容。即使设备支持，也还要考虑许可证、证书部署、检查性能和实际拓扑。

HTTPS 请求经过防火墙时，哪些内容是可见的

一次 HTTPS 请求大致经过以下过程：

1. 客户端向服务器发起 TCP 连接。
2. 客户端与服务端完成 TLS 握手。
3. 双方协商加密算法并建立会话密钥。
4. 客户端将 HTTP 请求封装为加密的 TLS Application Data。
5. 服务端或前置代理解密数据，再交给 Web 服务和应用程序。

如果硬件防火墙只做旁路观察或四层转发，它通常可以看到前两个阶段的大部分连接信息，却看不到第四阶段的 HTTP 内容。

防火墙通常能够看到什么

在不终止 TLS 的情况下，设备通常能够获得以下信息：

在常见 TLS 握手中，设备可能读取到 SNI 等元数据，但 SNI 只能表示目标主机名，并不包含完整 URL、查询参数或请求体。即使设备知道客户端访问的是 api.example.com，也不知道请求的是 /login 还是 /expensive-report。

随着 TLS 配置和协议特性的变化，可观察的握手信息也可能减少。不能把“能看到域名”理解成“已经看到了 HTTPS 请求”。

端口过滤为什么无法识别恶意请求

从传统防火墙的角度看，下面两类连接可能非常相似：

客户端 A -> TCP/443 -> /health
客户端 B -> TCP/443 -> /api/login
客户端 C -> TCP/443 -> /search?q=复杂查询

三者都使用 TCP 443，TCP 握手也可能正常，TLS 握手也可能成功。若没有 TLS 终止和应用层解析，防火墙很难只凭端口判断其中哪个请求会触发数据库慢查询、登录校验或大量报表计算。

如果直接封锁 443，确实可以阻断攻击请求，但正常用户也无法访问 HTTPS 服务。这是网络层策略与应用层判断之间的边界。

TLS 解密不是简单读取证书私钥

要检查 HTTPS 内容，设备通常需要作为中间的 TLS 终止点：

客户端
  │  HTTPS
  ▼
TLS 检查设备 / 反向代理 / WAF
  │  重新建立 HTTPS 或 HTTP 连接
  ▼
源站应用

设备先与客户端建立一条 TLS 会话，解密请求并进行 WAF 检查，再以另一条连接访问源站。这不是被动复制数据包，而是设备参与了连接建立和转发。

仅拥有服务器证书私钥，也不能简单地对所有现代 TLS 会话进行被动解密。许多 TLS 配置使用临时密钥交换，设计目标就是避免仅凭长期私钥还原会话内容。因此，真正的 HTTPS 检查通常要求设备具备在线代理能力，并正确处理以下事项：

• 证书和私钥的导入、轮换与权限保护；
• TLS 版本、密码套件和客户端兼容性；
• 双向 TLS 或客户端证书认证；
• WebSocket、HTTP/2、长连接和大请求体；
• 解密后的吞吐、并发连接数和每秒新建 TLS 会话数；
• 检查失败时的旁路、阻断或回源策略。

这也解释了为什么“设备标称具备 SSL 检查”不等于“在攻击流量下仍能完成高质量的 HTTPS 应用识别”。

DDoS 与 CC 如何形成叠加效果

DDoS 和 CC 经常被放在一起讨论，但二者消耗的资源并不完全相同。

• 网络或传输层 DDoS 更关注带宽、数据包速率、连接建立和设备会话表。
• CC 类应用攻击 通常通过大量 HTTP/HTTPS 请求消耗 Web 线程、TLS 处理、接口执行时间、缓存、连接池和数据库资源。

在双重攻击中，常见过程是：

1. 大量网络流量冲击公网入口，使链路、上联端口或边界设备承压。
2. 仍然能够到达源站的流量建立正常 TCP 和 TLS 连接。
3. 请求访问登录、搜索、下单、报表、接口聚合等高成本路径。
4. 硬件防火墙看到的是大量“访问 TCP 443 的正常连接”。
5. 反向代理、Web 服务、应用线程池或数据库先达到瓶颈。
6. 即使网络流量后来下降，应用积压和连接超时仍可能持续一段时间。

带宽不大，也可能是严重的 CC

应用层攻击的特点是“请求量与处理成本”比“字节数”更重要。

下面是一个用于理解机制的示例。若每秒收到 3,000 个 HTTPS 请求，每个请求进入方向的平均大小只有 2 KB，按十进制单位计算：

• 每秒数据量：3,000 × 2 KB = 6,000 KB/s；
• 换算为 MB/s：6,000 KB/s ÷ 1,000 = 6 MB/s；
• 换算为 Mb/s：6 MB/s × 8 = 48 Mb/s。

48 Mb/s 对一条 1 Gbps 的线路来说并不大，但如果每个请求都触发一次复杂查询，或者平均处理时间为 1.5 秒，那么理论上的在途请求数约为：

• 并发请求数 = 每秒请求数 × 平均处理时间；
• 3,000 × 1.5 = 4,500 个在途请求。

4,500 个请求可能迅速消耗应用线程、连接池和数据库连接。此时，硬件防火墙即使能够转发 48 Mb/s 的流量，也没有因此保护应用。

另一方面，如果攻击流量达到 1.2 Gbps，而服务器公网入口只有 1 Gbps：

• 1.2 Gbps = 1,200 Mbps；
• 1 Gbps = 1,000 Mbps；
• 超出入口能力的部分约为 200 Mbps。

这部分流量在到达服务器之前就可能造成丢包、排队或上联拥塞。本地防火墙即使配置了精确规则，也无法把已经到达不了设备的流量“过滤掉”。实际结果还会受到链路封装、运营商策略和设备处理方式影响，这里的数字仅用于说明判断过程。

设备的瓶颈不只有 Gbps

安全设备的处理能力至少要从几个维度观察：

设备在“只做四层转发”和“启用 TLS 解密、IPS、WAF、日志审计”时，负载并不相同。一个看似足够的防火墙吞吐数字，可能只对应某种测试条件，不能直接等同于启用全部安全功能后的 HTTPS 检查能力。

为什么 CC 请求很难靠 IP 黑名单解决

传统策略经常从 IP 地址开始：发现某个地址请求过多，就封禁该地址。但 CC 场景下，这种方法存在明显限制。

攻击源可能分散

请求可能来自大量不同地址，每个地址的请求速率并不高。单个源地址没有超过阈值，聚合后却足以拖慢业务。

如果阈值设得过低，公共出口、移动网络或企业 NAT 后的正常用户可能被一起限制；如果阈值设得过高，分散请求又可能绕过策略。

HTTPS 内容对网络设备不可见

即使所有请求都访问同一业务路径，未终止 TLS 的防火墙也通常只能看到：

多源地址 -> TCP/443 -> 建立 TLS -> 持续发送加密数据

它无法直接确认这些请求是否都在访问高成本接口，也无法仅凭端口区分正常访问和恶意调用。

请求可能使用正常业务语义

CC 不一定发送畸形数据包。攻击者可能使用合法的 GET 或 POST、正常的 TLS 版本、合理的请求头，甚至等待服务端返回结果。网络层看来，这些请求与普通浏览器访问没有明显区别。

应用层需要结合更多维度判断，例如：

• 单个账号或会话的调用频率；
• 同一设备短时间内访问多个账号的行为；
• 某个接口的单位时间成本；
• 验证码、登录失败、搜索条件和分页方式；
• 请求间隔、Cookie 连续性和页面访问顺序；
• 返回码、响应时间和后端查询耗时。

这些都超出了普通状态防火墙的职责范围。

硬件防火墙仍然能做什么

“难以过滤 HTTPS 恶意请求”不表示硬件防火墙没有价值。它对网络边界保护仍然重要，只是需要把任务放在合适的层级。

适合由网络防火墙处理的任务

以下场景通常适合由防火墙或上游网络防护完成：

• 阻止明显无关的源地址、协议和端口；
• 丢弃格式异常、无效状态或不符合访问策略的数据包；
• 控制新建连接速率和单源并发；
• 缓解部分 SYN、连接耗尽和协议层攻击；
• 隔离不应暴露在公网的管理端口；
• 在流量进入服务器前完成基础 ACL 和路由策略；
• 将特定攻击流量导向清洗或黑洞策略。

这些能力可以减少无效流量进入服务器，但不能自动识别所有合法格式的 HTTPS 请求。

需要上移到应用入口的任务

以下任务通常需要部署在 TLS 终止点或应用入口：

• 根据 URL、HTTP 方法、参数和请求体检查攻击特征；
• 对登录、搜索、下单等路径设置不同限流；
• 按账号、会话、设备和行为进行关联分析；
• 识别异常 Cookie、请求顺序和自动化访问；
• 对高成本接口设置排队、缓存或挑战机制；
• 根据业务结果判断请求是否具有真实用户行为。

常见的职责分工可以表示为：

互联网
  │
  ▼
上游 DDoS 防护或流量清洗
  │
  ▼
网络防火墙：IP、端口、连接和协议策略
  │
  ▼
负载均衡或反向代理：TLS 终止、连接管理
  │
  ▼
WAF：HTTP 规则、限流和异常请求识别
  │
  ▼
Web 服务与应用：身份、会话、接口和业务风控

这不是固定架构。小规模服务可能由反向代理同时承担 TLS 终止和部分 WAF 功能；大型服务则可能将 DDoS 清洗、四层负载均衡、七层代理和应用风控分开部署。关键不是设备数量，而是每一层能否看到它需要判断的信息。

影响防护效果的五个因素

1. 防火墙是否处于真正的流量入口

如果攻击首先打满运营商到机房的链路，部署在服务器前的本地防火墙没有足够空间完成过滤。此时需要确认：

• 公网带宽是独享、共享还是按端口限速；
• 防火墙位于运营商边缘、机房出口还是服务器旁；
• 流量清洗是否发生在上游；
• 清洗后的流量是否通过专用链路回源；
• 源站真实地址是否仍然直接暴露。

防护设备离源站越近，越适合做精细检查；但面对入口带宽型攻击，越靠近上游越有价值。

2. 设备规格是否覆盖实际指标

不要只比较一个“防火墙吞吐量”。至少应同时核对四层转发、启用安全功能后的吞吐、PPS、并发会话、CPS、TLS 握手和 WAF 请求处理能力。

例如，设备可能在关闭 TLS 检查时能够转发大量流量，但开启解密、恶意规则匹配和详细日志后，CPU、内存或专用检查模块先达到上限。实际判断应以相同功能开关和相近报文特征为准。

3. TLS 在哪里终止

如果 TLS 在源站 Web 服务上终止，前置防火墙在此前只能做四层判断。如果 TLS 在反向代理或 WAF 终止，应用层设备才有机会读取 HTTP 内容。

还要确认是否存在以下情况：

• 部分域名经过 WAF，部分域名直连源站；
• 443 端口由负载均衡转发，但某些端口绕过检查；
• WebSocket 或长连接走了不同路径；
• IPv4 经过防护，IPv6 直接回源；
• 证书配置变化导致部分流量绕过预期入口。

4. 攻击请求访问的业务成本

同样是一个 HTTPS 请求，访问静态文件、缓存接口和复杂报表接口，后端成本可能完全不同。WAF 能够拦截明显恶意请求，但无法替代数据库索引、缓存设计、接口超时和任务队列。

如果接口允许匿名调用、参数组合很多、每次请求都触发远程调用或复杂聚合，那么即使网络层和 WAF 层都正常，CC 仍可能使业务资源枯竭。

5. 防护策略的粒度

只按源 IP 限流通常不够。更合理的策略可能按以下维度组合：

• 主机名与 URL；
• HTTP 方法；
• IP 与会话；
• 账号与设备；
• 接口类型与响应时间；
• 单位时间内的失败次数；
• 正常用户访问路径与调用顺序。

但策略越细，越依赖 TLS 终止、日志质量和业务标识，也越需要避免误伤正常用户。

如何验证：先确认瓶颈在哪一层

验证的目标不是证明某个设备“好”或“坏”，而是回答三个问题：

1. 流量是否已经超过入口或链路能力？
2. 防火墙是否看得到需要识别的 HTTPS 内容？
3. 业务资源是否被合法格式的请求耗尽？

第一步：观察网卡、链路和连接状态

在 Linux 源站上，可以先使用只读命令查看基础状态。以下命令适用于常见 Linux 环境，具体字段会因发行版和工具版本略有差异：

ip -s link show

查看网卡收发字节、数据包和丢包计数。需要连续观察时，可使用：

sar -n DEV 1 5

该命令每秒采样一次网络设备统计，共输出五次。重点关注接收速率、发送速率、丢包和错误是否与业务异常同时出现。

查看内核维护的 TCP 概况：

ss -s

如果需要观察 443 端口相关连接，可先使用：

ss -tan state established '( sport = :443 )'

不同版本的 ss 对过滤表达式支持可能存在差异，若命令报错，应先执行 ss --help 或查看本机手册，不要直接套用其他系统的语法。

如果网卡接收速率接近线路上限，同时出现大量丢包或上游告警，问题更接近入口型 DDoS。如果带宽只有几十或几百 Mb/s，但 443 连接、TLS 握手或应用请求数异常，则应继续检查应用层。

第二步：区分连接洪泛、TLS 压力和 HTTP 压力

可以将监控数据按以下方式对照：

这里不能只看 CPU 总使用率。某个 Web 工作进程、TLS 线程、数据库连接池或内核软中断可能先达到瓶颈，而整机平均 CPU 仍未达到 100%。

第三步：从访问日志确认是否存在应用层集中

应用日志应至少包含以下字段：

• 时间；
• 请求方法和路径；
• 状态码；
• 请求耗时；
• 上游耗时；
• 响应字节数；
• 客户端地址；
• 主机名；
• 会话或请求标识；
• 必要时记录 TLS 协议和连接复用信息。

下面是一条用于说明格式的模拟日志：

198.51.100.24 - - [12/Mar/2025:10:15:21 +0800] \
"POST /api/login HTTP/2.0" 200 \
request_time=1.84 upstream_response_time=1.80 \
bytes_sent=742 request_id=demo-7f21

如果大量请求集中在少数高成本路径，且 upstream_response_time 明显升高，说明瓶颈可能已经进入应用或数据库。若大量请求只访问静态缓存资源，响应时间仍然很短，则应继续观察入口带宽和连接行为。

不要只因为状态码是 200 就认为请求正常。CC 请求往往希望服务端完整处理并返回结果，2xx 反而可能说明后端确实执行了业务逻辑。

第四步：确认防火墙到底看到了什么

需要向设备管理界面或设备厂商资料核对以下项目：

• 设备是路由模式、透明模式还是旁路模式；
• TCP 443 是否由设备终止；
• 是否开启 TLS 解密；
• 解密后是否启用 HTTP/WAF 检查；
• 规则是否只应用于特定域名或策略组；
• 是否存在 IPv6、备用端口或直连回源路径；
• 当前功能组合下的吞吐、PPS、并发和 TLS 处理指标；
• 设备是否出现会话表、内存、CPU、丢包或检查队列告警。

如果设备日志只能显示：

src=198.51.100.24 dst=203.0.113.10 proto=tcp dport=443 action=allow

这只能证明它放行了一个 TCP/443 连接，不能证明它已经检查了 HTTP 请求。

在经过授权的维护窗口内，可以对自有域名的健康检查接口发起少量、非破坏性请求，观察客户端、前置代理、WAF 和源站日志是否都有对应记录：

curl --http1.1 -sS -o /dev/null \
  -w 'code=%{http_code} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n' \
  https://example.com/health

这个命令只适合访问自己管理的测试或健康检查地址，不应通过公开网络制造大量请求。若要确认连接是否在预期设备上终止，还应结合各层日志、证书链和请求标识，而不是只根据一次 curl 结果判断。

第五步：必要时做有限数据包观察

在获得授权并注意敏感信息保护的前提下，可以对网卡进行有限数量的数据包采样：

sudo tcpdump -nn -i eth0 'tcp port 443' -c 100

该命令只抓取 100 个匹配数据包，主要用于观察 TCP 握手、连接方向、包长和是否存在大量重传。HTTPS 内容仍然是加密的，但抓包文件可能包含地址、时间和 TLS 元数据，应限制权限并在使用后按组织规范处理。

如果看到大量 SYN 却很少完成握手，重点检查连接建立、防火墙会话表和上游过滤。如果握手正常、TLS 会话大量建立，随后 Web 日志中的请求数和后端耗时升高，则问题已经越过了传统四层防火墙的主要能力边界。

不要在生产公网环境中自行发起洪泛、压力或绕过防护的测试。需要验证容量时，应使用隔离环境、获得授权的测试流量和明确的停止条件，否则测试本身可能造成服务中断，也可能影响无关网络。

适合改变防护位置的判断

通过上述数据，通常可以得到几种条件化结论：

• 入口带宽或上游端口已被打满：本地物理防火墙不是主要解决点，需要在更靠近攻击源的网络位置进行清洗或限制。
• 带宽正常，但 TCP 新建连接或并发会话异常：应检查连接保护、会话表、CPS、SYN 策略和连接复用。
• TCP 和 TLS 均正常，但请求集中于高成本 URL：需要在 TLS 终止点配置 WAF、接口级限流、缓存或业务风控。
• 设备宣称支持 HTTPS 检查，但设备日志看不到 URL 和方法：应确认实际策略是否启用 TLS 终止和解密后的 HTTP 检查。
• 防火墙已有 WAF 功能，但启用后设备先达到 CPU、TLS 或检查队列上限：问题是功能组合下的容量不足，而不是单纯的端口规则失效。
• 攻击流量与正常用户共享大量地址或出口：不能只按 IP 粗暴封禁，应结合会话、账号、URL、请求频率和业务结果判断。

最终判断可以围绕四个证据展开：流量是否在到达设备前就堵塞，设备是否能够看到 HTTP 内容，设备在启用实际安全功能后是否仍有余量，以及应用是否被合法格式的高成本请求拖垮。只要其中任一环节超出物理防火墙的观察范围或处理能力，继续增加端口封禁规则都很难解决 HTTPS 应用层攻击。

硬件防火墙适合守住网络边界，但不应被当成所有层级的唯一防线。面对 DDoS 与 CC 的叠加场景，更可靠的做法是让上游承担入口流量清洗，让网络防火墙处理 IP、协议和连接，让 TLS 终止点承担 HTTP 检查，再由应用本身限制高成本操作。这样才能根据实际瓶颈决定过滤位置，而不是在看不到请求内容的设备上反复调整规则。