混合流量清洗体系：网络层DDoS与业务层CC攻击协同防护实战

网络层DDoS攻击和业务层CC攻击同时打过来，是运维和安防岗位最不想遇到的局面。单靠高防清洗扛不住应用层的模拟请求，单靠WAF又会被大流量直接压垮带宽入口，两套设备各管一段、告警各报各的，中间那段灰色地带就成了攻击者最舒服的突破口。混合流量清洗体系要解决的就是这个复合场景——把网络层和应用层的清洗能力串成一条链路，让攻击流量在进入业务系统之前被分层识别、分层处置。这套东西适合有一定业务体量、已经踩过单点防护坑的运维负责人、安全工程师，也适合正在做防护方案选型的技术决策者参考。下面我按实际落地的思路，把整体设计、核心细节、实操过程和踩坑经验完整拆一遍。

1. 混合清洗体系的整体设计与选型逻辑

1.1 为什么单层防护在复合攻击下必然失效

先把问题说透。网络层攻击的典型特征是流量大、包特征明显，比如SYN Flood、UDP反射、ICMP洪水，这类流量在带宽入口就能靠流量基线、包速率阈值识别出来，清洗设备直接丢弃或者限速即可。业务层攻击完全是另一副面孔，攻击者用大量看起来合法的HTTP请求，慢速连接、高频接口调用、模拟正常用户行为，单个请求的包大小和协议字段都挑不出毛病，网络层设备看过去全是"正常流量"，根本不敢拦。

复合攻击的杀伤力在于两者的配合。攻击者先用大流量把带宽打满，逼迫防护系统进入应急模式，这时候运维注意力全在流量清洗上，业务层的慢速攻击趁虚而入，等大流量退去，业务已经被拖垮了。还有一种更阴的玩法，用业务层攻击制造大量半连接和慢请求，把服务器的连接池占满，这时候再来一波中等规模的网络层流量，服务器直接雪崩。

我见过不少团队的做法是买一台高防设备加一套WAF，以为双保险，实际跑起来问题一堆。高防设备清洗完的流量回源到源站，WAF部署在源站前面，但高防回源的流量往往做了地址转换或者走了专线，WAF看到的源IP全是高防设备的地址，业务层的限频、黑名单策略全部失效。这就是典型的"两层防护、各管一段、中间断链"。

混合清洗体系的核心思路，是把清洗能力做成一条有状态的链路，而不是两台设备的简单叠加。流量先过网络层清洗，做粗粒度的大流量过滤，清洗后的干净流量不是直接回源，而是带着原始会话信息进入业务层清洗模块，业务层模块基于完整的七层信息做精细识别。两层之间共享会话状态和信誉数据，网络层识别出的可疑源，业务层可以直接重点关照；业务层判定为恶意的源，网络层可以提前在入口做限速。这种联动才是"混合"两个字的真正含义。

1.2 分层清洗的架构选型与关键取舍

架构上我倾向于"边缘清洗+近源清洗+业务层清洗"三段式，而不是把所有能力堆在一个节点上。边缘清洗部署在带宽入口，负责扛住第一波大流量，做SYN Cookie、包速率限制、畸形包丢弃这些轻量但高效的操作，目标是保住链路不被压垮。近源清洗部署在离业务集群更近的位置，做协议层和应用层的深度检测，处理那些边缘层放行但实际可疑的流量。业务层清洗则贴近应用，做接口级的限频、行为分析和人机校验。

这个分段的理由很实在。边缘层如果做深度检测，设备性能扛不住，大流量一来检测引擎自己先过载；业务层如果做流量清洗，带宽根本不够看。各层做自己擅长的事，通过统一的调度中心串联，才是可持续的方案。

调度中心是整个体系的大脑，负责收集各层的流量指标、攻击告警、信誉数据，动态调整清洗策略。这里有个关键取舍：调度策略是集中式还是分布式。集中式调度逻辑统一、策略一致性好，但调度中心本身成为单点，一旦故障全链路降级；分布式调度各节点自治、容错性强，但策略容易不一致，出现"这层放行那层拦截"的尴尬。我的实践是混合调度——全局策略由中心统一下发，保证基线一致，局部应急策略由各层节点根据本地指标自主触发，事后上报中心做策略收敛。这样既保证了策略一致性，又避免了中心故障导致的全链路瘫痪。

1.3 清洗链路的状态保持与会话关联

混合清洗最容易翻车的地方是会话状态丢失。网络层清洗设备通常做的是无状态或者半状态处理，清洗完的流量转发给业务层时，如果做了SNAT，业务层看到的源IP就变了，基于源IP的限频、黑名单全部失效。这个问题在真实环境里非常普遍，很多团队上线后才发现业务层的防护策略形同虚设。

解决办法有两个方向。一是清洗链路全程透传原始源IP，网络层清洗设备用透明模式部署，不做地址转换，通过策略路由把清洗后的流量引到业务层模块。这种方式对网络规划要求高，需要保证回程路径一致，否则会出现非对称路由导致连接异常。二是用会话标记的方式，网络层清洗时给每个会话打上标记，把原始五元组信息封装在自定义头部或者隧道里传给业务层，业务层解析后还原真实源信息。这种方式对设备有定制要求，但网络规划简单，适合多机房、多线路的复杂环境。

我实际项目里用的是第二种，因为业务集群跨了多个可用区，透明模式的路由规划太复杂，会话标记虽然要定制开发，但一次投入长期受益。标记信息里除了原始五元组，还带了网络层的风险评分，业务层拿到后可以直接作为限频策略的输入，联动效果比单纯透传源IP更好。

2. 核心细节解析与实操要点

2.1 网络层清洗的阈值设定与动态调整

网络层清洗的核心是阈值，阈值设高了漏放攻击流量，设低了误杀正常业务。很多团队直接抄厂商的默认值，结果上线第一天就误杀了正常的大文件上传流量。阈值必须基于业务基线来定，而且要动态调整。

基线采集至少要做一周，覆盖业务高峰和低谷。采集的指标包括入向包速率、入向比特率、新建连接速率、并发连接数、各协议占比。采集完不是简单取平均值，而是取P95或者P99分位值作为基线，再乘以一个安全系数。安全系数怎么定？业务波动大的取1.5到2倍，波动小的取1.2到1.5倍。比如某业务入向包速率P99是80万pps，波动较大，阈值就设在120万到160万pps之间。

动态调整的逻辑是：正常状态下阈值维持在基线安全系数之上，一旦检测到攻击特征，阈值自动收紧到基线附近，同时启动更细粒度的检测；攻击结束后阈值缓慢恢复，避免突然放宽导致二次攻击趁虚而入。恢复速度要控制，我一般设置每分钟恢复不超过5%，给系统一个观察窗口。

注意：阈值调整一定要有灰度机制，新阈值先在小流量线路生效观察，确认无误杀再全量下发。直接全量调整是误杀事故的高发原因。

2.2 业务层清洗的特征识别与策略组合

业务层清洗不能只靠单一规则，要靠特征组合。我常用的特征维度包括请求频率、请求间隔规律性、URL访问分布、User-Agent指纹、请求头完整性、Cookie行为、TCP连接复用情况。单一维度很容易被绕过，组合起来才能提高识别准确率。

举个实际例子，慢速攻击的特征是请求间隔极其规律，正常用户的请求间隔是随机分布的，攻击工具为了控制资源往往用固定间隔。单看请求频率可能不高，但结合间隔规律性就能识别出来。再比如模拟正常用户的攻击，User-Agent和请求头都伪装得很好，但URL访问分布异常集中，正常用户会访问多个页面，攻击往往盯着少数几个接口猛打。

策略组合的原则是"宽进严出"，入口层用宽松规则做粗筛，把明显异常的流量挑出来；中间层用组合规则做精筛，提高准确率；出口层用严格规则做兜底，宁可误杀少量可疑流量也要保住业务。三层策略的阈值逐层收紧，形成漏斗结构。

人机校验是业务层清洗的最后一道防线，但不能滥用。我的经验是只在关键接口和异常会话上触发，比如登录、下单、支付这些高价值接口，以及被判定为可疑但证据不足的会话。全站触发人机校验会严重影响用户体验，而且校验服务本身也会成为攻击目标。

2.3 两层清洗的联动机制与信誉共享

联动机制是混合清洗区别于设备堆叠的关键。联动分三个层次：数据联动、策略联动、处置联动。

数据联动是基础，网络层把流量指标、攻击类型、可疑源列表实时同步给业务层，业务层把应用层攻击特征、恶意会话标识回传给网络层。数据同步的频率要控制，太高会拖垮链路，太低联动不及时，我一般设置秒级同步，关键指标用增量推送。

策略联动是核心，网络层识别出某源IP在发起SYN Flood，除了本地限速，还要把这个源标记为高风险同步给业务层，业务层对该源的HTTP请求直接触发严格校验。反过来，业务层识别出某源在发起CC攻击，把源标记同步给网络层，网络层在入口对该源做连接数限制，从源头减少进入业务层的攻击流量。

处置联动是闭环，两层的处置动作要协调，避免出现网络层放行、业务层拦截但拦截后流量又回环到网络层的情况。处置动作要有优先级，网络层的限速和丢弃优先级最高，业务层的挑战和拦截次之，应用层的降级和熔断最后。优先级混乱会导致处置冲突，比如业务层已经拦截的流量，网络层还在为其保留连接资源，白白浪费清洗能力。

信誉共享要建统一的信誉库，记录源的攻击历史、行为评分、处置记录。信誉库的更新要谨慎，单次可疑行为不能直接拉黑，要累计评分，达到阈值才降级处置。信誉评分要有衰减机制，长期表现良好的源要能恢复信誉，否则信誉库会越来越臃肿，误伤越来越多。

2.4 清洗能力的容量规划与冗余设计

容量规划经常被忽视，很多团队按当前业务量买清洗能力，结果攻击一来清洗设备自己先过载。清洗容量要按业务峰值的倍数来规划，我一般按业务峰值带宽的3到5倍规划网络层清洗能力，按业务峰值QPS的5到10倍规划业务层清洗能力。这个倍数看起来夸张，但复合攻击的流量往往是业务峰值的几十倍，清洗能力不足等于没有防护。

冗余设计要覆盖设备、链路、调度三个层面。设备层面至少双机热备，主备切换时间控制在秒级；链路层面多线接入，单线故障不影响整体清洗；调度层面调度中心做集群，避免单点故障。冗余不是简单堆设备，要定期做切换演练，我见过双机热备配置了但切换脚本有bug，真出故障时切不过去的情况。

清洗能力的弹性扩展也要考虑，攻击流量是波动的，固定容量要么浪费要么不够。云清洗的优势就在这里，可以按需弹性扩容，但扩容有延迟，要提前配置好自动扩容策略，触发条件设在容量使用率达到70%时就启动扩容，给扩容留出时间窗口。

3. 实操过程与核心环节实现

3.1 业务基线采集与清洗阈值计算实操

基线采集我一般用两周的数据，第一周观察，第二周验证。采集工具用现成的流量分析平台就行，重点采集前面说的那几个指标。采集时要注意剔除已知的攻击时段和异常时段，否则基线会被污染。

拿到数据后做分位数计算，用P99而不是平均值。计算过程举个例子：某业务一周的入向包速率数据，排序后取第99百分位，假设是60万pps，业务波动系数取1.8，那么基础阈值就是108万pps。这个阈值作为正常状态下的清洗触发线，攻击状态下收紧到70万pps左右。

业务层阈值的计算更细，要分接口算。核心接口比如登录、支付，QPS基线乘以1.5作为限频阈值；普通浏览接口乘以2到3；静态资源接口可以放宽到5倍。分接口算的原因是不同接口的正常访问频率差异很大，统一阈值要么误杀要么漏放。

# 基线数据分位数计算示例（伪代码逻辑） # 读取采集的包速率序列，排序后取P99 sort -n pps_data.txt | awk '{a[NR]=$1} END{print a[int(NR*0.99)]}' # 输出结果乘以波动系数得到基础阈值

阈值下发后要观察至少48小时，重点看误杀率和漏放率。误杀率超过0.1%就要回调阈值，漏放率通过模拟攻击测试来验证。模拟测试用压测工具发小规模攻击流量，看清洗是否按预期触发，这个测试要定期做，不能上线时测一次就完事。

3.2 网络层清洗策略的配置与验证

网络层清洗策略配置分三步：基础防护、协议防护、自定义策略。基础防护开SYN Cookie、畸形包丢弃、IP分片检查这些通用能力，这些能力对正常业务影响极小，可以默认开启。协议防护针对具体协议做限制，比如UDP限速、ICMP限速、TCP连接数限制，这些要按业务实际情况配置，业务不用UDP就把UDP限速设严格，业务依赖UDP就设宽松。

自定义策略是重点，针对已知攻击特征做精准防护。配置时要注意策略顺序，精准策略放前面，通用策略放后面，避免通用策略先匹配导致精准策略失效。策略匹配条件要写清楚，源IP、目的IP、协议、端口、包特征这些维度组合使用。

验证方法是用测试流量逐条验证策略是否生效。测试流量要覆盖正常流量和攻击流量两类，正常流量验证不误杀，攻击流量验证能拦截。验证时看清洗设备的会话日志和丢弃计数，确认策略按预期匹配。我习惯把验证结果整理成表格，每条策略对应验证结论，方便后续复盘。

3.3 业务层清洗规则的编排与灰度上线

业务层规则编排的核心是规则组和优先级。我把规则分成基础规则组、业务规则组、应急规则组三类。基础规则组放通用的频率限制、请求头校验，默认开启；业务规则组按接口定制，跟随业务版本迭代；应急规则组是攻击时临时启用的严格规则，平时关闭避免误杀。

规则优先级从高到低：应急规则、业务规则、基础规则。同一优先级内按匹配精确度排序，精确匹配的在前。规则编排完不能直接全量上线，要走灰度。灰度分两步，先小流量线路灰度，观察误杀和拦截效果；再按业务模块灰度，先非核心模块后核心模块。灰度期间重点看拦截日志，抽样分析被拦截的请求是否真的恶意，发现误杀立即回滚。

灰度周期我一般设3到5天，覆盖一个完整的业务周期。灰度期间规则调整要记录变更日志，包括调整原因、调整内容、观察结果，这些日志是后续优化的依据。

3.4 联动策略的联调与压测验证

联动策略的联调是最费时间的环节，因为涉及两层设备的交互。联调前先把数据同步通道打通，确认指标和信誉数据能双向同步，同步延迟在可接受范围内。然后逐条验证联动策略，比如网络层标记高风险源后，业务层是否在预期时间内对该源触发严格校验。

压测验证用模拟复合攻击的方式，同时发网络层大流量和业务层慢速请求，观察两层清洗是否协同工作。压测要分阶段，先单独压网络层，再单独压业务层，最后混合压，每阶段记录清洗效果和业务影响。混合压测时重点看三个指标：攻击流量拦截率、正常业务成功率、清洗链路延迟。拦截率要高，成功率不能掉，延迟增加要控制在可接受范围。

压测中发现的问题要逐条修复，修复后回归验证。我踩过的坑是联动策略在低流量下正常，高流量下因为同步延迟导致策略不一致，网络层已经放行的流量业务层还在拦截，造成正常用户被误伤。解决办法是给联动策略加超时兜底，同步延迟超过阈值时业务层降级为宽松策略，优先保业务可用。

4. 常见问题与排查技巧实录

4.1 清洗后业务异常但攻击已停止的排查思路

攻击停了业务还没恢复，这种情况很常见，原因往往不是清洗没生效，而是清洗过程中留下的"后遗症"。排查顺序我一般这样走：先看连接状态，大量TIME_WAIT或者CLOSE_WAIT说明连接回收有问题；再看会话表，清洗设备的会话表如果没及时老化，新连接建不起来；最后看业务日志，有没有因为限频或者人机校验导致的正常请求被拒。

连接状态问题多半是清洗设备的会话老化时间设太长，攻击时建立的半连接在攻击停止后还占着资源。解决办法是调短会话老化时间，攻击结束后主动清理异常会话。会话表满的问题要扩容会话表容量，或者优化会话回收逻辑。

业务日志里如果大量出现限频拒绝，说明阈值还没恢复。前面说过阈值恢复要缓慢，但如果恢复太慢，正常业务会持续受影响。我的做法是攻击停止后手动触发一次阈值评估，确认流量确实恢复正常后加速恢复，但加速幅度不超过正常恢复速度的3倍。

提示：攻击停止后不要立即全量放开策略，保留一段观察期，防止攻击者用"打了就跑、跑了再打"的战术反复消耗防护资源。

4.2 误杀正常流量的定位与策略回调

误杀是清洗体系上线后最头疼的问题，定位误杀要看三个地方：清洗设备丢弃日志、业务层拦截日志、业务侧的错误日志。三个日志按时间戳对齐，找到同一请求在哪个环节被拦。

定位到环节后分析拦截原因。网络层误杀常见原因是阈值过严或者策略匹配过宽，比如把某个正常业务的端口误配到了限速策略里。业务层误杀常见原因是规则组合过严，比如频率限制叠加请求头校验，正常用户偶尔触发其中一个就被拦。还有一种是信誉库误伤，某个IP段因为历史攻击被整体降级，段内正常用户受牵连。

策略回调要精准，不能一误杀就把整条策略关掉。我的做法是调整策略参数而不是关闭策略，比如放宽阈值、缩小匹配范围、增加白名单。调整后观察误杀是否消失，同时确认攻击防护是否还有效。回调要有记录，记录误杀案例、调整内容、调整效果，积累多了能形成误杀特征库，后续配置策略时提前规避。

4.3 复合攻击下清洗链路性能瓶颈的排查

复合攻击时清洗链路本身可能成为瓶颈，表现是清洗设备CPU打满、内存告警、转发延迟飙升。排查先从设备资源看起，CPU和内存的使用曲线能反映是哪个环节吃资源。网络层清洗吃CPU多，业务层清洗吃内存多，分开看能快速定位。

资源瓶颈的常见原因是检测规则过多或者会话表过大。规则过多要精简，把长期不触发的规则下线，把可以合并的规则合并。会话表过大要优化老化策略，缩短空闲会话的老化时间。还有一种情况是日志写入拖垮性能，攻击时日志量暴增，同步写日志会阻塞转发，解决办法是日志异步化，用缓冲队列削峰。

链路瓶颈还要看层间转发，网络层到业务层的转发如果走了多次NAT或者隧道封装，延迟会增加。优化方法是简化转发路径，能直连的不走隧道，必须走隧道的优化封装效率。压测时我一般会记录各环节的延迟基线，攻击时对比基线找异常环节。

4.4 清洗体系日常运维的检查清单

日常运维不能等出问题才动手，要建检查清单定期巡检。我整理的清单包括：清洗设备资源使用率、会话表使用率、策略命中情况、信誉库更新情况、联动同步延迟、误杀告警、业务成功率。每项设阈值，超阈值告警。

巡检频率我设的是每日快检加每周深检。每日快检看资源使用率和告警，五分钟能完成；每周深检看策略效果和信誉库质量，抽样分析拦截日志，评估策略是否需要优化。每月做一次模拟攻击测试，验证清洗能力是否还达标。

检查清单要随业务变化更新，新上线的业务要补充对应的检查项，下线的业务要清理相关策略。我见过检查清单几年不更新的情况，里面全是已下线业务的检查项，真正需要关注的反而没有，这种清单不如没有。

5. 个人实操体会与后续优化方向

这套混合清洗体系落地下来，我最大的体会是"联动"两个字说起来简单做起来难。设备买回来配置好只是开始，真正花时间的是两层之间的策略对齐、数据同步、故障兜底。很多团队把预算花在买设备上，却在联调和运维上投入不足，结果设备能力发挥不出来，复合攻击一来还是手忙脚乱。

另一个体会是阈值和策略没有一劳永逸的配置，业务在变、攻击手法在变，防护策略必须持续迭代。我现在的做法是每月做一次策略复盘，看拦截数据、误杀数据、攻击趋势，该调的调该加的加。复盘不用搞得很复杂，一两个小时把关键指标过一遍，比出了问题再救火强得多。

后续优化我关注两个方向。一是清洗决策的智能化，现在阈值和策略还是人工配置为主，未来想引入基于历史数据的自动调参，减少人工干预。二是清洗能力的下沉，把部分轻量清洗能力放到更靠近业务的位置，减少层间转发延迟。这两个方向都还在摸索，有进展再分享。