尧图网站建设 
1. 甲方边界安全为什么“WAF防火墙抗DDoS”必须联合部署做了这么多年安全运维我越来越觉得边界安全不是单点产品的堆砌而是一套需要联动、分层、有主次的防御体系。很多甲方同学一开始会问“我们已经有防火墙了为什么还要上WAF上了WAF是不是就能防住所有攻击”这个问题其实代表了大多数人对边界安全的误解。先说结论防火墙、WAF、抗DDoS这三类产品各自解决的是不同层面的问题它们不是替代关系而是上下游的协同关系。防火墙管的是网络层和端口级别的访问控制相当于小区门口的保安看进出的人是否持有有效证件WAF管的是应用层的请求内容相当于小区楼栋的专属管家检查你带来的包裹里有没有夹带违禁品抗DDoS管的是流量洪峰相当于小区门口的交通疏导员当一大群陌生人同时涌向门口时他要负责把车流拆散、过滤、限流保证真正的住户还能正常进出。这三者缺一不可。防火墙挡不住应用层SQL注入因为SQL注入是通过80/443端口合法进入的WAF挡不住流量型攻击因为WAF本身的处理能力是有限的大流量一来先被打死抗DDoS设备只能清洗流量但无法对精细化的应用攻击做规则匹配。所以联合防护是唯一靠谱的路线而不是什么“可选优化项”。这篇落地复盘就是结合我实际参与过的甲方边界安全项目把架构设计、设备选型、策略配置、日志溯源、问题排查这些环节全部串起来讲一遍。无论你是刚接手企业安全的甲方工程师还是正在做等保整改的运维负责人这篇内容都值得你对照着自己环境里的拓扑走一遍。2. 边界安全核心需求拆解我们需要防住的到底是什么2.1 从一次真实攻击事件看边界防御的盲区之前我们处理过一个客户的真实事件业务域名被黑产盯上先是狂打流量型DDoS把出口带宽打满业务直接瘫痪等我们启用云清洗把流量压下去之后攻击者又换成了CC攻击专门打查询接口再往后居然还在某个上传接口尝试用畸形报文打WAF的绕过。整个过程中如果只靠防火墙第一个小时就全部沦陷了如果只靠WAF在DDoS阶段WAF就已经无法响应了。这就是为什么一定要联合部署——每一层都只能解决自己职责范围内的问题缺一层就多一个被击穿的点。从这个案例可以提炼出甲方边界安全的三个核心需求第一网络层必须能快速阻断恶意流量源不管是IP封禁还是限速都要能秒级生效。第二应用层必须能精细化识别攻击载荷尤其是针对Web业务的SQL注入、XSS、命令执行、文件上传绕过等。第三在遭遇大流量冲击时必须有一套独立的清洗通道保证正常业务流量不中断同时把攻击流量引流到清洗节点上去。这三条需求对应的产品形态很清晰防火墙负责第一层WAF负责第二层抗DDoS系统负责第三层。但真正落地的时候细节远比“各上一台设备”复杂得多比如串接还是旁路、透明模式还是路由模式、规则要不要同步、日志要不要汇总这些都会直接决定防护效果。2.2 三种设备的职责边界与配合关系我画过无数遍这个配合逻辑大概可以用一句话概括抗DDoS守流量入口防火墙守网络通道WAF守应用出入口。抗DDoS设备或者云清洗服务部署在最外侧它要识别的是超过基线的流量异常例如SYN Flood、UDP Flood、ICMP Flood这类纯流量型攻击。它不关心请求内容是GET还是POST也不关心URI是什么只关心“数量”和“特征”。当流量异常时它触发清洗策略把攻击流量丢弃或限速把正常流量放行给后端防火墙。防火墙部署在抗DDoS之后负责网络层和传输层的访问控制包括IP白名单、端口限制、协议过滤、会话状态检查等。防火墙可以根据源IP、目的IP、源端口、目的端口、协议类型做精细的规则匹配还能做一些基础的威胁情报封禁例如把已知恶意IP的整个网段直接拒绝掉。但防火墙不理解HTTP协议内部的语义所以它没法判断一个POST请求的body里是不是含有恶意SQL语句。WAF部署在防火墙之后、业务服务器之前串联或旁路均可但生产环境我强烈建议串联至少是代理模式。WAF能解析HTTP/HTTPS协议做解码、归一化、规则匹配识别应用层攻击还能对异常User-Agent、高频访问、特定URI的访问行为做频控和封禁。它既是规则引擎也是行为分析引擎。所以整体数据流向是用户请求先经过抗DDoS清洗再到防火墙过滤最后到WAF做应用层检测然后才转发到源站。任何一个环节出了问题后面都能兜住一部分但别指望某一层能包办所有事。2.3 边界安全方案选型背后的几个关键考量很多甲方在做方案选型时喜欢拿各家的产品参数表对比我这里想说的是参数只是一个方面真正决定成败的反而是项目前期没写在参数表里的几个点。一个是部署模式。串联部署会引入网络延迟和单点故障虽然现在的硬件设备都有BYPASS口但你要考虑BYPASS了之后防护是不是就失效了。旁路部署不影响业务链路但拦截能力会受限尤其是WAF旁路模式下很难做到实时阻断只能做告警和重置连接。所以除非合规需求只要求检测能力否则生产业务必须有串联或代理接入。另一个是高可用设计。三层设备串联之后任何一台出现宕机都会导致业务中断。所以每一层都需要考虑主备、负载、链路冗余。我们之前做的一期项目中WAF直接以集群方式接入两台WAF做负载均衡一台挂了另外一台自动接管防火墙做VRRP热备抗DDoS通过DNS调度或BGP引流实现双线路冗余。还有一个是策略协同。三层设备的规则不能各自为政至少要做两级联动封禁联动和日志关联。当WAF检测到某个IP在短时间内发起大量恶意请求时WAF应该能联动防火墙临时封禁该IP一段时间当抗DDoS系统识别到某个IP在发起流量攻击时也应该能下发规则到防火墙做持久封禁。这条联动链路如果做不起来联合防护就还是“三台孤立设备”只能算物理上的串联不是逻辑上的联合。3. 核心细节解析WAF、防火墙、抗DDoS各自的落地要点3.1 WAF落地的关键规则调优、HTTPS解密与误报平衡WAF是三层防线里最容易让甲方头疼的一环因为它的误报会直接干扰正常业务。默认规则库都偏严刚上线时往往会把一些正常的参数例如包含“select”“union”等关键字的内容给拦掉。所以生产环境上WAF不能直接开全量拦截我一般的做法是先旁路观察一周把日志拉出来看有哪些正常请求被误报再把误报规则关掉或者改成“仅告警不拦截”然后再切到串联或代理模式做真实阻断。HTTPS解密是WAF落地的重点和难点。如果不做SSL卸载或解密WAF只能看到加密流量规则完全失效。所以WAF必须能导入证书私钥做SSL termination看到明文之后再重新加密回源。这个操作在合规和运维上比较敏感很多公司明文存储私钥这一关就过不了。折中方案是使用镜像流量旁路解密但实时阻断能力又受限。我的建议是核心业务必须做全解密私钥用硬件加密机或KMS托管访问权限做最小化审计留痕这样既能发挥WAF的功效又能扛住安全审计的质询。WAF常见的几类规则配置包括SQL注入防护规则、XSS防护规则、命令注入规则、文件包含规则、上传检测规则、CC频控规则这些都要根据业务实际做微调。比如业务本身就是一个互联网公开的知识库里面必然会有搜索关键词包含“php”“sql”等字符串那SQL注入规则里的某些payload匹配就该改成带更多上下文条件的检测避免一刀切误杀。另外WAF的CC频控一定要加“会话维度”和“IP维度”的双重检测只按IP频控很容易伤到NAT出口下的正常用户。比如一个学校出口就是一个公网IP几百个学生同时访问按IP限10次每秒正常用户全被限制了。所以频控阈值必须结合业务模型设置并且支持白名单放行。3.2 防火墙落地关键区域隔离、最小权限与策略生命周期防火墙这块我见过太多甲方在Web防火墙和传统防火墙之间犯迷糊。传统防火墙NGFW管的是网络隔离和访问控制Web防火墙WAF管的是Web攻击检测两者千万别混为一谈。在边界安全场景下传统防火墙至少要做好三件事区域隔离、端口最小化、出站管控。区域隔离是说把网络划分成不同安全域例如外网区、DMZ区、内网区、管理区每个区域之间通过防火墙做策略互访控制。不要因为业务麻烦就给所有区域打全通策略那样防火墙等于形同虚设。最小权限原则具体到端口上就是只放行业务必须的端口其他一律拒绝包括常用的远程管理端口必须限制源IP别把3389、22暴露到全互联网。出站管控经常被忽略。很多甲方只关心外面进不来不关心里面出不去结果主机失陷后攻击者从出站连接下载恶意工具、外传数据防火墙根本没有告警。所以出站策略至少要限制HTTP/HTTPS外联只允许通过代理或放到指定服务器其他高危端口如SSH、Telnet、数据库端口一律禁止出站。之前我们处理过一个勒索病毒事件就是因为一台失陷服务器可以直接访问外网445端口结果内网横向传播。出站管控这种事儿说起来简单真正落地的时候总会有人嫌麻烦但你不做出事是早晚的。防火墙策略的生命周期管理也值得单独提一嘴。线上设备跑了几年之后策略表会膨胀到几百上千条其中大量都是“以前临时放行后来忘了放行的”。这些僵尸策略不仅带来安全隐患还会增加排查耗时。所以至少每个季度要做一次策略梳理把每一条策略的申请时间、申请原因、上线人、关联业务都记清楚没有对应审批记录的策略一律回收。这个小习惯在后续排障和等保测评中会受益良多。3.3 抗DDoS落地关键清洗能力、调度方式与防护基线抗DDoS要分两个层面看硬件设备层面和云清洗层面。如果客户有自建机房且带宽规模不大可以串接部署抗DDoS硬件设备例如市场上常见的旁路部署加BGP引流。如果客户业务在云上直接用云服务商提供的高防IP或流量清洗服务即可。这里我结合本地实践把硬件的玩法说透。硬件抗DDoS设备通常有两种工作模式串联模式和旁路模式。串联模式适合防护能力完全覆盖出口带宽的场景所有流量先过清洗设备由设备直接决定丢弃或放行。这种模式实现简单但当流量超出设备处理能力时设备本身会成为瓶颈。旁路模式更适合大带宽场景设备不做流量转发而是通过交换机做端口镜像或BGP引流把可疑流量引导到清洗设备上进行检测清洗再通过策略路由或BGP发布正常路由回到原链路。旁路模式对设备性能要求相对低但对网络规划和路由调度的要求更高。关于防护基线这是很多甲方最容易拍脑袋的地方。防护基线包括正常业务QPS、正常带宽占用、正常请求来源地域分布、常见UA比例等。以带宽为例如果业务高峰期平均带宽是200Mbps那么触发清洗的阈值可以设置在300Mbps左右如果平时只有20Mbps阈值可以直接设在100Mbps。阈值设置太灵敏容易误触发清洗导致正常用户被丢包设置太迟钝攻击流量上来时设备还没动作业务已经挂了。还有一个细节是流量调度切换。很多采用DNS调度高防IP的客户一旦遇到攻击需要把域名解析切换到高防IP由高防IP回源到真实服务器。这个过程涉及TTL、回源IP白名单、证书适配等配置。切换时间如果太久攻击期间业务直接中断切换太快可能导致DNS缓存还没失效部分用户已经无法访问。所以提前做好切换预案、在无攻击时进行演练是非常重要的。4. 联合防护的实操体系搭建从拓扑设计到策略下发4.1 网络拓扑架构与设备接入位置我在做这套方案时推荐的最小化拓扑是这样的出口路由器/防火墙 → 抗DDoS清洗设备或云端清洗入口 → 边界防火墙NGFW → 核心交换机 → WAF集群串联或接入 → Web业务服务器。实际部署时抗DDoS设备也可以旁挂在核心交换机上通过BGP引流方式接收镜像流量看具体网络架构而定。串联部署链路中非常重要的是要配置设备互联IP、路由和健康检查。以常见的双机高可用为例两台防火墙之间通过心跳线同步会话状态对外使用VRRP虚拟IP上行连接出口交换机下行连接核心交换机。WAF集群前面通过负载均衡设备分发流量两台WAF之间做会话同步确保一台宕机后另一台能接管全部请求。抗DDoS与防火墙之间的配合通常是由抗DDoS设备识别攻击源IP后通过BGP community或API接口把恶意IP信息同步给防火墙由防火墙在时间窗口内做封禁。拓扑搭建完以后不要急着配置策略我建议先做连通性测试。用ping测链路用telnet或nc测端口连通性用curl测试WAF代理转发后的应用响应是否正常。这个阶段虽然枯燥但能帮你排除掉大量后续排障中的“玄学问题”否则策略一开业务不通你根本分不清是策略误拦还是链路本身有问题。4.2 WAF策略配置与调优实操记录WAF策略配置这块我选了一个经典的可直接照抄的流程。先登录WAF控制台把防护域名添加好配置源站IP和端口HTTPS证书导入后开启SSL卸载。在攻击防护模块里先启用默认的“中等防护”模式包含SQL注入、XSS、CSRF、命令注入、文件上传、恶意爬虫检测等全部先设为“告警”模式不要直接“阻断”。然后我通常会自己构造几个测试请求来做验证比如# 模拟SQL注入测试请求 curl -i -k https://yourdomain.com/user?id1 AND 11-- # 模拟XSS测试请求 curl -i -k https://yourdomain.com/search?kwscriptalert(1)/script # 模拟命令注入测试请求 curl -i -k https://yourdomain.com/download?file;cat /etc/passwd如果WAF配置正常这三个请求应当被拦截返回403或自定义拦截页面。但此时因为还在“告警”模式我会去日志里确认。确认无误后再逐步把高危规则切成“阻断”模式低危的保持“告警”。在上线阻断模式时我建议灰度放行部分IP白名单例如把内部办公网段加为白名单避免办公人员业务受影响才发现误报问题。WAF的频控规则我一般这样设置单IP每秒最多20次请求单IP每分钟最多200次请求超过后触发10分钟封禁。但如果业务有API接口接口的频控阈值通常要单独放开否则正常API轮询都会被误伤。所以WAF配置最重要的一句话规则是死的业务是活的配置前先搞懂业务模型。4.3 防火墙策略分组与下发记录防火墙策略我习惯按业务模块分组每组策略命名带上业务名和编号比如“WEB-APP-001-Allow-Https-To-WebServer”。这样后续排障和变更都清晰。策略下发的基本原则是“白名单优先黑名单兜底”先放行明确允许的业务端口然后在防火墙的“拒绝所有”默认策略之外再增加针对恶意IP的封禁黑名单。封禁黑名单的来源有两个一是人工维护的威胁情报IP二是WAF或抗DDoS联动下发的动态封禁IP。动态封禁可以设置一个“攻击源封禁地址组”WAF通过API把恶意IP加入这个地址组防火墙对地址组立即生效。同时配置一个老化时间例如24小时自动移除避免长期封错。这里有一个很容易踩的坑防火墙策略的“会话状态”配置。如果启用了状态检测那么新连接的建立必须满足状态表的规则。很多业务之所以在防火墙后面访问不通就是因为运维同事只放行了入方向的规则忘记了出方向的回包流量也要被状态检测放行。虽然大部分防火墙默认开启状态检测后会自动放行已有会话的返回流量但遇到严格模式或某些厂商的默认配置不同时就容易出现能发包但不能收包的问题。遇到这种情况优先检查会话表再检查出方向规则比胡乱改入方向策略高效得多。具体下发过程我记录一下在防火墙上创建服务组Web服务组包含80和443端口管理服务组包含SSH(22)、RDP(3389)但管理服务组只允许内部管理网段源IP访问。创建安全策略外网区域到DMZ区域放行Web服务组源地址为any目的地址为Web服务器IP。创建安全策略管理网段到核心设备区域放行管理服务组其他区域禁止访问管理端口。创建默认拒绝策略外网区域到DMZ区域除已放行策略外一律拒绝。全局开启攻击防护功能包括扫描防护、畸形报文检测、IP信誉联动但先设成告警模式观察7天。下发后用防火墙自带的抓包工具或策略命中计数器确认流量走向。比如连续访问业务URL然后去防火墙看“Web服务组放行策略”的命中次数是否在增加如果没有增加说明流量根本没有走到这条策略上来要去查路由或区域划分是不是有问题。4.4 抗DDoS触发清洗与联动封禁的记录抗DDoS这块我以旁路BGP引流为例。设备上线后先做“学习模式”让设备学习正常业务模型的流量特征一般需要学习3到7天。学习结束后根据历史流量数据设置防护基线。例如正常带宽200Mbps峰值QPS 1500则将带宽清洗阈值设为350MbpsQPS清洗阈值设为3000。一定要留足冗余不要卡的太死。当攻击发生时流量达到阈值设备自动触发清洗从攻击流量中识别出攻击包特征和攻击源IP。此时有两种处置第一直接丢弃攻击流量第二把攻击源IP加入临时黑名单并联动防火墙执行封禁。联动封禁需要提前配置好SNMP或syslog或API对接。我们当时的实现是通过设备API将带日期的黑名单IP列表推送到防火墙的地址组防火墙每隔5分钟拉取一次更新保证联动延时不超过5分钟。5分钟看上去不短但足以防止大流量攻击持续消耗带宽因为清洗设备本身还在持续拦截联动只是为了后续长效封禁。实战记录里有一次我们的清洗设备触发了清洗但用户反馈业务仍然卡顿。排查发现清洗策略把攻击流量识别为UDP小包并做了丢弃但攻击流量其实是混合型的还有大量TCP连接耗尽了源站连接数。所以这里就体现出了“联合防护”的重要性清洗设备只能处理网络层攻击针对TCP慢速攻击和CC攻击必须要靠WAF的频控和防火墙的并发连接限制来配合。于是我在防火墙上对业务服务器设置了最大连接数限制并启用了SYN Cookie功能同时WAF开启CC防护这才彻底解决了卡顿问题。5. 日志溯源与长期监控方案攻击过后怎么复盘5.1 基于syslog汇总的三层日志联动分析联合防护体系搭建完成后最重要的不是设备策略而是日志。每一层设备的日志应该统一汇总到日志审计平台或自建的日志中心例如用syslog或CEF格式发送到SIEM。至少保留90天以上满足合规要求的同时也便于溯源。日志格式尽量做字段标准化包括时间戳、源IP、目的IP、源端口、目的端口、协议、动作、威胁名称、规则ID、请求URL、User-Agent等。不要只保存默认的设备日志要让WAF把HTTP全量访问日志也发出来否则攻击发生时你只能看到一个IP看不到它具体请求了什么内容溯源就无从谈起。关于溯源我总结过一个标准流程第一在WAF日志里搜目标时间段的拦截记录找到攻击源IP第二在防火墙日志里搜该IP的所有访问记录确认它是否试探过其他端口第三在抗DDoS日志里搜该IP是否出现在流量攻击源列表里第四把该IP放到威胁情报平台查询相关背景第五回到Web服务器日志看看该IP是否已经成功命中过某条请求评估是否失陷。这五步走完基本能还原一个攻击者的完整攻击路径。5.2 长期监控指标与告警阈值建议长期监控不能只盯着防火墙的“安全事件”计数那样太多了没人看。我建议只设几个核心指标业务可用性指标包括WAF代理后端健康检查、Web服务器响应码比例、传输层连通性攻击拦截指标包括WAF拦截次数、防火墙封禁IP数、抗DDoS清洗流量峰值性能指标包括防火墙CPU/内存使用率、WAF新建连接数、WAF吞吐量安全事件指标包括暴力破解尝试次数、0day利用相关规则命中次数、异常地域访问次数。告警阈值可以按实际环境设置我给一个通用参考值具体还需结合业务调整。监控指标参考阈值告警等级WAF单日拦截攻击次数超过1000次中危WAF拦截同源IP频率单IP超过100次/小时高危防火墙CPU使用率连续5分钟超过70%告警抗DDoS清洗触发次数单日超过3次高危Web服务器5xx错误率超过5%并持续10分钟告警新建连接数异常超过正常基线200%高危暴力破解尝试次数单目标IP超过30次/小时中危源IP地理异常非业务地区大量访问不必告警仅记录防火墙策略变更任何变更记录审计事件WAF许可证剩余时间少于30天提醒这些指标建议直接接入告警平台支持电话、短信、邮件等多通道推送。但我特别要说一点告警不要一味的“越多越好”否则案发时全是刷屏真正的高危告警被淹没在无用告警里。所以告警一定要分级比如高危及以上的走电话中危走IM群低危和审计事件只记录不打扰。5.3 长期监控方案中的自动化脚本示例为了减轻工作量可以写一些简单脚本来自动化封禁和生成日报。比如用Shell脚本配合防火墙API每天拉取一次WAF的拦截IP列表自动汇总到CSV文件并生成报表。也可以写一个Python脚本定时检查WAF和防火墙的证书到期时间提前进行续期提醒。这类脚本不复杂但能让运维的活儿轻松不少。这里分享一个简单的Python脚本思路用来定时同步WAF封禁IP到防火墙地址组# 此脚本仅为示例思路实际API接口以各家设备为准 import requests import time # 从WAF获取攻击源IP列表 waf_api_url https://waf.management.local/api/v1/attack_ips headers {Authorization: Bearer YOUR_TOKEN} resp requests.get(waf_api_url, headersheaders, timeout10) attack_ips resp.json().get(data, []) # 推送到防火墙地址组 fw_api_url https://firewall.management.local/api/v1/address_groups/blocklist payload {ip_list: attack_ips, overwrite: False} fw_resp requests.post(fw_api_url, jsonpayload, headersheaders, timeout10) print(f同步完成本次封禁IP数量: {len(attack_ips)})实际生产环境里这段代码的API地址和认证方式要根据设备厂商的接口文档调整。但思路是通用的获取威胁情报 → 写入封禁名单 → 设置有效期 → 自动清理过期名单。手动封禁管理员可以参考这个思路落地成自动化平台或脚本能大幅缩短攻击响应时间。6. 常见问题与排查技巧实录那些年踩过的坑6.1 WAF误拦正常业务怎么办WAF误拦是高频问题比如业务提交的数据里包含“ WAF+防火墙+抗DDoS联合防护：甲方边界安全落地方案复盘
1. 甲方边界安全为什么“WAF防火墙抗DDoS”必须联合部署做了这么多年安全运维我越来越觉得边界安全不是单点产品的堆砌而是一套需要联动、分层、有主次的防御体系。很多甲方同学一开始会问“我们已经有防火墙了为什么还要上WAF上了WAF是不是就能防住所有攻击”这个问题其实代表了大多数人对边界安全的误解。先说结论防火墙、WAF、抗DDoS这三类产品各自解决的是不同层面的问题它们不是替代关系而是上下游的协同关系。防火墙管的是网络层和端口级别的访问控制相当于小区门口的保安看进出的人是否持有有效证件WAF管的是应用层的请求内容相当于小区楼栋的专属管家检查你带来的包裹里有没有夹带违禁品抗DDoS管的是流量洪峰相当于小区门口的交通疏导员当一大群陌生人同时涌向门口时他要负责把车流拆散、过滤、限流保证真正的住户还能正常进出。这三者缺一不可。防火墙挡不住应用层SQL注入因为SQL注入是通过80/443端口合法进入的WAF挡不住流量型攻击因为WAF本身的处理能力是有限的大流量一来先被打死抗DDoS设备只能清洗流量但无法对精细化的应用攻击做规则匹配。所以联合防护是唯一靠谱的路线而不是什么“可选优化项”。这篇落地复盘就是结合我实际参与过的甲方边界安全项目把架构设计、设备选型、策略配置、日志溯源、问题排查这些环节全部串起来讲一遍。无论你是刚接手企业安全的甲方工程师还是正在做等保整改的运维负责人这篇内容都值得你对照着自己环境里的拓扑走一遍。2. 边界安全核心需求拆解我们需要防住的到底是什么2.1 从一次真实攻击事件看边界防御的盲区之前我们处理过一个客户的真实事件业务域名被黑产盯上先是狂打流量型DDoS把出口带宽打满业务直接瘫痪等我们启用云清洗把流量压下去之后攻击者又换成了CC攻击专门打查询接口再往后居然还在某个上传接口尝试用畸形报文打WAF的绕过。整个过程中如果只靠防火墙第一个小时就全部沦陷了如果只靠WAF在DDoS阶段WAF就已经无法响应了。这就是为什么一定要联合部署——每一层都只能解决自己职责范围内的问题缺一层就多一个被击穿的点。从这个案例可以提炼出甲方边界安全的三个核心需求第一网络层必须能快速阻断恶意流量源不管是IP封禁还是限速都要能秒级生效。第二应用层必须能精细化识别攻击载荷尤其是针对Web业务的SQL注入、XSS、命令执行、文件上传绕过等。第三在遭遇大流量冲击时必须有一套独立的清洗通道保证正常业务流量不中断同时把攻击流量引流到清洗节点上去。这三条需求对应的产品形态很清晰防火墙负责第一层WAF负责第二层抗DDoS系统负责第三层。但真正落地的时候细节远比“各上一台设备”复杂得多比如串接还是旁路、透明模式还是路由模式、规则要不要同步、日志要不要汇总这些都会直接决定防护效果。2.2 三种设备的职责边界与配合关系我画过无数遍这个配合逻辑大概可以用一句话概括抗DDoS守流量入口防火墙守网络通道WAF守应用出入口。抗DDoS设备或者云清洗服务部署在最外侧它要识别的是超过基线的流量异常例如SYN Flood、UDP Flood、ICMP Flood这类纯流量型攻击。它不关心请求内容是GET还是POST也不关心URI是什么只关心“数量”和“特征”。当流量异常时它触发清洗策略把攻击流量丢弃或限速把正常流量放行给后端防火墙。防火墙部署在抗DDoS之后负责网络层和传输层的访问控制包括IP白名单、端口限制、协议过滤、会话状态检查等。防火墙可以根据源IP、目的IP、源端口、目的端口、协议类型做精细的规则匹配还能做一些基础的威胁情报封禁例如把已知恶意IP的整个网段直接拒绝掉。但防火墙不理解HTTP协议内部的语义所以它没法判断一个POST请求的body里是不是含有恶意SQL语句。WAF部署在防火墙之后、业务服务器之前串联或旁路均可但生产环境我强烈建议串联至少是代理模式。WAF能解析HTTP/HTTPS协议做解码、归一化、规则匹配识别应用层攻击还能对异常User-Agent、高频访问、特定URI的访问行为做频控和封禁。它既是规则引擎也是行为分析引擎。所以整体数据流向是用户请求先经过抗DDoS清洗再到防火墙过滤最后到WAF做应用层检测然后才转发到源站。任何一个环节出了问题后面都能兜住一部分但别指望某一层能包办所有事。2.3 边界安全方案选型背后的几个关键考量很多甲方在做方案选型时喜欢拿各家的产品参数表对比我这里想说的是参数只是一个方面真正决定成败的反而是项目前期没写在参数表里的几个点。一个是部署模式。串联部署会引入网络延迟和单点故障虽然现在的硬件设备都有BYPASS口但你要考虑BYPASS了之后防护是不是就失效了。旁路部署不影响业务链路但拦截能力会受限尤其是WAF旁路模式下很难做到实时阻断只能做告警和重置连接。所以除非合规需求只要求检测能力否则生产业务必须有串联或代理接入。另一个是高可用设计。三层设备串联之后任何一台出现宕机都会导致业务中断。所以每一层都需要考虑主备、负载、链路冗余。我们之前做的一期项目中WAF直接以集群方式接入两台WAF做负载均衡一台挂了另外一台自动接管防火墙做VRRP热备抗DDoS通过DNS调度或BGP引流实现双线路冗余。还有一个是策略协同。三层设备的规则不能各自为政至少要做两级联动封禁联动和日志关联。当WAF检测到某个IP在短时间内发起大量恶意请求时WAF应该能联动防火墙临时封禁该IP一段时间当抗DDoS系统识别到某个IP在发起流量攻击时也应该能下发规则到防火墙做持久封禁。这条联动链路如果做不起来联合防护就还是“三台孤立设备”只能算物理上的串联不是逻辑上的联合。3. 核心细节解析WAF、防火墙、抗DDoS各自的落地要点3.1 WAF落地的关键规则调优、HTTPS解密与误报平衡WAF是三层防线里最容易让甲方头疼的一环因为它的误报会直接干扰正常业务。默认规则库都偏严刚上线时往往会把一些正常的参数例如包含“select”“union”等关键字的内容给拦掉。所以生产环境上WAF不能直接开全量拦截我一般的做法是先旁路观察一周把日志拉出来看有哪些正常请求被误报再把误报规则关掉或者改成“仅告警不拦截”然后再切到串联或代理模式做真实阻断。HTTPS解密是WAF落地的重点和难点。如果不做SSL卸载或解密WAF只能看到加密流量规则完全失效。所以WAF必须能导入证书私钥做SSL termination看到明文之后再重新加密回源。这个操作在合规和运维上比较敏感很多公司明文存储私钥这一关就过不了。折中方案是使用镜像流量旁路解密但实时阻断能力又受限。我的建议是核心业务必须做全解密私钥用硬件加密机或KMS托管访问权限做最小化审计留痕这样既能发挥WAF的功效又能扛住安全审计的质询。WAF常见的几类规则配置包括SQL注入防护规则、XSS防护规则、命令注入规则、文件包含规则、上传检测规则、CC频控规则这些都要根据业务实际做微调。比如业务本身就是一个互联网公开的知识库里面必然会有搜索关键词包含“php”“sql”等字符串那SQL注入规则里的某些payload匹配就该改成带更多上下文条件的检测避免一刀切误杀。另外WAF的CC频控一定要加“会话维度”和“IP维度”的双重检测只按IP频控很容易伤到NAT出口下的正常用户。比如一个学校出口就是一个公网IP几百个学生同时访问按IP限10次每秒正常用户全被限制了。所以频控阈值必须结合业务模型设置并且支持白名单放行。3.2 防火墙落地关键区域隔离、最小权限与策略生命周期防火墙这块我见过太多甲方在Web防火墙和传统防火墙之间犯迷糊。传统防火墙NGFW管的是网络隔离和访问控制Web防火墙WAF管的是Web攻击检测两者千万别混为一谈。在边界安全场景下传统防火墙至少要做好三件事区域隔离、端口最小化、出站管控。区域隔离是说把网络划分成不同安全域例如外网区、DMZ区、内网区、管理区每个区域之间通过防火墙做策略互访控制。不要因为业务麻烦就给所有区域打全通策略那样防火墙等于形同虚设。最小权限原则具体到端口上就是只放行业务必须的端口其他一律拒绝包括常用的远程管理端口必须限制源IP别把3389、22暴露到全互联网。出站管控经常被忽略。很多甲方只关心外面进不来不关心里面出不去结果主机失陷后攻击者从出站连接下载恶意工具、外传数据防火墙根本没有告警。所以出站策略至少要限制HTTP/HTTPS外联只允许通过代理或放到指定服务器其他高危端口如SSH、Telnet、数据库端口一律禁止出站。之前我们处理过一个勒索病毒事件就是因为一台失陷服务器可以直接访问外网445端口结果内网横向传播。出站管控这种事儿说起来简单真正落地的时候总会有人嫌麻烦但你不做出事是早晚的。防火墙策略的生命周期管理也值得单独提一嘴。线上设备跑了几年之后策略表会膨胀到几百上千条其中大量都是“以前临时放行后来忘了放行的”。这些僵尸策略不仅带来安全隐患还会增加排查耗时。所以至少每个季度要做一次策略梳理把每一条策略的申请时间、申请原因、上线人、关联业务都记清楚没有对应审批记录的策略一律回收。这个小习惯在后续排障和等保测评中会受益良多。3.3 抗DDoS落地关键清洗能力、调度方式与防护基线抗DDoS要分两个层面看硬件设备层面和云清洗层面。如果客户有自建机房且带宽规模不大可以串接部署抗DDoS硬件设备例如市场上常见的旁路部署加BGP引流。如果客户业务在云上直接用云服务商提供的高防IP或流量清洗服务即可。这里我结合本地实践把硬件的玩法说透。硬件抗DDoS设备通常有两种工作模式串联模式和旁路模式。串联模式适合防护能力完全覆盖出口带宽的场景所有流量先过清洗设备由设备直接决定丢弃或放行。这种模式实现简单但当流量超出设备处理能力时设备本身会成为瓶颈。旁路模式更适合大带宽场景设备不做流量转发而是通过交换机做端口镜像或BGP引流把可疑流量引导到清洗设备上进行检测清洗再通过策略路由或BGP发布正常路由回到原链路。旁路模式对设备性能要求相对低但对网络规划和路由调度的要求更高。关于防护基线这是很多甲方最容易拍脑袋的地方。防护基线包括正常业务QPS、正常带宽占用、正常请求来源地域分布、常见UA比例等。以带宽为例如果业务高峰期平均带宽是200Mbps那么触发清洗的阈值可以设置在300Mbps左右如果平时只有20Mbps阈值可以直接设在100Mbps。阈值设置太灵敏容易误触发清洗导致正常用户被丢包设置太迟钝攻击流量上来时设备还没动作业务已经挂了。还有一个细节是流量调度切换。很多采用DNS调度高防IP的客户一旦遇到攻击需要把域名解析切换到高防IP由高防IP回源到真实服务器。这个过程涉及TTL、回源IP白名单、证书适配等配置。切换时间如果太久攻击期间业务直接中断切换太快可能导致DNS缓存还没失效部分用户已经无法访问。所以提前做好切换预案、在无攻击时进行演练是非常重要的。4. 联合防护的实操体系搭建从拓扑设计到策略下发4.1 网络拓扑架构与设备接入位置我在做这套方案时推荐的最小化拓扑是这样的出口路由器/防火墙 → 抗DDoS清洗设备或云端清洗入口 → 边界防火墙NGFW → 核心交换机 → WAF集群串联或接入 → Web业务服务器。实际部署时抗DDoS设备也可以旁挂在核心交换机上通过BGP引流方式接收镜像流量看具体网络架构而定。串联部署链路中非常重要的是要配置设备互联IP、路由和健康检查。以常见的双机高可用为例两台防火墙之间通过心跳线同步会话状态对外使用VRRP虚拟IP上行连接出口交换机下行连接核心交换机。WAF集群前面通过负载均衡设备分发流量两台WAF之间做会话同步确保一台宕机后另一台能接管全部请求。抗DDoS与防火墙之间的配合通常是由抗DDoS设备识别攻击源IP后通过BGP community或API接口把恶意IP信息同步给防火墙由防火墙在时间窗口内做封禁。拓扑搭建完以后不要急着配置策略我建议先做连通性测试。用ping测链路用telnet或nc测端口连通性用curl测试WAF代理转发后的应用响应是否正常。这个阶段虽然枯燥但能帮你排除掉大量后续排障中的“玄学问题”否则策略一开业务不通你根本分不清是策略误拦还是链路本身有问题。4.2 WAF策略配置与调优实操记录WAF策略配置这块我选了一个经典的可直接照抄的流程。先登录WAF控制台把防护域名添加好配置源站IP和端口HTTPS证书导入后开启SSL卸载。在攻击防护模块里先启用默认的“中等防护”模式包含SQL注入、XSS、CSRF、命令注入、文件上传、恶意爬虫检测等全部先设为“告警”模式不要直接“阻断”。然后我通常会自己构造几个测试请求来做验证比如# 模拟SQL注入测试请求 curl -i -k https://yourdomain.com/user?id1 AND 11-- # 模拟XSS测试请求 curl -i -k https://yourdomain.com/search?kwscriptalert(1)/script # 模拟命令注入测试请求 curl -i -k https://yourdomain.com/download?file;cat /etc/passwd如果WAF配置正常这三个请求应当被拦截返回403或自定义拦截页面。但此时因为还在“告警”模式我会去日志里确认。确认无误后再逐步把高危规则切成“阻断”模式低危的保持“告警”。在上线阻断模式时我建议灰度放行部分IP白名单例如把内部办公网段加为白名单避免办公人员业务受影响才发现误报问题。WAF的频控规则我一般这样设置单IP每秒最多20次请求单IP每分钟最多200次请求超过后触发10分钟封禁。但如果业务有API接口接口的频控阈值通常要单独放开否则正常API轮询都会被误伤。所以WAF配置最重要的一句话规则是死的业务是活的配置前先搞懂业务模型。4.3 防火墙策略分组与下发记录防火墙策略我习惯按业务模块分组每组策略命名带上业务名和编号比如“WEB-APP-001-Allow-Https-To-WebServer”。这样后续排障和变更都清晰。策略下发的基本原则是“白名单优先黑名单兜底”先放行明确允许的业务端口然后在防火墙的“拒绝所有”默认策略之外再增加针对恶意IP的封禁黑名单。封禁黑名单的来源有两个一是人工维护的威胁情报IP二是WAF或抗DDoS联动下发的动态封禁IP。动态封禁可以设置一个“攻击源封禁地址组”WAF通过API把恶意IP加入这个地址组防火墙对地址组立即生效。同时配置一个老化时间例如24小时自动移除避免长期封错。这里有一个很容易踩的坑防火墙策略的“会话状态”配置。如果启用了状态检测那么新连接的建立必须满足状态表的规则。很多业务之所以在防火墙后面访问不通就是因为运维同事只放行了入方向的规则忘记了出方向的回包流量也要被状态检测放行。虽然大部分防火墙默认开启状态检测后会自动放行已有会话的返回流量但遇到严格模式或某些厂商的默认配置不同时就容易出现能发包但不能收包的问题。遇到这种情况优先检查会话表再检查出方向规则比胡乱改入方向策略高效得多。具体下发过程我记录一下在防火墙上创建服务组Web服务组包含80和443端口管理服务组包含SSH(22)、RDP(3389)但管理服务组只允许内部管理网段源IP访问。创建安全策略外网区域到DMZ区域放行Web服务组源地址为any目的地址为Web服务器IP。创建安全策略管理网段到核心设备区域放行管理服务组其他区域禁止访问管理端口。创建默认拒绝策略外网区域到DMZ区域除已放行策略外一律拒绝。全局开启攻击防护功能包括扫描防护、畸形报文检测、IP信誉联动但先设成告警模式观察7天。下发后用防火墙自带的抓包工具或策略命中计数器确认流量走向。比如连续访问业务URL然后去防火墙看“Web服务组放行策略”的命中次数是否在增加如果没有增加说明流量根本没有走到这条策略上来要去查路由或区域划分是不是有问题。4.4 抗DDoS触发清洗与联动封禁的记录抗DDoS这块我以旁路BGP引流为例。设备上线后先做“学习模式”让设备学习正常业务模型的流量特征一般需要学习3到7天。学习结束后根据历史流量数据设置防护基线。例如正常带宽200Mbps峰值QPS 1500则将带宽清洗阈值设为350MbpsQPS清洗阈值设为3000。一定要留足冗余不要卡的太死。当攻击发生时流量达到阈值设备自动触发清洗从攻击流量中识别出攻击包特征和攻击源IP。此时有两种处置第一直接丢弃攻击流量第二把攻击源IP加入临时黑名单并联动防火墙执行封禁。联动封禁需要提前配置好SNMP或syslog或API对接。我们当时的实现是通过设备API将带日期的黑名单IP列表推送到防火墙的地址组防火墙每隔5分钟拉取一次更新保证联动延时不超过5分钟。5分钟看上去不短但足以防止大流量攻击持续消耗带宽因为清洗设备本身还在持续拦截联动只是为了后续长效封禁。实战记录里有一次我们的清洗设备触发了清洗但用户反馈业务仍然卡顿。排查发现清洗策略把攻击流量识别为UDP小包并做了丢弃但攻击流量其实是混合型的还有大量TCP连接耗尽了源站连接数。所以这里就体现出了“联合防护”的重要性清洗设备只能处理网络层攻击针对TCP慢速攻击和CC攻击必须要靠WAF的频控和防火墙的并发连接限制来配合。于是我在防火墙上对业务服务器设置了最大连接数限制并启用了SYN Cookie功能同时WAF开启CC防护这才彻底解决了卡顿问题。5. 日志溯源与长期监控方案攻击过后怎么复盘5.1 基于syslog汇总的三层日志联动分析联合防护体系搭建完成后最重要的不是设备策略而是日志。每一层设备的日志应该统一汇总到日志审计平台或自建的日志中心例如用syslog或CEF格式发送到SIEM。至少保留90天以上满足合规要求的同时也便于溯源。日志格式尽量做字段标准化包括时间戳、源IP、目的IP、源端口、目的端口、协议、动作、威胁名称、规则ID、请求URL、User-Agent等。不要只保存默认的设备日志要让WAF把HTTP全量访问日志也发出来否则攻击发生时你只能看到一个IP看不到它具体请求了什么内容溯源就无从谈起。关于溯源我总结过一个标准流程第一在WAF日志里搜目标时间段的拦截记录找到攻击源IP第二在防火墙日志里搜该IP的所有访问记录确认它是否试探过其他端口第三在抗DDoS日志里搜该IP是否出现在流量攻击源列表里第四把该IP放到威胁情报平台查询相关背景第五回到Web服务器日志看看该IP是否已经成功命中过某条请求评估是否失陷。这五步走完基本能还原一个攻击者的完整攻击路径。5.2 长期监控指标与告警阈值建议长期监控不能只盯着防火墙的“安全事件”计数那样太多了没人看。我建议只设几个核心指标业务可用性指标包括WAF代理后端健康检查、Web服务器响应码比例、传输层连通性攻击拦截指标包括WAF拦截次数、防火墙封禁IP数、抗DDoS清洗流量峰值性能指标包括防火墙CPU/内存使用率、WAF新建连接数、WAF吞吐量安全事件指标包括暴力破解尝试次数、0day利用相关规则命中次数、异常地域访问次数。告警阈值可以按实际环境设置我给一个通用参考值具体还需结合业务调整。监控指标参考阈值告警等级WAF单日拦截攻击次数超过1000次中危WAF拦截同源IP频率单IP超过100次/小时高危防火墙CPU使用率连续5分钟超过70%告警抗DDoS清洗触发次数单日超过3次高危Web服务器5xx错误率超过5%并持续10分钟告警新建连接数异常超过正常基线200%高危暴力破解尝试次数单目标IP超过30次/小时中危源IP地理异常非业务地区大量访问不必告警仅记录防火墙策略变更任何变更记录审计事件WAF许可证剩余时间少于30天提醒这些指标建议直接接入告警平台支持电话、短信、邮件等多通道推送。但我特别要说一点告警不要一味的“越多越好”否则案发时全是刷屏真正的高危告警被淹没在无用告警里。所以告警一定要分级比如高危及以上的走电话中危走IM群低危和审计事件只记录不打扰。5.3 长期监控方案中的自动化脚本示例为了减轻工作量可以写一些简单脚本来自动化封禁和生成日报。比如用Shell脚本配合防火墙API每天拉取一次WAF的拦截IP列表自动汇总到CSV文件并生成报表。也可以写一个Python脚本定时检查WAF和防火墙的证书到期时间提前进行续期提醒。这类脚本不复杂但能让运维的活儿轻松不少。这里分享一个简单的Python脚本思路用来定时同步WAF封禁IP到防火墙地址组# 此脚本仅为示例思路实际API接口以各家设备为准 import requests import time # 从WAF获取攻击源IP列表 waf_api_url https://waf.management.local/api/v1/attack_ips headers {Authorization: Bearer YOUR_TOKEN} resp requests.get(waf_api_url, headersheaders, timeout10) attack_ips resp.json().get(data, []) # 推送到防火墙地址组 fw_api_url https://firewall.management.local/api/v1/address_groups/blocklist payload {ip_list: attack_ips, overwrite: False} fw_resp requests.post(fw_api_url, jsonpayload, headersheaders, timeout10) print(f同步完成本次封禁IP数量: {len(attack_ips)})实际生产环境里这段代码的API地址和认证方式要根据设备厂商的接口文档调整。但思路是通用的获取威胁情报 → 写入封禁名单 → 设置有效期 → 自动清理过期名单。手动封禁管理员可以参考这个思路落地成自动化平台或脚本能大幅缩短攻击响应时间。6. 常见问题与排查技巧实录那些年踩过的坑6.1 WAF误拦正常业务怎么办WAF误拦是高频问题比如业务提交的数据里包含“