Nginx Proxy Manager 好像不太安全？几百个 CVE 漏洞...

[t41372]

刚接触 docker 和反向代理的时候，我用的是 Nginx Proxy Manager 。

但后来我注意到 Nginx Proxy Manager 的 GitHub 页面上有 1.5K 个待解决的 issues... 这对于一个反向代理，一个负责管理你公开 80 和 443 端口的服务，并不是个好现象。因为写过 web 应用的应该都知道，web 这玩意儿，更新很重要，一会儿不更新你用的什么依赖就爆出漏洞了。如果一个重要的 web 项目上有一堆 bug ，那安全性就要打问号了。

我之前没怎么注意，就只是把 nginx proxy manager 换成 caddy ，把自己服务器所有端口关掉，改用 tailscale 访问而已。

但我今天在网上晃悠的时候看到了这个 Nginx Proxy Manager 的 issue ，2024 年 1 月的 issue： https://github.com/NginxProxyManager/nginx-proxy-manager/issues/3503

该死，400 多个 CVE 漏洞，真的假的？

他 issue 里面提供的扫描容器的网址已经挂了，不过没关系。有个开源的容器漏洞扫描工具叫做 Trivvy ，我用这个工具扫描了一下最新的 Nginx Proxy Manager 的 docker 镜像。 https://github.com/aquasecurity/trivy

该死，真的有好几百个 CVE 漏洞，还有两个 Critical 级别的漏洞...

有点吓人，考虑到 Nginx Proxy Manager 应该现在还是自部署领域比较主流的反向代理工具，影响面还是挺大的。

如果可以的话还是改用其他的反向代理吧。

关于 “容器被黑了又能怎么样” 的问题

虽然 Docker 容器具有隔离性，但这不是绝对安全的！

Docker 的隔离性主要依赖于 Linux 内核的 namespaces 和 cgroups 技术。

Namespaces: Namespaces 提供了进程、网络、挂载点、用户等资源的隔离。

Cgroups: Cgroups 用于限制容器可以使用的资源，例如 CPU 、内存、磁盘 I/O 等。

然而，隔离性不是万无一失的，它依赖于以下因素:

内核的安全性: 容器与宿主机共享同一个内核，因此内核漏洞可能导致容器逃逸。

Docker 的配置: Docker 守护进程和容器的配置是否安全，例如是否以 root 权限运行 Docker 守护进程，是否将宿主机的敏感目录挂载到容器中，是否禁用了不安全的功能等。

容器内部的应用安全: 容器内部运行的应用是否存在漏洞，例如 SQL 注入、代码执行等。

我自己比较担心的是黑客攻破服务器之后，拿来当跳板干花活，最后给我惹上麻烦...

另外还在把 docker 运行在 root 权限上的，记得去配置一下 无 root docker ，不要把 docker 进程跑在 root 权限上...

[devopsdogdog]

😁正经服务器谁用？
Trivvy 只要没更新系统啥的几百个也正常吧，多读书多看报

[yinmin]

docker 反向代理应该用 nginx:stable 这个镜像

[OrenZ]

Nginx Proxy Manager 不是本地开发用的吗，一点都不稳定

[falcon05]

都是因为懒才用这玩意，不过我最近刚换成了 1panel 里的 openresty ，也是图形化操作，而且 1panel 里可以申请泛域名证书，比 npm 方便很多。南墙也可以做反代，但给的默认用户名密码显示不对，放弃。

[WizardLeo]

😰
正在用 Nginx Proxy Manager ，看起来好危险。

[bankroft]

我都是内网用避免有些应用强制 https ，外面用 VPN 连回来

[bankroft]

@bankroft 还可以统一用一个端口

[lekai63]

目前用 nginxui 主要是用它配置 nginx+ssl 挺方便。

漏洞啥的就说不来了

[whh945atsyzx]

看成 ng 有千把个漏洞，冷汗冒了 0.01s

[icaolei]

@falcon05 #4 试试 NginxUI https://github.com/0xJacky/nginx-ui

[Yadomin]

用 traefik 吧

[macaodoll]

玩具，而已。

[COW]

这种涉及修改基础设施配置的工具，一般就不该暴露 UI 出去的，都是内部网络，自己一个人访问，很多漏洞可以无视。

[whoami9426]

treafik 很方便

[bkmi]

@whoami9426 @Yadomin treafik 是要在每个容器上都配上指定的 label 吗，这样感觉侵入性好强

[f165af34d4830eeb]

@bkmi #15 可以用最基础的 file config 模式

[akira]

这种必须禁止公网访问的东西，无所谓了

[abolast]

这就是不同工种的区别了，开发用 Nginx Proxy Manager 方便你本地调试，真上线上环境了就得用 nginx/caddy 这种了，这就是运维的活了，而靠谱的运维是必须过一遍 nginx 源码的，因为很多细节文档是没讲清楚的

[bao3]

这种反代工具，本身是不在公网曝露的，所以有没有 CVE 并不影响，何况还有 docker 环境隔离。如果 dock 是 root ，那就办法了。
要说漏洞，当年系统加软件漏洞都已经有上千个了，我家里的反代还是跑在 freebsd 5.3 上，要知道现在的 freebsd 已经是 14 了。
你只要保证给应用/进程最低的权限、最低的曝露量，再加一些权限验证，其实你 10 几年不升级都没问题。
我再举个当下的例子，pve 使用 lxc 搭建应用平台，一般人都是直接在 lxc 里以 root 运行实例，而我从来都是自己在 lxc 里另开单独的帐户，有时候不给帐户 login 权限，跑相应的实例，挂载的 host 文件夹也通过 setfacl 设定最低的权限。 无论有多少漏洞，都不担心安全问题。

[fuzzsh]

…
不是 NPM 本身程序有漏洞慌啥，按截图的 libaom3 搜了下，是音视频解码的 library ，而 NPM 仅是个 proxy ，不参与实际的 decode 行为，要是数据包/proxy 层面的巨大漏洞不修复则是维护者有问题

而 op 的结论和应届出的等保报告有何区别？