SECURITY NOTE · 2026-09-19

这台机器被黑的概率有多大

结论先说：没有开放任何入方向端口，攻击者最多只能碰到一个「只能读文件」的本地服务。但我排查时确实发现了两个真实暴露，都已经修掉了，下面写清楚。

一、隧道到底暴露了什么

Cloudflare 快速隧道的连接是从这台机器主动向外建立的。它的效果是：公网域名 → Cloudflare 边缘 → 那条出方向长连接 → 127.0.0.1:8899。

机器上没有任何新的入方向端口开放，防火墙/安全组都不用动。
攻击者不能通过隧道碰到 SSH（22）、Hermes 网关、状态数据库、.env 这些东西——隧道的映射是「一个域名对本地一个服务」，不是把整台机器搬上网。
能到达的那个服务是静态文件服务：只有 GET/HEAD，没有上传、没有 CGI、没有代码执行入口。

二、我实际查出并修掉的两个问题

问题 1：运维脚本和目录列表曾经是公开可读的

我实测从公网链接直接访问 /new_post.py、/ensure_site.py、/build_index.py 都返回 200，能完整下载源码（脚本和网页当时放在同一个目录）；/news/ 还会直接列出目录内容。

已修：把脚本整体移到 /home/ubuntu/site-ops/（网站目录外），并把服务换成加固版：关闭目录列表、拦掉 .py/.sh/.pyc/.env/.bak/.zip/.log 等扩展名与所有隐藏文件。重新实测：源码、目录列表、隐藏文件全部 404，正常页面 200。

问题 2：原来的服务是单线程的

python -m http.server 默认单线程——一个慢速连接就能把整站卡死，等于给了任何人一个廉价的拒绝服务手段。

已修：换成 ThreadingHTTPServer（多线程），单个慢连接不再阻塞其他人，服务版本号也改成不暴露 Python 信息。

顺带把二进制的来源问题也证实了

之前 cloudflared 是从 GitHub 镜像站下载的（官方 GitHub 在这台机器上超时），这是整个方案里我认为最需要交代的一环。现在已改用 Cloudflare 官方 GPG 签名 apt 源安装，两个文件的 sha256 完全一致：

03f1f25d1cc93b9ad6c60569d44060bc4f17ed97075760ed8cfca4b12dcd68cc

也就是说镜像站没有被动过手脚，现在机器上跑的是官方签名的版本。

三、剩下的真实风险（不修饰）

风险	说明	要不要管
无鉴权	任何拿到链接的人都能看内容。如果哪天往 `/home/ubuntu/site` 里放了私密文件，就等于公开发布。	要管：这个目录只放可公开的东西
Cloudflare 能看到明文	TLS 在 Cloudflare 边缘终止，不是端到端加密。	知道就好，别传隐私内容
带宽被刷	有人反复抓取会消耗这台机器的出方向带宽（脚本/网页极小，影响有限）。	低
静态服务自身漏洞	没有上传/执行入口，从 Web 层拿到 shell 的路径基本不存在；历史上 Python 这一族出现过的是重定向/信息泄露类小问题。	低，保持系统更新即可
快速隧道凭据	这种匿名隧道不需要账号凭据，所以没有「凭据被偷就等于隧道被劫持」的问题（将来换成具名隧道会有 `~/.cloudflared/*.json` 需要 600 权限）。	低

四、想更安全的三档选择

Cloudflare Access（免费）：给域名加邮箱验证门禁，只有你点邮件链接才能打开。页面还在你机器上。
迁到 Cloudflare Pages：页面根本不在你机器上，本机攻击面直接降到 0，链接还永久固定——你要是不想折腾，这是最省心的答案。
用完即关：不需要的时候把隧道停掉，需要时再开（代价是 URL 会换）。

我没有动的东西（避免误伤）：SSH 配置、防火墙规则、Hermes 网关与它的端口，全部保持原样。