|
IT行业发展到现在，安全问题已经变得至关重要，从最近的“棱镜门”事件中，折射出了很多安全问题，信息安全问题已变得刻不容缓，而做为运维人员，就必须了解一些安全运维准则，同时，要保护自己所负责的业务，首先要站在攻击者的角度思考问题，修补任何潜在的威胁和漏洞。 一、 一次Linux被入侵后的分析 下面通过一个案例介绍下当一个服务器被rootkit入侵后的处理思路和处理过程，rootkit 攻击是Linux系统下最常见的攻击手段和攻击方式。 1 受攻击现象 这是一台客户的门户网站服务器，托管在电信机房，客户接到电信的通知：由于此服务器持续对外发送数据包，导致100M带宽耗尽，于是电信就切断了此服务器的网络。此服务器是Centos5.5版本，对外开放了80、22端口。 从客户那里了解到，网站的访问量并不大，所以带宽占用也不会太高，而耗尽100M的带宽是绝对不可能的，那么极有可能是服务器遭受了流量攻击，于是登录服务器做详细的检测。 2 初步分析 在电信人员的配合下通过交换机对该服务器的网络流量进行了检测，发现该主机确实存在对外80端口的扫描流量，于是登录系统通过“netstat –an”命令对系统开启的端口进行检查，可奇怪的是，没有发现任何与80端口相关的网络连接。接着使用“ps –ef”、“top”等命令也没有发现任何可疑的进程。于是怀疑系统是否被植入了rootkit。 为了证明系统是否被植入了rootkit，我们将网站服务器下的ps、top等命令与一个同版本可信操作系统下的命令做了md5sum校验，结果发现网站服务器下的这两个命令确实被修改过，由此断定，此服务器已经被入侵并且安装了rootkit级别的后门程序。 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文件，就不得而知了。 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 15 0 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 Sep 29 22: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程序就是用来替换系统登录程序的木马程序，此程序还可以记录登录帐号和密码。 5 查找攻击原因 到这里为止，服务器上遭受的攻击已经基本清晰了，但是入侵者是如何侵入这台服务器的呢？这个问题很重要，一定要找到入侵的根源，才能从根本上封堵漏洞。 为了弄清楚入侵者是如何进入服务器的，需要了解下此服务器的软件环境，这台服务器是一个基于java的web服务器，安装的软件有apache2.0.63、tomcat5.5，apache和tomcat之间通过mod_jk模块进行集成，apache对外开放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" 本文发表在程序员杂志2013年11期！ (责任编辑：IT) |