01-为什么要自研一个WAF

为什么要自研一个 WAF

ShieldWAF 系列文章第一篇，2026-10。四篇的分工：本篇讲清"这是什么、为什么做"；第二篇拆引擎流水线；第三篇讲智能防护（ML）；第四篇讲平台自身的安全与部署。

立项的时候，摆在我们面前的其实有三条路：买商业 WAF（云 WAF 或硬件盒子）、用开源组合（ModSecurity + CRS + 自己写管理脚本）、或者自研。

商业方案的问题不在功能，在于它是黑盒。WAF 是串联在流量主路径上的组件，它出故障就是全站故障。凌晨两点源站 502、流量异常、策略生效延迟——这种时候你需要的是能立刻读代码、打补丁、抓现场，而不是提工单等响应。对一个安全产品来说，"出事时的话语权"比功能列表重要得多。

开源组合的问题是另一半：引擎是好的，管理面要自己拼。规则散在配置文件里，改一条规则没有版本、没有灰度、没有回滚；日志要看、证书要续、多站点要管，最后你会发现一半的精力在写胶水脚本，而且胶水脚本本身没有测试。

所以最后选了第三条路：引擎核心用成熟开源（Coraza），平台自研。CRS 的规则生态和 ModSec 语法有二十年的积累，没必要重造；但检测流水线、策略同步、事件链路、管理台、训练闭环，全部自己写。事后看这个思路是对的——我们后来给引擎加语义检测器、加 ML 评分、加 GraphQL 静态分析，都是因为流水线是自己的，才能在任意两个阶段之间插进新逻辑。

ShieldWAF 是什么

一句话：Go 写的、自带管理平台的反向代理型 WAF。流量打到引擎的 80/443，引擎检测后把"干净"的流量转发给源站；管理台通过控制面 API 配策略、看事件。

四个组成部分：

• waf-engine（数据面）：Coraza v3.8.1 跑 OWASP CRS v4.27.0（300+ 条规则），外面套一条自研检测流水线——TLS 指纹、语义分析、GraphQL 静态分析、黑白名单、限流、Bot 判定、ML 评分。这是第二篇的主角。
• control-plane（控制面）：REST API，模块化单体。应用与源站管理、策略与虚拟补丁、证书与 ACME 自动续期、Bot/API 安全、告警、日志审计、合规报表都在这里。
• admin_web（管理台）：React 18 + TypeScript。智能防护按使用者拆成两个页面，运维看防护总览和事件处置，运维开发看模型管理和训练任务，按钮级权限门控。
• training/（训练器）：独立 Python 进程，吃控制面导出的样本，产出 ONNX 模型回传。这是第三篇的主角。

架构上最想强调的一条设计：数据面和控制面彻底分离，引擎不依赖控制面活着。引擎每 5 秒从控制面增量拉一次策略，落在本地缓存；控制面停机、数据库迁移、甚至整个控制面所在机器宕掉，引擎都按最后一次同步的策略继续防护（黑盒测试里有专门一例关掉控制面打流量）。这是一条单向依赖：引擎只认识控制面的 /v1/sync/*，控制面从不主动连引擎——数据面上报事件和心跳，控制面只负责收。

这条设计来自一个朴素的判断：WAF 挂掉比没有 WAF 更糟，因为流量已经把它串在主路径上了。所以引擎的每个外部依赖都要能降级：PG 挂了事件落本地文件，Redis 挂了限速退化到进程内实现，规则引擎本身故障时 block 模式 fail-closed（宁可 502 不放行），monitor 模式 fail-open 但强制全量日志加 CRITICAL 告警。

基础设施上的克制

Phase 1 的存储只有 PostgreSQL + Redis。没有 Kafka，没有 Elasticsearch，没有对象存储。

事件存储、全文检索（GIN + tsvector）、按月分区、审计日志（append-only + SHA-256 哈希链）全部压在 PG 里；Redis 扛会话、分布式限速（Lua 令牌桶 + ZSET 滑动窗口）、nonce 防重放、JS 挑战状态。

这么选不是偷懒，是算过账的：消息队列和 ES 是为"事件量超过单库写入能力"或"检索复杂到 SQL 写不动"准备的，我们还没到那个量级。先保证一台 4 核机器就能 docker compose 起全套、一条 deploy.py 命令部署到任意环境，等真有规模压力再引入中间件——届时引入的成本也比一开始就背上要低，因为所有存储访问都收在各自的模块边界内。

一点性能底数

32 核单节点实测（vegeta 恒定到达率压测矩阵）：纯代理处理一个请求 133µs，CRS 全检增量约 57µs；2000 RPS 下 P99，直连 1.1ms、纯代理 3.5ms、开 CRS 6.6ms、全模块开 4.0ms；CRS 开启时饱和吞吐约 8800 RPS。ML 推理的增量 CPU 在噪声以下。

这些数字怎么来的、以及三场热路径优化硬仗，在第二篇里展开。

不是说完爆谁

ModSecurity 的规则生态、雷池的语义引擎、各家云 WAF 的威胁情报，都有值得反复学习的地方——事实上我们对标雷池白皮书的那轮差距分析，直接催生了现在的 52 维语义特征和 ML 融合方案。自研的意义从来不是"别人做得不好"，而是：每一行行为都可解释、可修改、可审计，并且管理面和数据面可以为同一个场景一起演进。

后面三篇：

• 一个请求在引擎里经历了什么 —— 流水线、决策融合、热路径优化
• 把机器学习塞进 WAF，最难的不是模型 —— 特征契约、训练闭环、上线纪律
• WAF 自己不能是短板 —— 管理面安全、AI 智能体的边界、部署与事故复盘