服务器被攻击了咋个办？？？
安全总是相对的，再安全的服务器也有可能遭受到攻击。作为一名安全运维人员，要把我的原则是：尽量做好系统安全防护，修复所有的已知的危险行为，同时，在系统遭受到攻击后能够迅速有效地处理攻击行为，最大限度地降低攻击对系统产生的影响。
处理服务器遭受攻击的一般思路
1，切断网络（大剪刀、大钳子剪断公司网线）
所有的攻击都来自于网络，因此，在得知系统正遭受黑客的攻击后，首先要做的就是断开服务器的网络链接，这样除了能切断攻击源之外，也能保护服务器所在网络的其他主机。
2，查找攻击源
可以通过分析系统日志或者登录日志文件，查看可疑信息，同时也要查看系统都打开了哪些端口，运行了哪些进程，并通过这些进程分析哪些是可疑的程序。这个过程要根据经验和综合判断能力进行追查和分析。
3，分析入侵原因和途径
可能是系统漏洞，也有可能是程序漏洞，一定要清楚是哪个原因导致的，还要查清楚遭到攻击的途径，找到攻击源，因为只有知道了遭受攻击的原因和途径，才能在删除攻击源的同时进行漏洞的修复。
4，备份用户数据
在服务器遭受到攻击后，需要立刻备份服务器上的用户数据，同时也要查看这些数据中是否隐藏着攻击源。如果攻击源存在用户数据中，要彻底删除，然后将用户数据备份到一个安全的地方。
5，重新安装系统
最安全的方法就是重新安装系统，因为大部分攻击程序都会依附在系统文件或者内核中，所以重装系统才能彻底清除攻击源。
6，修复程序或者漏洞
修复系统漏洞或者更改程序bug，只有将程序漏洞修复完毕才能正式在服务器上运行。
7，回复数据和链接网络
将备份的数据重新复制到新安装的服务器上面，然后开启服务，最后将服务器的网络链接开启，对外提供服务。
检查并锁定可疑用户
在发现服务器遭受攻击后，首先要切断网络链接，但是在有些情况下，比如无法马上切断网络链接时，就必须登录系统查看是否有可疑用户，如果有可疑用户登录了系统，那么需要马上将这个用户锁定，然后中断此用户的远程链接。
登录系统查看可疑用户
通过root用户登录，然后执行“w”命令即可列出所有登录过系统的用户，看看是否有可疑或者不熟悉的用户登录，同时还可以根据用户名以及用户登录的源地址和它们正在运行的进程来判断它们是否为非法用户。
锁定可疑用户
一旦发现可疑用户，就要马上将其锁定，例如上面执行"w"命令后发现nobody用户应该是个可疑用户（因为nobody默认情况下是没有登录权限的），于是首先锁定此用户，执行如下操作：
[root@server ~]# passwd -l nobody
锁定之后，有可能此还处于登录状态，因此还要将此用户踢下线，根据上面"w"的输出，即可获得此用户登录进行的pid值，然后操作如下：
[root@server ~]# ps -ef | grep @pts/3
531 6051 6049 0 19:23 ? 00:00:00 sshd: nobody@pts/3
[root@server ~]# kill -9 6051
如此就将此用户nobody踢下线了，而且此用户再次登录已经登录不上了，就是牛。
通过last命令查看用户登录事件
last命令记录着所有用户登录系统的日志，可以用来查找非授权用户的登录事件，而last命令的输出结果来源于/var/log/wtmp文件，稍有经验的入侵者都会删掉/var/log/wtmp以清除自己行踪，但还是会在此文件中漏出蛛丝马迹的。
查看系统日志
查看系统日志是查找攻击源最好的方法，可查看的系统日志有/var/log/messages、/var/log/secure等，着两个日志文件可以记录软件的运行状态以及远程用户的登录状态，还可以查看每个用户目录下的.bash_history文件，特别是/root目录下的.bash_history文件，这个文件中记录着用户执行的所有历史命令。
检查并关闭系统可疑进程
检查可疑进程的命令很多，例如ps、top等，但有时候只知道进程的名称无法得知路径，此时可疑通过如下方式查看。
首先通过pidof命令查找正在运行的进程PID，例如，要查找sshd进程的PID，执行如下命令：
[root@server ~]# pidof sshd
13276 12942 4284
然后进入内存目录，查看对应PID目录下的exe文件的信息：
[root@server ~]# ls -al /proc/13276/exe
lrwxrwxrwx 1 root root 0 Oct 4 22:09 /proc/13276/exe -> /usr/sbin/sshd
这样就找到了进程对应的完整执行了已经。如果还有查看文件的句柄，可以查看让如下目录：
[root@server ~]# ls -al /proc/13276/fd
通过这种方式基本可以找到任何进程的完整执行信息，此外还有很多类似的命令可疑帮助系统运维人员查找可疑进程。例如，可以通过指定端口或者tcp、udp协议找到进程PID，进而找到相关进程：
[root@server ~]# fuser -n tcp 111
111/tcp: 1579
[root@server ~]# fuser -n tcp 25
25/tcp: 2037
[root@server ~]# ps -ef | grep 2307
root 2037 1 0 Sep23 ? 00:00:05 /usr/libexec/postfix/master
postfix 2046 2037 0 Sep23 ? 00:00:01 qmgt -l -t fifo -u
postfix 9612 2037 0 20:34 ? 00:00:00 pickup -l -t fifo -u
root 14927 12944 0 21:11 pts/1 00:00:00 grep 2037
有些时候，攻击者的程序隐藏很深，例如rootkit后门程序，在这种情况下，ps、top、netstat等命令也有可能已经被替换掉，如果再通过系统自身的命令去检查可疑进程就变得好不可信，此时，要借助于第三方工具来检测系统可疑程序，例如前面介绍过的chkrootkit、PKHunter等工具，通过这些工具可以很方便地发现系统被替换掉或篡改的程序。
检查文件系统的完好性
检查文件属性是否发生变化时验证文件系统完好性的最简单、最直接的方法。可以借助Linux下的RPM工具来完成验证，具体操作如下：
[root@server ~]# rpm -Va
....L... c /etc/pam.d/system-auth
S.5.... c /etc/security/limits.conf
S.5....T c /etc/sysctl.conf
S.5....T /etc/sgml/docbook-simple.cat
..5....T c /etc/lib64/security/calsspath.security
....L... c /etc/pam.d/system-auth
S.5.... c /etc/ldap.conf
对于输出中每个标记含义介绍如下
- S 表示文件长度发生了变化
- M 表示文件的访问权限或者文件类型发生了变化
- 5 表示MD5校验和发生了变化
- D 表示设备节点的属性发生了变化
- L 表示文件的符号链接发生了变化
- U 表示文件/子目录/设备节点的owner发生了变化
- G 表示文件/子目录/设备节点的group发生了变化
- T 表示文件最后一次的修改时间发生了变化
如果输出结果中有“M”标记出现，那么对应的文件可能已经遭到篡改或者替换，此时可以通过卸载这个RPM包重新安装来清除受攻击的文件。
不过这个命令有局限性，只能检查通过RPM包方式安装的所有文件，对于通过非RPM包方式安装的文件就无能为力了。同时，如果RPm工具也遭到替换，就不能使用这种方法了，可以从正常的系统上复制一个RPM工具来进行检测。当然，对文件系统的检查也可以通过chkrootkit、PKHunter等工具来完成。
一次Linux被入侵后的分析
下面通过一个案例来介绍一个服务器被rootkit入侵后的处理思路和处理过程。rootkit攻击时Linux系统下最常见的攻击手段和攻击方式。
受攻击现象
这是一台客户的门户网站服务器，托管在电信机房。客户接到电信的通知：犹豫次服务器持续对外发送数据包，导致100MB带宽耗尽，于是电信切断了此服务器的网络。次服务器安装了CentOS5.5,对外开放了80、22端口。
从客户那里了解到，网站的访问量并不大，所以导致带宽占用也不会太高，而耗尽100MB带宽是不可能的，所以极有可能是收到了流量攻击，于是登录服务器做详细的检测。
初步分析
通过netstat -an命令对系统开启的端口进行检查。奇怪的是并没有发现任何与80端口相关的网络联机。接着使用ps -ef、top等命令也没有发现任何可疑的进程。于是怀疑系统可能被植入了rootkit。为了验证系统是否被植入了rootkit，我们将网站服务器下的ps、top等命令与之前备份的同版本可信操作系统命令进行md5sum校验，结果发现网站服务器下的这两个命令确实被修改过。由此断定次服务器被入侵、且安装了rootkit级别的后门程序。
断网分析系统
由于服务器不停的向外发包，因此首先要做的就是断开服务器网络，然后分析系统日志寻找攻击源。但是系统命令已经被替换掉了，如果继续在该系统上操作命令将变得不可信。这里有两种方法：1，将次服务器的硬盘取下装载到另一台安全的主机上进行分析；2，从同版本可信操作系统下复制所有的命令到次服务器，然后执行命令到时候指定此命令完整路径即可。这里采用第二种方法
首先查看系统的登录日志，查看是否有可疑登录信息，执行如下命令：
more /var/log/secure | grep Accepted
通过查看命令输出，有一条日志引起了我们的怀疑：
Oct 3 03:10:25 webserver sshd[20701]:Accepted password for mail from 62.17.163.186 port 53349 ssh2
这条日志显示在10月3日凌晨3点10分，有个mail账号从62.17.163.186这个IP成功登录了系统，mail是系统内置的账号，默认无法执行登录操作的，而经过查证62.17.163.186这个IP，是来自爱尔兰的一个地址。从mail账号登录的时间来看，早于此网站服务器操守攻击的时间。
接着查看系统密码文件/etc/shadow,又发现可疑信息：
mail:$1$kCEd3yD6$W1evaY5BMPQIqfTwTVJIX1:15400:0:99999:7:::
很明显，mail账号已经被设置了密码，并且被修改为可远程登录，之所以时候mail账号，才想可能是因为入侵者想留下一个隐藏的账号，以方便日后再次登录系统。
然后继续查看其他系统日志，如/var/log/messages、/var/log/wtmp等均为空文件，可见，入侵者已经清理了系统日志文件，至于为何没有清空/var/log/secure文件，就不得而知了。
寻找攻击源
到目前为止，我知道情况是有个mail账号登录了系统，但是为何会导致此网站服务器持续对外发送数据包呢？必须找到对应的攻击源，通过替换到次服务器上的ps命令查看系统目前运行的进程，又发现了新的可疑：
nobody 22765 1 6 Sep29 ? 4--00:11:58 .t
这个.t程序是什么？继续执行top命令，结果如下：
PID USER PR NI VIRT TES SHR S %CPU %MEM TIME+ COMMAND
22765 nobody 150 1740m 1362m 1228 S 98.3 91.5 2892:19 .t
从输出可知，这个t程序已经运行4天左右，运行这个程序的是nobody用户，并且这个t程序小号了大量的内存和CPU，这也是之前客户反映的网站服务器异常缓慢的原因。根据这个输出，我们得到了t程序的进程PID为22765。接下来根据PID查找下执行程序的路径。
进入内存目录，查看对应PID目录下exe文件的信息：
[root@webserver ~]# /mnt/bin/ls -al /proc/22765/exe
lrwxrwxrwx 1 root root 0 Sep2922:09 /proc/22765/exe -> /var/tmp/.../apa/t
这样就找到了进程对应的完整程序执行路径，这个路径很隐蔽，由于/vat/tmp目录在默认情况下任何用户可读，而入侵者就是利用这个漏洞在/var/tmp目录下创建一个"..."的目录，而在这个目录下隐藏着攻击的程序员。进入/var/tmp/.../目录，发现了入侵者放置的一系列rootkit文件，列表文件：
[root@webserver ...]# /mnt/bin/ls -al
drwx-xr-x 2 nobody nobody 4096 Sep 29 22:09 apa
-rw-r--r-- 1 nobody nobody 0 Sep 29 22:09 apa.tgz
drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 caca
drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 haha
-rw-r--r-- 1 nobody nobody 0 Sep 29 22:10 kk.tar.gz
-rwwr--r-- 1 nobody nobody 0 Sep 29 22:10 login
-rw-r--r-- 1 nobody nobody 0 Sep 29 22:10 login.tgz
-rwxr-xr-x 1 nobody nobody 0 Sep 29 22:10 z
通过分析这些文件，基本断定这就是我们要找的程序攻击源，其中：
- z程序是用来清除系统日志等相关信息的，例如执行：
./z 62.17.163.186
在执行这条命令后，系统中所有与62.17.163.186有关的日志将全部都被清除。- 在apa目录下有个后门程序t，这就是之前在系统中看到的程序。在运行此程序后，此程序会自动读apa目录下的ip这个文件，而ip这个文件记录了各种ip地址信息，猜想这个t程序会自动读apa目录下的ip这个文件，而ip这个文件记录了各种ip地址信息，猜想这个t程序应该是去扫描ip文件中记录的所有ip信息，进而获取远程主机的权限。可见这个网站服务器已经是入侵者的一个肉鸡了。
- haha目录下放置的就是用来替换系统相关命令的程序，也就是说这个目录下的程序使我们无法看到操作系统的异常情况。
- login程序就是用来替换系统登录程序的木马程序，此程序还可以记录登录账号和密码。
查找攻击原因
到这里为止，服务器上遭受的攻击已经基本清晰了，但是入侵者是如何入侵的呢？还是要找到根本原因才能彻底解决。
为了弄清楚入侵者如何入侵此服务器的，就需要了解服务器的软件环境，这台服务器是一台基于Java的Web服务器，安装的软件有Apache2.0.63、Tomcat5.5、Apache和Tmocat之间通过mod_jk模块进行集成，Apache对外开放端口80。由于Tomcat没有对外开放端口，因此将问题集中到Apache上面。
通过查看Apache的配置发现，Apache仅仅处理些静态资源请求，而网页也以静态页面局多，所以通过网页入侵方式可能性不大。既然漏洞肯能来自于Apache，那么尝试查看Apache日志，也许能发现一些可疑的访问很急。通过查看access.log文件，发现了如下信息:
62.17.163.186 - - [29/Sep2013:22:06 +0800] "GET http://www.xxx.com/cgi-bin/awstats.pl?configdir=|echo;echo;ps+-aux%00 HTTP/1.0" 200 12333 "-" "Mozilla/5.0(Windows;U;Windows NT 5.1;pt=BR;rv:1.8.1) Gecko/20121010 Firefox/2.0"
62.17.163.186 - - [29/Sep/213;22:17:35 +0800] "GET http://www.xxx.com/cgi-bin/awstats.pl?configdir=|echo;cd+ /vat/tmp/.../haha;ls+-a%00 HTTP/1.0" 2001626 "-" "Mozilla/5.0 (Windows;U;Windows NT5.1;pt-BR;rv:1.8.1)" Gecko/20121010 Firefox/2.0"
至此，发现了漏洞的根源，原来是awstats.pl脚本中configdir的一个漏洞，通过了解此服务器的应用，客户确实是通过一个Awstats的开源插件来做页面访问统计，通过这个漏洞，攻击者可以直接在浏览器上操作服务器，例如查看进程、创建目录等。通过上面第二条日志可以看出，攻击者将正常浏览器执行切换到/vat/tmp/.../haha目录的操作。
这个脚本漏洞挺可怕的，不过在Awstats官网上也早已给出了补修的方法。对于这个漏洞，修复方法很简单，打开awstats.pl文件，找到如下信息：
if ($QueryString =~ /configdir=([^&]+)/i)
{
$DirConfig=&DecodeEncodedString("$1");
}
修改为如下即可：
if ($QueryString =~ /configdir=([^&]+)/i)
{
$DirConfig=&DecodeEncodedString("$1");
$DirConfig=~tr/a-z0-9_-/./a-z0-9_-/.cd;
}
揭开谜团
通过前面的逐步分析和介绍，，对此服务器遭受入侵的原因和过程已经非常清楚了，大致过程如下：
- 攻击者通过Awstats脚本awstats.pl文件的漏洞进入系统，在/var/tmp目录下创建了隐藏目录，然后将rootkitH后门文件传到这个路径下
- 攻击者通过植入后门程序，获取了系统超级用户权限，进而控制了这台服务器，通过这台服务器向外发送包
- 攻击者的IP地址62.17.163.186可能是通过代理过来的，也可能是攻击者控制的其他肉鸡服务器
- 攻击者为了永久控制服务器，修改了系统默认账号mail的信息，将mail账号变为可登录，并且设置了mail账号的密码
- 攻击者在完成攻击后，通过后门程序自动清理了系统访问日志，毁灭了证据
通过对这个入侵过程的分析，发现入侵者的手段还是非常简单和普遍的，虽然入侵者删除了系统的一些日志，但还是留下了很多可查的踪迹。其实还可以查看用户下.bash_history文件，这个文件是用户操作命令的历史记录。
如何恢复网站
由于系统文件已经被更改和篡改，此系统已经变得完全不可信，因此建议备份网站数据，重新安装系统，基本步骤如下：
- 安装稳定版本的操作系统，删除系统默认且不需要的用户
- 系统登录方式改为公钥认证方式，避开密码认证的缺陷
- 安装更高版本的Apache和最新稳定版本的Awstats程序
- 使用Linux下的tcp_wrappers防火墙，限制SSH登录的源地址
rootkit后门入侵攻击是Linux系统下比较常见的一种攻击手段，虽然此类攻击比较难以防范，但是目前已经有很多可以检测rootkit的工具，例如RKHunter、chkrootkit等都可以用于检测系统是否感染rootkit。
