第一部分 by Mariusz Burdach 1. 介绍 在应急事件响应的过程中，我们常遇到系统没有通过用户和管理员而停止运作的情况。这是一个非常好的学习一些有价值知识的机会， 来防止那些由于系统停止运作而造成的不可挽回的损失。 我将会谈到的内容有：运行进程， 开放TCP/UDP端口， 那些虽然已经删除但还在主内存中存在的程序映像，缓存的内容，连接请求列， 建立连接和Linux内核保留的部分虚拟内存中的模块。所有这些数据可以帮助调查人员在脱机环境下发现取证数据。此外，一个事件仍然在进行中，我们可以覆盖所有入侵者正在使用的数据。 有时因为一些特定类型的攻击，我们这里描述的进行中的程序是唯一的方法来获得事件数据，例如基于LKM的rootkit, 只是驻留在内存中而且不改动任何文件和目录。一个类似的情况也存在于Windows操作系统当中—---红色代码蠕虫就是一个好的例子，攻击代码不会被作为文件存储，但被加入到文件当中然后从内存中运行路径。 另外一方面，下面介绍的方法有着很严重的局限性和妨碍了为数字式研究收集过程的主要需求—不可以轻易的满足的需求。例如：每个本来用做收集数据的用户和内核空间工具改变目标系统的状态。在运行的系统中使用任何工具，我们会载入他们到内存并且至少创造一个可能覆盖证据进程。通过创建一个新的进程，操作系统的内存管理将分配数据到主内存中并覆盖其它主内存中没有分配的数据，或在文件交换系统中。 当我们计划需要进行合法操作并需要遵从地方规则的时候出现的其它问题。在主内存中发现攻击的征兆可能是不可相信的, 因为他们可能是我们自己获得的工具创造的。所以在采取任何行动之前必须明确是否这些数据来自一个正在受到威胁的系统。 通常来说，是很值得收集类似的数据的。 在主要内存映像中，我们可以发现密码或者被解密的文件。使用/proc 伪文件系统，我们可以恢复那些已经被删除但还驻留在内存中的程序。 在一个理想的世界中，我们可以想象一种为Intel电脑而设计的以硬件为基础的解决方案，他允许我们弃置所有内存的内容到一个外存设备中，在没有操作系统的协助下。例如在Sparc机器中存在的一种解决方案，我们可以弃用整个物理内存通过使用固化的OpenBoot. 不幸的是， 在Inter和AMD电脑中没有类似的解决方案存在。 尽管上面的问题的存在， 以软件为基础的方法还是有它对于取证目的来说的优势的, 并且我将尝试在这篇文章中介绍他们。这篇文章的主要目的是介绍在证据收集过程中使用的方法。所有收集的数据将被用来脱机取证分析。一些介绍的步骤可能在事件响应循环中准备和鉴定阶段使用—这就是称为”Incident Handling Step By Step”的指南定义的6个部分中的两个部分， 由SANS理工学院出版。 2. 取证分析 这部分文章被分为4个相关的部分： · 2.1 适应环境 · 2.2 准备取证工具包媒体 · 2.3 从运行当中的系统收集数据-按部就班的过程 · 2.4 最初的数据分析和关键字查询 2.1，2.2和部分2.3的内容将会在这篇文章中讨论，而剩下的步骤和一些脱机步骤将在下个月的第二部分中介绍。 2.1 适应环境 在从运行的系统中收集数据之前，我们不得不先适应环境。首先我们必须运行一个网络Sniffer并且他必须”看”一个受到危及的系统的数据流的来源和去向。这个条件是强制性的。我们仅通过记录和实时分析就可以侦测一些形式的恶意行为。utility tcpdump 是用作此目的的很好的工具。我的建议是以原始格式记录数据由于运行可能导致其它结果。 在对受到危及的系统采取行动前，我们需要建立一个我们数据收集的流程规范。一个流程的例子可以在这篇文章的第三章找到。这个流程帮助我们避免任何事件取证中的错误。我们必须在完成每个步骤特别是出现什么错误的时候做额外的记录。文档是很重要的，特别是如果我们计划把取证的内容带到法庭我们必须始终记住这件事。 我们下一步是记录在数据收集过程当中运行每个命令的结果。我们连接一个目标主机到将收到受威胁的主机发出信息的局域网中。记住，我们不允许在受到威胁的系统中记录任何结果。直接记录数据在受到威胁的主机上可能删除入侵的迹象。为了减少对于受威胁系统的影响，我们不得不发送所有的电子数据到远程或者目的主机中。这个是在取证分析过程中最重要的原则。并且再强调一下，如前面所描述的，这是一个要求，并且不是常常很容易满足的。 如果我们没有可以安装在能够动的媒体的取证工具包， 现在是个好的时机为受到威胁的系统准备了。使用这个工具包的工具，我们将会收集所有的重要数据，从不稳定的到稳定的。 下面的方法描述了准备你在取证工具包中的媒体。 2.2 准备取证工具包媒体记住在数据收集过程中我们需要满足如下标准是很重要的： · 尽量不要运行程序在受到威胁的系统中。为什么？一个入侵者能改变系统命令（例如：netstat）或者系统的库（例如libproc）, 令结果不可靠。为了满足这个标准，我们不得不准备各种版本的静态编译的工具。 · 尽量不要运行那些可能会修改文件描述数据和路径的程序。 · 所有调查的结果必须被记录到远程的空间中。为了满足这些要求，我们将用远程主机作为我们的目标。Netcat工具将被用来传输数字数据。 · 你不得不用工具来计算电子数据的Hash值。 这是一种对于数字数据不被改动的保障。一个最好的练习就是确定数据没有被改动， 并且准确的存储在目标主机当中, 所以我们也将比较在源主机和目标主机中计算的Hash值。有时计算被危及的主机的Hash值是不可能的一个好的例子就是在主内存当中。当我们尝试使用/dev/mem/设备中的md5sum先后两次时，每次的Hash值是不一样的。这种情况发生是因为每次我们调用程序到内存当中（并且从而创建一个新的需要内存来操作的进程）我们改变了内存的状态。 在我们的程序中，我们在收集完所有数据以后要马上计算数字数据的Hash值， 如果可能的话要对源和目的主机都进行操作。为了保证所有结果的完整性，我们将使用md5sum工具. · 为了防止我们工具的使用不被记录数据到内存或者交换受到威胁系统的空间的影响所需要的标准不能满足一些步骤的需要。这个将在2.3中做具体的讨论。现在让我们先确保我们有合适的取证工具包在可移动媒体上，像下面表格中所介绍的。 /upload/p1_30bf03.jpg 当我们成功的建立了上面的工具，我们能拷贝所有这些到我们的可移动媒体（例如CD-RW盘） 2.3 在一个正在运行的系统中做数据收集—一个逐步的过程 下一个非常重要的要求是我们需要开始按照合适的从不稳定到稳定的顺序收集数据。我们需要记住这个在数据收集过程当中。 步骤 1: 给受到危机的屏幕照张照片这个是一种屏幕拷贝，并且我们必须用数码相机来完成这个步骤。这个是一个简单的步骤。在进行第二步之前，准备好我们的媒体，让我们一起考虑一下可能对受到威胁的系统的影响。什么将影响我们的行为？目前来讲，让我们忽略对于受到威胁的系统的内存的影响。很明显我们需要设置外置媒体在受到威胁的系统上。我们必须使用不可信赖的设置命令来完成任务。一个不可靠系统命令被使用，这可能是唯一的情况。如果所有的事情都按照计划发展的话，我们将运行其余可信赖设置媒体命令。 我们也不得不检查运行命令将会对系统产生的影响。我已经在一台电脑上做了一些研究， 下面的图表2列出了相关的文件和修改的路径。 # strace /bin/mount /mnt/cdrom /upload/p1_X55481.jpg 当一个入侵者更改设置命令，我们能想象那个情况。这种程序被称为“deadman 开关”。但是让我们假定不是这种情形，并且回到数据收集的过程当中。我建议一个将来可能会用来在受到威胁的计算机上收集证据的工具要校验所有的将在取证工具包媒体中使用的命令。 我们也不得不停止并考虑过程当中可能遇到的问题: o 在放置媒体到驱动器当中后，卷标管理程序将自动的运行媒体。什么文件和路径将会被更改？这些文件在图表1中列出了吗？ o 假设一个未知的媒体正在受威胁的系统上使用。接着第一步将停止媒体的使用。 我们如何安全的停止其使用呢？我建议两个解决方案。我们能使用不信任的停止运行命令文件，或者我们可以放置可靠的停止运行命令文件到软盘。下一步， 我们使用不可靠运行命令来使用软盘并运行可靠的停止运行命令文件. 这个可能有一点复杂，但是有效。我们仍然只使用一个不可靠命令。 o 一个管理员注销或者更糟的话，入侵者可能改变一个管理员密码。在登陆过程中，什么文件将被访问或者更改？有多少附加的进程会被创建。如果管理员密码被改变了，那其它系统中的账号又会怎么样呢？ 什么样的数据不用访问Shell就可以收集？开放TCP/UDP 端口，当前连接，还有别的什么呢？ o 还有什么其它不可预知的问题吗？ 步骤二: 媒体设备 让我们先使用我们的媒体，也就是一个有我们的工具包的CD-ROM。 # mount -n /mnt/cdrom 如果启动程式成功，我们能开始最重要的数据收集部分的工作。记住，所有由可靠命令得出的结果要求发送到远程主机上。我使用netcat工具和管道方法来做这个。为了更好的区分哪个步骤在哪台主机运行， 所有在受威胁主机上运行的命令前将事先绑定一个(compromised)词。而在远程主机上运行的命令将绑定一个(remote)词。注意下面的例子。 为了发送关于受威胁主机真实数据的信息到远程目标(在这篇文章里作为例子的IP是192.168.1.100), 我们不得不像下面所说打开远程主机的TCP端口： (remote host)# nc -l -p 8888 > date_compromised Next, on the compromised host we do the following: (compromised host)# /mnt/cdrom/date | /mnt/cdrom/nc 192.168.1.100 8888 -w 3 为了保证完整的数字证据，我们计算收集的文件的hash值和证明我们拷贝的每一步，来证明整个过程。 (remote host)# md5sum date_compromised > date_compromised.md5 有时我们可以在受威胁主机上生成checksums并发送结果到远程主机。 这可能导致一些我们在这片文章中讨论的问题。 (compromised host)# /mnt/cdrom/md5sum /etc/fstab | /mnt/cdrom/nc 192.168.1.100 8888 -w 3 步骤三: 当前约定 结果是以UTC格式发表的 (remote)# nc -l -p port > date_compromised(compromised)# /mnt/cdrom/date -u | /mnt/cdrom/nc (remote) port(remote)# md5sum date_compromised > date_compromised.md5 步骤四: 缓存表格 第一，由于数据的寿命，我们必须从缓存表格中收集信息， 放置在表格中。我将从arp和路由表格中收集数据。 Mac 地址缓存表格: (remote)# nc -l -p port > arp_compromised(compromised)# /mnt/cdrom/arp -an | /mnt/cdrom/nc (remote) port(remote)# md5sum arp_compromised > arp_compromised.md5 核心路由缓存表格: (remote)# nc -l -p port > route_compromised(compromised) # /mnt/cdrom/route -Cn | /mnt/cdrom/nc (remote) port(remote)#md5sum route_compromised > route_compromised.md5 步骤五: 当前未决的连接和打开TCP/UDP端口。 现在，我开始收集关于当前连接的信息和打开TCP/UDP端口。关于所有激活的raw sockets 的信息将会在步骤8中收集。 (remote)#nc -l -p port > connections_compromised(compromised)# /mnt/cdrom/netstat -an | /mnt/cdrom/nc (remote) port(remote)#md5sum connections_compromised > connections_compromised.md5 我们能使用cat命令来替代netstat在这个情况中。关于开放端口的信息保留在/proc伪文件系统中（/proc/net/tcp和/proc/net/udp文件）。信息关于当前连接保存在/proc/net/netstat文件中。所有这些文件里的数据是16进制格式。 例如：0100007F:0401 在10进制是 127.0.0.1:1025. 如以前所提到的，当前的连接能通过分析记录流量来侦测。我们不得不远程扫描受威胁的主机并且比较侦测的开放端口和我们从netstat命令得到的结果。 但这可能导致很多问题和我们再一次改变受威胁系统的状态， 在步骤7中我将一个侦测隐藏 LKM 基础的 rootkits的替代方法。 第一部分总结 现在我们有了准确的时间和网络日志状态，我们已经准备好在关闭受威胁的系统电源前作进一步的取证分析. 下个月，在第二部分中，我将集中分析通过收集更多发送到我们远程主机的数据来寻找恶意代码。一旦我们有一个安全的环境， 我们将进一步讨论一些通过我们已经收集的数据可以做到的搜索。 参考书目 · Alessandro Rubini, Jonathan Corbet. Linux Device Drivers, 2nd Edition. O'Reilly; 2001. · Dan Farmer, Wietse Venema. Column series for the Doctor Dobb's Journal. http://www.porcupine.org/forensics/column.html. · Daniel P. Bovet, Marco Cesati. Understanding the Linux Kernel, 2nd Edition. O'Reilly; 2002. · Kernel source code. http://www.kernel.org · Linux manual pages. · National Institute of Standards and Technology. Computer Security Incident Handling Guide. http://csrc.nist.gov. · PHRACK #61. Finding hidden kernel modules (the extrem way) by madsys. http://www.phrack.org. · RFC 3227. Guidelines for Evidence Collection and Archiving. · Smith Fred, Bace Rebecca. A guide to forensic testimony. Addison Wesley; 2003. · Symantec Corporation. CodeRed Worm. http://securityresponse.symantec.com. · The Honeynet Project. Scan 29. http://www.honeynet.org · The SANS Institute. Incident Handling step by step. http://www.sans.org