- 楼主
事情起因是烧饼论坛的这篇帖子:《有 vmiss 就看下帖子,没有 vmiss 的顶一下》。
看到帖子后,我决定检查一下自己的 VMISS 服务器,随后让 Codex 协助排查登录记录、运行进程、监听端口和自启动服务。结果发现,服务器已经被陌生 IP 使用 root 密码登录,并安装了一个隐藏的 SOCKS5 代理。
下面是根据服务器日志和现场检查还原的过程,时间均为北京时间。服务器地址、我的正常登录 IP 和代理认证口令已省略。
这次能够确认的是服务器发生了未授权登录,密码最初如何泄露、是否与服务商有关,目前没有证据可以下结论。
异常登录发生在 10 月 24 日
Codex 首先读取了 SSH 成功认证日志。我逐一核对来源,排除了自己熟知的 IP,剩下七个异常地址,全部使用 root 密码成功登录。
时间 来源 IP 已确认的事件 10 月 24 日 08:55:37 5.78.129.77root 密码认证成功 10 月 24 日 13:09:31 46.225.30.169root 密码认证成功 10 月 24 日 13:09:33 与上一条登录高度关联 恶意脚本和服务文件创建,服务开始启动 10 月 24 日 13:09:34 同上 恶意服务启动完成 10 月 24 日 15:07:08 186.244.245.70root 密码认证成功 10 月 24 日 15:07:13 45.13.225.32root 密码认证成功 10 月 24 日 16:38:49 103.92.25.148root 密码认证成功 10 月 24 日 16:45:43 185.250.37.109root 密码认证成功 10 月 24 日 16:45:49 45.195.159.26root 密码认证成功 最关键的线索,是
46.225.30.169登录成功后,仅过两秒,隐藏代理的脚本和自启动服务就被创建了。文件时间与 systemd 日志吻合,强烈支持这次登录与代理部署有关。执行速度很像自动化脚本,但服务器没有完整的命令审计,无法还原攻击者下发的具体命令,也不能确定这七个 IP 是否属于同一操作者。
代理伪装成了内核线程
检查运行进程时,Codex 发现一个名为
kworker/u8:8的进程,以 root 身份监听公网 TCP45581端口,并与多个外部地址建立连接。进一步检查发现,它实际运行的是 Python,脚本藏在:
/var/cache/.sys-cache-910wsh/sys-data.dat对应的自启动服务是:
/usr/lib/systemd/system/systemd-hwdb-sync.service服务描述写着 “System cache sync daemon”,看起来像系统缓存同步程序。启动命令却刻意将进程名称改成了内核线程的样子:
exec -a "[kworker/u8:8]" "/usr/bin/python3" \ "/var/cache/.sys-cache-910wsh/sys-data.dat"脚本内部还通过
prctl修改进程名称。隐藏目录、.dat扩展名、系统服务名称和内核线程名称,都在帮助它躲过日常检查。静态分析确认,这是一个带固定用户名和密码认证的 Python SOCKS5 TCP 代理。客户端可以指定目标地址和端口,由我的 VPS 代为连接并转发数据。它支持 IPv4 和域名目标,不支持 UDP 转发。
服务配置了开机自启和异常退出后自动重启,还会在启动时添加防火墙规则,放行
45581。单纯杀掉进程,无法完成清理。它已经运行了三天多
10 月 27 日 22:08:27,Codex 读取的连接快照如下:
代理客户端 IP 已建立连接 等待关闭的连接 85.121.149.2324 44 194.102.105.191 0 176.123.4.1810 1 当时有两个来源 IP 保持连接,代理另一侧还有五条已建立的目标连接。这个程序确实在被使用,但快照只能说明检查时的状态,不能代表全部历史使用者。
防火墙针对
45581的规则累计记录了约 264.24 MB 入站流量。这只是该端口的单向计数,包含协议开销,也可能包含未通过认证的连接,不能当作代理消耗的总流量。由于程序没有流量日志,系统也未开启对应的流量统计,无法准确还原三天里的总用量。
清理与复核
我修改服务器密码后,让 Codex 清除这套已确认的恶意组件。
清理前,Codex 保存了脚本、服务配置、连接快照、防火墙规则和服务日志,随后:
- 停止恶意服务,确认进程退出。
- 移除开机自启动链接。
- 删除恶意服务文件和隐藏脚本。
- 删除它添加的
45581防火墙放行规则。 - 重新加载 systemd,并通过新的 SSH 连接复核。
恶意服务在 10 月 27 日 22:12:41 停止。从启动到停止,它持续运行了约 3 天 9 小时 3 分钟。
复核时,进程没有复活,
45581已停止监听,恶意脚本和服务文件均已删除。服务器原有的代理及网站服务保留。供排查参考,恶意脚本的 SHA-256 为:
e67cbdf0fc079dd91e7c3d95ac7feebdfc365686b72c541be0df016c8e53a2b1这次排查也有边界:没有完整命令审计,无法确认攻击者是否读取过业务数据、复制过其他凭据,或留下其他改动。清除了这套代理,不代表曾被 root 入侵的系统已经完全可信。
我的建议是:立即更换泄露的密码,SSH 只允许使用密钥登录。 同时检查成功登录记录、监听端口和自启动项,不要只盯着失败登录次数。对于已经确认遭到 root 入侵的服务器,应考虑从可信镜像重建,并轮换服务器能够访问的其他凭据。
关闭 SSH 密码认证前,先在新终端验证密钥能正常登录,保留当前会话,再修改配置并校验生效。修改密码也不会自动断开攻击者已经建立的会话,这一点需要单独检查。
收藏支持 1反对打赏个性签名本论坛第 32 号成员,也做 GPT 代充,欢迎咨询。简介有联系方式。jubao@email_sb
46.225.30.169 / 5.78.129.77 是 Hetzner 的 IP,去 https://abuse.hetzner.com/ 投诉会有用吗
最好用证书登录 别用密码 容易暴露
牛啊这都能查到
太好了,还是帮到人了,但是最好还是重装一下系统改密钥登录
我前面一直都是 root 密码登录的,今晚有空,刚刚换成私钥切换。