nginx 防火墙模块开发总结

为什么要写这篇文章？

我起初并没有写这篇文章的意思，因为无论是从难度还是代码复杂度来说这个项目在我写过的项目里只能算中等，但是它却有一个特点，就是我的第一个专门开发出来供他人使用并且希望被他人使用的项目。先前的项目要不然不能公开，要不然个人属性非常强，不适合他人使用。所以这篇文章主要是以纪念为目的的。

那段时间我的站点有时会打不开，起初以为是网络问题，后来越来越严重，进入后台才发现数据库 IO 拉满了。看了看 nginx 的日志才发现站点被疯扫，于是打算做点什么。

我先从网上搜索到了一些基础的拦截扫站的规则，直接 copy 到 nginx.conf 里就能用，但是这些规则都特别多，而且杂，直接丢到配置文件里会大大降低配置的可读性，所以当初就被否了。

后来我拉黑了一些 IP，不过这也就一时起作用，过段时间换了 IP 继续来扫。补救措施是用 whois 找到 IP 地址快直接全部拉黑。但是这导致了一些误伤，于是这个方案也被否了。

然后我找到了 ngx_lua_waf，用了一段觉得还行，但是也发现了一些缺陷，最明显的就是拉黑 IP 的时候只能拉黑单个 IP，而不能拉黑一个地址块。但是这个模块大概已经停止维护了，不能指望作者更新了。

然后在 Github 上看了几个防火墙模块，要不然功能不全，要不然使用复杂，于是萌生了自己写模块的想法。

主要是因为这样可以不用安装 lua_nginx_module，其次是因为 C 的执行效率理论上要高于 lua，因为 lua 需要启动一个 VM。

不过我主要考虑的是安装是否方便，性能倒不是那么看重，因为 lua_nginx_module 身经百战，性能完全可以保证。

不过用 C 语言开发必然增加开发难度，最重要的是要自己控制内存，这类 Web 服务器上的模块一旦内存泄露、段错误啥的那麻烦就大了，不过我还是有信心不出大问题的。

只实现基础的防护，即 IP 检测、Url 检测、Get 参数检测、Cookie 检测、Post 检测、Referer 检测和 CC 防御。不会引入更复杂的功能，比如根据某个 IP 的行为进行综合判断是否拦截。

在保证代码良好可读性的情况下提高性能。

说实话我之前还真没把这个当回事，但是当我打算把这个项目给别人用的时候我发现版本号似乎也能传递一些比较重要的信息，所以开发这个项目的时候我是一直遵守这个标准的。

简单来说语义化版本将版本号分为 X.Y.Z。

这样版本号就可以向用户传递对应的信息，这无疑是十分有用的，最明显的就是当用户看到 X 递增的时候就会十分谨慎，因为贸然更新可能会导致现有的程序出现不兼容的情况。

作为一个打算给他人使用的项目，一个清晰的 Change Log 就是很必要的了，它可以将每次更新的内容展示出来，方便他人了解也方便自己记录。

项目写到后期就不得不写开发文档了，首先是方便了自己，其次也是方便别人。可以从头开始写效率太低了，强烈推荐 doxygen。这个工具可以通过代码内的注释自动生成文档，这样为源代码写注释的同时还能生成开发文档，十分方便。

开发文档简单，清晰，还能自动生成函数调用图和被调用图等一系列图。如果觉得丑还能自定义 CSS，不过对于我这个前端困难户来说就不搞了。

性能优化的主要工作就是降低请求检查花费的时间。

Url 检查、Get 参数检查、Post 检查、Cookie 检查和 Referer 检查都需要执行正则匹配，暂时没发现什么合适的方法去优化，只能一个一个地去检查。时间复杂度为 O(mn)， n 为需要测试的正则条数， m 为执行正则匹配的时间。

不过由于本模块只会在 nginx 启动时读取规则，运行时规则不会改变，所以对于同一个 URL 无论检测多少次结果都不会变，于是本模块会缓存检查的结果，每次检查前先读取缓存，如果命中则直接取出结果，反之则走流程检查。除了 IP 检查和 Post 检查以外所有的检查都使用了缓存机制。

缓存淘汰策略为 LRU。当缓存的内存不足时会引起频繁的淘汰，增加内存碎片。于是本模块会周期性地按照 LRU 的策略淘汰掉一定比例的缓存。

IP 检查很有搞头。本模块使用了一种经过修改的前缀树来改进 IP 检查的性能。

前缀树的查找时间为O(h) ，其中 h 为树的高度。对于 IPV4 来说一共有 32 位，那么树高最多 32，IPV6 对应的树高最多为 128。那么查找时间复杂度为 O(1) ，也就是说执行 IP 检查的时间基本上不会受到 IP 黑白名单规模的影响。

经过比较极限的测试，QPS 降低了约 4%，详情见性能测试。

笔者碎碎念：这位同学是大佬，强烈建议收藏