先在这里交代一下背景。
该公司规模较小，且历史包袱重。服务器在某云平台，且N年无人维护。
服务器使用的系统是 Centos6.5
风起
某天，诸多业务不可用。定位到某台服务器A，随后登陆服务器查看，发现CPU资源被不认识的进程占用，内存也告急。意识到可能是病毒，第一反应，先kill掉进程，随后去云控制台修改登录密码。
修改密码遇到麻烦事
病毒进程能被kill，但在云控制台修改密码失败。基本可以断定云厂商在服务器的内置管理程序被病毒干掉了，那只能提交工单给某云，让其工程师协助恢复内置的管理程序。
某云工程师在处理过程中，反映内存占用太高，无法继续安装。
内存占用很头疼
那就先解决内存占用问题。free -hm命令，查看-/+ buffers/cache占用近乎95%的内存，而且top中没有找到哪怕占用1%内存的进程。神奇。正常情况下，内存的使用可以简单的划分为：
- 系统本身占用
- 进程占用
那么既然进程没有占用，那肯定是系统本身占用了。有可能是系统运行过程中产生的缓存，这个容易判断，重启即可。
重启后，内存占用问题还在，排除了系统运行过程中各种原因导致的缓存。那么可以猜测是系统内核的配置参数，使系统在刚启动，就占用了超高的内存。
查看/etc/sysctl.conf文件就能够验证猜测，不查不知道，一查吓一跳。/etc/sysctl.conf文件异常的大，里面有大量的重复的配置，形如vm.nr_hugepages=xxxxxx、kernel.nmi_watchdog=0等（回过头才知道，这些奇怪的配置是病毒添加的），这些配置使系统开机就分配掉了大量内存。
知道问题，解决就简单了，从正常的同系统服务器上，或者某云上提供的默认配置示例，copy一份覆盖掉现在的被污染的/etc/sysctl.conf，随后重启，内存占用问题解决。
那么某云工程师也能正常安装管理程序了，工单处理完成，密码修改成功，一切看起来很美好。
机缘巧合
用修改后的密码登陆服务器，先把业务恢复，然后寻找病毒藏在哪里。不一会，CPU又开始飙高。病毒又卷土重来了。
看来，这个病毒会定时触发，crontab -l一下，果然，定时执行了 /etc/newinit.sh脚本，得来全不费功夫，这个脚本就是病毒咯。
google该病毒脚本的一些代码，找到对应的杀毒脚本。病毒问题解决: )
当然，分析病毒脚本到底做了什么事，还是有必要的。
窥探病毒的真面目
下面开始分析这个病毒脚本干了什么事，由于篇幅原因，只列出比较关键的操作。
修改进程能打开的最大文件数
关闭各个系统的防火墙
关闭SELINUX
清除所有iptables规则
关闭watchdog
清除操作日志
将各个常用命令curl、wget等改名字
卸载各个常见共有云的内置管理程序
声明矿池地址等
安装unhide gawk
批量杀掉一批有特征的挖矿病毒（足足写了486行的命令来干掉同行，看来挖矿病毒也卷起来了:) ）
通过一些特点干掉其他进程（进程的完整命令里带不带/tmp、进程的cpu占用有没有超过40%，如果满足条件，就认为是同行，也干掉）
还有80行命令，用来干掉同行
添加iptables规则屏蔽掉同行的端口（5555，7777，10008等）
修改/etc/resolv.conf
藏匿ps、top、pstree命令（将原来的命令改名，写假的文件替代原来的命令）
写crontab脚本，来定时执行本脚本（保活）
在/root/.ssh目录下，放一个公钥，用来让黑客轻松登陆
下载了一个txt文件（黑客的小幽默，这个txt里面只有一个笑脸 :) ）
下载挖矿程序
启动挖矿程序
下载并执行了一个脚本A
脚本A里最后下载并执行了脚本B
下面看看脚本A和B里干了啥
脚本A
升级除了procps* psmisc*以外的软件（加固系统安全？防止同行入侵？不升级管理进程的工具）
下载了1.0.4.tar.gz 和 pnscan.tar.gz (Masscan和pnscan)
解压并make安装了上述两个程序
注：Masscan 是端口扫描工具，pnscan是一个病毒，使用redis漏洞。脚本B
使用pnscan扫描ip段内的所有6379端口（找redis）
尝试使用无密码、弱密码登陆可能的redis服务
写了个攻击脚本，如果上步登陆成功了，就执行这个攻击脚本，下一台服务器就沦陷了
下载了俩二进制文件，用来做端口扫描和攻击
总的来说：
使用将近600行代码，用来杀掉同行:)
病毒会在感染本服务器后，继续扩散感染其他服务器。方式是扫端口，redis未授权访问漏洞
病毒下载的所有工具/文件，都来自一个固定的ip（当然了，八成也是一个受害者）
病毒会将进程管理、文件下载工具等命令进行改名隐藏。增加了解决问题的难度。
对症下药
依据病毒的操作，进行逆操作就可以干掉病毒了。
比如：
清理定时器、脚本文件
封锁病毒用到的ip、ssh公钥
恢复chattr、top、ps等命令文件
修改/etc/resolv.conf
# 例如：腾讯云
# 183.60.83.19
# 183.60.82.98
# 命令：
echo -en "nameserver 183.60.83.19\nnameserver 183.60.82.98\noptionstimeout:1 rotate\n" > /etc/resolv.conf- 开启防火墙等安全模块、安装云供应商的管理程序
- 等等，不再一一赘述
其实，目前阶段的挖矿病毒，原理其实大同小异。找到薄弱的点、展开攻击、挖矿、进一步扩散。
解决方法也相差无几，不过病毒和杀毒，两者就是互相进化、无休止的对抗过程，一方有新计谋，另一方就有新对策。
解决一个特定的病毒，可能并不困难，但重要的，依旧是做好最全面的防护，补齐短板，不给黑客们可乘之机。
再回首
在这段时间，不止A服务器被病毒感染了，B服务器也有类似的情况。
两个病毒的不同之处：
- 触发方式不同：有个是将病毒脚本放在某个目录下，定时触发；有个是定时从某个网址拉取脚本后执行。
- 病毒脚本不同
- 入侵方式不同（SSH口令爆破、redis未授权访问漏洞）
- 挖矿工具、矿池不同（有w.apacheorg.xyz、w.apacheorg.top、也有47.100.95.105）
相同点：
- 目的相同，都是使用服务器资源来挖矿
- 都是通过crontab定时脚本来保活
- 脚本大体流程相同
总的来说，这些服务器的安全问题相当之严重，被不止一批黑客随意使用。既然黑客能神不知鬼不觉的入侵进来，那他能干什么事，也就不得而知了。
一些想法
总结起来，这次服务器被病毒感染的原因有以下几点：
- 为了方便，服务器全都向外网开放了22端口
- SSH弱口令，甚至所有的root密码都一致
- 服务器内应用服务的密码简单（mysql密码简单、redis无密码等）、版本低。
- 系统版本过低，从未安装过安全补丁。Centos6在2020.11已停止维护。
上述几个原因，每个都是相当危险的，SSH弱口令会被轻易爆破，redis无密码且版本低会被黑客利用redis的漏洞，将文件写入到本地，从而被侵入。系统未打过补丁，会降低黑客利用系统漏洞的成本等等。
对应的解决方法：
- SSH更换端口，不使用22
- 替换掉SSH密码登陆，改用公钥
- redis一定要设定密码，redis尽量尽量尽量不暴露在外网
- mysql、redis、mq等基础软件，一定要关注安全更新
- 操作系统要使用支持维护的稳定版。比如Centos7会维护到2024年。
- 操作系统一定要及时安装安全补丁
- 生产环境一定要放在完全封闭的内网，仅通过跳板机/堡垒机操作
- 权限管理尽量细致，避免root滥用的情况
以此为鉴，要对服务器安全、数据安全有足够的重视，不可仅顾业务拓展，而无视了业务运行之基石。
参考
future-is-centos-stream (一声叹息)
Rocky Linux (准备迎接 rocky linux)
