网站安全WAF搭配DDoS防护构建完整防护体系

网站安全从来不是单点防御能解决的问题，WAF（Web应用防火墙）和DDoS防护经常被混为一谈，但两者处理的是完全不同的攻击层面。WAF主要针对应用层，拦截SQL注入、XSS跨站脚本、命令执行、恶意爬虫和业务逻辑漏洞利用；DDoS防护则处理流量型攻击，比如SYN Flood、UDP Flood、CC攻击造成的带宽耗尽或服务器资源耗尽。很多站点只部署了WAF，结果被大流量DDoS直接打挂；也有站点只买了DDoS高防，应用层被注入拖库却毫无察觉。真正有效的做法是把WAF放在应用入口做精细过滤，把DDoS防护放在网络层做流量清洗，两者串联形成纵深防御。

WAF的核心能力是解析HTTP/HTTPS请求内容，理解URL参数、请求头、Cookie、请求体中的语义，再根据规则或行为模型判断是否为攻击。它能看到“某个参数里带了union select”，也能识别“某个接口被高频调用且参数异常”。但WAF本身通常部署在源站前面，如果攻击流量大到把WAF所在节点的带宽占满，或者把WAF进程的连接数耗尽，WAF自己就先不可用了。DDoS防护则相反，它不关心请求内容是什么，只关心流量特征：包速率、连接速率、源IP分布、协议异常、流量模型偏离基线。DDoS防护设备或高防机房会把攻击流量引流到清洗中心，过滤掉畸形包和洪水流量，再把正常流量回注到源站。

一个常见的误解是“CC攻击就是DDoS，WAF管不了”。实际上CC攻击是应用层DDoS，它模拟真实用户请求，不断访问某些高消耗页面或接口，导致服务器CPU、内存、数据库连接耗尽。这类攻击流量在带宽上可能并不大，传统基于包速率的DDoS设备很难识别，但WAF结合频率控制、人机识别和访问行为分析可以较好地缓解。所以CC攻击恰恰是WAF和DDoS防护需要协同的典型场景。

构建完整防护体系的第一步是梳理流量路径。假设你的架构是：用户 -> DNS解析 -> CDN/高防IP -> 负载均衡 -> WAF -> 源站。这个顺序意味着DDoS清洗发生在最外层，WAF在清洗之后、源站之前。高防IP或高防机房负责扛住海量流量，WAF负责精细过滤应用层攻击。如果顺序反过来，WAF暴露在最外层，大流量DDoS会直接把WAF打挂，后面的高防IP形同虚设。

对于没有使用CDN或高防IP的场景，也可以在本机或边界防火墙上做基础限速和协议异常过滤，再把WAF部署在反向代理层。比如Nginx作为流量入口，先通过limit_req模块限制单IP请求速率，再通过ModSecurity或OpenResty的WAF模块做应用层检测。这种方式成本低，但抗DDoS能力有限，适合流量规模较小或对可用性要求不那么极端的业务。

很多WAF产品自带大量通用规则，比如OWASP CRS（核心规则集）。但默认规则直接上线往往误报率很高，尤其是针对国内业务常见的JSON接口、文件上传、富文本提交等场景。正确做法是先以检测模式运行，收集一段时间内的告警日志，分析哪些规则触发了真实攻击，哪些是业务正常行为被误判。然后针对误报规则做白名单或降级处理，对真实攻击规则保持拦截模式。

WAF策略至少需要覆盖几个层面：一是协议合规性检查，比如请求方法是否合法、Content-Length是否与实际一致、URL编码是否规范；二是特征匹配，针对已知漏洞利用payload做正则或语义检测；三是行为分析，比如同一IP在短时间内请求大量不同URL、同一会话频繁修改参数、访问路径明显不符合正常用户浏览逻辑；四是业务逻辑防护，比如注册接口被批量调用、短信验证码接口被恶意触发、支付回调参数被篡改。最后一项往往需要结合业务定制，通用WAF很难覆盖。

对于API接口较多的业务，建议启用WAF的API防护功能，或者使用专门的API安全网关。传统WAF对JSON和XML的解析能力有限，很多攻击payload藏在嵌套JSON结构中，默认规则无法识别。API防护需要理解接口的Schema定义，对参数类型、长度、取值范围做严格校验，同时监控异常调用模式，比如某个API的响应时间突然变长、某个参数的值分布发生明显变化。

DDoS攻击大致可以分为带宽消耗型和资源消耗型。带宽消耗型包括UDP Flood、ICMP Flood、SYN Flood、反射放大攻击（NTP、DNS、Memcached反射），这类攻击的特点是流量巨大，动辄几十G甚至上百G，目标是把入口带宽占满。资源消耗型包括SYN Flood耗尽连接表、Slowloris慢速连接耗尽并发数、CC攻击耗尽应用资源。选型时要先分析自己业务历史上遭遇的攻击类型和峰值流量。

如果是带宽消耗型攻击为主，必须依赖运营商或高防机房的大带宽清洗能力。自建清洗设备在百G级别攻击面前基本没有意义，因为本地接入带宽可能只有1G或10G。高防IP方案通过BGP牵引把攻击流量引到清洗中心，利用清洗中心数百G甚至T级别的带宽进行过滤。选择高防服务时要关注几个指标：清洗时延、回源质量、是否支持HTTPS加密流量清洗、是否提供攻击溯源报告。

如果是资源消耗型攻击为主，尤其是CC攻击，DDoS防护设备需要具备应用层识别能力。很多高防服务商提供“CC防护”功能，本质是在清洗节点上做频率限制、人机验证、IP信誉库过滤。但这类功能与WAF的CC防护有重叠，需要明确分工：高防节点上的CC防护负责拦截明显异常的流量，比如单IP每秒请求超过阈值、User-Agent缺失或异常、来源IP属于已知攻击源；WAF上的CC防护负责更精细的行为分析，比如针对特定URL的访问频率、会话级别的访问序列异常、验证码绕过检测。

单独部署两个设备或服务还不够，关键是让它们之间形成联动。一个典型的联动场景是：DDoS防护检测到某个源IP在发起CC攻击，自动将该IP加入黑名单并同步给WAF，WAF在应用层直接拒绝该IP的所有请求，减少后续处理开销。反过来，WAF检测到某个请求包含恶意payload，将源IP上报给DDoS防护平台，DDoS防护在更外层对该IP做限速或封禁，避免攻击流量继续消耗清洗资源。

实现联动通常需要API对接。大多数商业WAF和高防服务都提供RESTful API，可以编程实现自动化的黑名单同步、策略下发和告警通知。比如当WAF检测到某个IP在5分钟内触发了50次SQL注入规则，就调用高防服务的API将该IP加入封禁列表，封禁时长可配置。同时，WAF的告警日志应该接入SIEM或日志分析平台，与DDoS防护的流量日志做关联分析，发现攻击模式的变化趋势。

如果使用开源方案自建，联动可以通过脚本实现。比如在Nginx层面使用fail2ban监控WAF日志，当某个IP触发规则次数超过阈值，自动调用iptables或云防火墙API封禁该IP。对于更复杂的场景，可以使用Redis或消息队列作为黑名单共享存储，WAF和高防清洗节点都从同一个数据源读取黑名单，实现近实时的同步。

很多站点全站启用HTTPS，这给DDoS防护带来额外挑战。传统基于明文流量检测的设备无法解析加密流量，只能看到TLS握手和加密后的数据包。如果攻击者使用HTTPS发起CC攻击，DDoS清洗节点无法区分正常请求和攻击请求，只能根据IP频率和TLS指纹做粗粒度过滤。这时候WAF的作用更加关键，因为WAF通常部署在SSL终结之后，能够解密流量并做深度检测。

解决HTTPS DDoS防护的常见方案是：在高防清洗节点上部署SSL卸载能力，将加密流量解密后做检测，再重新加密回源。但这要求清洗节点持有网站的SSL证书私钥，存在一定的安全风险。另一种方案是使用TLS指纹识别，通过分析ClientHello中的密码套件、扩展字段、椭圆曲线参数等特征，识别出自动化攻击工具和真实浏览器的差异。这种方法不需要解密，但识别精度有限，攻击者可以通过修改TLS指纹来绕过。

更稳妥的做法是结合WAF的会话管理和人机验证。对于可疑的HTTPS请求，WAF可以返回JavaScript挑战或验证码，要求客户端执行计算或完成交互验证。真实浏览器能够自动通过验证，而大多数攻击脚本无法执行JavaScript或处理验证码。这种方法能有效缓解HTTPS CC攻击，但会增加正常用户的访问延迟，需要合理设置验证触发条件。

防护体系不只是设备和规则，还包括日志记录、监控告警和应急响应流程。WAF日志需要记录完整的请求信息，包括源IP、请求时间、请求方法、URL、请求头、请求体（脱敏后）、命中的规则ID、处理动作。DDoS防护日志需要记录攻击类型、峰值流量、包速率、清洗前后流量对比、攻击源IP分布。这些日志不仅是事后溯源的基础，也是优化规则的重要依据。

监控方面，建议对关键指标设置阈值告警：WAF拦截率突增、误报率突增、源站响应时间变长、DDoS清洗流量突增、正常业务流量突降。告警通道要多样化，邮件、短信、即时通讯工具同时通知，避免单点失效。应急响应流程要提前制定，明确谁负责切换高防、谁负责调整WAF规则、谁负责与运营商沟通、谁负责对外沟通。攻击发生时，最忌讳的是临时慌乱，把正常流量也误杀了。

定期做攻防演练也很重要。模拟不同类型的DDoS攻击和应用层攻击，验证防护体系的实际效果。演练过程中记录各个环节的响应时间和处理效果，事后复盘找出薄弱点。很多团队在演练中才发现WAF规则对某些业务接口存在误杀，或者高防切换过程中DNS缓存导致部分用户无法访问。

完整防护体系需要投入成本，包括WAF授权费用、高防服务费用、带宽成本、运维人力成本。对于小型站点，可能只需要云服务商提供的WAF和基础DDoS防护，成本可控。对于中大型站点或频繁遭受攻击的业务，可能需要专业的高防IP、定制化WAF规则、专职安全运维人员。关键是根据业务价值和风险承受能力做合理配置，而不是盲目追求最高规格。

一个实用的建议是：先评估业务中断一小时造成的直接损失和间接损失，再对比不同防护方案的成本。如果业务中断一小时损失数万元，而高防服务每月成本只有几千元，那么投入是值得的。如果业务本身流量很小、收入有限，可以先使用云服务商提供的基础防护，配合开源WAF和脚本化联动，等业务增长后再逐步升级。

最后要强调的是，WAF和DDoS防护不是部署完就一劳永逸。攻击手法不断变化，规则库需要持续更新，策略需要根据业务变化调整，日志需要定期分析。安全是一个持续对抗的过程，防护体系的价值在于让攻击者的成本远高于你的防护成本，而不是追求百分之百的绝对安全。