服务器被黑之后的排查经验分享
2023年3月6日，对于我注定是不平凡的一天，来到公司，悠闲的吃完早餐，打开电脑例行巡检，发现公司内网jenkins服务器、k8s集群、ES服务器CPU利用率直接拉满，top命令看不到任何异常，服务器重启也不起作用，甚至去了机房拆机检查，也不是没有收获，检查出一台服务器的内存条坏了一根。在没有排查除问题的情况下，开始怀疑设备被黑了，但是用top命令看又一切正常，没有证据证明被黑。此时灵光一闪，何不用cat命令看看top命令，这一看不要紧，简直吓一跳，top命令竟然被替换了，它长这样：
于是，新开了一台干净的系统版本一致的机器，把top命令copy了一份到被黑的机器上（在这之前要先用chattr -ia /usr/bin/top and chattr -ia /usr/sbin/top，解除限制，否则会替换不成功）；然后删除/usr/sbin/top命令，此时执行top命令会提示找不到命令，因为它把top的环境变量整到了sbin目录下，此时要么将/usr/bin/top超链接到/usr/sbin/top下，要么重启，要么重新添加top的环境变量。
紧接着查看了etc目录下cron.d/ cron.daily/ cron.deny cron.hourly/ cron.monthly/ crontab cron.weekly/；果不其然，是各种计划任务，这些文件一个不留，全部chattr -ia之后删掉，从干净的机器copy一份过来。
再进入/usr/bin/目录下，用lsattr命令遍历该目录下的所有文件，找出带有“ia”标识的文件，再去干净的机器上对比，发现凡是带“ia”标识的文件在干净机器上都没有，那么还是一个不留，chattr -ia之后删掉。如下面步骤：
chattr -ia /etc/cron.daily/ntpdate chattr -ia /etc/rc.d/init.d/ntpdate chattr -ia /etc/cron.hourly/ntpdate chattr -ia /etc/cron.weekly/ntpdate chattr -ia /etc/cron.monthly/ntpdate ********** rm -rf /etc/cron.daily/ntpdate /etc/rc.d/init.d/ntpdate /etc/cron.hourly/ntpdate /etc/cron.weekly/ntpdate /etc/cron.monthly/ntpdate ********** chattr -ia /usr/bin/crondr chattr -ia /usr/bin/sysdr chattr -ia /usr/bin/entpdate chattr -ia /usr/bin/lntpdate chattr -ia /usr/bin/initr chattr -ia /usr/bin/monitor chattr -ia /usr/bin/crond chattr -ia /usr/bin/where chattr -ia /usr/bin/execute chattr -ia /usr/bin/decode chattr -ia /usr/bin/clean chattr -ia /usr/bin/power chattr -ia /usr/bin/whereis chattr -ia /usr/bin/crontab chattr -ia /usr/bin/whereos chattr -ia /usr/bin/flush *********** rm -rf /usr/bin/crondr rm -rf /usr/bin/sysdr rm -rf /usr/bin/entpdate rm -rf /usr/bin/lntpdate rm -rf /usr/bin/initr rm -rf /usr/bin/monitor rm -rf /usr/bin/crond rm -rf /usr/bin/where rm -rf /usr/bin/execute rm -rf /usr/bin/decode rm -rf /usr/bin/clean rm -rf /usr/bin/power rm -rf /usr/bin/crontab rm -rf /usr/bin/whereos rm -rf /usr/bin/flush
然后又查看了root目录下/root/.ssh/authorized_keys，被传入了公钥，果断删除。
这个时候才想起来看它的进程，用新的top命令还是没看到它的进程，于是果断用ss -ntlp命令看陌生端口，毕竟网络通信的基础就是socket连接，果然看到了陌生的端口，一个进程名为monitor的程序起了一个大端口，那么这个monitor进程是怎么起的呢？它把程序名伪装成了ntpdate，并且这个ntpdate到处都有，需要find / -name ntpdate找到之后全部干掉。
最后，重启服务器，服务器运行正常了，再也没有CPU跑高的情况了。
随后，又装了个阿里云云安全中心的agent，让其做了个扫描，扫描发现是一个叫Rootkit的病毒。
处理方式：清空/etc/ld.so.preload文件，也可以删掉，这个文件在干净的机器上是没有的。它定义了ld.so.preload模块的加载路径。然后执行rm -rf /etc/ld.so.preload文件。再检查/etc目录下的一些rc开头的目录：rc0.d/ rc1.d/ rc2.d/ rc3.d/ rc4.d/ rc5.d/ rc6.d/ rc.d/ /etc/rc.local文件、/etc/init.d/目录下也会有一些残留的文件或者配置，需要删掉。然后重启服务器即可。
后来又将公司出口路由器上映射的端口做了清理并清理了一批VPN账号，取消了堡垒机的映射。上面的方式只能作为应急使用，给重装系统，迁移服务争取时间，最终将服务迁移到干净的系统之后，还是需要将被黑的机器重装系统，这样是最妥善的处理方式。希望能给广大运维朋友带来一些帮助。
https://www.cnblogs.com/zhangzhide/p/15223446.html #我的另一篇关于被黑的一篇文章，二者可以结合来看。
