ki 的折腾笔记.

VPSsing-box玩机Python

← 返回首页

333 个 Tor 出口节点被劫持：一次针对 SSH 密码登录的拦截行动

TorSSHVPS安全
333 个 Tor 出口节点被劫持：一次针对 SSH 密码登录的拦截行动

背景：Tor 出口节点是什么

Tor 把你的流量包三层加密，经过三个中继转发：入口、中间、出口。出口节点负责拆掉最后一层加密、真正去连接目标网站或服务器。也就是说，从出口节点到目标服务器的最后一段，流量是什么样，取决于目标协议本身：HTTPS 本身加密，出口节点看不到内容；但 SSH、邮件这些协议如果配置不当，出口节点就能插手。

2026 年 10 月初，就有人对出口节点动了手脚——目标不是浏览网页，而是 SSH。

事件经过：333 个出口，12 台拦截服务器

10 月 2 日上午，研究员 kaba 通过 Tor 用 SSH 连自己的服务器时，OpenSSH 弹出了"远程主机标识已更改"的警告。他用 Tor 官方也在用的扫描工具 exitmap 对约 3000 个出口节点做了一轮测试，结果发现：333 个出口节点把 SSH 连接送到了同一批 12 台攻击者控制的服务器上。

攻击者改的是出口节点的 torrc 配置文件里的 ExitPolicy（决定该节点愿意转发哪些端口）：

  • 342 个原本屏蔽 22 端口的节点被改成放行 SSH；
  • 24 个根本不是出口的节点被改造成了出口；
  • 多数受影响节点上，加密邮件端口 993（IMAPS）、995（POP3S）被关闭，明文邮件端口反而被打开。

Tor 官方在 10 月 4 日 18:00（UTC）开始对这些节点投 BadExit 标记，21:00 进入共识；到 10 月 5 日 17:00（UTC），受影响节点已全部清除出网络。攻击高峰时，这些节点占 Tor 出口总容量的 7.46%。

拦截是怎么得手的：关键在"密码"二字

当你的 SSH 连接从被劫持的出口出去时，它并没有到达真正的服务器，而是到了拦截服务器。拦截服务器会拿出自己的 host key 应答：

  • 以前连过的用户会看到 OpenSSH 的"host key 已更改"警告；
  • 第一次连接的用户则看到正常的"是否信任新密钥"提示。

如果你忽略警告、继续用密码登录，密码就交出去了。 拦截服务器随即用这个密码登录真正的服务器，会话看起来一切正常，但你的每条命令都可能被记录。在 kaba 的蜜罐里，拦截方还会检查账号是否有免密 sudo，然后下发一段 base64 编码的 Perl 安装脚本——形态与下文提到的 Ebury 后门植入命令一致。

为什么偏偏是密码登录中招？SSH 密钥登录时，客户端的签名里包含当前会话独有的标识，中继者拿着这个签名去真正的服务器是无效的——它只能给你一个假 shell，却无法冒充你登录真服务器。密码则不同：密码是在加密会话内部传输的，谁持有会话，谁就能读到它。 这就是"密钥登录"这条老建议在这次事件里最硬的注脚。

根因：Ebury 后门 + 一个被复用的密码

受影响最大的中继家族运营者 Zimmer 在 10 月 7 日的事后复盘里写清了入侵链：攻击者在 8 月 28 日一次尝试就用运营账号的密码登录了他的管理服务器，几分钟内拿到 root 并装上了 Ebury 1.8.3。

复盘里列出的几个失误，每一个都值得所有 VPS 用户对照：

  1. 同一个密码复用在 SSH 登录、sudo 和备份口令三处，且以明文形式存放；
  2. 面向公网的服务器开着 SSH 密码认证；
  3. Ebury 的后门登录不留痕迹：10 月 2 日出现的配置改动，在日志里找不到对应的登录、sudo 命令或 cron 任务。

Ebury 是安全厂商 ESET 从 2009 年起追踪的 OpenSSH 后门与凭证窃取工具，2024 年估计感染约 40 万台服务器。1.8.3 版本至少从 2026 年 6 月起就在流传，研究者警告可能还有更多被感染的主机尚未被发现。

另外一个未解之谜：同一托管商旗下 101 个节点中有 71 个同时切换了攻击者的策略，而其他托管商 9054 个节点中只有 13 个——40 个分属 21 个运营者的节点在 10 月 1 日约 5 分半钟内集中改动。分析认为这指向单一攻击者已有的批量访问能力，托管商本身是否被攻破尚未证实，也无人被公开确认身份。

你的 VPS 自查清单

你不一定跑 Tor 节点，但入侵路径是通用的。下面这组检查，任何一台公网 VPS 都值得跑一遍：

# 1. 密码认证是不是还开着（应该看到 no）
grep -E '^(PasswordAuthentication|PermitRootLogin)' /etc/ssh/sshd_config

# 2. 最近登录记录里有没有不认识的来源
last -n 50 | head -n 50

# 3. 有没有多出来的用户、authorized_keys 条目
cat /etc/passwd | awk -F: '$3 >= 1000 {print $1}'
grep -r "" /home/*/.ssh/authorized_keys /root/.ssh/authorized_keys 2>/dev/null

# 4. 可疑的定时任务与服务
crontab -l; ls /etc/cron.d/; systemctl list-timers --all | grep -v "n/a"

如果你确实在跑 Tor 中继，对照 Tor 官方给运营者的清单再查一遍：torrc 及其 include 文件里有没有你没设过的 ExitRelay、ExitPolicy、ContactInfo、MyFamily、Nickname，以及指向 22 端口的 NAT 规则、未知监听进程、异常出站连接。

需要注意的一点：Ebury 藏身于单个 setuid 库文件，常规的包校验工具查不出来，"查了一圈没事"不等于没事。Tor 官方建议的稳妥做法是离线挂载磁盘镜像检查；一旦确认感染，正确处置是下线、保留磁盘与日志取证、重装而不是清理，并轮换这台主机上所有凭证。

如果你在 10 月 1 日至 5 日之间经 Tor 用过 SSH

同时满足以下几条，就按"密码已泄露"处理：

  • 在上述窗口期经 Tor 建立过 SSH 连接；
  • 连接恰好走了被劫持的出口；
  • 你接受了陌生或已更改的 host key；
  • 并且用密码完成了登录。

处置：立即在真正的服务器上改掉那个密码；检查本地 ~/.ssh/known_hosts 在窗口期内有没有新增或变动的条目；kaba 连接中见到的拦截方 host key 之一是 ED25519 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E，可作为比对参考（其余 11 台可能使用不同密钥）。

普通 Tor 网页浏览不受这次事件影响——HTTPS 流量穿过被劫持出口时仍是加密的。

三条铁律

  1. 密钥登录，关掉密码认证：这是唯一让中继攻击失效的办法。具体步骤见本站 10 月 19 日的SSH 加固三板斧：把你 VPS 的大门焊死。
  2. Host key 警告就是停车标志：看到"remote host identification has changed"，先断开，再通过另一条可信渠道核对服务器指纹，绝不要顺手按 yes。
  3. 密码绝不复用：SSH、sudo、备份口令各用各的，敏感密钥的备份真正离线保存。

这次事件没有出现受害者数量统计，攻击者身份也未查明——但它把一条老生常谈变成了有时间、有数字、有尸体的案例：密码认证开着的一天，你的服务器大门就是向全网敞开的。

*事件细节来源：Attackers Hijacked 333 Tor Exit Relays to Redirect and Intercept SSH Logins（2026 年 10 月 24 日更新）。*