日均处理数亿+次请求，超100万人都在用的国产 WAF

我曾经遭遇到 SQL 注入 这样的问题，也被 CC 攻击 给弄得到服务器都挂掉，还被 爬虫 弄得到服务器都冒烟，这好几个坑我可是都碰到。

干站长这一行当时间久了，最为担忧的，倒还不是流量少。而是某一天服务器的 CPU 忽然就达到了 100%。登录到后台去瞅一瞅，满满的全是陌生的 IP 在疯狂地试探登录接口。那感觉如同半夜里听见有人用钥匙捅你家的锁眼似的。

Web 应用防火墙（WAF） 并非是什么新鲜的事物。可是前些年可供选择的并没有太多。商业版本的一年授权费用 好几万起步，小站长根本承受不了。那开源版本的情况又是如何的，ModSecurity 的规则库维护起来比较麻烦。要是正则表达式写错那么一个字，不是漏掉拦截就是错误地杀掉好多。国产的开源 WAF 在近几年才慢慢有了进展，雷池（SafeLine）就是其中的一个，而且还是挺有名气的那一个。

官方所给出的数据看起来还挺能唬人的。全球装机量超过 100万台，防护的网站超过 一百万个，日均清洗 HTTP 请求超过 数亿+次。这数据里头到底有多少水分，可得好好地去掰扯掰扯。我可不打算弄个简简单单的试用报告随便应付一下，而是把部署的情况、防护的能力、后台的情况，还有很多在文档里没明明白白说出来的问题，一个一个地分开来讲。你能够看到完整的图文，自己去判断一下它到底是不是配得上这么大的体量。

一、简介

首先要把这一点给讲清楚了，要不然会有那么一些人会觉得只要安装上一个网络应用方面的防火墙就能够把所有的问题都给解决掉了。

雷池是一种呈现 反向代理式 特征的 Web 应用防火墙（WAF）。它既不会处于你的应用代码之中，也并非通过对服务器配置进行修改的方式来开展工作。它就搭建在 Web 服务 和 公网 的中间位置。所有进出的流量都必须得先经过它这里。很多恶意的请求在抵达你真实的服务器之前被阻挡下来了。

你能够将它设想成伫立在你网站入口处的保安。访客也就是流量，先抵达保安这儿。保安得去判别你是前来办事的正常用户，还是来搞破坏的坏家伙。正常的就放进去，坏的就留在门外呗。

它开展攻击识别所借助的是 语义分析引擎，并非是依靠去堆砌 正则规则。这二者之间的差别还是比较大的，需要进行展开来详细说一说。

传统的 Web 应用防火墙（WAF），像 ModSecurity 这类，它的实现yuan'li是：预先准备下众多条关于攻击形态的规则。一旦有请求过来就进行对比，查看是否像坏人（即是否符合攻击特征）。但是问题就在于攻击者天天搞出新的花样来，规则库总是处在后面去追赶（攻击手段）。今天拦住了 Union 注入 这种攻击方式，明天人家就用编码的方式来进行绕过，这时候又得手动去添加规则。

雷池的语义解析并非依照那样的路径前行。它在接收到请求之后，得去搞清楚这条请求具体要干什么。是要查询 数据库、要 执行命令，又或者仅仅是翻一下页。在弄清楚意图之后，不管攻击者如何变换模样、如何进行编码，只要目的是相同的，就能够被识别出来。这是两种全然不同的思路。

部署的时候不挑剔环境情况，官方提供了通过 Docker 一键拉起 的这样一种方式，前面还可以连接上 宝塔、1Panel、Nginx 这些东西，不会和现有的架构产生冲突，这对于很多已经有业务在运行着、还不想进行大改动的老站点来说可是很友好的。

二、安装

仅仅依靠官方所说的一条命令是起不到作用的，我在测试的机器上面实际进行了一番操作，把所碰到的很多坑给记录下来。

雷池的标准安装就 一行 Docker 命令（自动编排好各个容器）：

sudo bash -c "$(curl -fsSLk https://waf-ce.chaitin.cn/release/latest/manager.sh)"

在完成访问管理端口的运行之后就可以进入到后台之中。但是真正让人犯难的并不是安装的这个事儿，而是 端口规划。由于它需要去做反向代理，得把原本暴露出来的 Web 端口 给接管过来。你之前 Nginx 所监听着的 80 和 443 得让出来给它，真实的服务得挪动到 内网端口 去。对于仅仅只是负责编写代码的开发者来讲，第一次去配置这一块儿可是容易把自己给弄糊涂。

添加应用这一个步骤是 关键所在。你得填入真实服务的 上游地址，比如 127.0.0.1:8080 这一类的。接着给雷池去分配一个对外的端口。在分配好之后，用户所访问的就是雷池的端口，请求在经过检测之后才会转发给真实服务。

踩坑提醒： 倘若你以往有运用 宝塔 或者 1Panel 来管理 Nginx 的情况，那么就不要让雷池和原来的 Web 服务 去争抢 80/443 端口。正确的做法是：雷池对外使用 80/443，把原来的 Nginx 更改成去监听比如 10080、10443 这类高位端口，之后把 上游 填进去。具体的更改方法我们之前已经拆分了 宝塔 和 1Panel 两套教程，图是比较齐全的，按照它来更改不会出现错误。

把东西装完之后进入到后台当中，第一眼所看到的是 站点管理 的页面。在这个页面之中能够看到每一个被保护着的网站以及它的状态情况，配置得有没有妥当一眼就能够清晰明了。

总体而言，进行部署的门槛并不是十分地高，但是也不是纯粹的新手依照一步一步的方式就可以成功搞定的。对于具备基本运维概念的人而言，半个小时 就可以把相关的事情给办理好。而对于完全没有接触过反向代理的新手来说，建议首先把官方文档当中的 端口说明 给看完之后再去进行操作。

三、实测拦截

在部署工作已经完成之后，最为关键的测试便登场。也就是得去瞧瞧它究竟能不能抵御住真实的 攻击载荷。

官方的文档里面存在着一套 模拟攻击的测试 的方式方法，它的路是比较简单的，就是运用典型的 SQL 注入 以及 XSS 字符串来对自己的测试站点进行攻击，然后看看雷池会反馈回来些什么内容。我依照这样的做法进行了一轮攻击的操作。

攻击的请求被雷池所阻拦住了。返回的是符合标准的 攻击阻断页面。在后台还可以看到完整的详细情况。你留意看下面那一张拦截示例，请求之中有着明显的注入方面的特征。雷池于语义层面将它判定为攻击行为，根本就没有让它去接触后端。

更为有价值的是后台方面的 攻击详情 情况。点开那一条拦截记录，你能够看到攻击的类型，还能够看到命中了哪一条 语义规则，能够看到来源的 IP，能够看到请求的路径，甚至于能够看到完整的请求体，这对于事后的复盘来讲是特别有用处的，你不但知道被攻击，还知道对方采用了什么样的招式。

我特地去做了好几种不同的变形。比如说将空格替换成注释，把关键字的大小写弄成混合着来写。在语义分析这一块，比起 正则规则 那可是更能够经受得住考验，只要意图没有发生改变，变形基本上就没办法躲避过去。当然也不是完完全全百分之百的（这一点在第五节再去讲）。

光自己打自己还不够有说服力，官方还做了一组横向测评，把雷池和 ModSecurity、CloudFlare 放一起比 检出率 和 误报率。严格模式下：

讲一讲数字背后的实际情形：76% 的检出率 表面上看没拦住大多数，但是那是由于测评集涵盖的攻击类型众多，存在不少冷门的变形情况。但在真实的业务当中，绝大多数是常见的攻击手法，雷池对于这些常见攻击手法的拦截率要比 76% 高上许多。真正让我放在心上的是 误报率 0.22% 以及 0.07%。误报对于企业而言比漏报更加让人犯难：你不期望正常的用户点个页面被拦截出去，又或者下单的时候表单被当作攻击给拦截了。在开源方案里面能够把误报压到这个水准的，并不多。

四、四大防护能力逐个拆

除了对 Web 攻击 进行阻拦之外，雷池还存在着其他的功能。在文档之中仅仅是简单地提及了一下。但是在实际进行使用的时候，每一个功能都有着自己各自所具备的要点。我现在来逐一地进行讲述一番。

4.1 限制访问频率

这个功能还是比较有作用的。你可以给某一个接口去设定一个 阈值，比如说 同一个 IP 每秒钟最多来十个请求，要是超过了的话就弹出阻断页面。CC 攻击 简单来说就是大量的请求把你的带宽或者连接数给占据满，频率限制 算得上是第一道关卡。

在实际进行搭配的时候需要留意，阈值可不能够借助感觉来确定。阈值要是太过宽松的话就起不到阻挡的作用，要是太过严格的话正常的用户刷动几下就会被阻拦住。建议先开启 日志 来观察几天真实流量的峰值情况，在那之后再返回过来进行调整。

4.2 人机验证

许多的攻击并不是由人工去进行打击的，而是依靠 自动化工具 来进行批量的扫描。雷池可以在可疑的流量上面弹出 人机验证，真实的人点击一下就能够通过，但是脚本却无法通过。这对于防范扫描器以及阻止垃圾注册是很有功效的。

配合着 安全态势页 当中的 人机验证趋势图，你可以明明白白地看到每一天有数量多少的流量被验证给阻挡在了外面。

4.3 身份认证

我个人认为这是一种被人们所低估了的能力。有不少的网站后台以及管理接口就毫无保留地暴露在公网之上，而且还没有去做鉴权操作，就好像那大门根本就没有锁上似的。那我们是可以在 反向代理那一层 强行再添加一层 登录 的设置，不管后端到底有没有去编写鉴权的相关代码的，外面的人就是进不来。

它所支持的认证方式那可真是不少。有 统一认证、钉钉、企业微信、OIDC、GitHub、微信 PC 扫码、CAS 这些。要是企业内网系统想要接入 钉钉 或者 企微 的账号体系，进行配置的也不费劲。

对开发者团队，用 GitHub 或 OIDC 登录后台也很顺手：

4.4 动态防护

此功能还挺有意味的，是值得单独去瞧一瞧的。当开启了这个功能之后，雷池就会把你页面返回的 HTML/JS 每一次都加密成不一样的模样，用户的浏览器是能够正常去解析它的。而别的人要是想要去扒你的前端源码、接口逻辑的，拿到的就是每一次都不一样的乱码。

防护前的源码是明文，谁都能读：

开了之后，每次访问返回的源码形态都不一样，变成混淆过的乱码：

运用这一招式来 防止抄袭 以及 防止脚本窃取接口，是相当直接的做法。不过它的代价就是每次响应都得多进行一层加解密操作，在 极高并发 的情况下会存在那么一点性能方面的开销，不过一般的站点是察觉不出来的。

五、后台体验

WAF 到底好不好用，后台可是起到关键作用的。仅仅只是拦住了，但是你却不知道都拦了些，那就好比是蒙着眼睛在进行防守。雷池在这一方面做的还算是可以的，把到底拦了多少、拦了些、究竟是谁在攻击我这些都给展示出来。

基础统计页 是首页默认视图，访问量、攻击次数、来源国家分布、攻击趋势 都有：

高级统计页 能按 客户端、响应状态码、QPS、来源站点 做细分，排查问题更细：

安全态势页我单独说，因为它回答了一个管理者最关心的问题：今天我被打了几次，拦住了没。下面是实时安全事件流，哪台机器、什么时间、被什么攻击，滚动展示：

还有另外一个具有实用性的小功能。攻击日志 是能够支持 黑白名单 自动进行刷新的。对于很多反复前来的恶意 IP，你可以通过一键操作来将它拉黑，要是不小心误拦住了正常的流量，还能够添加到白名单里面让它得以放行。这可比每次都手动去修改配置要更加省事得多。

六、超100万台装机、数亿+次请求，意味着什么

回到最开始所提及的那一个数字。每一天平均有着 数亿次+ 的清洗操作、超100万台 设备的装机情况、100 万个 网站处于运行的状态。这并非是某一个大型工厂的内部数据，而是全世界许许多多的中小站长、企业、开发者一同创造出来的生产方面的数据。

对于一般的用户而言，这个数目字意味着三件事情。那我就一项一项地跟您来讲讲。

1. 第一，已经有众多之人踩过坑了，坑差不多都被填平了。 你在部署的时候所碰到的报错、端口冲突、某一个特殊框架之下的兼容问题，十有八九别人已经碰到过，官方也已经将它给修复好。开源项目就害怕你是第一个去尝试的人，雷池肯定不是那种状况。
2. 第二点，在社区活动这一块，资料是比较容易去找到的。 比如说部署出现报错、配置方面有冲突这些状况，用搜索引擎这么一搜索，就能找得到大把大把现成的答案以及很多踩坑的帖子。这可比很多文档弄得乱七八糟、提了问题没人回应的项目要强多。要是出了问题，你可不会对着黑屏干着急。
3. 第三点，这个项目在短时间之内是不会出现黄掉这种情况的。 开源的项目就害怕作者不干了，然后就变成那种没人去管理的烂摊子。这个项目有着 100万 的装机量，背后是有商业公司 长亭 在进行推动的，而且还有专业版在维持着，至少在近几年是不用去操心它会出现断更这类事情的。

和很多下载量仅仅就只有个位数的小众的方案相比较，选择它出现问题的可能性要小上很多很多。这个 100万 可不是那种虚假设立的数字，它就是真真切切的让人有安全感的东西。

七、说点不好听的

全部都讲优点那就是软文，得泼一泼冷水。雷池社区版本有些方面得弄清楚，我尽可能说得具体一点儿。

1. 语义分析对未知变形攻击的检出率并非 100%。 在横向测评集当中，综合的数值是 76%。在真实业务里常见的手法能够较好地进行拦截，可是当遇到比较冷门的 0day 思路的时候，仍然是存在有可能被漏检的情况。不要将语义分析当作是万能的防护盾牌，后端的鉴权、最小权限、定期进行打补丁这些纵深防御方面的措施，该去做的还是得去做。

2. 部署要有一点运维底子。 对于 端口转发、反代链路 这些得弄明白。新手第一次进行配置的时候，很容易把自己给弄晕乎了。要是前面挂了 宝塔 或者 1Panel 的话，端口规划 要是不对就会使得站点出现 502 的情况。建议先去看看官方的端口说明，要不就按照我们所写的部署教程来做。

3. 高级能力在专业版里。 社区版是能够在日常进行使用的，但是如果想要更加细致的防护策略、集群管理、商业性质的支持，还有合规性的审计这些方面的话，那就得要花钱去购买 专业版 了。这并不算是坑害别人，但是得要有这样的一个预期才行。

4. 动态防护有轻微性能开销。 对于高并发的站点，是需要去进行一番评估的。通常来讲业务层面是察觉不出来的，但是可千万不要就不管不顾地把它全部都开启。

另外还有这么一句话，文档里没写到的就是：配置同步（多节点） 社区版是能够支持的，但是 配置下发存在时延，可别期望着秒级生效。

八、总结

对于站长以及独立开发者还有小团队的运维人员而言，我的观点是：值得上，而且应该尽早去安装。

理由并不复杂。它是 免费、是 开源 的，只需要 一条命令 就可以进行安装，而且 误报率还低，后台也是清清楚楚的，并且还能够阻挡住大部分常见的 Web 攻击。在安全这一方面，像这种投入小、回报实实在在的事情可是不多见的。我见过好多人的网站被挂马、被当作肉鸡，回过头去问他们之前都干什么去了，答案往往就是觉得 WAF 麻烦或者觉得它贵。雷池把这两个门槛都给消除掉。

就算你已经拥有了 Nginx 的 limit_req 或者 CDN 的防护措施，在前面再加上雷池来进行一层语义分析也是挺好的。多层的防线原本就是正确的做法。并没有哪一种防护能够借助一层把所有的情况都给挡住。

当然，也可别把它给想象得太过神奇。它可不是那万能的解决问题的法子。该去做后端鉴权的依旧还是得去做，该去打补丁的还是得去打。把它当作是网站安全的头一道关卡，老老实实地去运用它就成。

下一步建议： 如果你决定上，优先把 限制访问频率 和 身份认证 这两个开关打开。这两个开关对于中小站点的收益影响是最为重大的。其中一个能够阻挡 CC 攻击，另一个能够堵住后台未被授权的访问，这两个都是见效非常快速的。

再就是可以扫描下方二维码，加入雷池社群，获取更多的技术帮助，感谢阅读