我被攻击了

个人服务器去年底最后两天被攻击了,因为一些事情拖着没来得及处理,今天实在忍不住了,记录一下被攻击后发现以及修复的过程。

2019-12-30 23:39:44 云盾预警访问恶意IP 178.170.189.5
这一次预警中有一个关键字“kdevtmpfsi”

2019-12-31 04:19:19 云盾预警矿池通信行为 178.170.189.5
kdevtmpfsi

如何找到根源

kdevtmpfsi 伪装的挺好,因为它和一个系统进程的名字非常相似 kdevtmpfs ,一不小心研究的重心就偏移了。我现在的程序是以 docker 运行的,宿主机如果被攻击了问题就严重了。

因为本身不是专业运维,排雷全靠猜测。云盾感知的 cms 可能存在安全漏洞,代码扫描后没有发现异常,到这里我感觉问题可能就更严重了。

容器存在漏洞?容器也就运行了 nmp,会是哪一个容器出现问题了呢?有些手足无措。cpu 占用高,docker 查看一下容器的 cpu 占用呢?

top

使用 top 命名直接可以查看到下图,kdevtmpfsi 差不多100%的CPU占用,导致服务器完全被恶意程序占用,我本身的服务难以正常运行。

container

cpu 被 kdevtmpfsi 挖矿程序占用 100%。按照上面的定位到容器的问题,使用命令查看容器状态 docker stats 获得下图。

看到是 redis 容器被利用了,使用命令 docker exec -it 容器ID /bin/bash 进入内部看看具体问题呢?CTRL+P+Q

使用命令 ls -lrt 可以看到最早下载的 kinsing 文件是去年30日,与最早告警时间也基本在同一天。通过搜索学习到这个文件是挖矿程序的手续进程,后续需要清理掉。

按照云盾报警的情况我们看下文件是否存在 /tmp/kdevtmpfsi ,如果存在也需要清理掉才行。文件肯定是存在的,我还干了一件事情就是 kill -9 ID,CPU 占用明显就降下来了 ,然后手动运行了一下这个程序,发现 CPU 直接就飙升了

它是如何做到的

问题找到了,只要杀掉当前进程以及守护进程,问题也就暂时解决了。没有找到根源,问题还是可能被利用,继续写入挖矿程序,我们先思考一下漏洞在哪里呢?

上面分析出来是因为 redis 的漏洞导致的?想一下我们的 redis 是如何安装的,我当初测试一个需要登录才能使用的应用程序,登录的方式是关注公众号,然后获取授权码去解锁使用。就使用 redis 存放了临时 token ,安装 redis 的时候直接就是裸奔在空气中,没有密码。

可以使用命令检测一下,例如我的公网 IP 是 110.110.110.110。 只需要使用命令 redis-cli -h 110.110.110.110 -p 6379 就直接可以连上我的 redis 服务了。

通过云盾安全预警查看到《【漏洞预警】Redis 4.x/5.x 远程命令执行高危漏洞》,解决这个问题的关键可以设置仅内网访问 redis,特殊对外的 IP 使用密码策略。

version: '3'
services:

  # 使用 command 命令设置一下密码
  redis:
    image: redis:5.0.7
    command: ["redis-server", "--requirepass", "yourpassword"]
    hostname: redis
    networks:
      - redis-net
    volumes:
      - redis-data:/data

networks:
  redis-net:

volumes:
  redis-data:

安全放心上

长呼一口气之后,想起了《亡羊补牢》的故事。


unofficial
1.5k 声望19 粉丝

姓名:吴非