安全与方便始终是对立的，然而运维人员忽视系统安全方面的建设，带来的后果将是非常严重的，以下是一台未上线服务器***后的***经历。
一、出现异常，排查原因
发现异常是通过远端监控脚本发现访问网站时断时续，使用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注入了***，一步一步***到服务器。数据库方面处理就不详细介绍了：
检查生产库的表结构，删除多余表。
然后备份所有生产库。
停止mysql
删除datadir目录所有文件
重启mysql
导入此前备份数据库
四、彻底扫除尾巴与隐患
通过上面的步骤已经能解决服务器被***作为***工具的问题了，但是系统是否还有***隐藏，是否安全还需要加个问号。
作者要介绍的方法是，使用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安全防护一定做到事前，在被******后处理会更麻烦，知道系统安全加强到一定程度，***很难***系统。
因本人对安全方面涉及不深，此篇文章只是记实阐述我的处理经过，很多地方经验欠缺，如有大神，不吝赐教
虚心学习才能进步，知识共享共同进步