linux 9090端口漏洞

上周帮一个朋友排查服务器，端洞发现他图省事，口漏直接把内部用的端洞 Jenkins 和几个测试服务全绑在了 0.0.0.0:9090 上，防火墙也只开了这一个口子。口漏结果呢？端洞日志里全是境外 IP 的扫描记录，有一个甚至已经尝试用默认口令登录他的口漏 Prometheus 了。这事让我觉得，端洞得把 9090 这个端口单独拎出来说说。口漏

9090 本身不是端洞漏洞。它只是口漏个端口号，跟 80、端洞443 一样无辜。口漏问题出在跑在这个端口上的端洞服务，以及管理员对它的口漏态度。最常见的端洞三个服务是 Prometheus、Cockpit 和某些定制化的 Web 管理后台。Prometheus 默认监听 9090，Cockpit 也是。这两个东西有个共同点：功能强、权限大、默认配置往往不考虑公网暴露的风险。

Prometheus 的坑在于它的 API。如果你没开认证，任何人访问 /api/v1/targets 就能拿到你所有被监控节点的地址、端口、甚至一些标签信息。更狠的是 /api/v1/query，攻击者可以直接执行 PromQL 查询，把你内存里的指标数据全捞出来。有些指标里带着主机名、内部 IP、容器 ID，拼凑一下就是一张内网拓扑图。我见过一个案例，攻击者通过 Prometheus 的 /api/v1/status/config 拿到了完整的 scrape 配置，里面明文写着数据库的 exporter 地址和端口，下一步就是直接打数据库了。

Cockpit 更直接。它本身就是一个带 root 权限的 Web 控制台。如果 9090 端口暴露在公网，而且你用的是弱密码，那等于把服务器的 shell 挂在网上。Cockpit 的登录接口没有默认的速率限制，爆破成本极低。我自己的扫描日志里，针对 9090 的爆破尝试每天都有几十次，字典里全是 admin、root、123456 这类组合。有人可能觉得改个端口就安全了，但扫描器是全端口扫的，改端口只是拖延几秒钟。

那怎么办？最干脆的做法是别让 9090 监听在 0.0.0.0 上。Prometheus 启动参数加 --web.listen-address=127.0.0.1:9090，Cockpit 用 systemctl edit cockpit.socket 把 ListenStream 改成 127.0.0.1:9090。需要远程访问就走 SSH 隧道或者 WireGuard，别偷懒直接开公网。如果非得暴露，至少套一层 Nginx 做 basic auth，再把 /api/v1/admin 这类敏感路径挡掉。Prometheus 从 2.24 开始支持 --web.config.file，可以配 TLS 和认证，但很多人根本不知道这个参数存在。

还有一个容易忽略的点：容器环境。Docker 的 -p 9090:9090 默认就是绑所有网卡。很多人写 docker-compose 时只写端口映射，不写 127.0.0.1:9090:9090，结果容器里的 Prometheus 直接裸奔。Kubernetes 里如果 Service 类型是 NodePort 或者 LoadBalancer，9090 也会暴露到集群外。检查一下你的 Service 定义，把 type: ClusterIP 用对，或者加 NetworkPolicy 限制来源 IP。

我自己的习惯是，在任何新机器上跑 ss -tlnp | grep 9090，看到 0.0.0.0:9090 就浑身不舒服。改配置、重启服务、再确认一遍。这个动作花不了两分钟，但能省掉后面可能几天的应急响应。端口暴露这种事，从来都是防君子不防小人，而互联网上小人多的是。