Jay's some notes

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

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

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

http://65.108.48.150/f2201rr/f.sh

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

• 安装矿机应用；

  # tree /etc/.system/rtm/
  /etc/.system/rtm/
  |-- config.json
  |-- config_background.json
  |-- miner.sh
  |-- scan
  |-- xmrig
  `-- xmrig.log

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

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

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

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

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

I. 恢复快照后不能上网

第一时间提了阿里工单，但是阿里解决问题的速度太慢了，解决问题后也没有告知处理方案，因为后面的服务启动还有问题，我需要反复恢复快照对比。该问题最后确定为更改专有网络后再恢复经典网络快照需要手动更改如下网络配置；

• 静态ip配置；
• 路由配置；
• dns配置；

II. 防火墙规则变化

恢复网络后服务启动还是异常，一顿分析后确定原来服务依赖通过tcp socket做进程通信，并且该tcp还必须是外网ip。而防火墙服务直接禁止掉外网访问。

$ sudo iptables -nL
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

这波操作相当业余，和刚才把redis无认证的服务暴露在公网一样，这里相当危险和低效。

但是没有办法所以直接简单粗暴的添加了一条入口规则，允许该外网ip的所有输入，这样暂时地利用防火墙把这里的进程通信过滤。

iptables -I INPUT -s $ip -j ACCEPT

III. mac地址变化导致服务认证失败

之后服务正常启动，但是提示服务未授权，心里一凉。怀疑升级网络类型导致服务mac地址变化，这里授权服务不可用。这里应用是由之前云服务供应商提供，早就倒闭了，不可能重新授权。心里做了最坏的打算，可能直接导致上万终端设备不可用，此时已经停服了2天，大量售后电话打过来，当时万念俱灰。

• 抱着一丝希望还是询问了以前的云服务供应商，2个技术不回复，一个老总直接告知放弃，团队解散了好几年。
• 询问阿里云是否还可以恢复经典网路，告知不行。

没有办法，硬着头皮分析了这里的认证策略，逆向了安全库，发现可能还有一线生机。原来这里的授权认证策略相对简单，直接通过mac和cpuid做了简单md5，认证的时候直接对比。

最后破解了这里的认证机制，重新生成了证书。

IV. 设备连接失败

本以为到这里了应该正常了，但是设备却没有上线，并且放开设备连接端口后出现了大量异常联调的tcp soket，抓包分析后发现设备正常上报uid后服务主动断开，看起来这里设备认证也失败了？

这里定位到设备端口带宽异常再到怀疑可能是设备连接异常了花了整整一天时间，因为从现象来看，一旦白名单设备端口后所有tcp socket都异常，看起来非常像ddos攻击。

最后没办法，只有直接分析这里的对应端口应用服务，该服务通过go实现，并且没有太好的逆向工具，但是还是顺着一些异常现象找到蛛丝马迹。最后确定该负载均衡服务在读取redis服务的配置时候解析失败了，未给设备返回正确的mqtt连接配置，导致几千个设备一直在重试，从而大量的socket 状态异常，同时端口带宽也异常。手动在redis设置该keys，最后正常。

至此4天过去了，服务恢复正常，现在回忆起依然心惊胆战，一次错误的运维完全可能导致一家小公司破产。

阿里云在整个过程虽然给予了技术支持，但是也显得相当不专业，比如是否可以恢复经典网络，多次告知我不行，最后通过商务协商又说可以。并且对于网络类型只是强制告诉我必须升级，并且没有告知可能风险。

同时之所以会出现该安全漏洞，完全是因为之前云服务提供商安全意识薄弱，不过也正是因为薄弱的安全设计，给了我们逆向分析破解的可能。