漏洞攻击和流量攻击同时打过来，本质上是在测试防御体系的“短板效应”。漏洞攻击负责穿透，流量攻击负责压制，两者叠加时，最危险的不是单点被打穿，而是安全团队在流量洪峰中根本看不清漏洞利用的痕迹。真正有效的防护不是把两类攻击分开处理，而是建立一套能在高压下保持可见性、并能自动收敛攻击面的联动机制。
先解决一个核心问题：流量攻击会“淹没”漏洞攻击的告警。大流量DDoS打过来时，IDS/IPS、WAF日志量会暴涨，安全运营人员很难从海量告警里分辨出哪一条是真实的漏洞利用。所以第一步要做的不是堆设备，而是做“告警降噪”和“流量清洗前置”。在流量进入业务系统之前，先在运营商侧或云清洗中心完成DDoS流量过滤，只把清洗后的“干净流量”回注到业务网络。这样WAF和IDS看到的流量已经大幅减少，漏洞攻击的特征才有机会暴露出来。
流量清洗不能只靠阈值触发，要结合业务基线。很多攻击者会使用“慢速DDoS”配合漏洞利用，流量并不大，但连接数异常。比如Slowloris攻击配合某个Web漏洞的利用，单看带宽可能只有几十Mbps，但连接数可能达到几十万。因此清洗策略必须同时监控带宽、PPS、新建连接数、并发连接数四个维度，并且针对业务特点设置不同的基线。比如API服务的新建连接数通常远高于静态页面服务，如果用一个统一阈值，要么误杀正常业务，要么漏掉攻击。
漏洞攻击的防护核心是“收敛攻击面”。攻击者发起漏洞攻击前，通常会先做资产测绘和指纹识别。如果业务系统暴露了不必要的端口、服务、管理后台，攻击者就能找到更多突破口。防护的第一步是关闭所有非必要端口，尤其是数据库端口、SSH端口、远程桌面端口，这些端口不应该对公网开放。管理后台要加IP白名单，或者通过堡垒机访问。很多实战案例中，攻击者并不是通过0day打进来的，而是通过一个没打补丁的旧版本组件或者一个暴露在公网的管理后台。
WAF策略在攻击叠加时需要切换到“严格模式”。正常情况下，WAF为了减少误报，很多规则可能设置为“仅告警”或“宽松匹配”。但在遭受攻击时，应该把核心业务域名的WAF策略切换为“拦截模式”，并且开启“虚拟补丁”功能。虚拟补丁是针对已知漏洞的临时防护规则，不需要等厂商发布正式补丁，就能在WAF层阻断漏洞利用流量。比如某个中间件爆出远程代码执行漏洞，厂商补丁还没打上，WAF可以先用虚拟补丁拦截对应的攻击特征。
这里有一个容易被忽视的点：WAF本身也可能成为瓶颈。大流量攻击时，WAF如果性能不足，反而会成为单点故障。所以WAF部署要考虑“旁路检测+串联阻断”的混合模式，或者使用硬件WAF配合软件WAF做分层。对于HTTPS流量，WAF需要解密检测，这会消耗大量CPU资源。攻击者如果同时发起大量HTTPS请求，WAF可能因为解密压力过大而宕机。解决办法是在WAF前面加一层SSL卸载设备，或者使用支持硬件加速的WAF。
漏洞攻击的另一个重要防线是“运行时应用自我保护”（RASP）。RASP不同于WAF，它不依赖流量特征，而是嵌入在应用运行时内部，监控应用的行为。当攻击者利用漏洞执行恶意代码、读取敏感文件、调用系统命令时，RASP能直接拦截。在流量攻击叠加的场景下，RASP的价值更大，因为即使WAF被绕过或者被流量压垮，RASP仍然能在应用内部提供最后一道防线。不过RASP对应用性能有影响，需要针对核心业务做性能测试后再上线。
联动防御是应对叠加攻击的关键。很多企业的WAF、IDS、抗DDoS设备是各自独立的，告警不互通。攻击者用DDoS吸引注意力，同时用漏洞攻击渗透，如果设备之间不联动，安全人员可能只看到DDoS告警，忽略了漏洞攻击。应该建立一套“统一安全编排与自动化响应”（SOAR）机制，让抗DDoS设备检测到攻击时，自动通知WAF切换到严格模式，同时通知防火墙收紧访问控制策略，并通知安全人员重点关注漏洞攻击告警。这种自动化联动能把响应时间从小时级缩短到分钟级。
日志分析在攻击叠加时尤其重要。攻击者利用漏洞时，往往会在Web访问日志、系统日志、数据库日志中留下痕迹。比如一个SQL注入攻击，可能在Web日志中看到异常的SQL语句，在数据库日志中看到异常的查询操作。安全人员需要提前准备好日志分析工具，能够快速检索和关联分析。推荐使用ELK（Elasticsearch、Logstash、Kibana）或者类似的日志平台，把WAF日志、Web服务器日志、数据库日志、系统日志集中收集。攻击发生时，通过关键字检索和关联分析，快速定位漏洞利用的路径和影响范围。
针对漏洞攻击，补丁管理是根本。很多企业因为业务连续性要求，不能及时打补丁，这就给攻击者留下了时间窗口。在攻击叠加的场景下，攻击者往往会利用那些公开时间较长、但企业未修补的漏洞。所以补丁管理要建立“分级响应”机制：对于高危漏洞，必须在24小时内完成评估和修补；对于中危漏洞，在一周内完成；对于低危漏洞，一个月内完成。如果确实无法打补丁，必须用WAF虚拟补丁、RASP规则、网络隔离等手段做临时防护。
网络层的访问控制也要在攻击时收紧。正常情况下，为了业务方便，防火墙可能开放了较多端口和IP段。攻击发生时，应该临时收紧策略，只允许业务必需的端口和来源IP访问。比如一个电商网站，正常情况下可能允许所有IP访问80和443端口，攻击时可以临时封锁来自特定国家或地区的IP段，或者只允许CDN节点回源。这种“最小化访问”策略能显著减少攻击面。
对于流量攻击，除了依赖云清洗中心和运营商清洗，企业自身也要有“本地缓解”能力。因为有些攻击流量可能不经过云端清洗，或者清洗后仍有残留流量。本地抗DDoS设备可以处理小规模的攻击流量，同时配合防火墙做限速和连接数限制。比如针对SYN Flood，可以在防火墙上开启SYN Cookie防护；针对UDP Flood，可以在边界路由器上做限速和丢弃策略。这些本地缓解措施能减轻云端清洗的压力，也能在云端清洗延迟时提供缓冲。
还有一个常被忽略的环节：DNS防护。很多业务系统依赖DNS解析，如果DNS服务器被攻击，即使业务服务器正常，用户也无法访问。攻击者可能会同时攻击DNS服务器和业务服务器，形成“双杀”。所以DNS服务要使用高可用的DNS方案，比如多运营商DNS、DNS云解析服务，并且配置合理的TTL值，减少DNS解析失败的影响。同时，DNS服务器本身也要有抗DDoS能力，防止被查询洪水打垮。
业务层面的“降级”和“限流”也是应对叠加攻击的有效手段。当攻击流量过大，业务系统无法承受时，可以启动“降级”策略，关闭非核心功能，只保留核心交易流程。比如一个社交平台，在攻击时可以关闭图片上传、视频播放等非核心功能，只保留文字消息和登录功能。同时，对API接口做限流，防止攻击者通过API接口消耗服务器资源。限流策略要基于用户、IP、设备等多个维度，不能一刀切，否则会影响正常用户体验。
安全团队的“战时响应流程”必须提前演练。很多企业在遭受叠加攻击时手忙脚乱，不是因为技术不行，而是因为流程不清晰。应该提前制定“安全事件响应预案”，明确攻击发生时谁负责流量清洗、谁负责漏洞分析、谁负责业务恢复、谁负责对外沟通。预案中要包含“升级路径”：什么情况下需要通知CTO、什么情况下需要通知CEO、什么情况下需要联系外部安全公司。平时要定期演练，确保每个角色都清楚自己的职责。
最后强调一点：防护不是一次性的，而是持续的过程。攻击者会不断变换手法，漏洞也在不断被发现。安全团队需要建立“持续监测、持续评估、持续优化”的机制。每次攻击结束后，都要做复盘分析，找出防护中的薄弱环节，更新防护策略。同时，要关注安全社区的漏洞情报，及时获取最新的漏洞信息和攻击手法。只有把防护做成一个动态的、自适应的体系，才能在漏洞攻击和流量攻击叠加的复杂场景下，真正守住业务安全。
