《高性能Linux服务器构建实战:系统安全、故障排查、自动化运维与集群架构》——1.7 一次Linux被入侵后的分析

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

本节书摘来自华章计算机《高性能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。

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
相关文章
|
2月前
|
SQL 监控 关系型数据库
MySQL主从复制:构建高可用架构
本文深入解析MySQL主从复制原理与实战配置,涵盖复制架构、监控管理、高可用设计及性能优化,助你构建企业级数据库高可用方案。
|
2月前
|
数据采集 运维 监控
构建企业级Selenium爬虫:基于隧道代理的IP管理架构
构建企业级Selenium爬虫:基于隧道代理的IP管理架构
|
3月前
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
558 3
|
2月前
|
人工智能 监控 测试技术
告别只会写提示词:构建生产级LLM系统的完整架构图​
本文系统梳理了从提示词到生产级LLM产品的八大核心能力:提示词工程、上下文工程、微调、RAG、智能体开发、部署、优化与可观测性,助你构建可落地、可迭代的AI产品体系。
401 51
|
4月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
434 0
|
2月前
|
机器学习/深度学习 人工智能 搜索推荐
从零构建短视频推荐系统:双塔算法架构解析与代码实现
短视频推荐看似“读心”,实则依赖双塔推荐系统:用户塔与物品塔分别将行为与内容编码为向量,通过相似度匹配实现精准推送。本文解析其架构原理、技术实现与工程挑战,揭秘抖音等平台如何用AI抓住你的注意力。
442 7
从零构建短视频推荐系统:双塔算法架构解析与代码实现
|
5月前
|
监控 安全 Ubuntu
从零开始学安全:服务器被入侵后的自救指南
在信息爆炸时代,服务器安全至关重要。本文针对黑客入侵问题,从应急处理、系统恢复到安全加固全面解析。发现入侵时应冷静隔离服务器,保存日志证据,深入排查痕迹;随后通过重装系统、恢复数据、更改密码完成清理;最后加强防火墙、更新软件、部署检测系统等措施防止二次入侵。服务器安全是一场持久战,需时刻警惕、不断优化防护策略。
657 1
|
18天前
|
域名解析 运维 监控
如何检测服务器是否被入侵?解析5大异常指标
本文系统介绍了服务器入侵的五大检测维度:硬件资源、网络流量、系统日志、文件完整性及综合防护。涵盖CPU、内存异常,可疑外联与隐蔽通信,登录行为审计,关键文件篡改识别等内容,并提供实用工具与防护建议,助力运维人员快速发现潜在威胁,提升系统安全防御能力。转载链接:https://www.ffy.com/latest-news/1916688607247077376
116 0
如何检测服务器是否被入侵?解析5大异常指标
|
5月前
|
存储 SQL 分布式计算
19章构建企业级大数据平台:从架构设计到数据治理的完整链路
开源社区: 贡献者路径:从提交Issue到成为Committer 会议演讲:通过DataWorks Summit提升影响力 标准制定: 白皮书撰写:通过DAMA数据治理框架认证 专利布局:通过架构设计专利构建技术壁垒
|
2月前
|
存储 监控 NoSQL
Redis高可用架构全解析:从主从复制到集群方案
Redis高可用确保服务持续稳定,避免单点故障导致数据丢失或业务中断。通过主从复制实现数据冗余,哨兵模式支持自动故障转移,Cluster集群则提供分布式数据分片与水平扩展,三者层层递进,保障读写分离、容灾切换与大规模数据存储,构建高性能、高可靠的Redis架构体系。

热门文章

最新文章