Linux入侵响应案例

时间：2022-08-26 08:08:30 其他范文收藏本文下载本文

以下是小编为大家整理的Linux入侵响应案例，本文共4篇，希望对您有所帮助。

Linux入侵响应案例

篇1：Linux入侵响应案例

最近，某校校园网管理员接到国外用户投诉，说该校园网中的一台视频服务器正在对外进行非法的TCP 443端口扫描，该视频服务器的地址是192.168.1.10，操作系统为redhat7.3，对外开放端口为TCP 22、80、443。

然而，管理员在机器上经过重重仔细检查，未观察到任何异常。在此情况下，我们接受请求帮助他们检查机器。

初步检测

我们首先在交换机上对该服务器的网络流量进行了镜像，发现该主机确实存在对外443端口的扫描流量，但是登录到系统上使用netstat -an命令却看不到任何与443端口相关的网络连接，使用psef命令也没有看到系统中有任何可疑的进程。因此，我们怀疑系统中可能被安装了 rootkit(注1)。

为了证实这一点，我们将系统中的ps命令拷贝到另外一台可信的操作系统版本相同的机器上（当然如果你在系统安装初始就维护了一张系统命令md5值表的话，那么你现在只需从别的地方拷一个md5sum程序过来就可以），使用md5sum命令对两个ps进行比对发现192.168.1.10上的ps已经被人修改过，因此可以断定系统确实是被入侵并安装了rootkit级的后门程序。

脱机分析

既然系统命令已经被替换，那么在该系统上所做的任何操作都是不可信的，因此接下来我们将被入侵服务器关闭并取下硬盘挂到另外一台主机上面进行分析。

我们首先查找系统中可疑的登录记录，使用如下命令：

more /var/log/secure |grep Accepted （注2）

我们对系统的登录日志进行了查看，在排除了管理员自己的登录记录后，下面这条记录引起了我们怀疑：

Jul 3 14:01:01 vsp-thu sshd[14042]: Accepted password for news from 82.77.188.56 port 1143 ssh2

这条记录显示在7月3号的下午14:01:01秒，有人使用news账号从82.77.188.56成功登录了系统，经查，82.77.188.56是一个罗马尼亚的地址。根据对方直接使用news账号登录这一点来看，对方攻击成功的时间应该早于7月3号14点，因为系统默认情况下news账号是内置账号没有密码并无法登录，但是我们查看/etc/shadow文件却发现如下记录：

news:$1$ChmaBoHa$ha.JnyJkIryk5wc5DeWzR1:12967:0:99999:7:::

这说明news账号被入侵者加设了密码，并改成了可以远程登录的账号，之所以做这样的修改，一般是入侵者想留下一个隐藏的登录账号，方便日后登录。我们继续检查系统的其他日志却再没发现任何可疑的纪录，很显然入侵者已经对系统的日志文件进行了修改。

继续深入

线索到这里似乎中断。而我们所知道的仅仅是入侵者可能来自罗马尼亚，他修改了系统的news账号权限，并篡改了系统日志。这些已知信息看起来对整个事件的处理并没有太大的帮助。但是我们有一个很有用的信息，就是攻击发生的大概时间可以定位在7月3号下午2点左右，有了这个时间我们就可以使用find命令来查找出这个时间段里面系统中被修改的文件有哪些？命令格式如下：

Find / -ctime +nprint 〉find.log （注3）

在输出的结果中我们发现入侵者在/var/opt下建了一个名为. (点后面是一个空格字符)（注4）的目录，而该目录下包含表1中所显示子目录和文件。

对这些程序进行分析后，知道其功能如下：

表1 入侵者在/var/opt下建立的名为.的目录

1、z程序是用来清除系统日志中相关信息的，例如：

./z 82.77.188.56这条命令执行后，系统中所有与82.77.188.56这个地址有关的日志信息全部会被清除掉；

2、cata目录下是一个IRC的后门程序，运行后系统会自动连接到以下4个IRC服务器，然后入侵者只要登录相应的IRC聊天室就能向这台机器发送控制指令，4个IRC聊天室服务器地址为：

server 194.134.7.195 6662

server 195.197.175.21 7000

server 161.53.178.240 6667

server 66.198.160.2 8080；

3、login程序是用来替换系统登录进程的木马程序，可以记录登录账号和密码；

4、kaka目录里放置的是用来替换系统命令的相应程序，就是这个目录里的程序使得我们在系统上看不出有任何异常；

5、atp 目录下放置的是专门用来扫描https服务和攻击openssl的程序，国外发过来的443端口的扫描投诉就是因为这个目录里的openssl-too程序引起的，

这个攻击程序是4月19号被公布出来的，利用的是编号为CAN--0656的openssl程序的漏洞；

另外，在7月3号被入侵者修改的文件还包括以下两个：

/etc/httpd/conf/httpd.conf（注5）

/etc/httpd/logs/ssl_request_log（注6）

由此可见：

1、入侵者修改了httpd.conf文件，注销了httpd.conf的443端口（跟管理员确认了不是他们自己注销的），大概是不想漏洞被其他人利用；

2、入侵者删除了ssl_request_log日志中的7月3号中午12点到14点的所有纪录（因为ssl_request_log并不算系统日志，所以不能用z程序直接清除，入侵者只能手动删除相应时间段的日志记录）。

继续检查相应日志我们又发现在root目录下的.bash_history（注7）文件中有如下一条命令纪录：./z 82.77.188.240

揭开谜团

有了上面这些信息，我们就可以对本次入侵事件做出如下分析：

1、入侵时间：从目录生成时间和入侵者删除ssl_request_log日志中相应时间段记录的情况来看入侵的大概时间应该在7月3号中午13点左右；

2、利用的漏洞：利用漏洞扫描程序对系统进行扫描发现系统中存在多个可被利用的漏洞，但是从入侵者关闭apache的443端口服务和修改 ssl_request_log日志文件来看，他利用的是apache的mod_ssl模块的漏洞（CAN-2002-0656）入侵系统的；

3、攻击地址来源：攻击地址来源有两个为82.77.188.56和82.77.188.240（但是这两个地址很有可能也是被入侵者控制的机器）；

4、入侵者进入系统后做了以下这些操作：

在系统中安装了通过IRC聊天服务器控制的后门程序修改了系统中news账号的权限和密码；

替换系统中一系列的系统命令；

替换了系统本身的login程序，并获得root的密码（注8）；

利用攻击程序对外进行443端口的扫描与攻击；

使用清除程序清除了系统日志中的相关记录。

解决办法

由于系统内核级的程序已经被替换，我们建议用户备份所需数据后重新安装系统，并执行以下操作：

1、安装更高版本的操作系统；

2、安装相应的系统补丁程序；

3、修改系统管理员的密码，并检查同网段内其他使用相同密码的主机。（因为入侵者已经通过木马程序获得了管理员的口令）；

4、安装更高版本的apache程序，并关闭不必要服务端口；

5、使用防火墙限制ssh 22端口的登录来源地址。

（作者单位为CERNET应急响应组）

注释

注1：简单点说rootkit就是一种的工具包，它里面通常包括：修改过的系统命令程序、后门程序、攻击程序、日志清除程序等，使用rootkit程序就是为了在被入侵的主机上隐藏自己的攻击行为。

注2：/var/log/secure 记录了系统账号的登录信息，而grep Accepted可以有效地过滤掉那些不成功的登录记录。

注3：这个命令的意思就是查找“/”目录下的所有n天前被修改过的文件，使用>管道符是为了将查询结果输出到find.log文件中，便于后面的分析。

注4：linux系统中以“.”开头的文件和目录都隐藏文件，需要使用ls -al命令才能查看到，而点后面加空格的目录名字很容易在ls -al显示结果中被我们忽略过去）

注5：httpd.conf是apche程序的主配置文件，在这个文件里注释掉443端口，将导致apche无法正常提供443端口的https服务。

注6：ssl_request_log文件是apache的一个日志文件，它记录着用户基于https协议的访问信息。

注7：默认情况下各相应用户主目录下的.bash_history文件记录保存着500条该用户在系统中曾经执行过的操作命令。

注8：既然入侵者已经使用了清除程序清除了系统日志，为什么还在root的.bash_history中留下了./z 82.77.188.240命令的记录呢？这就要从.bash_history的记录机制说起了，用户每次登录系统后所做的任何操作并不会直接就存储到了.bash_history文件中，而是保存在一个变量中，只有当用户退出登录以后，这个变量的值才会被写入到.bash_history文件中。这就说明入侵者最后一次是通过82.77.188.240这个地址使用root账号登录系统的，他在运行./z 82.77.188.240这个命令时./bash_history中还没有这条记录，所以也没有被清除，当他退出系统后，变量中的./z 82.77.188.240就被写入到.bash_history中了。因此我们可以断定入侵者已经通过假冒的login程序获得了root的密码。

篇2：入侵案例

案例A 一．事情的^ 我的一W友突然鹘o我一W址x.x.x.x.(R克)，他我退zyzy他W站的安全性，

入侵案例

，

@是一家群艽蟮人主空g服站W站(支持asp+php)，我M口答了他。/ 我首先M行了一些呙port的活樱呙杞Y果看到共_了10端口

篇3：一次成功的入侵检测和应急响应

文章作者：吴海民

8月27日，启明星辰公司接到某北京重要机关的电话，其网站系统可能遭受攻击，造成用户无法正常访问网站，希望启明星辰能够进行应急响应，对攻击进行处理，在做了必要的准备和沟通后，启明星辰迅速派出安全专家和相应的产品技术人员第一时间赶赴现场。

经过启明星辰安全技术人员在现场的分析，发现攻击者是采用了DDOS的攻击手法，向该机关的WEB服务器发起大量的服务请求，同时请求某一固定内容，严重消耗其带宽，因此丧失对外正常服务能力。在了解了攻击者的攻击手法后，应对攻击也就非常容易了。经过细致的策略配置和实施，最终将攻击阻断，并保证了网站的正常访问。用户对此非常满意。

从攻击角度说，这是一次非常典型的攻击事件，处理起来也是具有相应的难度。但是最终能够在很短的时间内解决问题，这中间有很多经验值得总结。必须指出的是，在这个过程中，启明星辰天阗入侵检测系统和规范的应急响应服务起到关键性的作用。下面我们就对该过程进行详细分析和经验总结：

1、网络安全必须具有相对完善的预警、检测和必要的防御措施。

在防御措施上，该机关拥有两种类型的防火墙，配置了一定的访问控制策略，因此是可以阻止一些非信任地址的访问和基于网络层的拒绝服务攻击。但是这次攻击不是采用通用的拒绝服务攻击手法，因此，防火墙对此是无法做好提前防范的。

幸运的是，在该机关目前正在试运行两套启明星辰天阗入侵检测系统。通过天阗入侵检测系统，我们发现在其警报中大量存在对该网站的WEB非正常访问请求三种不同事件，并结合流量检测功能，发现来自与部分地址的连接请求数量严重超标。攻击者正是发送大量上述事件到该机关网站系统，导致网站堵塞；要使网站能够被正常访问，必须阻止上述三种事件的发生。通过上面的入侵检测的事件分析，该攻击被定性为基于WEB应用的有针对性的分布式拒绝服务攻击。

因此，在应对攻击事件的时候，防火墙是有一定的局限性的，只有通过入侵检测我们才能检测到基于应用的攻击行为的发生，并且判断出是何种攻击手段，这就是一个从不知到可知的过程。在进行应急响应的时候，入侵检测系统是必须事先部署的必备环节，否则，其分析攻击难度将增大很多。

2、入侵检测系统必须具备强大的行为关联检测机制以及自定义检测功能

由于该攻击是针对WEB服务的分布式拒绝服务攻击，从攻击特征分析的角度看，其单个服务请求和正常的服务请求机制是相同的，

如果是简单的对这样的特征事件进行阻断，必然导致正常的服务请求也被中断。因此，这里我们用到了天阗行为关联分析机制和强大的自定义功能（VT++语言）。在这里我们区分是拒绝服务还是正常访问主要在于判断行为的关联性。拒绝服务的特点就是在短时间内出现大量的连接行为。因此，检测的机制就是基于异常行为的统计关联。然后通过采用简洁易用的自定义描述语言，形成对该种行为的事件定义，下发到探测引擎。

经过专门定义后，我们可以很容易的看出那些事件是正常访问造成，而那些事件是由攻击造成。

3、入侵检测系统能够很好的和防御措施（如防火墙）形成动态防御

从应急响应的要求看，入侵检测的目的最终是阻止攻击行为，对已经造成攻击后果做相应恢复，并形成整体的安全策略调整。入侵检测系统本身是具有阻断功能的，但是如果单纯利用本身的阻断功能必然对入侵检测的效率有所影响。针对入侵检测后的动态防御，天阗提供了一个通用协议（VIP―FW），可以使防火墙和天阗入侵检测系统形成一个联动安全防御系统。当天阗发现了攻击事件，发送动态策略给防火墙，防火墙接收到策略后就产生一条对应的访问控制规则，可以对指定的攻击事件进行有效的阻断，保证攻击不再延续。这种联动的好处是即利用了防火墙的优势特点，又由于这些规则是根据攻击的发生而动态触发的，所以不会降低防火墙的工作效率。同时又由于启明星辰天阗入侵检测系统的联动标准早就为广大防火墙厂商普遍接受，这次该机关的两种防火墙已经具备了联动功能，所以，最后成功了实现了对分布拒绝服务攻击的防范，保证了网站的正常运行。

在这个实际应用的案例中，天阗入侵检测系统的作用表现得到了有力的证明。因此，一个好的入侵检测系统对保障用户的网络安全是起到积极而重要的作用。通过入侵检测，我们不仅能够知道攻击事件的发生、攻击的方式和手法，还可以指挥其它安全产品形成动态的防御系统，这就对网络的安全性建立一个有效屏障。

同时，我们也看到，用户和攻击者之间是存在着安全知识的不对称性的。要提高网络安全的防护能力，除了有效的安全产品部署和使用，必要的应急响应服务也是一个很好的保障手段。对用户来说，就需要选择一个好应急响应服务的合作伙伴。这样的合作伙伴要有诚信的服务意识、良好的网络安全技术背景、规范的服务流程和独到的安全服务人才和经验积累，能够在用户发生网络安全问题时候及时响应，并可以成功解决问题。