这里记录一次无效的运维，称之为无效，更多的是我人为原因引起的。

1月2号阿里云提示服务器执行恶意脚本，当时正在休元旦，直接忽略。

1月4号上班的时候查看了完整提示，分析了启动上下文，确定服务器被redis恶意注入矿机脚本。能够被注入原因很简单，把无认证的redis直接暴露了在公网，因为该服务器是从其他公司过户过来，稳定运行了5年，接手后保持原来的端口安全策略也没有注意。

第一时间分析了该脚本启动脚本，发现其破坏了大量系统安全策略，同时预留了大量系统认证的后门，例如：

• 安装矿机应用；

• 杀死阿里云安全组件；
• 关闭selinux，开门狗等系统安全组件；
• 预留ssh认证公钥，预留系统系统登录账号；

而该脚本注入应该是利用redis持久化，把keys保存在了/etc/crontab，好在我们应用工作在docker，并未关闭掉阿里的安全组件，所以阿里第一时间通知我。同时，该脚本只是注入矿机执行，并没有破坏原来的系统应用，也算是盗亦有道了。

正常来说我只要按照该脚本关闭矿机启动，删除应用，恢复安全策略就行了，但是手贱顺便按照阿里提示升级了网络类型从经典网络到专有网络，噩梦就此开始。

之所以升级网络类型，是因为这前后阿里曾打电话告知，3月份之前不升级会导致网络不可用，这台机器几年不运维一次，所以干脆一劳永逸。

升级完网络类型后服务启动异常，第一时间没有定位到原因，所以直接考虑恢复快照。

第一时间提了阿里工单，但是阿里解决...