排查了一周，写个总结吧。
第一轮分析
由于后端服务器访问数据时总是报java.net.SocketException: Connection reset
从这一步开始排查，排查后发现数据量不大的几个表做连接查询时总是报慢查询。
到这一步感觉是数据的问题，优化了一下索引和innodb_buffer_pool_size配置参数、
配置完了，好了一会，但是没完全好。过一阵查询还是还是报Connection reset
用top命令查看，load average 长期超过核心数，这个情况就必须优化了
补一下查看核心数命令
下面查看的是物理核心数 逻辑核心数 和线程数
[root@192 ~]# cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l
1
[root@192 ~]# cat /proc/cpuinfo| grep "cpu cores"| uniq
cpu cores : 2
[root@192 ~]# cat /proc/cpuinfo| grep "processor"| wc -l
4最后一个线程数也可用下面这个命令
nproctop命令排查下来后发现cpu占用最高的是mysql cpu占用才50%，优化完配置效果有提升但是不大。
第二轮分析
那么接下来应该排查什么呢？问了一遍通义灵码
应该排查io和网络
使用ss -p命令打印了一个列表，如下
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp ESTAB 0 0 192.168.88.131:43626 51.91.220.237:https
tcp ESTAB 0 0 192.168.88.131:55568 209.141.39.182:https
tcp ESTAB 0 0 192.168.88.131:42362 192.168.1.131:3306 users:(("java",pid=30139,fd=92))
tcp ESTAB 0 0 192.168.88.131:55546 209.141.39.182:https
可以看到，有两个异常的ip连接，而且ss -p命令还没有显示进程号，这就很诡异了。
猜想可能是病毒替换掉了对应的shell命令，不管三七二十一，先用杀毒软件clamav扫描一波
yum install -y epel-release
yum install clamav clamav-update
sudo clamscan -r / > scan_results.txt
cat scan_results.txt|grep FOUND找到4个病毒
文字版如下
[root@database ~]# cat scan_results.txt|grep FOUND
/usr/bin/crond: Win.Trojan.Tsunami-5 FOUND
/usr/bin/where: Win.Trojan.Tsunami-5 FOUND
/usr/bin/execute: Win.Trojan.Tsunami-5 FOUND
/usr/lib64/libstdc++.so: Unix.Trojan.Prochider-9821784-0 FOUND由于病毒都在系统目录。为了不影响系统功能，开个同版本的centos虚拟机，对对应的bin目录替换成正常的系统文件
替换过程也一波三折，大多数病毒文件加了 i a的不可变属性，需要先去掉才能替换。
比如对上面的/usr/bin/crond去掉不可变属性使用下面的命令
sudo chattr -i /usr/bin/crond
sudo chattr -a /usr/bin/crond
去掉之后可以执行对应的copy和rm命令了。
删除之后负载并没有下降。怀疑可能存在隐藏进程。通过搜索找到一个工具unhide
安装
yum install unhide执行
unhide proc执行后把出现的进程id都kill掉
这个进程很狡猾
冒充busybox kthreadd ntpdate，全kill掉一遍之后 load average降低为原来的一半了。
第三轮分析
本以为这样就相安无事了。
第二天发现，mysql的查询还是慢。这下就得好好排查了
systemctl status mysqld发现mysql重启时间不对，总是整点重启，这下又得排查了。
查看隐藏进程发现，昨天有一些进程又回来了
unhide proc这下先解决bin目录文件被篡改的问题
使用两个方法
rpm -Va #这个是rpm数据库校验有没有篡改
md5sum /usr/bin/top #这个用来查询对比正常系统对应文件的md5值替换的文件不完全统计如下
crontab
moduli
nologin
rc.local
ssh_config
sshd_config
top
whereis
crond
ntpdate用正常的系统文件替换完之后 top下，占用高的进程显原型了。
记录下这里历史时刻，后面的清理都是针对它展开的。
kill掉这个pid之后，发现它过一段时间又重启。所以逐个清理了/etc/cron.d/下面的定时
发现这个定时很想伪装成ntpdate，
伪装的文件如下
lrwxrwxrwx 1 root root 17 1月 2 2021 K60ntpdate -> ../init.d/ntpdate索性我就先卸载了ntpdate，然后全局搜索文件
find / -name "*ntpdate*"找到的全干掉。
然后使用journalctl -b查看最近的日志，确认是伪装ntpdate的问题。没有其他问题作祟。
系统修复
这下全干掉之后开始着手系统修复。
对rpm -Va校验有问题的逐个分析，对有问题的软件包一律reinstall，对有问题的命令一律替换。
对ssh命令配置用正常系统上的进行替换。删除用不到的vnc等远程空值软件。
对系统所有用户设置强密码。
逐个排查定时任务文件和内容
逐个排查启动文件的内容。
病毒样本
关于病毒样本
光顾删和替换了，目前留一个bin目录下的lntpdate和etc的crond下的定时0clock
病毒样本传到VirScan和腾讯哈勃了，都是未检出。从这方面看，linux上的防病毒能力还是任重道远。
virscan报告如下
VirScan - 多引擎文件在线检测平台
VirScan - 多引擎文件在线检测平台
哈勃报告如下
腾讯哈勃分析系统
腾讯哈勃分析系统
