从 L3/L4 到 L7：如何建立 DDoS 多层联防架构？

在上一篇〈DDoS 攻击类型全解析：从流量攻击、CC 到 L7 攻击〉中，我们提到，不同 DDoS 攻击消耗的资源并不相同。

Volumetric Attack 消耗 Bandwidth，Protocol Attack 消耗 Connection；到了 Application Layer，HTTP Flood、CC Attack 则可能直接消耗 Web Server、API 或 Database Resource。

因此，即使最终结果都是服务异常，背后面对的问题也可能完全不同。大量 UDP Traffic 的核心问题通常发生在 Network Layer；大量 Login Request 则可能透过看似正常的 HTTP Request，持续消耗 Application Resource。

现代 DDoS 防护不能只衡量能够承受多少攻击流量，还需要根据攻击发生的 Layer，采取不同的辨识与处理方式。而这也是多层联防架构的核心。

为什么只靠单一防护机制可能不够？

当攻击发生在 L3/L4，企业可能面对大量 Packet、Connection 或 Reflection Traffic；当攻击进入 L7，攻击者发送的则可能是完全符合 HTTP Protocol 的 Request。

例如 POST /login 可能来自正常用户，也可能是 Automated Client 持续调用 Login API。只从 Network Layer 观察，很难判断这些正常格式的 Request 是否正在对业务造成风险。

因此，不同 Security Mechanism 并不是彼此取代，而是处理不同层面的问题：

• Network / Transport Layer：主要观察 Traffic、Packet 与 Connection
• Application Layer：判断依据延伸到 HTTP Request、URI、API Endpoint 与 Request Rate
• 更复杂的 Automated Traffic：需要进一步分析 Client、Session 与 Behavior

多层联防的目的，就是让不同 Layer 的异常，在适合的位置被辨识与处理。

Layer 1｜DDoS Protection：先处理 L3/L4 异常流量

多层联防的第一层，是处理 Network / Transport Layer 的异常。

SYN Flood 可能透过大量未完成的连线消耗 Connection Resource；UDP Flood、ICMP Flood 或 DNS Reflection 等攻击，则可能在短时间内制造大量异常 Traffic。因此，L3/L4 防护的主要任务，是在这些流量进一步影响 Application 之前，先辨识并处理 Network / Transport Layer 的 Attack Pattern。

ByteShield DDoS Protection 涵盖以下攻击类型：

• Land Flood、ICMP Flood
• SYN Flood、SYN-ACK Flood、ACK Flood、FIN/RST Flood
• TCP Reflection、Connection Exhaustion
• TCP/UDP Fragmentation
• DNS Reflection / Amplification

并可透过 GEOIP、Black/Whitelist 等条件进行流量控制，再依 ICMP、TCP、UDP 等不同 Protocol 进一步分类与处理。

这一层主要关注 BPS、PPS、SYN Rate 与 Concurrent Connections。当这些指标出现明显异常，就需要优先确认 Network / Transport Layer 是否正在承受攻击。

Layer 2｜CC Defense：到了 L7，开始判断 Request

当 Network Layer 没有出现明显的大流量异常，并不代表服务没有遭受攻击。

到了 Application Layer，攻击可能转变成大量 HTTP Request。例如 POST /login、GET /search 或 GET /api/query，单独来看都可能正常；但如果短时间内大量出现，或集中在 Authentication、Database Query、Search 等高成本 Endpoint，就可能持续消耗 Application Resource。

L7 防护需要进一步判断 HTTP Request 与 Request Pattern 是否符合正常的业务使用情境。

ByteShield CC Defense 可透过多种 HTTP 条件组合匹配建立自订规则，并搭配限速、行为式验证、JS 等处理方式。针对 APP 与 API 场景，也可透过算法签名进行 Request 校验，或搭配 Challenge Mechanism 增加 Client Verification 的判断依据。

当攻击来源更加分散，单纯依靠 IP Blocklist 可能不足，因此也可以进一步从 Request Pattern 与行为特征分析异常，并透过全网联动，使识别出的 CC Attack 特征与相关防御策略同步生效。

到了这一层，防护所观察的信息也从 Traffic、Packet、Connection 延伸到 HTTP Request、URI、API Endpoint 与 Request Frequency。

Layer 3｜Bot Management：从 Request 进一步理解 Behavior

到了更复杂的 L7 场景，只判断单一 Request 可能仍然不够。

正常用户、合法 Crawler 与 Malicious Bot 都可能送出相同的 GET /product/123。如果 Automated Traffic 再透过 Distributed IP、不同 User-Agent、Request Interval，甚至模拟一般浏览流程，单纯依靠 IP 或固定 Request Rule，就更难区分不同 Client。

因此，L7 防护需要从 Request Analysis 进一步延伸到 Client 与 Behavior Analysis。

ByteShield Bot Management 透过已知 Bot Library 与智能辨识机制，对不同 Automated Traffic 进行分类，包括合作伙伴 Bot、监控 Bot、聚合器 Bot、恶意 UA Bot、伪造模拟搜索引擎 Bot，以及其他已知 Automated Traffic。

但 Bot 本身并不等于恶意流量。搜索引擎、Monitoring Service 或合作伙伴服务，也可能产生正常且必要的 Bot Traffic。因此，Bot Management 的目的不是封锁所有 Bot，而是先辨识其类型与行为，再根据业务需求采取观察、阻断、封禁、人机辨识或精准访问控制等策略。

到了这一层，判断依据也从单一 HTTP Request 延伸到 Client、Session 与 Behavior。

从 Traffic、Request 到 Behavior：多层联防如何运作？

把三层防护放在一起，就可以看到 ByteShield 多层联防的整体逻辑：

整套逻辑可以简化成：Traffic → Request → Behavior

也就是从 Network Layer 的流量辨识，逐步延伸到 Application Layer 的 Request Analysis，以及更进一步的 Behavior Analysis。

多层联防不是把所有流量都挡掉

多层防护的目的并不是让每一道 Security Control 都采取相同的封锁逻辑。

正常 User、合法 Crawler、合作伙伴服务与 Malicious Bot 可能同时存在于网站流量中，因此不同 Security Layer 应该处理各自最适合辨识的问题。

ByteShield DDoS Protection 主要处理异常 Traffic、Packet 与 Connection；CC Defense 进一步分析 HTTP Request、Access Frequency 与 Client Verification；Bot Management 则根据 Bot Type 与 Behavior 采取不同管理策略。

越接近 Application 与 Business Layer，需要理解的信息也越细致。

从「吸收流量」走向「理解流量」

大型 Volumetric Attack 并没有消失，因此 Network Layer 的 DDoS Protection 仍然是整体安全架构的重要基础。

但当攻击进入 Application Layer，只知道目前承受多少 Gbps 已经不够。企业需要观察的信号会从 BPS、PPS、Connection，延伸到 RPS、URI、API Endpoint、Client、Session 与 Behavior。

L3/L4 看 Traffic，L7 看 Request，更复杂的 Automated Traffic 则需要进一步理解 Behavior。

ByteShield：从 L3/L4 到 L7 建立多层安全防护

不同企业所面对的 Traffic Pattern、Application Architecture、API 使用方式与业务场景并不相同，需要的 Security Policy 也会有所差异。

ByteShield 透过 DDoS Protection、CC Defense 与 Bot Management，从 Network Traffic、HTTP Request 到 Automated Behavior 建立不同层面的防护与管理机制，协助 Web、APP 与 API 业务降低不同类型 Attack Traffic 对服务造成的影响。

多层防护的核心，不只是提升可以承受的攻击流量，更重要的是逐层增加对流量的辨识能力，让不同类型的异常能在适合的 Layer 被发现与处理。

常见问题

为什么只靠单一 DDoS 防护机制可能不够？

L3/L4 攻击以大量 Packet、Connection 或 Reflection Traffic 为主，L7 攻击则可能是完全符合 HTTP Protocol 的 Request。只从 Network Layer 观察，很难判断正常格式的 Login 或 API 请求是否正在造成业务风险，因此需要不同 Layer 的机制各自处理最适合辨识的问题。

DDoS Protection、CC Defense 与 Bot Management 各自负责什么？

DDoS Protection 处理 L3/L4 的异常 Traffic、Packet 与 Connection，主要观察 BPS、PPS、SYN Rate 与 Concurrent Connections；CC Defense 在 L7 分析 HTTP Request、URI、API Endpoint 与 Access Frequency；Bot Management 则从 Client、Session 与 Behavior 辨识并管理 Automated Traffic。

Bot Management 会不会把搜索引擎或合作伙伴的 Bot 也挡掉？

不会一律封锁。Bot Management 的目的是先辨识 Bot 的类型与行为，再依业务需求采取观察、阻断、封禁、人机辨识或精准访问控制等策略。搜索引擎、Monitoring Service 与合作伙伴服务产生的正常 Bot Traffic 可以被保留。

攻击来源很分散时，CC Defense 怎么处理？

当攻击来源分散，单纯依靠 IP Blocklist 可能不足。CC Defense 可从 Request Pattern 与行为特征分析异常，针对 APP 与 API 场景使用算法签名校验 Request，并透过全网联动让识别出的 CC Attack 特征与防御策略同步生效。

如果您有相关的需求，欢迎了解 ByteShield 安全防护服务，或联系 ByteShield 团队，我们将根据您现有的应用架构与业务需求，提供合适的解决方案。