阿里云服务器被[crypto]攻击导致CPU爆满(已解决)

缘由

之前玩Docker并开放了2375端口和redis 弱密码 且默认6379端口 的时候，安装时未使用密码，然后还在阿里云开放了0.0.0.0的6379端口，导致出现了漏洞，

现象

1. 被安装了Docker镜像且启用了容器运行。
2. Reids多了几条任务计划的缓存数据
3. /usr/share  目录下多了 5个文件
   1. -rwxr-xr-x    1 root  root 4563624 Jul  1 17:46 '[crypto]'
   2. -rw-r--r--    1 root  root  438439 Jul 14 14:47 '[crypto].log'
   3. -rw-r--r--    1 hilde 1000    3561 Jul 13 14:05 '[crypto].pid'
   4. -rwxr-xr-x    1 root  root     279 Jul 13 14:01 '[crypto].sh'
   5. -rwxr--r--    1 root  root    4775 Jul 13 14:03 '[scan]'

看网上说的这两个挖矿病毒一般都是使用redis的漏洞，阿里云一直给我发消息，说我服务器异常，我以为是小事情，没在意，然后发下cpu与内存100%。。。。。坐不住了。

查找问题

首先是top命令也没发现什么异常，这是最奇怪的，我看网上的文章一般都会在这里发现一些异常的进程。最后使用pstree 发现了两个不对劲的进程，开了1023个进程。。。上图

问题原因找到了，我也不知道为啥top命令不会出现这两个玩意。。。可能病毒大神用什么方式伪装了吧。。。

解决病毒

首先在、usr/share目录找到了好几个crypto和pncan的文件，也没急着删除掉他们显示打开看一下，他们都在干什么，方便更干净的去删除。cat一下他们的.sh文件，也就是大致扫一眼，看看还有哪些目录下有生成文件啊，改了定时任务啊，改了什么配置啊。其实也没必要看太清。。。。只要让他们以后跑不起来就完事了。（记得吧redis的密码改成强密码啊先）

rm -rf /usr/share/*crypto*
rm -rf /usr/share/*scan*

大致看完之后，把他们删掉，再去/etc/看看，因为上图的sh脚本，差不多相当于拿着地图去删文件了。
最后看看自己的用户啊，组啊有没有新的奇怪的用户和组
cat /etc/passwd
cat /etc/group

再去找找crontab有没有不认识的定时任务。 最后重启服务器，看看有没有问题，再等一两天看看解决了没有。

最后

之后发现在我根目录 ls -a 发现给我怼了一万多个.r.什么的文件。。。。淦，删删删。

我的问题其实是根据这位博主的文章先进行的修复。。大家可以先看他的，再看看我的查漏补缺

#############

一、事情缘由

• 前段时间给大家录制《玩转Docker》教学视频，链接参考www.bilibili.com/video/BV1BK…。，为了更好的演示，就在阿里云搞了一个云服务器，自己本地连接。
• 云服务器到手之后，为了可以让自己本地可以连接到阿里云服务器上就做了如下操作：
  • 开放了ssh（port:22）端口：为了远程连接使用。
  • 开放了剩余的其他所有端口：录制教学视频时启动了相关容器，容器的一些固定端口6379等映射到了宿主机的随机端口上，为了能从公网访问到容器的内容，就开放了这些端口（这是隐患）。

​

二、原因排查

• 录制教学视频时做了一些相关演示案例，例如在云服务器中搭建了含有Redis/Nginx等服务的容器（但是Redis服务并没有设置密码），如下图所示

​

• 好家伙，就在我搭建完这些容器之后，后面云服务器就开始给我报警了。首先是CPU暴涨（这也算是挖矿的基本特征），如下图所示

​

• 接着就是安全警告

​

• 打开一看，没错，redis被攻进来了（教学视频介绍Docker 3大网络的时候，把容器的6379端口直接映射到宿主机上了）

​

• 分析原因：恶意攻击访问本地服务，上传了相关恶意脚本。
• 报警报了一两天，一开始我也没在意，后来我忍不住了，我能让你在我面前玩？？？那就开整，干死你。

三、找出挖矿机器目的地（新加坡）

• 查找进程对应执行程序地址 ls -l /proc/[pid]/exe 如下范例
  • 

• CPU暴涨，那肯定是后台有恶意程序在跑了，先top命令查看一下，果然，两个常见的挖矿病毒，crypto和pnscan

top
复制代码

​

• 这些恶意程序一般都存在/usr/share目录下，查看一下都在里面，执行下面的命令把这些相关程序都删除了

# 查看
ls -l /usr/share | gre cry
# 删除
sudo rm -rf /usr/share/*crypto*
# 确认下是否删除完成
ls -l /usr/share | gre cry
# 查看
ls -l /usr/share | gre scan
# 删除
sudo rm -rf /usr/share/*scan*
复制代码

​

• 再来查看一下网络情况，程序肯定是把本机的一些数据往外面传了，结果发现这个家伙把我本地好多的命令全部都改了，气死我了，例如下面netstate命令把我的可执行权限给删了。

# 查看网络相关信息
netstat -aptn
sudo netstat -aptn

# 查看netstat命令在哪里
which netstat
whereis netstat

# 查看一下netstat程序的相关信息
ls -l /bin/netstat
复制代码

​

• 如上图所示，netstat没有x权限（可执行权限），那就用chmod给它加下x权限，结果发现netstat不能赋值可执行权限，如下所示：

sudo chmod +x /bin/netstat
lsattr /bin/netstat
复制代码

​

• 从上图的lsattr命令可以看到，/bin/netstat有一个i权限，表示这个文件不可以被修改，也就是说不能被赋予可执行权限。这里介绍2个命令：
  • lsattr：查看文件的相关属性。
  • chattr：与lsattr对应，用来设置文件相关属性。
• 解决方法就是使用chattr命令来更改，把其i属性去除，结果如下所示，chattr命令不能执行，原因也是chattr没有可执行权限

# 将netstat命令的i属性去除
sudo chattr -i /bin/netstat
# 查看chattr
ls -l /usr/bin/chattr
复制代码

​

• 接着就用chmod给chattr去赋值可执行权限，结果发现chattr也有i属性，不能被赋值权限，唉。

# 赋值可执行权限
sudo chmod +x /usr/bin/chattr
# 查看chattr属性
lsattr /usr/bin/chattr
复制代码

​

• 哦吼，这下怎么办？chattr既不能赋值权限，也不能更改自己的属性。后来想到一种办法：
  • 我的另一台机器上有chattr命令，那就把另一台机器上的chattr命令拷贝到这台被攻击的机器上。
  • 因为另一台机器上的chattr命令是好的，所以拿过来可以直接使用。
• 输入下面的命令，把另一台机器上的chattr命令拷贝到本地，保存名为~/chattr_tmp，然后用chattr_tmp去除有问题的chattr命令的i属性（可能有点绕），如下所示：

# 将0.0.0.0机器上的/usr/bin/chattr拷贝到本地，保存为~/chattr_tmp
sudo scp ubuntu:0.0.0.0:/usr/bin/chattr ~/chattr_tmp

# 查看一下，确认是可以执行的
ls -l ~/chattr_tmp

# 使用~/chattr_tmp去除/usr/bin/chattr的i属性
sudo /home/dongyusheng/chattr_tmp -i /usr/bin/chattr
复制代码

​

• 上面执行完成之后就可以给chattr赋予可执行权限了，如下所示：

# 查看chattr的i属性被去除
lsattr /usr/bin/chattr
# 赋予可执行权限
sudo chmod +x /usr/bin/chattr
# 查看权限，已经可执行了
ls -l /usr/bin/chattr
复制代码

​

• 下面使用chattr去除netstate的i属性，去除之后赋予其可执行权限，如下所示：

sudo chattr -i /bin/netstat
sudo chmod +x /bin/netstat
ls -l /bin/netstat
复制代码

​

• 接着查看网络信息，可以看到，crypto正在往一个IP为172.104.165.191的机器上传输数据呢，IP一查是新加坡的机器。

sudo netstat -aptnl
复制代码

​

​

四、删除恶意进程

• 下面删除这些恶意进程，结果kill的时候发现kill命令也没有可执行权限，最后只好用跟上面一样的方法给kill命令赋予可执行权限

​​

whereis kill
sudo ls -l /bin/kill
sudo chmod +x /bin/kill
lasttr /bin/kill
sudo chattr -i /bin/kill
lsattr /bin/kill
sudo chmod +x /bin/kill
sudo ls -l /bin/kill
复制代码

​

• kill命令可以使用之后，杀掉这2个进程

sudo kill -9 657 604
复制代码

​

• 杀掉之后查看再次查看进程，可以看到CPU恢复正常，程序没了

top
复制代码

​

五、删除容器镜像

• 接着检查本地的容器情况（容器已经被我停止运行了，这是后面截的图片），这家伙给我构建了一个容器，里面曾跑过脚本。

# 停止运行容器
sudo docker stop 5e3defeb058c

# 查看本地所有容器, 不论是否正在运行
sudo docker ps -a
复制代码

​

• 再查看镜像，这家伙给我构建了一个镜像

# 查看本地所有镜像
sudo docker images
复制代码

​

• 我就尝试着删除这个容器，结果失败了，因为有内容被链接挂载。

# 删除容器, 删除之前需要先停止运行该容器
sudo docker rm 5e3defeb058c
复制代码

​

• 来到容器的目录下，找到这个容器相关的内容

cd /var/lib/docker/containers
sudo find . | grep 5e3defeb058c
复制代码

​

• 找到之后全部删除，一点不留情。

sudo rm -rf 5e3defeb058cd75b39740cd1584945f9a822a022b2a7c3bf025ee027017edb0f
sudo rm -find . | grep 5e3defeb058c
复制代码

​

• 然后再次删除容器还是不可以。

​

• 没办法，只能重启docker进程。下面重启docker进程，发现service程序没有可执行权限，果断给其赋值可执行权限，然后再重新启动，结果还是错误，显示systemctl程序不能执行。

sudo service docker restart
whereis service
sudo chattr -i /usr/sbin/service
sudo chmod +x /usr/sbin/service
sudosudo service docker restart
复制代码

​

• 那就果断给systemctl程序再赋予可执行权限，指挥重启docker服务，成功。

whereis systemctl
ls -l /bin/systemctl
sudo chattr -i /bin/systemctl
sudo chmod +x /bin/systemctl
sudosudo service docker restart
复制代码

​

• 再次查看容器，哈哈哈哈哈哈，容器没了。

# 查看所有容器
sudo docker ps -a
复制代码

​

• 容器没了就可以删除镜像了，如下所示，镜像也删除成功。

# 查看镜像
sudo docker iamges
# 删除镜像
sudo docker rmi b4a24c6be971
# 确认是否删除成功
sudo docker iamges
复制代码

​

清理authorized_keys 是否有免密登录设置

1. 一般这种木马必定留有后门，查看authorized_keys文件发现不对劲，黑客留下了自己的ssh秘钥，可以直接登进服务器，必须删掉。
2. 直接rm -rf提示没权限，于是chmod 777 authorized_keys赋权限，继续删，依旧提示没权限。
3. 应该是被人用chattr命令加了不可修改的属性，执行lsattr发现确实是这样，被加了ia属性，不可修改，不可删除。
4. chattr -ia authorized_keys去除这个属性，居然依旧报错，这可就怪异了，这不可能啊。
5. 思考之后，认为应该是有人篡改了chattr命令，cd /usr/bin 发现chattr文件是白色的，不是一个可执行文件。。。果然如此。
6. chmod -x chattr让他变成可执行文件，不出意外，提示没有权限。。。执行lsattr命令后，发现其被赋予了i属性，不可修改。这就操蛋了，我根本就不知道黑客把chattr命令替换成了什么，这么多的文件，不好排查。
7. 一度想放弃，后来急中生智，从本驴自己的服务器上拷贝一份chattr文件到朋友的服务器中，重命名为chattr1，执行命令chattr1 -i chattr，居然可以！
8. 恢复chattr文件后，解除authorized_keys文件的ia属性，然后成功删除该文件

root用户额外操作

1. 修复SELinux
   病毒脚本首先就会尝试关闭SELinux子系统，我们可以使用getenforce命令查看SELinux状态。
   如果你想要重新打开，可以修改/etc/selinux/config文件将SELINUX=disabled改为SELINUX=enforcing，然后重新启动服务器。
2. wget命令和curl命令会被改为wge和cur，需要修改回来
   1. 注：如果不清楚被改成什么命令了，那么用yum remove wget 进行卸载后，然后yum install wget 进行在安装，Curl同理

mv /bin/wge /bin/wget
mv /bin/cur /bin/curl
mv /usr/bin/wge /usr/bin/wget
mv /usr/bin/cur /usr/bin/curl

六、结束语

• 搞了我半天这个东西，在这里给大家总一下整个流程：
  • 第1步：云服务器告警，受到攻击。
  • 第2步：进入服务器排查，发现有恶意程序。
  • 第3步：删除恶意程序，虽然在删除的时候发现很多命令被篡改，不过在我的小聪明下解决了这些命令问题。
  • 第4步：查看容器也被攻击，删除容器和相关镜像。
  • 第5步：查看/etc/passwd是否有特殊账号存在 如：/home/hidle
    • 

     

  • 第6步：清理authorized_keys 是否有免密登录设置
    • /home/hilde/.ssh/authorized_keys【被恶意添加的账号ssh免密登录】
    • /root/.ssh/authorized_keys
  • 第7步：是否安装了恶意定时任务 
    • crontab -l用来查看定时任务信息
    • crontab -e用来编辑定时任务信息
• 这里也给大家一些在使用云服务器时的相关建议：
  • 一些重要的端口不要随便开放。
  • 如果迫不得已端口需要开放，请配置好相关密码，密码尽量不要太简单，要不然容易被暴力破解。
  • 如果云服务器不使用了，也没有功能要用，尽量关机。
• 这里我云服务器关闭了相关重要的端口，先暂时开发ssh：

​

• 另外，Docker教学视频录制完成之后，我准备重启装一下云服务器，后面不随意开放端口了。