6.3 网络检测与韧性：IDS、流量分析与 DDoS
网络控制描述应该发生什么，检测系统观察实际发生了什么。加密流量越来越普遍后，检测不能只靠深度检查 payload；连接元数据、DNS、身份、端点行为和应用遥测需要被关联起来。
IDS 与 IPS 的故障模式不同
IDS 旁路观察并告警，误报主要消耗分析能力；IPS 位于流量路径并可阻断，误报会直接造成可用性事故。高置信、可快速回滚的规则才适合自动阻断，其余先观测、关联和人工确认。
Signature detection 擅长已知模式，anomaly detection 寻找偏离基线的行为。异常不等于恶意：发布、批处理和节日流量都可能改变基线。每条高优先级检测应有资产范围、攻击假设、预期误报和响应动作。
元数据仍能回答关键问题
即使 TLS payload 不可见，flow 与端点数据仍可回答：
谁首次连接新目的地？
哪台主机突然扫描多个端口？
哪个 workload 向非常用区域持续上传？
DNS 查询是否出现高熵或新注册域？
同一身份是否从不可能的设备/位置并发？TLS 指纹、SNI、证书和流量大小的可见性与价值取决于观测位置。被动旁路传感器通常看不到 TLS 1.3 加密握手中的证书，ECH 又会隐藏内层 ClientHello/SNI；端点或终止代理可提供不同视角，客户端更新也会改变指纹。它们应作为相关信号，不应单独形成不可解释的封禁。
在 TLS 终止点记录受控应用信息通常比到处解密流量更可靠。全网 TLS interception 会引入新的根 CA、私钥、隐私、兼容和单点风险，需要严格限定场景。
Detection-as-Code 需要测试数据
规则应版本化，包含：
- 数据源与必要字段；
- ATT&CK technique 或内部攻击假设；
- 阈值和聚合窗口；
- 允许的业务例外；
- owner、severity、runbook；
- 正样本、负样本和历史回放测试。
数据源停止上报不能表现为“零事件所以安全”。要监控 sensor coverage、日志延迟、字段解析失败和规则执行状态。
DDoS 是容量与状态耗尽问题
攻击可以耗尽带宽、连接表、TLS 握手 CPU、线程、队列、数据库连接或昂贵业务操作。分层防护：
上游清洗/CDN + Anycast 分散流量
→ L4 SYN/连接保护
→ L7 限速与身份配额
→ 应用并发/队列/超时
→ 依赖隔离与降级只按源 IP 限速会伤害 NAT 后用户，也容易被分布式来源绕过。应组合账户、API key、设备、租户、操作成本和全局容量，并对匿名与已认证流量设不同预算。
限速器自身需要分布式一致性取舍：过于强一致可能成为瓶颈，完全本地又会让可接受总额度随实例数增长。例如每实例 200 次/秒，4 个实例在流量可均匀分发时可共接受约 800 次/秒，扩到 8 个后则约 1,600 次/秒；这还未计入各算法的突发额度。关键是限制最昂贵资源之前的工作量，例如在密码哈希、复杂查询和文件转码前做低成本筛选。
Anycast 主要把流量分散到不同入口，不会自己识别或清除攻击；若上游链路已饱和，源站进程再快的限速器也无济于事。还要限制绕过 CDN 直连源站的路径。
响应要保留证据并控制爆炸半径
高置信事件触发后可以：撤销短期凭据、隔离 workload、收紧 egress、切换只读、阻断恶意 destination 或提高认证保证。动作要有作用域、期限与授权规则。隔离等关键控制不能到时盲目恢复：回滚前要满足已清除入侵、已恢复可信身份等条件，必要时延长隔离。
在持续损害允许的情况下，重启或清理前先保留关键易失证据；若必须立即遏制，记录处置与丢失证据的原因，不能为取证无限延误阻断。按事件等级保留 flow、DNS、身份、进程、镜像 digest、内存/磁盘证据，并确保时间同步。网络团队看到 IP，身份团队看到 subject，应用团队看到 trace；共同的 correlation 和资产目录才能拼成攻击链。
演练清单
- 模拟应用主机向新外部域外传，检测多久触发？
- 模拟内部端口扫描，分段是否阻断、IDS 是否定位主体？
- 关闭一个 sensor，平台是否告警数据缺失？
- 回放一次正常大促，规则是否误阻断？
- 对昂贵匿名接口压测，哪一层先饱和？
- 执行隔离后，恢复和清理临时策略是否可审计？
这些演练应使用自有测试端点、合成数据与约定流量上限。下一章把同样的可验证要求放进软件开发流程。