[FEATURE] 在应用市场中提供第三方 WAF 应用，比如safe3出品的南墙 uuWAF

[maninhill]

1Panel 版本

v1.5.2

请描述您的需求或者改进建议

在应用市场中提供第三方 WAF 应用，比如【南墙uuWAF】。

https://github.com/Safe3/uuWAF

请描述你建议的实现方案

No response

附加信息

No response

[okxlin]

你们问我资瓷不资瓷，我是资瓷的。😁

PS:

打个广告：路过的朋友可以来试试1Panel 应用商店的非官方应用适配库 来一键启动体验一下，然后等待官方上架内嵌完整的正式版本上线

[zclaiqcc]

那当然是雷池社区版啊，https://waf-ce.chaitin.cn/

[maninhill]

已经上线。

[Felmon]

已经上线。

要怎么使用呢？1panel openresty搭建的站点想使用uuwaf但是两个应用都得占用80和443，两者只能二选一 能否第三方waf能够直接接管openresty的lua waf而不是需要替换掉现有的openresty及其搭建的站点呢？ 假如第三方waf是这种割裂式的单独应用，还不如继续在lua waf基础上继续优化

[Felmon]

这种投机取巧的应付需求的方式真的很眼熟 不就跟我们跟张小龙提加“已读状态”、“批量删除好友”等需求一样吗，给我说隔壁telegram就有这功能，你只需要把联系人重新加到telegram里进行聊天 你看看你closed掉的那些需求都是希望集成在openresty lua waf模块里 你们倒好，直接取巧，还劳烦您单独开一个issue提👍👍 这种基础linux面板功能或者应用集成功能就不能做迭代优化吗？docker面板就是比linux面板的饭好吃？

[Felmon]

不如直接把你们这个 https://github.com/1Panel-dev/waf 也closed算了 这些迭代需求都没人催，知道你们有你们计划，但是你这样敷衍应付真的败rp

[maninhill]

WAF 这个问题我们内部也在反复评估，我们面对的情况和做出的选择是：

1. 我们必须承认 WAF 是很专业、很深的领域，我们自己搞的 Lua waf 短期很难达到专业 WAF 的水平。
2. 所以，为了满足部分用户的需求，我们先集成一些第三方的 WAF 进来，让这些用户先有个选择（解耦的方式）。
3. 我们 v1.6 会解决 OpenResty 改端口的问题，解决 80/443 冲突的问题。
4. 后续我们也会继续寻找改进 lua waf 这块的方案。

很抱歉让你失望，我们人力有限，一方面很难兼顾大量的需求，另一方面沟通上做的也不好。

望理解。你的批评和建议我们后续积极改进。

[zclaiqcc]

WAF 这个问题我们内部也在反复评估，我们面对的情况和做出的选择是：

1. 我们必须承认 WAF 是很专业、很深的领域，我们自己搞的 Lua waf 短期很难达到专业 WAF 的水平。
2. 所以，为了满足部分用户的需求，我们先集成一些第三方的 WAF 进来，让这些用户先有个选择（解耦的方式）。
3. 我们 v1.6 会解决 OpenResty 改端口的问题，解决 80/443 冲突的问题。
4. 后续我们也会继续寻找改进 lua waf 这块的方案。

很抱歉让你失望，我们人力有限，一方面很难兼顾大量的需求，另一方面沟通上做的也不好。

望理解。你的批评和建议我们后续积极改进。

基于「规则」的 lua waf 需要使用者持续维护最新的漏洞规则，不然就跟没有一样，而大多数面板使用者又不具备这种能力。另一个思路是，由某个统一的安全平台下发安全规则。这依赖有一个安全团队持续跟进和追踪最新漏洞，这件事确实属于很专业的领域。

我不太认同上面 @Felmon 师傅的那个类比场景。微信是否增加「已读功能」「批量删除好友」，本质上是对微信这个产品的目标定位的问题。这两个功能都属于更企业的、个人用户很少用到的功能，所以微信的解决方案（我认为）是通过「企业微信」来解决。这何尝不是一种第三方接入式的解决方案？说实话，还真就是把微信好友在 telegram 加一遍，到 telegram 聊天，只不过把这里的 telegram 换成企业微信。

我个人一直觉得要求一个 all-in-one 的解决方案是不现实的，无论是安全领域，还是非安全领域。解耦 + 专业化分工就是效率最高、效果最好的方式。我是比较认可让专业的产品做专业的事。对于 Linux 面板，提供简单、易用的 Linux 运维能力就够了。用户可以方便地部署和管理 Linux 服务器，至于里面到底各个服务之间如何组合，应该完全交由用户决定。对于 Web 应用的安全防护，1Panel 团队就算意愿上想做到很好，精力和能力上也做不到。

思考一下，如果某个专业领域如此容易就能做到还不错的水平，那么也不需要那么多的专家、垂直领域的公司来做相关产品了。大家都大一统，未来直接集成到 Linux 发行版里面算了。这也不符合 Linux 设计哲学。

当然如果限定就是要求以某种集成式、非第三方服务的接入方式，也可以考虑类似 OpenAPI 等方式接入也都是很方便的。这部分涉及跟第三方产品的沟通、合作，这里只是提供某种思路和方向。

个人认为 WAF 核心一个是转发，另一个是检测（当然日志处理和分析等也都属于核心功能）。转发侧要的是稳定、高性能，遇到极端情况下可降级（比如只转发不检测）。检测部分需要的是高检出、低误报、高性能。

（可以当做广告）自卖自夸地说，从检测能力方面，雷池的「语义分析引擎」确实能更好更方便地解决「规则引擎需要及时更新」问题，比如对一些基于语义的 0day 漏洞拥有天然防护能力（见最后）。从转发和流量接入方面，可以基于 lua 把流量接入雷池 WAF，这部分不需要改动原先 OpenResty 占用的 80/443 端口，接入的改造成本相当低。

---

关于雷池天然防护的 0day 漏洞列表，可以参考 https://stack.chaitin.com/techblog/detail/121 ，或者关注微信公众号「Skynet 安全团队」，我们每月都会发布雷池语义分析引擎天然能够防护的 0day 漏洞列表。这些都是实打实的，可以自行 POC 验证。

[shellsec]

啥时候 雷池 进场？

[longjuan]

从转发和流量接入方面，可以基于 lua 把流量接入雷池 WAF

如何实现这种接入方式呢，希望能有具体文档🤩。

[zclaiqcc]

从转发和流量接入方面，可以基于 lua 把流量接入雷池 WAF

如何实现这种接入方式呢，希望能有具体文档🤩。

@longjuan 就是基于 https://github.com/chaitin/lua-resty-t1k 把流量导入到雷池检测引擎，同时拿到检测结果。APISIX 也是类似的接入方式。这种优点是是不用改原先的网络拓扑，流量大的时候可以自己控制流量不过 WAF（降级机制），自己搞转发集群等等。缺点是需要一定的 DIY 能力，目前还并没有一键接入的方式，性能方面没有实测过，预期是会低一丢丢但是不会很多。

文档的话目前还没有官方的，可以搜下社区其他师傅自己写的，比如 https://zhuanlan.zhihu.com/p/641117894

[safe1ine]

从转发和流量接入方面，可以基于 lua 把流量接入雷池 WAF

如何实现这种接入方式呢，希望能有具体文档🤩。

@longjuan 就是基于 https://github.com/chaitin/lua-resty-t1k 把流量导入到雷池检测引擎，同时拿到检测结果。APISIX 也是类似的接入方式。这种优点是是不用改原先的网络拓扑，流量大的时候可以自己控制流量不过 WAF（降级机制），自己搞转发集群等等。缺点是需要一定的 DIY 能力，目前还并没有一键接入的方式，性能方面没有实测过，预期是会低一丢丢但是不会很多。

文档的话目前还没有官方的，可以搜下社区其他师傅自己写的，比如 https://zhuanlan.zhihu.com/p/641117894

有官方文档了 https://github.com/chaitin/SafeLine/discussions/295

[wanghe-fit2cloud]

v1.6.0 版本支持在创建 OpenResty 应用时修改默认 80 和 443 端口。