|
联机的Linux的系统分析（第二部分）（第一版）
======================================================================
----原著:Mariusz Burdach
翻译:西安邮电学院电科0101 徐兆元 02985384887
译文版权: 徐兆元 西安邮电学院156# FLxyzsby@163.com/FLxyzsby@yahoo.com.cn
2004.8.15
转载请通知
======================================================================
1.第二部分简介
在本文的第一部分中,我们讨论了一些在分析非安全系统时候的准备工作和必须的步骤.现在我们继续来分析系统以找出系统是恶意代码的所在,然后讨论从被传送到远程主机上的数据中寻找的方法.
纪录:
一些读者在阅读完本文的第一部分后指出:在从非安全系统是传送任何数据之前,受托的shell应该被运行.我想这是一个很好的想法,所以我们来静态编译bash shell然后将它拷贝到我们都可移动存储设备上.第2a步被替代为:
(compromised)# /mnt/cdrom/bash
必须让我们引起注意的是,当任何命令被健入系统时命令解释器都会将它们写入历史纪录文件.但我们不向修改本地系统的文件所有最好将历史纪录关掉.
2.3 Data collection for a live system - continued
第六步:物理内存镜象
数据收集的一个步骤是获取整个系统内存的一个拷贝.我们可以通过拷贝/dev/mem设备或者拷贝kcore文件来直接得到物理内存.kcore文件在linux系统中是用来纪录RAM中内容的.它是一个虚拟的文件,存在于/proc目录下.整个文件的大小和当前物理内存的大小是一样的,扩展了大约４KB.用kcore文件的好处是它是ELF格式的,所以可以用gdb进行调试.个gdb工具集是跟踪和分析小模块代码或内存的绝佳工具.在2.7节中我将为你展示如何在分析中使用这些工具的高级功能.但作为基础的分析我将使用更通用的工具比如grep,string(字符串),hex(十六进制)编辑器.
另外,为了能很好地分析整个物理内存我们必须了解一些关于操作系统的内存的页面方面的知识------相对于物理地址的虚拟地址表的数据结构.我们必须知道物理内存包含着虚拟内存的页面.在页面表(块表)中我们可以找到关于被写入物理内存的页面的索引(在intel处理器中为４KB每页).
如前面所提及的,我们在利用软件工具获取易失性存储器的内容时会很自然地改变内存的内容.更严重的是,我们会重写可能存在入侵证据.
下面的例子我使用了/proc虚拟文件系统来获得内存镜像
(remote)#nc -l -p port > kcore_compromised
(compromised)#/mnt/cdrom/dd < /proc/kcore | /mnt/cdrom/nc (remote) port
(remote)#md5sum kcore_compromised > kcore_compromised.md5
其实,在拷贝整个系统内存时我们既拷贝了已经分配出去的内存也拷贝了未分配的内存,原因是我们只是复制了这个物理内存的镜象.在第九步中我们将尝试用/proc虚拟文件系统去复制一个确切进程所使用的内存.我必须说明当是当我们用/proc时其实我们会改变swap交换分区里的内容.为了能复制那些可疑的进程我们将强制主存的一些页面对于swap交换分区是可读的,其他页面则是可写的.另一个重要的方面是,我们只拷贝进程已经分配的内存空间.
第七步:被载入操作系统内存的模块列表
我们要保证所收集到的数据是完整的,并且netstat和lsof命令的结果不能在内核级上被修改.所以我们必须检测当前那些模块被加载到内存中了.
(remote)# nc -l -p port > lkms_compromised
(compromised)#/mnt/cdrom/cat /proc/modules | /mnt/cdrom/nc (remote) port
(remote)# nc -l -p port > lkms_compromised.md5
(compromised)# /mnt/cdrom/md5sum /proc/modules | /mnt/cdrom/nc (remote) port
不幸的是,一些恶意的进程根本不会被列出来(译者注:恶意进程本身有保护机制).为了检测从/proc/modules加载的模块的信息,我将用在最近Phrack Magazine的文章"Finding hidden kernel modules (the extrem way)".中的方法.检测模块hunter.o检查一系列被加载到内核中的模块.
(compromised)#/mnt/cdrom/insmod -f /mnt/cdrom/hunter.o
我用了-f参数,它表示强制加载hunter.o模块因为版本不匹配.版本不匹配是很hunter.o的编译上的系统内核和当前使用系统的内核不一致所导致,避免这种情况的最好办法是在每个你使用的系统上重新编译代码.如果你知道你所操作的非安全系统的内核版本,你可以从www.kernel.org下载源代码和喜爱相应的头文件以重新编译和连接以产生和你系统 版本匹配的hunter.o.
(remote)#nc -l -p port > modules_hunter_compromised
(compromised)#/mnt/cdrom/cat /proc/showmodules && /mnt/cdrom/dmesg | /mnt/cdrom/nc (remote) port
(remote)#md5sum modules_hunter_compromised > modules_hunter_compromised.md5
我们现在可以比较结果了.还必须注意模块的大小,有时一些恶意代码会插入合法的文件中.(译者注:这样就会改变文件的大小)
最后一件事是我们拷贝内核模块输出的符号数据.有时脆弱的基于LKM的rootkit会输出自己的符号数据.通过分析ksyms文件系统我们可以检测到在系统中是否存在入侵者.
(remote)#nc -l -p port > ksyms_compromised
(compromised)#/mnt/cdrom/cat /proc/ksyms | /mnt/cdrom/nc (remote) port
(remote)# nc -l -p port > ksyms_compromised.md5
(compromised)#/mnt/cdrom/md5sum /proc/ksyms | /mnt/cdrom/nc (remote) port
我们可以用其他工具(比如kstat或kern_check)模块来检测恶意模块,但不幸的是所有的这些工具都使用System.map这个文件.这个文件由系统产生和编辑.如果管理员没有复制这个文件并且没有建立校检和的话我们不应该信任存储在那里的系统所调用的地址.即使当系统所调用的地址是正确的,入侵者也可以使用惯用的伎俩将恶意模块隐藏在内核内存.作为此种情况的例子,adore-ng工具就可以替换已经存在提供系统目录列表的常驻内存管理器.
如果我们可以确保在System.map和ksyms文件中的系统调用地址不会被修改并且确认系统调用地址表中的调用地址没有被入侵者所改变.详情请看2.7节.
第八步:活动进程列表
所有的进程、开放的端口和文件的信息可以用lsof工具来收集.当然,其中的要求是在内存中不能有任何基于LKM的工具存在.在下一步中我们将拷贝可疑的进程.通过拷贝具体的进程我们可以很容易从系统的内存中区分出恶意数据.你应该可以回忆起来,我们在第六步已经收集所有的内存数据(kcore or /dev/mem)
(remote)#nc -l -p port > lsof_compromised
(compromised)#/mnt/cdrom/lsof -n -P -l | /mnt/cdrom/nc (remote) port
(remote)#md5sum lsof_compromised > lsof_compromised.md5
现在,我们来分析从lsof工具得来的结果.如果你发现任何活动进程是可疑的,那么现在就是一个很好的时机去拷贝它们.如果我们发现lsof工具在初始化时就被入侵者检测到,而此时我们看到结果很明显不准确.即使这样我们依然有机会恢复结果.我将在下一步向你展示任何操作.
我列举几个可疑的进程作为例子:
○正在监听非常规定TCP/UDP端口或开放的原始socket的进程
○一个和远程主机有活动连接的进程
○一个在被删除到程序又开始运行
[1] [2] [3] [4] [5] 下一页
[MySql]联机的Linux的系统分析（第一部分）（第一版）
| 
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
