mirror of
https://github.com/ADD-SP/ngx_waf.git
synced 2026-04-26 14:05:52 +03:00
[GH-ISSUE #73] 请问提供bypass模式吗？ #188
Labels
No labels
MacOS
Nginx
OpenResty
Tengine
bug
documentation
enhancement
needs-investigation
pull-request
question
stale
stale
stale
timeout
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ngx_waf#188
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @SaltedFishChili on GitHub (Dec 10, 2021).
Original GitHub issue: https://github.com/ADD-SP/ngx_waf/issues/73
hey,
我们在上线前希望使用只记录不拒绝的bypass模式。
请问是否支持？
@ADD-SP commented on GitHub (Dec 10, 2021):
很好的功能，预计今天实现（大概）。
@SaltedFishChili commented on GitHub (Dec 10, 2021):
记录到具体的log文件，今天可以发布吗？
@ADD-SP commented on GitHub (Dec 10, 2021):
不支持记录到指定的文件，所有的日志都会记录到错误日志中，比如
/var/nginx/log/error.log，今天应该可以实现，但不会发布稳定版。@SaltedFishChili commented on GitHub (Dec 10, 2021):
好的，谢谢。我们先测试现在的版本，等待bypass稳定版本的发布。
@ADD-SP commented on GitHub (Dec 10, 2021):
作为软件作者，我们希望用户去尝试非稳定版本，因为能联系到的用户圈子很小，缺少测试群体，所以发稳定版更多是因为下列原因。
不过这只是一厢情愿而已，对于生产环境还是小心为妙。
@SaltedFishChili commented on GitHub (Dec 10, 2021):
测试版本稳定性有保障嘛？有的话，我这可以用非稳定版本。保障可以理解为对性能的损耗，崩溃等..
@SaltedFishChili commented on GitHub (Dec 10, 2021):
我们前面用了modsecurity，最终结论是对我们的耗时增加30%~80%不等。调整了大量规则还是达不到预期，所以在性能损耗方面我们会额外关注一些。其实我个人也想用非稳定版本，因为看到支持modsecurity的规则。所以如果测试版本在稳定性方面有保证的话，我们可以用非稳定版本，且随时反馈:)
@ADD-SP commented on GitHub (Dec 10, 2021):
关于 ModSecurity 的性能问题，本模块支持 ModSecurity 的规则是因为使用了 ModSecurity 官方的 libmodsecurity，所以当其它条件不变时，性能是不会有数量级上的变化的。
我们曾经试图使用缓存来优化 ModSecurity 的性能，但是发现除了重写规则引擎外没有稳定的方式来实现。原因是对于两个完全相同的请求，使用同一套规则进行检测，检测结果可能是不同的，而且也会有副作用。
举两个例子。
理论上来说当请求静态文件时关闭 ModSecurity 是可以的，比如
.html、.css和.jpg等。所以，如果你可以保证所使用的 ModSecurity 的规则是可以保证其行为和一个 “纯函数” 一致，我们可以在此基础上进行激进的性能优化。
@ADD-SP commented on GitHub (Dec 10, 2021):
负责任地说，即使是稳定版，我们也无法保证稳定性，因为没有建立起测试群体，其实就是能联系到的用户太少了。如果你有建议来改善这一情况欢迎提出来。
只有一些个例，比如 v10.0.0，一个流量特别大的用户使用了两周后没有发现问题，然后就发布了稳定版。
@SaltedFishChili commented on GitHub (Dec 10, 2021):
唔.
不行的，用户请求和行为是不同的，我们没法保证纯函数的规则。
@ADD-SP commented on GitHub (Dec 10, 2021):
至于性能问题，我们建议您进行压力测试，虽然从收集到的反馈来说没人对性能提出过建议，但这并不保证它适合您的需求。
毕竟这只是个人作品而已。
@SaltedFishChili commented on GitHub (Dec 10, 2021):
我们的请求量相对也很大，所以在稳定性方便有些要求。
极端点来说，我们可以接受waf检测不到攻击行为，但是接受不了崩溃。
@ADD-SP commented on GitHub (Dec 10, 2021):
无需在乎业务处理逻辑，只需要关注规则中是否存在 I/O 和时间这种易变的因素。因为检测基本上只会检测请求路径，请求头，和请求体，其它的通常无关痛痒，比如 HTTP 版本。
@SaltedFishChili commented on GitHub (Dec 10, 2021):
理解，性能我们可以测试。主要是担心非稳定版本产生异常崩溃以及对正常请求的性能损耗。
我可以同时用非稳定版本和稳定版本进行比较，来验证线上是否有压力
@ADD-SP commented on GitHub (Dec 10, 2021):
关于稳定性的测试，我提供一个方法。使用 ngx_http_mirror_module 将真实的流量复制到测试环境，这样既不会影响线上，也能用真实的流量来测试。
@SaltedFishChili commented on GitHub (Dec 10, 2021):
我们测试环境不太一样的是，测试环境没有足够的数据应对线上的真实请求，如果完全copy，可能会触发大量的非200状态码。这也是我头疼的问题
@SaltedFishChili commented on GitHub (Dec 10, 2021):
也不好保证，原因是我们多个业务团队之间定义的请求和行为是不同的。
@ADD-SP commented on GitHub (Dec 10, 2021):
其实就测试本模块的稳定性来说够了，因为本模块是先于业务逻辑生效的，就算业务逻辑出错，也不会影响这种优先生效的东西。
@ADD-SP commented on GitHub (Dec 10, 2021):
那确实没什么优化空间了，唯一的建议就是对于静态文件关闭 ModSecurity，比如图片，js，css 等。记得把 ModSecurity 的审计日志关掉。
@SaltedFishChili commented on GitHub (Dec 10, 2021):
我们本身有自研的安全拦截逻辑，针对非200状态码有不同的行为，如果触发非200状态码，可能会导致很多跳转和响应，最终导致测试结果并非真实的线上性能。
@SaltedFishChili commented on GitHub (Dec 10, 2021):
静态资源已经过滤了，modsec审计日志必须要打开，原因是我们需要针对性的修复以及被拦截时需要精确的知道。，所以modsec预计要被放弃了。啊啊啊啊啊啊啊啊，难搞。
@ADD-SP commented on GitHub (Dec 10, 2021):
似乎没有低成本的方法，Cloudflare 支持 ModSecurity 的规则，他们为了优化性能使用 Rust 重写了规则引擎，并且使用了许多黑魔法来优化性能，比如使用 SIMD 指令集来加速字符串处理。
@SaltedFishChili commented on GitHub (Dec 10, 2021):
cloudflare好像是针对自家产品吧，并不开源。十分感谢作者给予的思路。
我已经开始打ngx_waf的内部包了，正常的话，下周可以放到线上测试。有问题我会及时反馈的。
另外就是，是不是考虑拉个群？要比提issues来的快很多啊。
@ADD-SP commented on GitHub (Dec 10, 2021):
之前搞过 QQ 群，但是别说没人说话，连人都没有，就给解散了。过了一段时间，项目的 star 多了，同时为了照顾非中文用户，联系方式就变成了文档中的那样了。
@ADD-SP commented on GitHub (Dec 10, 2021):
实际上他们开源了重写过的 wirefilter 引擎，https://github.com/cloudflare/wirefilter ，并且他们有一个 ModSecurity 规则到 wirefilter 规则的转换器，不过貌似没开源。
@SaltedFishChili commented on GitHub (Dec 10, 2021):
哈哈，理解。有问题我会及时提issues。
@ADD-SP commented on GitHub (Dec 10, 2021):
其实就安全性上来说，本模块主要依赖两部分。
waf_action，该指令允许在拦截某个请求后对当前 IP 启用验证码，不通过验证将无限验证码。对于自动工具来说是绝杀，因为自动工具总是尝试每个漏洞，而我们总是可以检测到一些明显的恶意请求，同时自动工具无法通过验证。对于手动攻击来说，这提高了时间成本。@SaltedFishChili commented on GitHub (Dec 10, 2021):
这个我也调研下，感谢。
@SaltedFishChili commented on GitHub (Dec 10, 2021):
是的，看着ngx_waf相对能满足我们的需求。感谢作者
@ADD-SP commented on GitHub (Dec 14, 2021):
你好，我刚刚发现了一个比较严重的 bug，内存回收机制并未正常运行，这虽然不会导致内存泄漏，但会导致内存占用居高不下，极端情况下会降低性能。建议更新到 v10.1.0，更多更新可见更新日志。
@SaltedFishChili
@ADD-SP commented on GitHub (Dec 14, 2021):
bypass 模式已经在 v10.1.0 中实现，故关闭 issue，如有问题可以重新打开。
@SaltedFishChili commented on GitHub (Dec 14, 2021):
好的，谢谢。我重新打一个10.1.10版本。感谢作者
@ADD-SP commented on GitHub (Dec 15, 2021):
你好，我希望做一个小调查，如果涉及到不能公开的信息可以不提供。调查的目的就是了解 ngx_waf-v10.1.0 的实际使用情况。
考虑到 v10.1.0 昨晚才发布，可以等一段时间回复。
@SaltedFishChili commented on GitHub (Dec 15, 2021):
这个需要点时间，还没开始跑v10.1.0，最近在处理log4j的漏洞，预计明日天开始测试v10.1.10。
测试时我会反馈这些数据。
@ADD-SP commented on GitHub (Dec 16, 2021):
哈哈，我又带来坏消息了，用户反馈 modsec 的规则不检测请求体，经验证是 bug，已经在分支 current-dev 修复，现在没时间发版本，晚上再发，你可以先更新一下。除此之外没有任何新的变动。
@ADD-SP commented on GitHub (Dec 16, 2021):
同时建议订阅一下新版本的发布消息，这样比较及时。
@SaltedFishChili commented on GitHub (Dec 16, 2021):
没事，我们近期不会使用modsec，哈哈
@SaltedFishChili commented on GitHub (Dec 16, 2021):
hey,
我用了v10.1.0，nginx.conf http配置块：
规则为：
postman发送请求：
日志内没有任何关于此请求的日志
@ADD-SP commented on GitHub (Dec 16, 2021):
access_log 中也没有么？
@ADD-SP commented on GitHub (Dec 16, 2021):
括号有点多？
(?i)(?:jndi\:)这样试试。@SaltedFishChili commented on GitHub (Dec 16, 2021):
access log记录了，200
@SaltedFishChili commented on GitHub (Dec 16, 2021):
依然是200
@ADD-SP commented on GitHub (Dec 16, 2021):
我本地测试了一下，没发现问题。你先运行一下项目提供的自动测试。
@SaltedFishChili commented on GitHub (Dec 16, 2021):
ok，我再跟进下。感谢
@SaltedFishChili commented on GitHub (Dec 17, 2021):
请问下， 拦截是在nginx哪个阶段实现的？
我们有些服务用lua开发了一些插件，在content_by_lua阶段把请求处理后直接返回了。猜测是不是跟waf有冲突。
@ADD-SP commented on GitHub (Dec 17, 2021):
大多数情况下是在
NGX_HTTP_ACCESS_PHASE运行，当涉及到修改响应体时会同时在NGX_HTTP_CONTENT_PHASE运行，比如验证码功能。@SaltedFishChili commented on GitHub (Dec 17, 2021):
ok，看起来是我们部分代码优先于拦截的逻辑。
@ADD-SP commented on GitHub (Dec 17, 2021):
其实，我读过 lua-nginx-module 的源码。理论上来说，ngx_waf 的内容处理器是优先于 lua-nginx-module 的，我觉得可能是其它的问题。
@ADD-SP commented on GitHub (Dec 17, 2021):
目前仅会在下列情况下调用内容处理器。
如果条件允许，你可以用 gdb 给下列两个函数下断点。
按照当初的设计，当 ngx_waf 需要修改响应体时，应该只有
ngx_http_waf_handler_precontent_phase会被调用，而另一个则不会被调用。@SaltedFishChili commented on GitHub (Dec 17, 2021):
👍，我们可能要基于ngx_lua_waf做二次开发了;(
@ADD-SP commented on GitHub (Dec 17, 2021):
哈哈，看起来不能偷懒了。
@ADD-SP commented on GitHub (Dec 17, 2021):
突然反应过来，我发现你用 postman 测试的时候将测试代码写到了 url 里，如果这样你应该将规则写到
args文件里的。@ADD-SP commented on GitHub (Dec 17, 2021):
同时请检查指令
waf_mode的设置情况，仔细阅读一下文档，可能设置出错了？@SaltedFishChili commented on GitHub (Dec 17, 2021):
waf_mode STD
args post useragen都添加了规则
@ADD-SP commented on GitHub (Dec 17, 2021):
结果还是不拦截么？
@SaltedFishChili commented on GitHub (Dec 17, 2021):
是的，200了。感觉是跟我们的代码有关系，但是还没查到是哪块的逻辑。
@ADD-SP commented on GitHub (Dec 17, 2021):
你可以开启一下调试日志，然后重新进行**一次**测试，检查 error.log 中是否出现关键字 ngx_waf_debug。
如果出现，则说明模块正常运行，反之则说明没有运行。
@ADD-SP commented on GitHub (Dec 17, 2021):
其实，你可以看一下这张图。
打了标记的三个阶段是 ngx_waf 的运行阶段，如果有冲突那肯定是前两个打标记的阶段冲突了，最后一个阶段不会影响请求的处理。每个阶段的名称都和 lua 模块的对应，比如
NGX_HTTP_CONTENT_PHASE对应content_by_lua。每个阶段是严格按照从上到下的顺序执行的，如果某个阶段返回了，那么后续的阶段都不会执行（除了最后一个阶段）。