简介这份PPT面向Web安全工程师、运维人员及安全架构学习者系统梳理WAF从产品形态到架构落地的完整知识脉络帮助读者理解如何为Web应用构建有效的攻击防护体系。内容围绕硬件盒子、软件WAF与云WAF三类产品展开深入讲解云WAF的流量接入方式DNS调度、CNAME、Anycast、HTTP(S)反向代理选型Nginx与OpenResty对比以及安全规则引擎的取舍并对ModSecurity CRS与Naxsi的规则机制、动作配置与参数组做了细致拆解兼顾原理认知与方案选型参考。资源包共1个pptx文件约3.93MB页面结构按产品形态、实施要点、规则引擎、配置实践逐层推进便于按主题检索与课堂讲解。目前已有314人学习适合需要快速建立WAF架构全局认知或准备技术分享的读者使用。1. 从一份 PPT 说起WAF 到底在防什么谁该看上周有个做后端的朋友问我他们业务刚上线就被扫出一堆 SQL 注入告警老板让他“加个 WAF”他第一反应是去搜“WAF 怎么装”。这其实是很多人的真实处境知道 WAF 这个词但说不清它拦的是哪一层、部署在哪、规则怎么落地。这份《WAF 的实现与架构演进》PPT 正好卡在这个缺口上——它不讲空泛的安全理念而是把 WAF 的产品形态、流量接入方式、反向代理选型、规则引擎配置一条线串下来最后落到 OpenResty 上跑一套可配置的规则。适合两类人一是要给自己业务加一层七层防护的后端或运维二是想搞明白云 WAF 背后那套反向代理加规则引擎怎么搭起来的安全初学者。下面我按“先立架构、再动手配规则、最后说坑”的顺序拆一遍能直接抄的部分我都给到参数和代码。2. 三种产品形态与流量接入先想清楚请求怎么走到你面前WAF 的第一道分水岭不是规则写得多好而是流量怎么接进来。PPT 把产品形态分成硬件、软件、云 WAF 三类这个分类背后其实是三种完全不同的流量路径选型时先对号入座后面反向代理和规则引擎才有意义。2.1 硬件、软件、云 WAF 的部署位置差异硬件 WAF 是一台独立设备串行或旁路挂在本地网络出口典型场景是机房里有几十台 Web 服务器、需要统一出口防护。串行部署意味着流量必须穿过它好处是阻断彻底坏处是它挂了业务就断所以实际项目里常见旁路加引流或者串行但做双机热备。软件 WAF 直接装在 Web 服务器上以模块或 agent 形式存在部署成本低但和业务进程抢资源规则误杀时排查也更麻烦。云 WAF 本质是反向代理用户浏览器先连到 WAF 节点节点再回源到真实服务器它天然是“中间人”所以流量接入方式成了它的核心设计点。选型时我一般看三个数QPS 峰值、是否有多机房、能不能接受改 DNS。QPS 上万且多机房云 WAF 的反向代理模型更省事单机房、延迟敏感、不想把证书交给第三方软件 WAF 或自建 OpenResty 更可控。硬件盒子现在更多出现在等保合规场景纯技术选型时它的性价比要打问号。2.2 DNS 调度与 Anycast两种把流量引到 WAF 的路子云 WAF 接入最常用的是 DNS 方式用户把域名 CNAME 到 WAF 厂商给的地址解析结果指向 WAF 边缘节点。PPT 里提到的 DNS 调度指的是按来源 IP、线路、机房负载做解析分流比如北京用户解析到北京节点、联通线路走联通机房。这种做法实现简单但生效依赖 DNS 缓存切换节点时 TTL 没调好会出现一段时间的流量错位这是血泪经验里最常见的一条。Anycast 则是网络层寻址同一个 IP 在多个节点宣告路由协议把用户带到“最近”的节点。它的优点是调度在路由层完成单点故障后流量自动切走不依赖 DNS 解析性能缺点是成本高需要整段 IPBGP 路由优化也复杂。PPT 里点到的代表厂商这里不展开记住结论就行预算充足、全球多节点、要求故障自愈快Anycast 更合适中小规模、想快速上线DNS 加 CNAME 足够。提示CNAME 接入后一定要确认回源地址和证书链很多“WAF 上了但 HTTPS 报错”的问题出在证书没同步到边缘节点而不是规则。3. 反向代理选型Nginx 还是 OpenResty差别在扩展点流量接进来之后WAF 节点本身要做一个七层反向代理。PPT 对比了 Nginx 和另一类代理方案结论偏向 Nginx 系理由是网络模型效率高、模块化、支持 Lua 扩展。这一节把“为什么选 OpenResty”和“扩展点在哪”讲透后面配规则才有落脚处。3.1 为什么是 OpenRestyNginx 加 Lua 的执行阶段原生 Nginx 做 WAF 的短板是规则逻辑要写进 C 模块改一条规则就得重新编译。OpenResty 把 Lua 嵌进 Nginx 的各个执行阶段规则可以用脚本写、热加载这才是它能承载 WAF 规则引擎的前提。PPT 列出的阶段对应关系很关键我按请求生命周期排一下执行阶段典型用途ssl_certificate_by_luaSSL 证书处理动态选证书set_by_lua变量初始化rewrite_by_lua转发、重定向、缓存access_by_lua请求头与参数检查WAF 主战场content_by_lua内容生成header_filter_by_lua响应头过滤body_filter_by_lua响应体过滤防敏感信息泄露log_by_lua异步日志记录WAF 的请求检测基本都放在 access_by_lua因为此时请求头和参数已经解析完、还没转发到后端拦在这里成本最低。响应侧的马脚检测放 body_filter_by_lua但要注意这个阶段数据是分块的跨块匹配需要自己做缓冲这是后面避坑章节要展开的点。3.2 用 OpenResty 搭一个最小可用的检测入口先给一个能跑起来的最小配置把 access 阶段的检测入口留出来规则逻辑后面再填。这段配置的作用是所有请求进 access 阶段先过一遍 Lua 检测函数命中就返回 403不命中放行到后端。# nginx.conf 片段 http { lua_shared_dict waf_cache 10m; # 规则缓存与计数共享内存 init_by_lua_block { -- 启动时加载规则文件避免每请求读盘 local waf require waf.engine waf.load_rules(/etc/openresty/waf/rules.json) } server { listen 443 ssl; server_name example.internal; ssl_certificate /etc/openresty/cert/fullchain.pem; ssl_certificate_key /etc/openresty/cert/privkey.pem; location / { access_by_lua_block { local waf require waf.engine local ok, err waf.check() if not ok then ngx.log(ngx.WARN, waf block: , err) return ngx.exit(403) -- 命中规则直接阻断 end } proxy_pass http://backend_pool; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } }逻辑说明init_by_lua_block在 master 进程启动时执行一次把规则从 JSON 读进内存lua_shared_dict给多 worker 共享计数和缓存用CC 防护的频次统计就靠它。access_by_lua_block里waf.check()返回 false 时直接ngx.exit(403)这是阻断动作最直接的写法。参数上waf_cache的大小按规则条数和并发量估规则几千条、QPS 几千10m 起步够用proxy_pass指向后端池回源地址别写死单机否则 WAF 节点本身成了单点。3.3 规则引擎的两种思路正则匹配与语义分析PPT 把规则引擎分成两派ModSecurity 的 CRS 核心规则集走正则验证覆盖 OWASP Top10 常见威胁规则全但误报要靠调Naxsi 不依赖规则库靠学习正常流量生成白名单对未知威胁有优势但初期学习成本高。实际落地我一般用前者打底、后者补位CRS 负责已知攻击特征语义分析库负责 SQL 注入和 XSS 的变形识别PPT 里提到的 libinjection 和 libhtmlentities 就是干这个的前者做 SQL 词法分析后者做 HTML 实体解码比纯正则抗混淆。选型判断很简单业务参数结构稳定、误报容忍度低先上 CRS 再逐条关规则业务形态多变、攻击面大加一层语义检测兜底。两者都不是“开了就安全”规则要跟着业务参数调这是后面避坑章节反复要说的。4. 规则怎么写动作、变量、操作符与转换函数规则引擎选好之后真正决定拦截效果的是规则本身。PPT 给了一套配置结构包含动作、匹配条件、变量组、解析方式、转换函数和操作函数。这一节把它拆成能直接抄的写法重点讲清楚每个字段改哪里、为什么这么改。4.1 一条规则的完整结构从动作到匹配条件一条规则由动作和若干匹配条件组成多个条件之间是“与”的关系单个条件里的多个变量是“或”的关系。动作决定命中后干什么PASS 跳过当前 phase 的规则DENY 阻断请求ALLOW 跳过所有检查REDIRECT 重定向RESET_CONNECTION 重置连接。生产环境里 DENY 用得最多ALLOW 要慎用一条写错的 ALLOW 可能把整个检测链短路。匹配条件的结构如下这是 PPT 里给出的字段我补上注释说明每个字段的实际含义{ match { { vars { -- 数组多个变量之间是“或” { var ARGS, -- 变量名如 ARGS、REQUEST_URI parse { specific id -- 只取参数 id支持数组 } } }, transform uri_decode, -- 转换函数可多个按顺序执行 operator detect_sqli, -- 操作函数 pattern , -- 操作参数detect_sqli 不需要 op_negated false -- 是否取反默认 false } } }逻辑说明vars里var指定从哪个参数组取值parse决定取这个组的哪部分specific取指定 key、ignore排除 key、keys取所有 key、values取所有 value、all全取这五种只能选一种。transform在匹配前对值做预处理比如先uri_decode再检测能防住 URL 编码绕过。operator是真正的判断函数pattern是它的入参。op_negated为 true 时结果取反适合写“不匹配某特征就放行”的白名单逻辑。4.2 变量组与解析方式取错变量等于没防变量组决定规则看哪里。PPT 列出的常用变量包括 REQUEST_METHOD、URL、REQUEST_URI、ARGS、HTTP_USER_AGENT、HTTP_REFERER、REMOTE_ADDR、REQUEST_HEADERS、RESPONSE_HEADERS、TIME_WDAY 等。这里有个容易翻车的点ARGS 只覆盖查询串和表单体JSON body 里的字段不一定在里面如果业务是 JSON 接口规则要额外解析 body否则攻击者把 payload 塞进 JSON 就绕过了。解析方式的选择直接影响命中率。举个例子检测参数id的 SQL 注入specific id最精准检测所有参数里的 XSS用values true遍历所有值检测请求头里的恶意 UA变量换成 HTTP_USER_AGENT 且不需要 parse。我一般按“先精准后放宽”的顺序调先用 specific 定位高频攻击参数误报可控后再扩到 values一上来就 all 会把正常业务参数也扫一遍误报量很难压。4.3 操作符与转换函数的组合套路操作符是规则的判断核心PPT 列了一长串常用的几类我按场景归一下字符串类有 begins_with、contains、contains_word、ends_with、equal、str_match数值类有 greater、less、greater_eq、less_eq、num_range安全语义类有 detect_sqli、detect_xss、validate_url_encoding网络类有 ip_utils支持单 IP、子网掩码和 IP 段。正则 regex 最灵活但也最慢高频路径上能不用就不用。转换函数负责在判断前“洗数据”PPT 里的 base64_decode、hex_decode、html_decode、sql_hex_decode、remove_comments、remove_whitespace、lowercase、normalise_path 都是抗绕过的关键。典型组合是先remove_comments去掉 SQL 注释符再lowercase统一大小写最后detect_sqli检测。少一步就可能被/*!50000select*/这类写法绕过。下面给一条检测参数注入的规则示例{ action DENY, match { { vars { { var ARGS, parse { values true } } }, transform { remove_comments, lowercase, uri_decode }, operator detect_sqli, pattern }, { vars { { var REQUEST_URI } }, transform { uri_decode }, operator contains, pattern ../ -- 路径穿越特征 } } }逻辑说明这条规则有两个条件第一个扫所有参数值的 SQL 注入第二个扫 URI 里的路径穿越任一条件命中即 DENY。transform写成数组表示按顺序执行先去掉注释再转小写再解码顺序不能乱——先解码再去注释攻击者用编码藏起来的注释符就漏了。pattern对 detect_sqli 为空因为语义检测不需要特征串对 contains 则必须给具体字符串。参数上values true会遍历所有参数QPS 高的接口要评估性能必要时收窄到 specific。5. 避坑与排查规则上线后最容易翻车的五件事规则配完不等于能用上线后真正花时间的是误报和绕过。这一节按“现象 → 原因 → 解决”记五条我踩过的坑都是能直接对号入座的。5.1 业务接口大面积 403日志里全是同一条规则现象规则上线后某个下单接口 403 率飙升日志指向同一条 detect_sqli 规则。原因下单备注字段允许用户输入自由文本里面出现select、order by这类词被语义检测命中。解决对备注类字段单独放行用parse { ignore remark }排除或者给该字段加白名单规则放在 DENY 之前。更稳的做法是先把新规则设成只记录不阻断观察一周误报再切 DENY。5.2 JSON body 里的攻击没被拦住现象安全扫描报告 JSON 接口存在注入但 WAF 日志无记录。原因规则只看了 ARGSJSON body 没解析攻击 payload 在 body 里完全没进检测范围。解决在 access 阶段先读 body 并解析成表把字段并入检测变量注意ngx.req.read_body()要在get_body_data()之前调用且大 body 要设上限否则内存会被打爆。5.3 响应体检测漏报敏感信息照样泄露现象配置了 body_filter_by_lua 检测响应里的手机号但部分响应没拦住。原因响应体是分块到达的单块内匹配不到跨块的敏感串。解决在 body_filter 里做缓冲按 chunk 拼接后再匹配同时设最大缓冲长度防止大文件撑爆内存或者把敏感信息检测前移到后端出口WAF 只做请求侧。5.4 规则热加载后旧规则还在生效现象改了规则文件reload 后行为没变。原因规则在 init_by_lua 里加载进共享内存reload 只重启 workermaster 的 init 不一定重跑旧缓存还在。解决规则加载做成带版本号的接口reload 时比对版本号强制刷新共享字典或者用单独的 admin 接口触发waf.load_rules别依赖 nginx -s reload。5.5 CC 防护把正常用户也限了现象促销活动期间大量正常用户被 503日志显示触发频次限制。原因CC 规则按 IP 计数办公网和运营商 NAT 出口下大量用户共享 IP阈值按单 IP 设得太低。解决计数维度加上 UA、Cookie 或路径做组合阈值按业务峰值调对静态资源路径单独放行别让图片请求也计入频次。注意任何新规则先跑观察模式日志里记命中详情但不阻断确认误报率可接受再切 DENY这一步能省掉大半线上事故。6. 进阶把规则验证做成可回归的流程规则写到一定数量后靠人工点页面验证已经不现实我的习惯是给规则建一套回归用例每次改规则先跑一遍。做法不复杂准备一批正常请求和攻击请求的样本用 OpenResty 的测试框架或者直接起一个本地实例把样本灌进去断言正常请求放行、攻击请求阻断。下面是一个用 resty 命令行跑单条规则验证的写法# 用 resty 直接加载规则引擎喂样本断言结果 resty -I /etc/openresty/lua \ -e local waf require waf.engine waf.load_rules(/etc/openresty/waf/rules.json) local cases { { uri /api/item?id1, expect true }, { uri /api/item?id1%27%20or%20%271%27%3D%271, expect false }, { uri /api/item?name%3Cscript%3Ealert(1)%3C/script%3E, expect false } } for _, c in ipairs(cases) do local ok waf.check_uri(c.uri) assert(ok c.expect, case failed: .. c.uri) end print(all cases passed)逻辑说明resty是 OpenResty 自带的命令行工具能脱离 Nginx 直接跑 Lua 代码适合做规则单测。cases里每条样本带期望结果expect true表示应放行false 表示应阻断assert不通过就报出具体 URI。参数上-I指定 Lua 模块搜索路径规则文件路径和线上保持一致避免测试和线上加载的不是同一份。这套用例积累到几十条后改规则前跑一遍能挡住大部分“改 A 坏 B”的回归问题。再补一个性能观察的习惯规则数量上去后access 阶段的耗时要用ngx.now()打点把每条规则的匹配耗时记进日志定期看哪条规则最慢。正则类规则和 values 遍历是性能大户慢规则要么收窄变量范围要么前移到更便宜的 contains 预筛。我一般要求单请求 WAF 检测耗时控制在 1ms 以内超了就说明规则该优化了。从那以后我每次改规则都强制走一遍“观察模式 → 回归用例 → 灰度切 DENY”这三步再急也不跳。规则是活的业务在变攻击手法也在变没有一劳永逸的配置只有持续验证的习惯。希望帮到你。本文还有配套的精品资源点击获取
