★ FEATURED ARTICLE 甲方采购了WAF、防火墙、抗DDoS设备但三层防御没有真正联动起来边界安全形同虚设。这是我近几年在多个甲方安全建设项目中反复看到的通病——设备堆了一堆厂商各自交付部署时各接各的网线策略各写各的规则真遇到攻击时要么被大流量打穿要么被封禁策略互相冲突要么误封正常用户还得靠人工慢慢捞。这篇文章我想用一套真正落地过的方案把WAF、防火墙、抗DDoS设备的联合防护体系讲透各自承担什么职责、网络拓扑上怎么串、策略上怎么联动、上线时怎么灰度切换而不是一刀切以及那些只有实际踩过坑才会知道的设计细节。这套方案是我在某企业边界安全改造项目中完整推过一遍的覆盖了一个典型甲方的核心诉求在不改变现网架构的前提下把三层安全设备从各自为战变成协同作战。如果你正在做等保整改、边界架构升级或者刚采购完安全设备但不知道如何编排联动这篇内容可以直接当设计参考用。1. 三个设备各管一摊职责分层是联合防护的前提很多甲方上来就问这三台设备是不是功能重叠了这是个好问题。WAF、防火墙、抗DDoS设备确实都具备一定的过滤能力但它们处理的攻击类型、工作的协议层级、性能消耗模式完全不同。没有搞清楚这个前提后面所有联动设计都是空中楼阁。1.1 抗DDoS设备先保链路和机房不被打瘫抗DDoS设备或者叫流量清洗设备工作在网络的入口侧核心目的是在攻击流量进入业务链路之前就把脏流量洗掉。它的防护对象是超大流量的网络层攻击典型如SYN Flood、UDP Flood、ICMP Flood、DNS Query Flood这些能直接打满带宽或者耗尽会话表的类型。我见过一个最容易犯的错误以为买了抗DDoS设备就不需要防火墙做状态检测了。实际上这是两类不同性质的过滤——抗DDoS设备关注的是流量规模和报文特征它不关心你的业务逻辑防火墙关注的是连接状态和访问关系它也不负责清洗大流量。一个形象的比喻是抗DDoS设备是大门外的保安遇到一群人冲过来先把明显闹事的拦下防火墙是大堂的闸机每个人都要验票才能进WAF是柜台前的业务专员专门识别那些证件伪造得特别像的坏人。1.2 WAF盯着应用层协议细节WAFWeb应用防火墙工作在四到七层解析HTTP/HTTPS协议内容检测SQL注入、XSS跨站脚本、命令注入、文件包含、CC攻击这类应用层威胁。它的强项是精细的协议解析和规则匹配弱项是处理超大流量的能力远不如抗DDoS设备。这里有个核心认知WAF不是你把它往链路里一插就能防住所有Web攻击的它的检测效果高度依赖三个东西——你是否有正确的Web业务流量镜像、是否配置了合理的检测策略模板、是否对HTTPS流量做了证书卸载或解密。我后面会专门讲证书卸载这个坑这里先记住WAF看不见的流量等于不存在。1.3 防火墙四层会话控制与安全域隔离防火墙在整个体系中承担的是白名单和会话管理职责。它不关心请求里是不是带了SQL注入payload也不关心流量速率是不是异常它管的是谁允许访问谁、什么端口允许通、连接状态是否合法。在联合防护设计里防火墙还有一个容易被忽视的角色——它是整个边界链路的会话锚点。所有经过边界进出的连接最终都要由防火墙来维护会话状态。如果防火墙的会话表被攻击流量打爆那即使WAF和抗DDoS设备都正常工作正常用户也进不来。所以联合防护的容量设计必须考虑最弱一环而防火墙往往是那个最弱一环。2. 部署拓扑怎么排串联还是旁路各自放在哪个位置设备职责清楚了接下来是落地时最关键的决策拓扑怎么排。这个决定直接影响了链路可用性、故障切换复杂度和策略配置方式。我直接把两套主流拓扑方案摆出来对比。2.1 主流拓扑一抗DDoS串联接入WAF与防火墙并联组合这是目前甲方边界最常见的做法运营商链路 → 抗DDoS清洗设备串联 → 核心交换机旁挂WAF或串联WAF → 防火墙串联 → 内网核心关键设计点抗DDoS设备串联在链路最前端保护的是整个边界不只是某一台服务器。这样当发生大流量攻击时清洗设备可以在流量进入防火墙之前就完成丢弃和限速避免后续设备被打瘫。WAF的接入方式有两种选择。对于单臂旁路模式WAF通过交换机镜像流量做检测检测到攻击后发RST或封禁源IP对于串联模式所有Web流量必须穿过WAF延迟增加但拦截能力更强。我在实际项目中倾向串联模式因为旁路模式存在一个天然缺陷——攻击流量本身已经到达了后端服务器WAF的RST报文能否生效取决于源IP的会话状态在CC攻击场景下效果非常不稳定。防火墙串联放在最内侧作为最后一道门槛同时承担安全域隔离和访问控制的职责。它的策略是默认拒绝按业务需求放行这个位置可以最大程度地保证内网安全。2.2 主流拓扑二抗DDoS旁路引流模式对于带宽很大的场景比如10G以上抗DDoS清洗设备如果串联部署设备本身的处理能力可能成为瓶颈。此时可以采用旁路引流模式正常流量直接走原链路当检测设备发现异常流量时通过BGP路由通告或策略路由把流量牵引到清洗设备清洗后再通过隧道或路由回注到原链路。这种模式的优点是正常路径延迟极低、设备故障不影响业务缺点是攻击发生时存在秒级的牵引切换延迟且配置复杂度高。我在实际项目中对带宽5G以下、链路结构单一的场景无脑推荐串联模式可靠性更高、排障也更直观带宽大于10G或者对可用性要求极高的核心链路才考虑旁路引流。2.3 高可用设计不要只在纸上画了两台设备做交付方案时很多设计图画得漂漂亮亮——两台设备做HA链路冗余也画上了。但实际上线时如果忽略下面几个点HA就是个摆设会话同步是否真的生效。防火墙的HA如果只同步了配置没有同步会话表主备切换时所有现有连接全部中断业务侧感知就是一次闪断。切换触发条件要配置合理。我遇到过备机CPU被打高导致频繁切换的情况这属于切换阈值设置不当需要根据实际业务流量模型调整。抗DDoS设备的Bypass功能必须验证。设备故障时要能自动切换到Bypass模式让流量直通否则一台设备宕机整个边界就断了。这个功能一定要在割接窗口做实际断电测试不要只听厂商说支持。3. 三层策略联动让三台设备真正“对话”而不只是串联拓扑搭好了这只是骨架。真正的难点在策略联动——如何让三台设备在攻击发生时像一个整体一样运转而不是各报各的警、各封各的IP。这一章是整套方案的精髓也是我踩过最多坑的地方。3.1 联动设计目标一个攻击从发生到处置的完整流程我先把目标场景描述出来。假设一个典型的Web攻击场景攻击者先对业务系统发起SYN Flood瞬间打满边界带宽正常用户访问开始卡顿。抗DDoS设备检测到流量异常自动启动清洗策略将攻击流量牵引至清洗节点进行丢弃和限速。部分攻击流量特征不够明显穿过了抗DDoS清洗到达WAF。WAF检测到大量来自同一IP段的请求带有明显的扫描特征触发封禁策略。WAF将封禁名单同步到防火墙防火墙在四层直接阻断该IP段的所有连接释放WAF的检测压力。安全运营人员通过统一日志平台看到攻击事件的全链路时间线确认处置结果。这个流程要跑通需要提前做三件事定义联动接口、配置策略阈值、联动动作分级。3.2 策略阈值和响应动作的分级避免“一刀切”误伤策略联动最怕的就是“一有风吹草动就封禁全网”。我见过某甲方把WAF的CC防护阈值调得太低结果大促流量一上来正常用户全被封了IP业务直接被打挂比被攻击还惨。我的建议是联动动作按三个等级设计而不是一个等级走到底。等级触发条件响应动作持续时间观察级单IP请求速率超过正常基线2倍告警通知WAF启动人机验证不封禁持续观察限制级单IP请求速率超过正常基线5倍或命中高危攻击特征WAF封禁该IP 30分钟并同步防火墙限速30分钟阻断级全网流量达到带宽上限的70%抗DDoS设备启动清洗防火墙封禁攻击源IP段1小时需人工确认这个分级设计的关键在于“基线”二字。很多甲方的策略配置失败就是因为没有做正常流量的基线统计。上这套方案之前我建议至少采集两周的正常业务流量数据统计出平均请求速率、峰值请求速率、单IP平均连接数这些指标再把这些指标乘以2、5、10作为触发阈值。3.3 联动方式的选择API同步还是策略下发脚本三台设备之间的封禁名单同步落地时无非两种方式设备厂商提供的API接口同步或者通过安全编排平台SOAR类工具编写剧本自动下发。我在没有预算单独采购安全编排平台的情况下用的是第三种方式——写策略同步脚本。脚本的核心逻辑是WAF检测到攻击事件通过syslog对外发送告警日志。日志服务器上的采集脚本解析WAF告警日志提取攻击源IP、封禁时长、封禁等级。脚本调用防火墙API下发封禁策略封禁来源IP。封禁结束后脚本自动调用防火墙API删除对应策略。同步操作记录写入独立的操作审计表。这套脚本方案虽然不如商业编排平台功能丰富但胜在轻量、可控、不依赖额外采购而且对于大多数甲方来说完全够用。需要注意的坑是API调用必须做失败重试和状态标记否则WAF告警了而防火墙策略没下发成功联动就悄悄失效了。3.4 WAF和防火墙的策略边界谁来封IP谁来封会话联动最容易产生冲突的地方是WAF和防火墙都配置了IP封禁策略但封禁的粒度不同。WAF封IP通常是基于应用层会话维度比如某IP在1分钟内超过100次请求就封禁防火墙封IP是基于网络层会话维度比如某IP在10秒内发起了1000个新建连接。两边如果都按自己的逻辑来就会出现同一个IP被两边重复封禁浪费规则数或者一边封了另一边没封漏防。我的做法是明确划分职责WAF负责应用层的CC攻击和Web攻击封禁防火墙负责网络层的异常连接速率封禁。WAF的封禁名单以API方式同步给防火墙作为防火墙的补充封禁而防火墙自己检测到网络层异常时直接封禁不回传WAF。这样规则不重复也不会互相打架。4. 灰度切换和验证方案上线不是一锤子买卖这套联合防护方案上线最大的风险不是配置写错而是所有设备同时接入链路后对现网业务的影响。我在做这个项目时有一个原则能旁路先旁路能检测先检测能小流量先小流量绝不一步到位直接串进去。4.1 第一阶段旁路监听只读不拦设备到货之后先不急着串进链路。把WAF的检测口和防火墙的镜像口接上所有设备处于旁路监听状态。这个阶段要做的事情是验证设备能正常解析现网流量特别是HTTPS流量能否正常解密这里就需要配置证书卸载。观察设备对正常流量的误报率。WAF的默认规则里往往有很高的误报风险比如某些静态资源请求可能被当成SQL注入、某些正常业务请求被当成爬虫。这个阶段就是用来调规则、调白名单的。生成基于现网流量的检测基线。记录正常状态下的访问速率、连接数、请求分布为后续策略阈值设置提供数据支撑。旁路监听的时间我建议不少于两周至少覆盖一个完整的业务周期比如电商业务至少覆盖一次大促或一次高峰。这段时间不能省后面能少掉很多头发。4.2 第二阶段单设备串联策略从宽松到严格旁路阶段结束后把WAF从旁路切成串联。注意这里是要先串WAF而不是先串抗DDoS设备——因为WAF是三层设备中对业务影响最直接的一台如果WAF的误拦率控制不住后面所有设备都不能上。WAF串联之后检测模式先从“告警”开始观察一周告警量和误报率。确认告警足够准确后再针对高危攻击类型SQL注入、XSS、命令注入开启阻断模式。低危类型可以长期保持告警模式避免正常业务被误伤。这个阶段还有一项重要工作测试WAF的Bypass能力。在业务低峰期人为触发WAF故障或管理口断开验证流量能自动直通而不中断业务。不要信任设备的“理论支持Bypass”要实际测过才放心。4.3 第三阶段全链路串联小流量灰度放行业务三层设备全部串联完成后先切一小部分低价值业务流量比如测试环境、内部系统跑几天确认没有问题再逐步放量。这里的放量不是指把带宽调大而是把防火墙策略中允许访问的目标网段逐步增加。每个阶段切换之后要立刻做三件事验证核心业务可用性从外网访问核心应用确认首页、登录、下单这些主链路功能全部正常。检查设备性能指标CPU、内存、会话表占用率、延迟是否在预期范围内。串联设备多了一层延迟必然增加要确认增加幅度在可接受范围内我通常的要求是新增延迟不超过5ms。观察日志有没有异常告警是否有大量TCP重传、连接重置、超时告警这些往往是链路配置有问题的信号。如果这三个检查项中任何一项不正常必须立刻回退。所以整个灰度切换过程中上一阶段的所有配置都要保留备份随时准备一键回退。我宁可动作慢一点也不接受业务中断。4.4 上线后的第一场实战攻防如何验证方案真的有效设备全部上线后光靠日常观察不足以验证防护能力。建议在业务低峰期和业务方协商后进行一次内部演练。不要攻击真实业务数据在测试环境搭建同样的拓扑模拟以下几种典型攻击对Web服务发起SYN Flood使带宽占用率达到50%以上观察抗DDoS设备是否在阈值触发后清洗流量。用SQL注入工具对测试业务发起SQL注入请求观察WAF是否拦截并触发告警。对登录接口发起高频请求模拟CC攻击观察WAF封禁后封禁名单是否同步到了防火墙。我做过的一次演练里发现SYN Flood触发清洗后部分连接从清洗设备回注到原链路时源IP被改写成了清洗设备的IP导致防火墙的会话状态校验失败正常用户无法建连。这个问题在旁路监听阶段是发现不了的只有在全链路串联并且真实攻击流量经过时才会暴露。这也是为什么上线后必须做真实攻击演练而不是只看配置。5. 落地中最容易踩的五个坑与对应解法最后把我在这个项目里踩过的几个有代表性的坑列出来每个都对应了具体的解决方式。这些都是真实遇到过、并且在排障过程中花了不少时间的写出来帮大家省点弯路。5.1 HTTPS流量没做证书卸载WAF直接“失灵”WAF如果不配置HTTPS解密证书卸载它看到的只是加密的密文流量所有基于payload的检测规则全部失效只剩基于IP和URL的粗粒度防护WAF等于白买。解决方式有两种一是把SSL证书上传到WAF由WAF终结TLS连接然后以明文形式将流量转发给后端服务器后端也是HTTP二是如果合规要求不允许WAF保存私钥则采用镜像解密方式但性能损耗会大不少。我推荐优先使用第一种方案落地简单且检测效果最好。5.2 区域间的MTU问题导致大包被丢弃抗DDoS设备串联部署后部分业务反馈传大文件时经常卡住甚至失败。排查后发现是设备链路的MTU设置不一致运营商侧MTU是1500防火墙接口MTU也是1500但抗DDoS设备的内联口MTU被厂商默认设成了1400导致超过1400字节的报文被静默丢弃。排查这个问题的过程中我用ping大包加DNF标志的方式验证从外网逐步缩小MTU值最终定位到抗DDoS设备的内联口。解决后把全线MTU统一为1500问题消失。这个问题的教训是设备接入后一定要做全链路MTU检查不能只检查接口配置还要用实际大包验证路径上所有设备的报文分片处理能力。5.3 防火墙的会话老化时间与业务长连接不匹配防火墙默认的会话老化时间通常是600秒TCP或30秒UDP。但实际业务里有大量长连接场景比如数据库连接池、WebSocket长连接、消息推送通道。这些连接如果空闲时间超过老化时间就会被防火墙强制清除导致业务偶发性断连。解决方式是在防火墙上针对不同的业务端口配置专属的服务策略需要加长会话超时时间。我的经验值是WebSocket的会话超时时间至少设置3600秒数据库连接池的至少设置14400秒4小时并且要确认这个超时时间小于业务的保活探测间隔否则连接刚被清掉又被业务探测到会表现为反复重连。5.4 内网回源流量绕过WAF检测形同虚设有一个场景很容易被忽略内网某台服务器直接访问另一台服务器的Web接口时如果这个访问流量走的路径不经过WAF那WAF对这些请求完全无感。攻击者如果已经拿下了内网一台低权限机器完全可以利用这个路径进行内网横向攻击而边界的所有防护设备都不会告警。解决方式是推动东西向流量也过防火墙——把内网核心交换机上互访的业务网段策略都串进防火墙让内网到内网的流量也经过检测。这一步涉及对现有内网路由的调整推动起来有一定阻力但从安全角度必须做否则整个边界体系存在明显的绕过点。5.5 设备时间不同步攻击溯源时对不上时间线三台设备如果时间没有同步攻击溯源时你会发现一件很崩溃的事抗DDoS设备显示攻击发生在14:00:00WAF记录的告警是14:00:07防火墙的连接日志是13:59:58。三个时间各差几秒看起来没有大问题但一旦要逐条比对封禁时间、分析攻击路径这几秒的误差就会导致无法准确判断设备之间的联动是否及时生效。解决方式非常简单在所有设备上配置NTP时间同步统一使用同一台时间服务器建议使用内网NTP服务器或指定外部NTP源并做一次时间偏差检查确认所有设备偏差在100ms以内。这个毫不起眼的配置项在事件溯源时能省下大量比对时间。写在最后这套WAF加防火墙加抗DDoS设备的联合防护方案技术门槛并不高核心难点其实是在设计阶段把三层设备的职责、接口、联动逻辑想清楚并且在上线时给足灰度验证和回退空间。对我个人来说做过越多这样的边界安全项目越觉得安全建设不是堆设备而是组织设备之间有序协作。设备是死的策略是活的真正让方案发挥价值的是你对业务的理解和对细节的把控。如果你们也正在做类似的边界防护改造我给一个最低限度的建议先别急着采购或串联拿网络拓扑图先画清楚每个设备的职责边界和联动动作再拿着这份设计去找厂商对参数、对接口文档、对调度逻辑。设计阶段多花一周实施阶段少踩一倍坑。
阅读完成 · 觉得有帮助？
