生产环境-linux-网站被挂******经历

    安全与方便始终是对立的，然而运维人员忽视系统安全方面的建设，带来的后果将是非常严重的，以下是一台未上线服务器***后的***经历。

一、出现异常，排查原因

    发现异常是通过远端监控脚本发现访问网站时断时续，使用ssh工具连接会经常断掉连接，无法开展工作。

使用其他服务器对另一个网卡ip进行ssh连接，可以登录服务器，初步怀疑网卡异常或者流量异常。

    分别使用ifstat、iftop、nethogs查看连接异常网卡流量信息（对几个流量分析工具进行对比，各有千秋）：

1使用ifstat

wget http://distfiles.macports.org/ifstat/ifstat-1.1.tar.gz

cd ifstat-1.1 ./configuremake make install  都是老套路

ifstat -a 加入监控lo

2使用iftop监控那个端口流量

 p  可以显示连接端口

3使用nethogs监控每个进程流量

yum换rpel源

wgethttp://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm

yum install nethogs

nethogs  eth0

效果展示ifstat：

                        可以看到服务器流量异常时，流量的变化情况。

效果展示iftop：

 

                        可以看到哪个PID进程导致流量过高

效果展示nethogs：

                        

二、查找真凶

通过上面分析，造成网站打不开的原因就是有进程大量发送数据包到某个ip（其实是阿里的服务器）的80端口，导致服务器网络阻塞，但是通过以上的工具，发现此***相当的狡猾，无法发使用的那个进程。

 

在使用netstat、ss通过端口获取***进程失败后（后面才知道netstat、ps等命令已经被***感染）

 

可以使用top工具，此***在大量发包时肯定会造成资源的消耗

通过锁定发现了两个进程有大量的嫌疑：

通过ps命令找到进程执行的目录：

/usr/bin/sshupdate-bootsystem-insserv
/tmp/GuiBger

通过持续观察发现时有agent进程一闪而逝，在使用find / -name agent 后

# ll /usr/bin/bsd-port/
总用量 1120
-rwxr-xr-x. 1 root root 1135000 12月 25 11:20agent
-rwxr-xr-x. 1 root root       4 12月 25 11:20 agent.conf
-rw-r--r--. 1 root root      69 12月 25 11:50 conf.n
-rw-r--r--. 1 root root       0 10月  9 19:36 getty

 

     此时，相关的可以进程都找到了，通过测试，在网络阻塞时，删除sshupdate-bootsystem-insserv、GuiBger两个进程后，网络流量立即正常。而agent则怀疑是与***的通信进程，用于接收命令（瞎猜的）或者监控上面连个进程。

三、解决真凶 

    找到这3个进程并不意味结束，因为他们很可以是开机自启动程序，所以要在找到他们的开机自起的配置文件，我通过一个脚本实现这个功能：

#!/bin/sh
echo > /tmp/find_init.log
function ergodic(){
         forfile in `ls $1`
         do
                   if[ -d $1"/"$file ] #如果 file存在且是一个目录则为真
                            then
                            ergodic$1"/"$file
                   else
                            localpath=$1"/"$file #得到文件的完整的目录
                            localname=$file       #得到文件的名字
                            #做自己的工作.
                            echo  $path 
                            rootkit_init=`cat$path | grep sshupdate | head -n 1`
                            if[ -z $rootkit_init ];then
                            echo  "sed -i 's#$rootkit_init##g' $path">>  /tmp/find_init.log
                            fi
                   fi
 
         done
}
INIT_PATH="/etc/init.d"
ergodic $INIT_PATH
cat /tmp/find_init.log

这个脚本功能很简单，通过遍历/etc/init.d目录所有文件，使用grep搜索进程名关键词，将含有这几个进程的文件找出来。

结果如下：

sed -i's#/usr/bin/sshupdate-bootsystem-insserv##g' /etc/init.d/DbSecurityMdt
sed -i's#/usr/bin/sshupdate-bootsystem-insserv##g' /etc/init.d/insserv

还真有自启动配置，迅速删除之

 

在删除这个***命令时会遇到无法删除的问题，这个很简单：

lsattr /usr/bin/sshupdate-bootsystem-insserv
查看文件的隐藏权限
-------i------e- sshupdate-bootsystem-insserv
发现被限制删除操作了
chattr -i  /usr/bin/sshupdate-bootsystem-insserv
取消影藏权限，然后再删除，完成。

    通过查看数据的表结构，发现***是从数据库***进服务器的，因为没有上线，方便开发测试在密码强度上使用了弱密码，所以被***破解了mysql的root账户密码，在mysql注入了***，一步一步***到服务器。数据库方面处理就不详细介绍了：

1. 检查生产库的表结构，删除多余表。

2. 然后备份所有生产库。

3. 停止mysql

4. 删除datadir目录所有文件

5. 重启mysql

6. 导入此前备份数据库

   
   

四、彻底扫除尾巴与隐患

    通过上面的步骤已经能解决服务器被***作为***工具的问题了，但是系统是否还有***隐藏，是否安全还需要加个问号。

    作者要介绍的方法是，使用linux系统的杀毒软件，作者使用的是avg，还是蛮好用的，被***感染的netstat、ps等命令和影藏文件就是通过avg扫描出来的。

    简单介绍下avg的安装和使用

avg杀毒软件{

下载地址:http://free.avg.com/us-en/download-free-all-product

启动 service avgd start

更新：avgupdate  

扫描：avgscan 加“要扫描的目录地址” 比如说sudo avgscan /etc

复制代码

-a 扫描内部档案

-l 自动愈合受感染的对象

-t 自动删除受感染的对象

-u 自动移动感染对象到隔离

    作者扫描时:avgscan /  

    avg会列出可以文件：找出删除即可，如果无法删除，上文有提过，先查看隐藏权限

五、总结

     最后总结下，之所以被***在linux服务器上挂马，是因为方便开发上线产品，关闭了iptables，数据库使用了弱密码，这个教训很深刻，所以使用iptables限制服务器的端口非常有必要，如果可能最好selinux开启。当然定时更换各账户密码也很重要！同时加强linux安全防护一定做到事前，在被******后处理会更麻烦，知道系统安全加强到一定程度，***很难***系统。

    因本人对安全方面涉及不深，此篇文章只是记实阐述我的处理经过，很多地方经验欠缺，如有大神，不吝赐教

    虚心学习才能进步，知识共享共同进步