我被攻击了
个人服务器去年底最后两天被攻击了，因为一些事情拖着没来得及处理，今天实在忍不住了，记录一下被攻击后发现以及修复的过程。
2019-12-30 23:39:44 云盾预警访问恶意IP 178.170.189.5
这一次预警中有一个关键字“kdevtmpfsi”
2019-12-31 04:19:19 云盾预警矿池通信行为 178.170.189.5
kdevtmpfsi
image
如何找到根源
kdevtmpfsi 伪装的挺好，因为它和一个系统进程的名字非常相似 kdevtmpfs ，一不小心研究的重心就偏移了。我现在的程序是以 docker 运行的，宿主机如果被攻击了问题就严重了。
因为本身不是专业运维，排雷全靠猜测。云盾感知的 cms 可能存在安全漏洞，代码扫描后没有发现异常，到这里我感觉问题可能就更严重了。
容器存在漏洞？容器也就运行了 nmp，会是哪一个容器出现问题了呢？有些手足无措。cpu 占用高，docker 查看一下容器的 cpu 占用呢？
top
使用 top 命名直接可以查看到下图，kdevtmpfsi 差不多100%的CPU占用，导致服务器完全被恶意程序占用，我本身的服务难以正常运行。
image
container
cpu 被 kdevtmpfsi 挖矿程序占用 100%。按照上面的定位到容器的问题，使用命令查看容器状态 docker stats 获得下图。
image
看到是 redis 容器被利用了，使用命令 docker exec -it 容器ID /bin/bash 进入内部看看具体问题呢？CTRL+P+Q
image
使用命令 ls -lrt 可以看到最早下载的 kinsing 文件是去年30日，与最早告警时间也基本在同一天。通过搜索学习到这个文件是挖矿程序的手续进程，后续需要清理掉。
按照云盾报警的情况我们看下文件是否存在 /tmp/kdevtmpfsi ，如果存在也需要清理掉才行。文件肯定是存在的，我还干了一件事情就是 kill -9 ID，CPU 占用明显就降下来了 ，然后手动运行了一下这个程序，发现 CPU 直接就飙升了
image
它是如何做到的
问题找到了，只要杀掉当前进程以及守护进程，问题也就暂时解决了。没有找到根源，问题还是可能被利用，继续写入挖矿程序，我们先思考一下漏洞在哪里呢？
上面分析出来是因为 redis 的漏洞导致的？想一下我们的 redis 是如何安装的，我当初测试一个需要登录才能使用的应用程序，登录的方式是关注公众号，然后获取授权码去解锁使用。就使用 redis 存放了临时 token ，安装 redis 的时候直接就是裸奔在空气中，没有密码。
可以使用命令检测一下，例如我的公网 IP 是 110.110.110.110。 只需要使用命令 redis-cli -h 110.110.110.110 -p 6379 就直接可以连上我的 redis 服务了。
image
通过云盾安全预警查看到《【漏洞预警】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:
安全放心上
长呼一口气之后，想起了一个《亡羊补牢》的故事。
网友评论