linux服务器 kdevtmpfsi solrd 病毒处理 记住一定要多删除几次。重启

所有中病毒  无非是cpu内存占用高  一定要断公网地址  修改root密码 删除history历史记录 history -c  映射端口也要注意   

solrd病毒

公司服务器负载突然上来了，用top命令查看，发现了一个很诡异的进程

然后grep这个进程的进程号，发现是运行在/tmp/.solr/solrd下；于是赶紧杀进程，删程序，负载就下来了；但是还没有完，用top命令再次查看的时候惊奇的发现有一个solr.sh的脚本在执行，通过grep它的进程号，发现还是运行在tmp下，但是奇怪的是明明脚本在运行，但是在对应路径下找不到该脚本，用find全局查找也找不到；为了不让其继续作恶，赶紧把进程杀了，在阿里云控制台添加了安全组，只允许80，443的请求进来；

这还没有完，过一会，solr.sh脚本又开始运行了，但是正主solrd却没有运行；因该是由于端口限制程序包进不来了；于是赶紧做了如下措施：

1、修改服务器密码；
2、检查/etc/passwd、/etc/group文件有没有不熟悉的用户；
3、检查计划任务，这一查不要紧，还真有东西；但是清除计划任务时，发现没有权限，我可是root啊，开玩笑没有权限；于是检查了特殊权限，发现还真有，一个个清除了，又检查了/etc/cron.d/、/etc/cron.daily/、/etc/cron.deny、/etc/cron.hourly/、/etc/cron.monthly/、/etc/crontab、/etc/cron.weekly/无一例外，都有计划任务，还都加了特殊权限；

4、用last查看最近登录的用户；
5、分析/var/log/messages、/var/log/secure日志

6、将chattr命令mv到其他地方，并修改名称，位置只有管理员知道，并将/var/log/wtmp、/var/log/secure、/var/log/cronrot加-a特殊权限，否则这些日志被清理后很恶心；最后一定要清除mv chattr命令的痕迹别让不法分子知道了你把chattr命令移动道理哪；

知识点

chattr

管理 Linux 系统中的文件和目录，除了可以设定普通权限和特殊权限外，还可以利用文件和目录具有的一些隐藏属性。
chattr 命令，专门用来修改文件或目录的隐藏属性，只有 root 用户可以使用。该命令的基本格式为：

[root@localhost ~]# chattr [+-=] [属性] 文件或目录名

+ 表示给文件或目录添加属性，- 表示移除文件或目录拥有的某些属性，= 表示给文件或目录设定一些属性。

 kdevtmpfsi病毒

Linux Centos 7 环境下的一台服务器CPU直接被打满，上服务器 top 命令看到了一个未知的 kdevtmpfsi 疯狂占用中，情况如下图

网上搜索了一下 kdevtmpfsi 是一个挖矿病毒，大多数都是 redis 程序侵入，而且受害者还不少，通常比较明显就是 占用高额的CPU、内存资源。

问题原因：

阿里云公布的威胁快报：https://yq.aliyun.com/articles/741602

Redis RCE导致h2Miner蠕虫病毒，其利用Redis未授权或弱口令作为入口，使用主从同步的方式从恶意服务器上同步恶意module，之后在目标机器上加载此恶意module并执行恶意指令。在以往常见的攻击者或蠕虫中，其大多都沿用登陆redis后写入定时任务或写ssh key的方式进行入侵，这种方式受权限与系统类型影响并不一定能够成功。而此次使用redis加载module的攻击方式，可以直接执行任意指令或拿到shell交互环境，危害极大。

问题解决：

第一步：cd 命令切换到自己 Redis 的安装目录下，然后删除该目录下的 red2.so 文件以及以 kinsing 开头的所有文件。

第二步：crontab -l 命令先看看 crontab 的定时任务列表

因为我这台服务器根本没设置过 crontab 定时任务，而且这是两个国外(伊朗，俄罗斯)的陌生IP，所以可以断定这就是罪魁祸首。

第三步：crontab -e 命令进行定时任务编辑(该步骤很重要)，去除陌生的定时任务(要求在root用户下)，在打开的文本中，按 i 进行编辑删除，编辑完后按【Esc退出】键退出编辑，再输入 :wq 强制性写入文件并退出。

[root@VM-0-9-centos /]# crontab -e

第四步：ps -ef|grep kdevtmpfsi  命令查看 kdevtmpfsi 的进程，并且使用 kill -9 PID 杀死kdevtmpfsi 对应的进程

 第五步：ps -ef|grep kinsing  命令查看kdevtmpfsi程序的守护进程kinsing  ，并且使用 kill -9 PID 杀死对应的进程

 第六步：find / -iname kdevtmpfsi 命令再次确定kdevtmpfsi文件所在位置以便删除，使用 rm -rf 所在位置 删除 kdevtmpfsi 程序

第七步：find / -iname kinsing 命令再次确定 kinsing 文件所在位置以便删除，使用 rm -rf 所在位置 删除 kdevtmpfsi 程序

 第八步：cat ~/.ssh/authorized_keys 查看是否有陌生的的公钥，有则删除掉，

问题防护

• 把异常的IP地址，入站及出站全部封禁
• 不定期更新 Redis 服务密码，禁止使用默认端口，非必要不暴露在公网或绑定指定IP
• 启用ssh公钥登陆，禁用密码登陆。
• 完善安全策略，入口流量，非必要一般只开放 80 443 端口就行，出口流量默认可以不限制，如果有需要根据需求来限制。
• 防火墙能用的尽量用起来，有条件可以上付费的。

经过几天的观察，服务器运行正常。