VPS 疑似被 GitHub self-hosted runner 相关进程拖下水,有没有类似经历?

查看 21|回复 3
作者:mns   
昨晚遇到一个比较头疼的问题。
一台 VPS 被服务商通知对外发起 SSH brute force ,随后 IP 被 null route 。机器上主要跑网站和一些自建服务,我自己肯定没有主动扫别人。
通过 VNC 进去看了一下,发现不是简单的误报。系统里确实有可疑进程在对外连很多 22/80/443 端口,而且进程挂在一个 runner 用户下面。继续查发现该用户家目录下有一个隐藏目录,里面有几个伪装成系统服务名的二进制文件,比如类似 crond 、init 、upd 这类名字,其中一个还是 UPX 压缩过的 ELF 文件。
目前的判断是:VPS 确实被植入东西了,且大概率和 self-hosted runner 或 CI/CD 执行环境有关,但还没完全确定入口。GitHub workflow 本身看起来没有明显异常,不过机器上确实有 self-hosted runner ,且恶意文件落在 runner 用户目录下。
现在已经做了几件事:
[ol]
  • 停掉 self-hosted runner
  • kill 掉可疑进程
  • 打包保留恶意目录
  • 准备重装系统
  • 准备轮换 SSH key 、GitHub secrets 、runner token
    [/ol]
    想问下大家:
  • self-hosted runner 是否确实不适合和生产服务放在同一台 VPS ?
  • 这种情况有没有必要继续深挖入口,还是直接备份数据后重装?
  • 如果后续还要用 self-hosted runner ,比较稳妥的隔离方案是什么?单独 VPS 、Docker 、临时 runner 、还是干脆不用?
  • 1Panel / Docker / CI runner 这些东西放公网,有没有比较推荐的最小暴露配置?

    目前个人感觉,self-hosted runner 这类东西如果长期在线、又和生产环境混在一起,风险比想象中高很多。

    VPS, 植入, Runner

  • zw2019   
    啊 ,我用 vps 跑了一个 self-hosted runner , 你这一说 我是不是要去给他卸载了。。。
    rbe   
    self-hosted runner 虽然不允许 root 用户跑,但你用 sudoer 用户是完全可以的,他也没有什么沙盒隔离、目录隔离,完全可以在 github action job 中执行删除各种系统文件命令的。
    他毕竟是 CI/CD 服务,怎么能和生产环境放同一台机器

    ,太危险了。
    self-hosted runner 有 k8s 部署的模式,https://github.com/actions/actions-runner-controller 你在机器上装个 k3s ,直接让 ai 教你改造就好了,现存的 workflow 可能需要做一些适配,如果有启动 docker 容器的需求可能还需要做 dind 模式。
    docx   
    Runner 直接宿主机跑?至少用容器吧,或者单独隔离一台 VPS 给它
    您需要登录后才可以回帖 登录 | 立即注册

    返回顶部