《高性能Linux服务器构建实战:系统安全、故障排查、自动化运维与集群架构》——1.7 一次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。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
4天前
|
敏捷开发 监控 数据管理
构建高效微服务架构的五大关键策略
【4月更文挑战第20天】在当今软件开发领域,微服务架构已经成为一种流行的设计模式,它允许开发团队以灵活、可扩展的方式构建应用程序。本文将探讨构建高效微服务架构的五大关键策略,包括服务划分、通信机制、数据管理、安全性考虑以及监控与日志。这些策略对于确保系统的可靠性、可维护性和性能至关重要。
|
17天前
|
API 数据库 开发者
构建高效可靠的微服务架构:后端开发的新范式
【4月更文挑战第8天】 随着现代软件开发的复杂性日益增加,传统的单体应用架构面临着可扩展性、维护性和敏捷性的挑战。为了解决这些问题,微服务架构应运而生,并迅速成为后端开发领域的一股清流。本文将深入探讨微服务架构的设计原则、实施策略及其带来的优势与挑战,为后端开发者提供一种全新视角,以实现更加灵活、高效和稳定的系统构建。
23 0
|
5天前
|
消息中间件 监控 持续交付
构建高效微服务架构:后端开发的进阶之路
【4月更文挑战第20天】 随着现代软件开发的复杂性日益增加,传统的单体应用已难以满足快速迭代和灵活部署的需求。微服务架构作为一种新兴的分布式系统设计方式,以其独立部署、易于扩展和维护的特点,成为解决这一问题的关键。本文将深入探讨微服务的核心概念、设计原则以及在后端开发实践中如何构建一个高效的微服务架构。我们将从服务划分、通信机制、数据一致性、服务发现与注册等方面入手,提供一系列实用的策略和建议,帮助开发者优化后端系统的性能和可维护性。
|
15天前
|
Kubernetes 安全 Java
构建高效微服务架构:从理论到实践
【4月更文挑战第9天】 在当今快速迭代与竞争激烈的软件市场中,微服务架构以其灵活性、可扩展性及容错性,成为众多企业转型的首选。本文将深入探讨如何从零开始构建一个高效的微服务系统,覆盖从概念理解、设计原则、技术选型到部署维护的各个阶段。通过实际案例分析与最佳实践分享,旨在为后端工程师提供一套全面的微服务构建指南,帮助读者在面对复杂系统设计时能够做出明智的决策,并提升系统的可靠性与维护效率。
|
2天前
|
监控 API 持续交付
构建高效微服务架构:后端开发的新趋势
【4月更文挑战第23天】 随着现代软件开发实践的不断演进,微服务架构已经成为企业追求敏捷、可扩展和弹性解决方案的首选。本文深入探讨了如何构建一个高效的微服务架构,涵盖了关键的设计原则、技术选型以及实践建议。通过分析微服务的独立性、分布式特性和容错机制,我们将揭示如何利用容器化、服务网格和API网关等技术手段,来优化后端系统的可维护性和性能。文章旨在为后端开发人员提供一套全面的指南,以应对不断变化的业务需求和技术挑战。
|
4天前
|
Cloud Native API 持续交付
构建未来:云原生架构在企业数字化转型中的关键作用
【4月更文挑战第21天】 随着企业加速其数字化转型的步伐,云原生技术已迅速成为推动创新和实现敏捷性的基石。本文深入探讨了云原生架构的核心组件,包括容器化、微服务、持续集成/持续部署(CI/CD)以及声明式API。通过分析这些技术的协同效应,揭示了它们如何共同促进系统的可伸缩性、弹性和维护性,进而支持企业在不断变化的市场环境中保持竞争力。
10 1
|
4天前
|
敏捷开发 Cloud Native 持续交付
构建未来:云原生架构的进化之路
【4月更文挑战第21天】随着数字化转型的深入,企业对IT基础设施的要求日益提高。云原生技术以其灵活性、可扩展性和敏捷性成为推动创新的重要力量。本文将探讨云原生架构的核心组件,分析其如何助力企业实现快速迭代和高效运营,并预测云原生技术的发展趋势。
|
6天前
|
存储 Java 网络安全
ZooKeeper【搭建 03】apache-zookeeper-3.6.0 伪集群版(一台服务器实现三个节点的ZooKeeper集群)
【4月更文挑战第10天】ZooKeeper【搭建 03】apache-zookeeper-3.6.0 伪集群版(一台服务器实现三个节点的ZooKeeper集群)
12 1
|
7天前
|
监控 持续交付 开发者
构建高效微服务架构:后端开发的新趋势
【4月更文挑战第18天】在数字化转型的浪潮中,微服务架构已成为企业提升系统灵活性、加速产品迭代的关键。此文深入探讨了构建高效微服务架构的实践方法,包括服务划分原则、容器化部署、持续集成/持续部署(CI/CD)流程以及监控与日志管理等关键技术点。通过分析具体案例,揭示了微服务在提高开发效率、降低维护成本及促进团队协作方面的显著优势。
|
7天前
|
Cloud Native 持续交付 云计算
构建未来:云原生架构在企业数字化转型中的关键作用
【4月更文挑战第18天】 随着企业加速迈向数字化,云原生架构成为推动创新与效率的催化剂。本文深入探讨了云原生技术如何助力企业实现敏捷开发、自动化运维和无缝可扩展性,以及它如何塑造着云计算的未来。我们将通过具体案例分析,揭示云原生架构在处理复杂系统时的灵活性和可靠性,并展望其对业务连续性和安全性的积极影响。
13 1