内容摘要：WAF防火墙的设置，核心就一句话：别指望开箱即用，默认配置挡不住任何有脑子的攻击者。我见过太多人装完WAF就当甩手掌柜，结果被绕得干干净净。 先讲最基础的接入方式。WAF要挡在用户和源站之间，要么改D

WAF防火墙的火墙设置，核心就一句话：别指望开箱即用，设置默认配置挡不住任何有脑子的火墙攻击者。我见过太多人装完WAF就当甩手掌柜，设置结果被绕得干干净净。火墙

先讲最基础的设置接入方式。WAF要挡在用户和源站之间，火墙要么改DNS把流量引过来，设置要么在负载均衡前面串一层。火墙改DNS省事，设置但有个坑——你得确认WAF厂商的火墙节点够多，不然用户跨省访问慢得想骂娘。设置串在架构里更灵活，火墙能拿到真实IP，设置但需要你对自己的火墙拓扑门儿清，别把WAF串到数据库前面去了，那叫行为艺术。

接入之后，第一件事不是调规则，是确认“学习模式”开着。让WAF先观察一周正常流量，把业务基线摸清楚。这时候别急着拦截，它会把所有请求都记下来，包括那些POST参数里的奇怪字符。我就见过有人一上来就开严格模式，结果自己的后台管理页面被当成SQL注入给拦了，运维半夜打电话骂娘。

学习期过了，再开“防护模式”，但默认规则集必须改。默认规则是给所有行业用的通用货，对你这种具体业务来说，误报率能到3%就是烧高香。把跟业务无关的规则组直接关掉——比如你是个纯API服务，那“文件上传防护”规则组就是摆设，留着只会让正常文件上传卡成PPT。

接下来是重头戏：自定义规则。这里有个反直觉的建议——别急着写复杂正则，先写几个简单粗暴的。比如你的登录接口，直接限制单IP每分钟最多请求10次，超过就拉黑15分钟。这招比任何语义分析都管用，暴力破解在你这儿直接哑火。再比如，所有请求头里如果同时出现“X-Forwarded-For”和“Client-IP”，直接拦——正常浏览器不会同时带这两个头，那是扫描器在试你后端信哪个。

规则里有个细节容易被忽略：大小写和编码绕过。攻击者把“select”写成“SeLeCt”，或者把“union”做一次URL编码再二次编码，默认规则经常看走眼。你得在自定义规则里加一步：把请求体先做一次标准化解码，再匹配关键词。别问为什么，问就是上周刚帮人排查了一个连续被绕过的案例，攻击者就靠把“alert(1)”拆成“alert(1)”就穿过去了。

日志必须开着，而且得接出去，别存在WAF本地。本地日志一满就覆盖，出了事连个毛都查不到。我习惯把WAF的访问日志和拦截日志都同步到独立的日志系统里，保留至少90天。然后每周花十分钟扫一眼拦截日志里的Top攻击源IP——如果某个IP连续三天都在尝试同一个漏洞路径，那基本可以断定是定向攻击，不是广撒网扫描，这时候就得考虑封IP段或者加验证码了。

最后说个很多人不知道的：WAF的“紧急模式”按钮，平时别开。那个模式会直接放行所有拿不准的请求，只拦那些百分百确定的攻击。听起来安全，实际上等于告诉攻击者“拿不准的都能试”。真遇到大流量攻击，正确做法是直接切到“完全拦截”加“JS挑战”，让所有访问者先跑一段JavaScript验证，能通过的才放进来。这招对DDoS有效，但对业务的影响也大，所以平时得演练过，别等到被打的时候才第一次按那个按钮。

设置完了不代表完事。WAF规则和业务代码一样，得定期review。每季度翻一次拦截日志，把那些被误杀的合法请求捞出来，加白名单或者调规则。同时关注厂商的规则更新公告——别用了一年半载还停在初始版本，新出的漏洞利用方式你一个都挡不住。这东西就是个动态博弈，你懒一天，攻击者就多赚一天。