蓝易云CDN：【架构实战】WAF Web应用防火墙：攻防一线的规则设计

WAF规则设计真正难的地方，不是“能不能拦住攻击”，而是能否在高并发环境下准确识别风险，同时尽量不影响正常业务。

在真实生产环境中，攻击流量和正常流量往往非常接近。一次SQL注入、XSS、命令注入或路径穿越请求，可能只是在某个参数中多了几个特殊字符。如果规则设计过于宽泛，就容易误拦；如果规则过松，又可能留下绕过空间。因此，成熟WAF通常不会依赖单一正则，而是采用多层判断架构。

一、第一层：协议与请求结构检测

请求进入蓝易云CDN节点后，首先应检查HTTP请求本身是否符合正常协议结构，包括：

• 请求方法是否合法
• Header结构是否异常
• Content-Type是否与请求内容一致
• URI长度是否异常
• 参数数量是否异常
• 请求体大小是否异常
• 编码方式是否存在明显异常

这一层不需要进行复杂语义计算，主要用于快速过滤协议异常、畸形请求以及明显扫描流量。⚙️

这样可以减少后续深度分析的压力。

二、第二层：规则与特征检测

传统WAF规则仍然非常重要。

针对SQL注入、XSS、文件包含、命令注入、路径穿越等已知攻击类型，可以利用规则快速识别明显特征。

但规则设计必须避免简单的“关键词即攻击”。

例如请求参数中出现：

select

并不能直接说明存在SQL注入，因为某些搜索、数据库管理或开发类业务本身可能包含该字符串。

更合理的方式是同时分析：

关键字 + 运算符 + 参数位置 + 编码状态 + 上下文结构

只有多个条件组合后形成明显攻击特征，才提高风险等级。

三、第三层：语义判断攻击意图

这是蓝易云语义WAF与传统规则防火墙的重要区别。

传统规则更像是在问：

“这个请求有没有危险字符？”

语义分析则进一步判断：

“这些字符组合起来是不是正在执行攻击行为？”

例如同样出现脚本、数据库关键字或者系统命令，不同URI、不同参数位置、不同请求方法，其风险程度完全不同。

因此可以结合：

URI、Query参数、POST数据、Header、Cookie、请求方法、Payload结构以及上下文关系进行综合分析。🛡️

对于经过编码、字符拆分、参数嵌套等方式构造的复杂请求，这种判断方式比单纯依赖正则更加灵活。

四、第四层：行为与客户端特征

单个请求正常，并不代表整个访问行为正常。

例如某个IP每秒持续访问：

/login

每次提交的数据格式都合法，传统WAF可能不会认为它存在问题，但连续高频访问已经具有明显异常特征。

因此实际防护还应该结合：

请求频率、URI访问规律、状态码变化、客户端特征、TLS指纹以及JA4等信号。

这样才能把“请求内容安全”与“访问行为安全”结合起来。

五、规则设计必须支持分级处理

生产环境中不建议所有规则命中以后立即封禁。

可以根据风险程度进行分级：

低风险：记录日志
中风险：观察、限速或验证
高风险：直接拦截

蓝易云WAF采用禁用、观察、防护等状态，本质上就是为了给规则上线和业务调优留下缓冲空间。

新规则上线时先观察命中情况，再根据日志确认真实攻击与正常业务的比例，最后进入正式防护，是更加稳妥的做法。

六、误报处理必须缩小范围

WAF最忌讳“一误报就整站加白”。

假设：

/api/order/create

某个JSON参数触发检测，应该分析具体触发的是哪一个字段、哪一类规则。

理想处理方式是：

指定域名 + 指定URI + 指定条件 + 指定规则例外

而不是关闭整个网站的安全检测。

白名单范围越精确，防护体系留下的空白区域就越小。🔐

七、一线WAF规则设计的核心原则

真正成熟的WAF，不应该追求“规则数量最多”。

规则越多，如果没有良好的优先级、解析机制和上下文判断，反而可能带来更高CPU消耗、更复杂的维护成本和更多误报。

更合理的架构是：

基础规则负责快速过滤，语义分析负责复杂判断，行为检测负责发现异常访问，CC策略负责限制高频请求，高防体系负责处理更大规模的流量风险。

对于蓝易云CDN来说，将CDN加速、DDoS防护、CC防护、规则引擎与语义WAF放在统一链路中，核心价值就在于可以从网络流量到Web请求逐层判断。

最终衡量一套WAF是否优秀，不应只看“今天拦截了多少次”，而应该看三个指标：

攻击有没有拦住、正常业务有没有误伤、开启防护以后网站是否依旧稳定。

这才是攻防一线真正有价值的WAF规则设计。🛡️