|
刚接触 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 权限上...
| 
