《高性能Linux服务器构建实战：系统安全、故障排查、自动化运维与集群架构》—

本节书摘来自华章计算机《高性能Linux服务器构建实战：系统安全、故障排查、自动化运维与集群架构》一书中的第1章，第1.7节,作者：高俊峰著，更多章节内容可以访问云栖社区“华章计算机”公众号查看。

1.7　一次Linux被入侵后的分析

下面通过一个案例来介绍一个服务器被rootkit入侵后的处理思路和处理过程。rootkit攻击是Linux系统下最常见的攻击手段和攻击方式。
1.7.1　受攻击现象
这是一台客户的门户网站服务器，托管在电信机房。客户接到电信的通知：由于此服务器持续对外发送数据包，导致100MB带宽耗尽，于是电信切断了此服务器的网络。此服务器安装了CentOS 5.5版本的系统，对外开放了80、22端口。
从客户那里了解到，网站的访问量并不大，所以带宽占用也不会太高，而耗尽100MB的带宽是绝对不可能的，那么极有可能是服务器遭受了流量攻击，于是登录服务器做详细的检测。
1.7.2　初步分析
在电信人员的配合下通过交换机对该服务器的网络流量进行了检测，发现该主机确实存在对外80端口的扫描流量，于是登录系统通过netstat -an命令对系统开启的端口进行检查。奇怪的是，没有发现任何与80端口相关的网络连接。接着使用ps -ef、top等命令也没有发现任何可疑的进程。于是怀疑系统可能被植入了rootkit。
为了验证系统是否被植入了rootkit，我们将网站服务器下的ps、top等命令与之前备份的同版本可信操作系统命令进行md5sum校验，结果发现网站服务器下的这两个命令确实被修改过，由此断定，此服务器已经被入侵、且安装了rootkit级别的后门程序。
1.7.3　断网分析系统
由于服务器不停向外发包，因此，首先要做的就是将此服务器断开网络，然后分析系统日志，寻找攻击源。但是系统命令已经被替换，如果继续在该系统上执行操作将变得不可信。这里可以通过两种方法来避免这种情况，第一种方法是将此服务器的硬盘取下来挂载到另外一台安全的主机上进行分析，另一种方法是从一个同版本可信操作系统下复制所有命令到这台入侵服务器下某个路径，然后在执行命令的时候指定此命令的完整路径即可。这里采用第二种方法。
首先查看系统的登录日志，查看是否有可疑登录信息，执行如下命令：

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文件，就不得而知了。
1.7.4 　寻找攻击源
到目前为止，我们所知道的情况是，有个mail账号曾经登录过系统，但是为何会导致此网站服务器持续对外发送数据包呢？必须找到对应的攻击源，通过替换到此服务器上的ps命令查看系统目前运行的进程，又发现了新的可疑：

nobody   22765     1  6 Sep29 ?        4-00:11:58 .t

这个.t程序是什么呢？继续执行top命令，结果如下：

PID USER   PR  NI  VIRT  RES  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
这样就找到了进程对应的完整程序执行路径，这个路径很隐蔽，由于/var/tmp目录在默认情况下任何用户可读，而入侵者就是利用这个漏洞在/var/tmp目录下创建了一个“…”的目录，而在这个目录下隐藏着攻击的程序源。进入/var/tmp/…/目录，发现了入侵者放置的一系列rootkit文件，列表如下：

[root@webserver ...]# /mnt/bin/ls -al
drwxr-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
-rwxr-xr-x 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

通过分析这些文件，基本断定这就是我们要找的程序攻击源，其中：
1）z程序是用来清除系统日志等相关信息的，例如执行：

./z 62.17.163.186

在执行这条命令后，系统中所有与62.17.163.186有关的日志将全部被清除。
2）在apa目录下有个后门程序t，这就是之前在系统中看到的程序。在运行此程序后，此程序会自动读apa目录下的ip这个文件，而ip这个文件记录了各种ip地址信息，猜想这个t程序应该是去扫描ip文件中记录的所有ip信息，进而获取远程主机的权限。可见这个网站服务器已经是入侵者的一个肉鸡了。
3）haha目录下放置的就是用来替换系统相关命令的程序，也就是说这个目录下的程序使我们无法看到操作系统的异常情况。
4）login程序就是用来替换系统登录程序的木马程序，此程序还可以记录登录账号和密码。
1.7.5　查找攻击原因
到这里为止，服务器上遭受的攻击已经基本清晰了，但是入侵者是如何侵入这台服务器的呢？这个问题很重要，一定要找到入侵的根源，才能从根本上封堵漏洞。
为了弄清楚入侵者是如何进入服务器的，需要了解下此服务器的软件环境，这台服务器是一台基于Java的Web服务器，安装的软件有Apache2.0.63、Tomcat5.5，Apache和Tomcat之间通过mod_jk模块进行集成，Aapache对外开放80端口。由于Tomcat没有对外开放端口，因此将问题集中到Apache上面。
通过查看Apache的配置发现，Apache仅仅处理些静态资源请求，而网页也以静态页面居多，所以通过网页方式入侵系统可能性不大。既然漏洞可能来自于Apache，那么尝试查看Apache日志，也许能发现一些可疑的访问痕迹。通过查看access.log文件，发现了如下信息：

62.17.163.186 - - [29/Sep/2013:22:17: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;echo;cd+/var/tmp/.../haha;ls+-a%00 HTTP/1.0" 200 1626 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1) Gecko/20121010 Firefox/2.0"

至此，发现了漏洞的根源，原来是awstats.pl脚本中configdir的一个漏洞，通过了解此服务器的应用，客户确实是通过一个Awstats的开源插件来做网页访问统计，通过这个漏洞，攻击者可以直接在浏览器上操作服务器，例如查看进程、创建目录等。通过上面第二条日志可以看出，攻击者将正常浏览器执行切换到/var/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;
}

1.7.6　揭开谜团
通过前面的逐步分析和介绍，对此服务器遭受入侵的原因和过程已经非常清楚了，大致过程如下：
1）攻击者通过Awstats脚本awstats.pl文件的漏洞进入系统，在/var/tmp目录下创建了隐藏目录，然后将rootkit后门文件传到这个路径下。
2）攻击者通过植入后门程序，获取了系统超级用户权限，进而控制了这台服务器，通过这台服务器向外发包。
3）攻击者的IP地址62.17.163.186可能是通过代理过来的，也可能是攻击者控制的其他肉鸡服务器。
4）攻击者为了永久控制这台机器，修改了系统默认账号mail的信息，将mail账号变为可登录，并且设置了mail账号的密码。
5）攻击者在完成攻击后，通过后门程序自动清理了系统访问日志，毁灭了证据。
通过对这个入侵过程的分析，发现入侵者的手段还是非常简单和普遍的，虽然入侵者删除了系统的一些日志，但还是留下了很多可查的踪迹。其实还可以查看用户下的.bash_history文件，这个文件是用户操作命令的历史记录。
1.7.7　如何恢复网站
由于系统已经文件被更改和替换，此系统已经变得完全不可信，因此建议备份网站数据，重新安装系统，基本步骤如下：
1）安装稳定版本的操作系统，删除系统默认且不需要的用户。
2）系统登录方式改为公钥认证方式，避开密码认证的缺陷。
3）安装更高版本的Apache和最新稳定版本的Awstats程序。
4）使用Linux下的tcp_wrappers防火墙，限制SSH登录的源地址。
rootkit后门入侵攻击是Linux系统下比较常见的一种攻击手段，虽然此类攻击比较难以防范，但是目前已经有很多可以检测rootkit的工具，例如前面介绍过的RKHunter、chkrootkit等都可以用于检测系统是否感染rootkit。