本文是人为引导下的 AI 创作。

提示词

:::success 帮忙调研一下多路径TCP(MPTCP)技术，分析这种方式绕过 WAF 的可行性。

:::

先把结论说前面：
MPTCP 理论上可以制造「多路径可见性缺口」，在非常特定的网络+部署条件下，对 IDS/NIDS 的确存在绕过风险；但对主流 WAF（尤其是反向代理型 L7 WAF）来说，作为通用绕过手段几乎不可行，更像是一种需要刻意配合的「实验室级」攻击面。

下面分块聊，一方面帮你补全 MPTCP 的框架，另一方面从攻防视角评估它对 WAF 的现实威胁。

一、MPTCP 是什么：协议 & 部署现状（大局）

1. 协议概览

Multipath TCP（MPTCP）是对传统 TCP 的扩展，在应用层仍然提供「单一可靠字节流」，但在传输层把这一条连接拆成多个子流（subflow），可以走不同的网络路径（不同接口、不同 ISP）。核心点：

  • 在 TCP option 里引入新的选项（如 MP_CAPABLE、MP_JOIN、DSS），建立/加入多条子流；
  • 每个子流本质上还是正常 TCP 连接，有自己的四元组（src/dst IP + src/dst port）；
  • 协议在端点维护一套「数据序列号」（Data Sequence Number，DSN），负责把各个子流上的 segment 重新编排成有序字节流。(datatracker.ietf.org)

Linux 官方文档对 MPTCP 的实现也有相对清晰的说明：多个接口可同时用于一条 MPTCP 连接，支持聚合带宽、故障切换等。(Linux Kernel 文档)

2. 现实中的部署

现在真正大规模用 MPTCP 的场景其实不多，典型是：

  • Apple 生态：iOS 7 开始，Siri、Apple Music、地图、Wi-Fi Assist 等会用 MPTCP，在 Wi-Fi 和蜂窝之间做切换/叠加。中间设备不支持时会回退到普通 TCP。(苹果支持)
  • Linux 内核：5.6 起内核支持 MPTCP v1（RFC 8684），但需要显式开启和配置，服务器侧实际落地比例很有限。(Linux Kernel 文档)
  • 网络设备 / 运营商场景：如 Citrix ADC 支持「客户端 ↔ ADC」之间跑 MPTCP，用来聚合链路，但到后端服务器一般还是普通 TCP。(docs.netscaler.com)
  • 云/CDN新特性：Cloudflare 等在探索 MPTCP 作为提升可用性和带宽的方案，但仍属渐进部署。(The Cloudflare Blog)

同时，还有一个关键现实：很多中间盒（老防火墙、NAT、负载均衡）不认 TCP option 30，会直接丢弃或剥离这些 option，导致 MPTCP 回退为普通 TCP。(Stack Overflow)

整体来看，MPTCP 还远没到「互联网默认开启」的程度，大部分 Web 业务栈今天看到的仍是传统 TCP。

二、WAF 的典型位置 & 能见度

先把 WAF 放在拓扑里看一下它到底能看到什么，才好谈「绕过」。

1. 主流部署模型

常见的 WAF 实现大致两类：

  1. 反向代理 / 负载均衡型 WAF（最常见）
    • Cloudflare、AWS WAF（配 ALB/API GW）、Azure App Gateway WAF、Nginx / Envoy + ModSecurity/FortiWeb 等；
    • 在 L7 终止 TCP/TLS，重组 TCP 流，按 HTTP/HTTPS 请求对象做规则匹配（签名、语义解析、行为分析等）。(docs.fortinet.com)
  2. 内嵌在 NGFW / IPS 中的 WAF 功能
    • NGFW 在 L3–L7 做深度检查，有时 HTTP 部分叫 WAF，有时和 IPS 混在一起；
    • 既有 flow-based 检测（类似 NIDS），也有 proxy-based 检测。

2. 和 MPTCP 的关系

  • 如果 WAF 是 明文代理 / TLS 终止点：
    不管下面跑 TCP 还是 MPTCP，对它来说都是「已经重组好的完整 HTTP 请求」，它看到的是已经按顺序排好的应用层 payload。
  • 如果 WAF 更像 流量旁路传感器（NIDS 模式）：
    它看到的是某一段路径上经过的 packet，需要自己做 TCP 重组。如果攻防双方能让同一条 MPTCP 连接的不同子流走不同路径，就可能出现「每个传感器只看到一部分流量」。

这也是为什么现有公开研究，多数是 “MPTCP 对 NIDS 的绕过潜力”，而不是直接谈 WAF。(Repositorio INESC TEC)

三、公开研究里 MPTCP 绕 IDS/NIDS 的思路（抽象版本）

几篇论文和硕士论文专门讨论了这件事，大致共同点是：(Repositorio INESC TEC)

利用 MPTCP 把攻击 payload 拆分到多个子流上，只要没有任何一个监控点能看到完整的重组后字节流，就有机会绕过基于签名/模式匹配的 NIDS。

抽象一下攻击条件：

  1. 端点双方都支持并启用 MPTCP；
  2. 网络中部署的 NIDS 对 MPTCP 不感知（不会跨子流重组，只在单 TCP flow 内做重组/检查）；
  3. 不同子流在网络中的路径不同，比如：
    • 子流1：走路径 A，经过 IDS A；
    • 子流2：走路径 B，经过 IDS B；
    • 任意一个 IDS 都只看到其中一部分 payload；
  4. 攻击者利用 DSN，把「无害片段」和「恶意片段」拆在不同子流上，重组后才构成完整攻击载荷，但任何单一路径上的 IDS 都看不到完整模式。

从攻防视角，你可以把它理解成：

传统的 NIDS 假定「全流量在一个地方看得到」；
MPTCP 则引入了「跨路径重组」这一新维度，给了攻击者一个利用「可见性碎片化」的机会。

注意这里是 NIDS（基于旁路流量复制的检测），不是反向代理 WAF——二者在可见性上差别很大。

四、把这套思路映射到 WAF：场景级可行性评估

下面按典型拓扑划几个 case，分别看「MPTCP 绕 WAF」是否现实。这里默认你是合法红队/安全研究视角。

场景 A：云厂商 SaaS WAF（Cloudflare / AWS WAF / 阿里云高防 + WAF）

拓扑抽象：

Client ⇄ Internet ⇄ WAF 边缘节点（终止 TCP/TLS，做 WAF）⇄ 内部专线 / 普通 TCP ⇄ 源站

特点：

  • 外部连接基本都是 传统 TCP + TLS，厂商公开文档中也几乎没强调对 MPTCP 的支持；
  • 即便未来支持 MPTCP，很大概率也是：
    • Client ↔ Edge 使用 MPTCP（为了提速、容灾）；
    • Edge ↔ Origin 仍是普通 TCP/TLS 或其他内部协议。

对绕过 WAF 的可行性：

  • 你无法控制 WAF 与 Client 之间的链路是否启用 MPTCP；
  • 就算启用了，WAF 自己就是终止点，看的是重组之后的 HTTP 请求；
  • 不存在「某条子流绕过 WAF 直达源站」这种路径，因为 WAF 就是唯一入口。

👉 现实结论：
作为互联网红队攻击面，「通过 MPTCP 绕过 SaaS WAF」几乎不可行。
除非你能发现极其离谱的边界拓扑错误（比如源站开放 MPTCP 监听，且对外直连绕过 cloud WAF），那风险本质上和「旁路未加固入口」有关，和 MPTCP 无关。

场景 B：企业自建 ADC/NGFW 上挂 WAF（Citrix / F5 / Nginx + WAF）

典型两种部署方式：

  1. 代理型 ADC/WAF 作为唯一入口

➜ 此时 WAF/ADC 是 MPTCP 终止点，看的是完整 HTTP，依然很难从 MPTCP 切。

- 类似 SaaS WAF，只是部署在本地或自建云；
- 一般支持 Client ↔ ADC 跑 MPTCP（用于链路聚合），**ADC ****↔**** Backend 仍然是普通 TCP**。([docs.netscaler.com](https://docs.netscaler.com/en-us/citrix-adc/current-release/system/tcp-configurations.html?utm_source=chatgpt.com))
  1. L3/4 转发 + 旁路 WAF / IDS 组合

➜ 在这种比较「野生」的部署中，理论上你可以仿照 NIDS 绕过思路：

但要想做到这一点，需要你：

- 有时 WAF / IDS 是在旁路流量镜像口做检测（span/mirror）；
- 如果网络工程师错误地只镜像了某一条链路，而 MPTCP 有其他子流走另一条链路直达后端，那么**与其说是 MPTCP 绕过 WAF，不如说是流量镜像不完整**。
- 子流1 走经过 WAF 的路径（发一些正常流量维持连接）；
- 子流2 走不经过 WAF 的路径（走某条未被镜像的链路），携带主要攻击 payload。
- 同时控制 MPTCP Client & Server；
- 非常清楚网络拓扑，知道哪些路径经过/不经过 WAF；
- 能操控调度，使不同子流走不同接口/路径——这个在实验环境（Linux MPTCP + policy routing）可以做到，但在真实运营商/骨干网络下则复杂得多。

👉 现实结论：

  • “做得到”的前提，是你几乎已经是这个网络的半个网工；
  • 对「互联网实战红队」来说，这种前置条件太重，性价比远不如找传统逻辑/实现漏洞；
  • 对「内部攻防演练 / 安全评估」来说，倒是可以作为一个 check item：
    • 若企业正在用 MPTCP 做链路聚合，
    • 又在不同路径上部署了不对 MPTCP 感知的检测设备，
    • 就值得用合法方式验证有没有「可见性碎片化」问题。

场景 C：有多入口 / 多路径到同一业务，部分路径不挂 WAF

比如：

Client ⇄ Internet ⇄ ISP A ⇄ WAF ⇄ App
Client ⇄ Internet ⇄ ISP B ⇄ 直连 App（运维忘了挡，或者只做了 L3 ACL）

此时，绕过 WAF 的关键其实是「未加固的第二入口」。
MPTCP 只是一个「更优雅地同时利用多条链路」的工具，和「某条链路没上 WAF」相比，它不是决定性因素。

你完全可以不使用 MPTCP，直接打那条没上 WAF 的入口——问题的本质还是网络暴露面管理。

五、综合评估：MPTCP 作为 WAF 绕过手段的现实价值

从攻防两边做个「简版评分」（1–5分，越高越现实 / 越值得投资源）：

目标类型是否支持 MPTCP典型部署MPTCP 绕过 WAF 现实可行性
公网 SaaS WAF 防护的网站大多不公开支持反向代理⭐ (1/5) 几乎不可行
企业自建 ADC + WAF（代理型）部分支持反向代理⭐⭐ (2/5) 理论上有空间，但很难
企业多链路 + 旁路 NIDS/WAF 混用可能混合拓扑⭐⭐⭐⭐ (4/5) 对 NIDS 绕过现实，对 WAF 取决于链路规划
内网实验/科研环境可完全控制任意⭐⭐⭐⭐⭐ (5/5) 很适合作为「安全性研究主题」

对你这种安全研究/红队背景来说，MPTCP 更适合用来：

  • 在实验环境里重现论文中的「跨路径 NIDS evasion」；
  • 帮防守方 audit 自己在「混合路径 + 多种安全设备」场景下是否有 blind spot；
  • 而不是用作「通用的 WAF 绕过 payload 技巧」。

六、防守视角：如果我在做蓝队 / 架构，要不要担心？

如果你站在防守侧，思路可以是：

  1. 搞清楚自己有没有用 MPTCP
    • Linux 内核是否启用 MPTCP；
    • 运营商/网络设备（如 Citrix ADC、运营商 Hybrid Access CPE）是否启用了相关功能。(docs.netscaler.com)
  2. 如果有，就要保证「所有 subflow 都在安全可见区」
    • 方案 A：在 MPTCP 终止点上挂 WAF/IPS，终止点负责跨路径重组（最推荐）；
    • 方案 B：如果使用旁路 NIDS/IPS，镜像策略必须确保所有子流流量都会被复制过去，不要只镜一个出口。
  3. 不需要 MPTCP 的互联网面向业务，干脆关闭
    • 尤其是公网入口服务器，通常没必要直接对外暴露 MPTCP 服务；
    • 把 MPTCP 限制在「终端 ↔ 运营商设备」或「站点之间专线」内部使用即可。
  4. 对安全产品厂商的要求
    • NIDS/IPS 厂商应该对 MPTCP 做协议识别并支持跨子流重组，避免论文提到的「inconsistent visibility」问题。(Repositorio INESC TEC)

七、给你的实战建议（合法红队 / 研究方向）

如果你后面想在这个方向上做点东西，比较「划算」的路线大概是：

  1. 优先定位：这是对 NIDS / 混合拓扑的绕过研究，而不是 WAF 绕过技巧
    • 标题/选题可以朝「MPTCP 时代的检测可见性」之类的方向去。
  2. 在实验室搭建一个「多路径 + 单点可见」vs「多点可见」的对比环境
    • 用 Linux + MPTCP 实现多子流；
    • 用开源 NIDS（Suricata/Snort）只看其中一个路径，验证绕过效果；
    • 再调整为共享可见性，看绕过怎么失效。
  3. 对真实企业网络做「架构审计」而不是「绕过 WAF POC」
    • 关注：专线/多出口 + MPTCP/负载均衡 + 安全设备的部署关系；
    • 输出一套「多路径环境下的检测覆盖矩阵」，帮助蓝队发现 blind spot。

最后一句话总结

MPTCP 带来的真实安全议题，是「多路径导致的检测可见性碎片化」，这对缺乏统一终止点的 NIDS 更致命；

对于大多数把 WAF 当作 L7 反向代理入口的 Web 架构来说，MPTCP 在当前阶段几乎不会成为实用的绕过手段。