服务器中了 aliyun.one 挖矿木马怎么办啊?

  • 回答 (1)
  • 关注 (0)
  • 查看 (69)

服务器中了aliyun.one 挖矿木马

1、crontab 中显示类似上面的任务,并且清理后又会出现。

2、 服务器负载高,CPU使用100%。存在fb972c73a8等数字的进程并且使得CPU100%

小羊驼小羊驼提问于
jkr94756回答于
推荐

回答来自于问答智囊团成员:何刚

专栏:https://cloud.tencent.com/developer/user/6827370

【原理分析】

为什么会删除不了crontab,原因是 /etc/ld.so.preload 被加载了木马so文件。

-rwxrwxrwx. 1 root root 26536 Apr 15 20:58 libevent_extrad.so

可以用如下命令进行核实并清理:

/etc/ld.so.preload #如果有只读保护,需要加 chattr –ia /etc/ld.so.preload 所以执行任何命令或者程序,都会加载libevent_extrad.so木马文件。

【木马源文件】

见附件

可以通过上面脚本分析执行的过程,从而找到清理该木马的方法 。

【清理】 注:以下操作如果删除不了或者修改不了 请执行 chattr –ia xx.xx 去掉只读属性。

一、 前置工作 上传busybox至主机 二、 清理免密登录 将机器authorized_keys、known_hosts文件命名为其他名字,重启sshd服务,与其他机器隔离,防止清理过程中被感染 三、 查看/etc/ld.so.preload中的内容,并利用busybox删除/usr/local/lib/下的动态链接库文件(文件名会变动)和/etc/ld.so.preload,删除恶意动态加载项

#./busybox cat /etc/ld.so.preload #./busybox rm /etc/ld.so.preload -f #./busybox touch /etc/ld.so.preload #./busybox rm /usr/local/lib/xxx-x.x.so -f

四、停止sshservice服务

systemctl kill sshservice

systemctl disable sshservice

五、busybox查看进程,杀掉挖矿进程和{00a022b712}进程(名称与此类似,字母加数字),并清理可能释放在下列路径中的恶意程序/usr/local/sbin(一般在此目录) 、/usr/bin/、/usr/libexec、/usr/local/bin/、/tmp/

./busybox rm /usr/local/sbin/fb972c73a8

./busybox killall -9 fb972c73a8

./busybox rm /usr/local/sbin/acpidets -f

./busybox killall -9 acpidets

六、清理/etc/bashrc文件末尾的恶意命令 七、清理/etc/cron和/var/spool/cron中的异常定时任务

grep -RE "(wget|curl)" /etc/cron*|grep "aliyun.one"|cut -f 1 -d :|xargs rm -rf

grep -RE "(wget|curl)" /var/spool/cron*|grep "aliyun.one"|cut -f 1 -d :|xargs rm –rf

八、清理/etc/rc.d/下的sshservice启动项

rm -f /etc/rc.d/init.d/sshservice

find /etc/rc.d -name "K01sshservice" -exec rm -f {} \;

find /etc/rc.d -name "S99sshservice" -exec rm -f {} \;

rm -f /etc/init.d/sshservice

rm -f /usr/lib/systemd/system/sshservice.service

rm -f /lib/systemd/system/sshservice.service

rm -f /etc/systemd/system/sshservice.service

九、清理/etc/hosts文件中被添加的信息 ------ 经过以上清理,可以把木马进行临时清理。由于没有清理干净或者漏洞,导致可能还会出现该木马,以及变异木马。 如果再次出现没有清理干净,原因: 某个进程已经加载了木马so,导致还会修改crontab任务 1、 开启audit审计功能,并加上标签方便后续进行分析。 # 安装 service start auditd yum install -y audit* # 启动 service enable auditd #监控 auditctl -w /var/spool/cron/root -pw -k marryhe #添加对cron文件的监控 auditctl –l # 核实配置是否生效。 cd /var/log/audit ; grep marryhe audit.log

ppid=1650 pid=5871 # 执行crontab的父进程,以及运行进程 comm=“crontab” exe="/usr/bin/crontab" #执行的命令 # 这样就可以监控是哪个进程对crontab进行修改。 2、如果是漏洞导致,下面溯源会进行分析。

二、mysql 数据库 数据库存在root启动,权限太高。

弱口令。

存在本地弱密码,但远程进行测试,发现此密码并不可以密码。

但用户root帐号是有远程登录的权限的。只是密码为另一个。具体需要用户自行核实该帐号的安全性。 三、redis 服务

1、Redis 使用root启动 2、空密码,直接对外 由于在8点49分已经把redis进行了删除,所以无法判断是否为此处进行入侵。该漏洞可以直接远程控制服务器,具体可以参考以下文章: https://blog.csdn.net/chenglanqi6606/article/details/100909518 四、nginx服务

Nginx日志非常少,并且没有发现可疑的请求。

并且未发现webshell相关的请求。

二、mysql 数据库 数据库存在root启动,权限太高。

弱口令。

存在本地弱密码,但远程进行测试,发现此密码并不可以密码。

但用户root帐号是有远程登录的权限的。只是密码为另一个。具体需要用户自行核实该帐号的安全性。 三、redis 服务

1、Redis 使用root启动 2、空密码,直接对外 由于在8点49分已经把redis进行了删除,所以无法判断是否为此处进行入侵。该漏洞可以直接远程控制服务器,具体可以参考以下文章: https://blog.csdn.net/chenglanqi6606/article/details/100909518 四、nginx服务

Nginx日志非常少,并且没有发现可疑的请求。

并且未发现webshell相关的请求。

【安全建议】 一、平台建议 1、安全组加固

目前的配置就像家里并没有上锁,所有人都可以进行出入。这样存在很大的安全隐患。 建议只开放需要的几个端口,如:

ssh 登录 tcp 22端口

nginx WEB服务器 tcp 80 或者 自定的端口

mysql 服务器 限制IP访问 3306

redis 服务 限制IP访问 6379

2、开启定期自动快照 二、数据库建议 1、定时进行数据备份 2、禁止数据库对外,如果一定需要,建议限制IP。 3、改为非root启动数据库 三、redis 建议 1、配置bind选项,限定可以连接Redis服务器的IP,修改 Redis 的默认端口6379 2、配置认证,也就是AUTH,设置密码,密码会以明文方式保存在Redis配置文件中 3、配置rename-command 配置项 “RENAME_CONFIG”,这样即使存在未授权访问,也能够给攻击者使用config 指令加大难度 四、web服务

禁止root启动。使用普通的帐号运行nginx。

扫码关注云+社区

领取腾讯云代金券