随着计算机弱点数量的日益增加、加之网络上攻击工具和黑客教程随手可得,入侵成本逐渐降低,相比之下,分析计算机入侵并进行取证所花费的代价则要大得多,据伏晓等^[15]的统计结果可知,对一般系统而言,每当一个安全事件发生时,平均1 h的攻击流量预计需花费40 h的时间来查找有效证据。且不包括弱点扫描、磁盘映像、系统恢复、系统强化等花费的时间。

解决之道在于在取证目标系统中预先做好证据的收集工作,即在取证之初根据不同取证环境制定取证需求,并合理设置取证方法及对象。基于软件工程和安全工程思想,孙波等^[14]将需求以场景和组件的形式进行定义,并给出了对取证过程需求进行分组归类的一般方法,然而其对于场景和组件的刻画不够细致和全面,缺乏实用性。尽管如此,将需求作为一个独立因素提出,为计算机取证领域的进一步发展做出了宝贵的贡献,本文的研究参考了其思想。

在DFR2中,需求控制组件将取证需求以事件和对象的形式进行定义,对象是取证过程中最基本取证单位,事件则是取证需求的具体表现形式,由对象的属性描述及各对象间的逻辑关系构成。

与系统调用分类方式相对应, DFR2支持的取证对象包括: 文件、进程、信号和网络这4类。各对象通过其自身特性抽象出的不同属性加以描述。例如: 进程对象的属性包含进程ID(identifier)、 子进程ID以及UID(user identifier)等; 网络对象的属性包含具体协议及四元组(源地址、目的地址、源端口和目的端口)等信息; 文件对象则包含文件名、目录名和是否包含子目录等属性。

为方便上层应用软件的升级和移植,需求控制组件屏蔽了底层的实现细节,将事件和对象以接口函数(具体分为3类: 事件管理、逻辑运算和对象操作)的形式提供给用户,通过API函数调用,可以很容易地实现取证策略的按需定制。

DFR2取证需求制定过程可依次分为以下阶段: 现实取证环境分析、确定取证环境、确定取证目标并调用上述API编写具体的取证需求。图2为用户在取证之初根据取证环境所制定的取证需求实例。

图2

	Figure Option ViewDownloadNew WindowDownload As Powerpoint Slide
	图2 DFR2的取证需求实例

在具体实现中,需求控制组件还采用系统调用ioctl完成用户态下编写的取证需求到内核逻辑设备事件采集组件之间的传递,从而实现了取证需求的动态增加、删除和修改,极大地提高了DFR2的可用性和灵活性。

合理制定取证需求之后, DFR2将所采集的事件以证据向量EV的形式存储于后端的数据库中,供取证分析组件进行证据分析和关联操作并重构整个入侵过程,最终以证据图的表现形式提交给调查取证人员。首先给出一系列相关概念及定义。

定义1 对象依赖 对象依赖OD(object dependency)可以定义为一个三元组OD=<Source,Sink,Operation>, 记为Source ⇒OperationSink, 称作对象Source依赖于对象Sink。其中: Source和Sink 统称对象, Source表示主体,即入侵事件的实施者; Sink表示客体,是入侵者所针对的目标; Operation是入侵者采取的操作。

根据对象依赖的定义, DFR2将每个证据向量EV用对象依赖加以描述,例如: 进程parent创建了一个子进程child, 则用对象依赖可表示为parent ⇒forkchild, 这里的主体是父进程parent, 客体是子进程child, 操作是系统调用fork。如果接下来该子进程child又对文件file进行了写操作,则可进一步表示为对象依赖child ⇒writefile, 主体是父进程parent, 客体是子进程child, 操作是系统调用write。

根据系统调用分类不难看出,在DFR2中共存在4种对象依赖关系。分别是进程/进程对象依赖、进程/文件系统对象依赖、进程/网络对象依赖、进程/信号对象依赖。因此, Source一般指进程对象,而Sink则可以是进程、信号、文件系统和网络对象中的任意一个, Operation为相应的系统调用。图3描绘了DFR2中各对象间的依赖关系转换图。

图3

	Figure Option ViewDownloadNew WindowDownload As Powerpoint Slide
	图3 对象依赖关系转换图

定义2 证据图 证据图EG(evidence graph)是一个有向图,定义为一个二元组EG=< N, E>, 其中: N是节点集合,包含对象依赖OD中全部对象(主体和客体), E是边集合。若$ n₁, n₂∈ N, 且满足 n₁依赖于 n₂, 即 n₁ ⇒Operation n₂, 则存在一条从 n₁到 n₂的有向边 e∈ E。

证据图给出了对象之间依赖关系的最直观表示,因此取证分析操作就等价于尽可能全面地生成证据图。为方便取证分析人员更快更准地发现证据图中的关键对象节点,使之有针对性地快速定位入侵过程中的关键步骤,继续定义3个图操作。

定义3 前驱图操作 给定一个证据图EG=< N, E>以及一个对象节点 n∈ N, 则前驱图操作precedent( n,EG)返回一个EG的最大子图PG=< N', E'>, 满足

1) n∈ N';

2) 对 "n'∈ N'且 n'¹n, 都存在一条从 n'到 n的有向边;

3) 对 "e∈ E', 都在从 n'到 n的路径上。

图PG称作节点 n关于证据图EG的前驱图。

定义4 后继图操作 给定一个证据图EG=< N, E>以及一个对象节点 n∈ N, 则后继图操作subsequent( n,EG)返回一个EG的最大子图SG=< N', E'>, 满足

1) n∈ N';

2) 对 "n'∈ N'且 n'¹n, 都存在一条从 n到 n'的有向边;

3) 对 "e∈ E', 都在从 n到 n'的路径上。

图SG称作节点 n关于证据图EG的后继图。

定义5 关键点操作 给定一个证据图EG=< N, E>以及一个对象节点 n∈ N, 则关键点操作key( n,EG)返回一个EG的最大子图KG=< N', E'>, 满足

1) n∈ N';

2) 对" n'∈ N'且 n'¹n, 都存在一条从 n到 n'或从 n'到 n的有向边;

3) 对 "e∈ E', 都在从 n到 n'或从 n'到 n的路径上。

图KG称作节点 n关于证据图EG的关键点图。

图4描述了3个图操作PG、 SG和KG的详细过程,在这个例子中,关键节点对象是由黑色圆圈标识的进程C。显然,关键点操作等价于前驱图操作和后继图操作的并集,即key( n,EG)=precedent( n,EG)∪subsequent( n,EG)。

图4

	Figure Option ViewDownloadNew WindowDownload As Powerpoint Slide
	图4 图操作过程示意

基于对象依赖关系,取证分析组件通过聚焦和分析2个阶段的操作来实现入侵过程的重构,并以证据图的形式呈现证据。

1) 聚焦阶段: 利用数据查询语句在数据库中检索出指定时间范围内、指定进程PID的所有证据向量EV。由于操作系统中的PID、 INODE(index node)等数据结构的取值都是循环计数的,因此如不限定时间范围,则可能导致2个PID值相同的证据向量所指代的进程却不相同,从而影响取证分析结果的准确性。

2) 分析阶段: 根据对象依赖定义,将聚焦阶段产生的证据向量转换为对象依赖关系,并执行算法1构建证据图,最后执行算法2进一步去掉证据图中的错误依赖关系,以提高证据的可信性和可靠性。

输入: 聚焦阶段产生的证据向量结果集set(EV)

输出: 证据图EG

(1) foreach elementv in set(EV) {

(2) convert v to object dependency Source⇒Sink;

(3) flag=0;

(4) foreach object O in graph EG{

(5) IF Source== O {flag ++; BREAK;}

(6) }

(7) IF (flag!=0) add object Source to graph EG;

(8) flag=0;

(9) foreach object O in graph EG{

(10) if Sink== O {flag ++; BREAK;}

(11) }

(12) IF (flag!=0) add object Sink to graph EG;

(13) add edge from Source object to Sink object;

(14) }

(15) RETURN EG;

算法1 证据图构建算法

输入: 聚焦阶段产生的证据向量结果集set(EV) 和待剪枝的证据图EG

输出: 剪枝后的证据图EG

(1) foreach elementv in set(EV) {

(2) IF v.revl==0 or v.mapped==0; {

(3) convert v to object dependency Source⇒Sink;

(4) delete the edge from object Source to object Sink in graph EG;

(5) }

(6) }

(7) RETURN EG;

算法2 证据图剪枝算法

取证前后端独立运行的模式,使DFR2具有良好的可扩展性。针对跳板攻击的取证需要,只需在跳板上分别添加取证前端即可,各取证前端所产生的证据向量则由id字段加以区分。此外,取证分析服务组件还支持多源证据向量的自动融合,实现对跳板攻击类型进行取证的目的。

在多源证据融合的设计中, 2个问题尤为关键:

1) 证据图合并问题,多源证据融合的本质是将多个有关联关系的证据图进行合并,给定一个取证主机上生成的证据图,需解决与之相关的其他跳板主机的证据图关联问题。DFR2的解决办法是,由于各跳板主机利用网络数据通信进行交互,因此只需关注证据图中的网络对象,并根据与之进行数据交互的主机的地址信息来查找相关联的证据图,向攻击源头方向的查找过程称为后向追踪,而远离攻击源头方向的查找过程称为前向追踪。图5列举了涉及5台主机的跳板攻击,假设已经获得主机 C的证据图,通过后向追踪可找到主机 B和主机 A的证据图,继续执行前向追踪又可找到主机 D和主机 E的证据图。

图5

	Figure Option ViewDownloadNew WindowDownload As Powerpoint Slide
	图5 跳板攻击多源证据融合流程

2) 准确性问题,通过网络数据交互虽然可以发现关联主机,但无法保证准确性。例如: 如果一个Apache服务器的httpd进程被缓冲区溢出攻击,通过关注非法请求,可以发现入侵者所在的主机并进行正确的证据图合并。然而正常请求也会将合法用户的主机关联起来,最终导致产生错误的证据图。由于缓冲区溢出是最为普遍的获得特权提升的攻击方式,因此, DFR2只关联那些存在缓冲区溢出特征的数据交互的主机,从而使上述问题得到了妥善解决。

在刑事司法领域,犯罪重现技术正作为提高证据证明力的有力途径而被刑事专家广泛采用。DFR2 的犯罪重现组件提供了一种自动的、基于数据回放的文件系统级犯罪重现功能,其核心思想是: 从某时刻的文件系统检查点开始,根据证据向量对系统按时序进行系统调用回放,回放过程中忽略入侵者的恶意行为,只处理合法用户的正常操作,以此达到数据恢复的最终目的。由于针对文件系统的读操作不改变系统安全属性,因此在数据回放过程中忽略所有读操作,以此降低复杂性、提高数据回放的性能。执行犯罪重现的具体操作步骤如下:

步骤1 将系统恢复至距恢复点最近的检查点。

步骤2 从数据库中检索出时间戳在检查点到恢复点之间的所有证据向量,对于那些客体(Sink)为文件系统对象的证据向量,判断其客体是否为取证分析组件产生的证据图的节点,是则标记。

步骤3 除Operation为读操作以及步骤②标记过的向量外,对每个客体按时序依次进行数据回放。

图6详细描述了犯罪重现的操作流程。其中A、 C表示文件系统对象、 B表示进程对象、 D表示网络对象、 W为写操作, R为读操作。

图6

	Figure Option ViewDownloadNew WindowDownload As Powerpoint Slide
	图6 犯罪重现操作示意图

图中黑色节点表示证据图中的节点,即相应的对象已经被入侵者攻击。最后,过滤掉读操作和恶意系统调用之后,对象A的恢复过程包含5个数据回放动作,而对象C的恢复过程仅包含4个数据回放动作。

由于电子证据收集系统往往存在于被攻击主机上,因此不同于传统的犯罪证据,电子证据更容易消失和被破坏,其完整性和真实性很难得到充分保障。为使电子证据能够作为定案的依据,取证机制自身的安全性是首要考虑的问题。

传统的安全防护方法的出发点均假定入侵者已知系统中有取证机制正在运行,且一旦获得系统管理权限后,入侵者必会发动针对取证机制自身的攻击,试图使之失效。从而引出了安全性检查等额外操作,导致系统开销增加。因此, DFR2提出了一种轻量级安全性增强技术,从防止取证机制被入侵者发现的角度入手,致力于提高取证机制自身的隐蔽性,从而规避了复杂且频繁的安全性检查操作,直接降低了实现难度和性能开销。

在具体实现上, DFR2采用模块隐藏、流量隐藏技术提高隐蔽性。借鉴著名的RootKit工具Knark和Adore, DFR2通过操作内核模块管理链表,并禁止模块符号信息导出的方法实现了证据数据采集的核心部件的隐藏。另外,由于证据数据要经过网络接口传输到取证后端,为防止入侵者利用netstat-e或ifconfig等工具发现流量上的变化, DFR2重写了虚拟文件/proc/net/dev中的统计数据,过滤了证据数据引发的流量变化。

然而,通过性能分析手段仍然可以检测到系统中的取证机制,例如: 入侵者可以频繁快速的读取空设备/dev/null, 同时通过监测CPU占用率是否大幅度提升来判断内核审计功能存在与否。解决之道在于剔除DFR2的性能瓶颈,降低资源开销。出于通用性考虑,操作系统协议栈在实现上效率往往很低,因此,在证据数据发送的关键路径中, DFR2直接调用网卡驱动的数据发送方法hard_start_xmit, 通过旁路协议栈的干预有效地消除了系统的通信瓶颈。实际上,只要合理使用DFR2提供的按需取证机制,有针对性的制定取证策略和目标,也完全能够解决上述例子中利用频繁读写空设备/dev/null所导致的性能颠簸来发现取证服务的问题,同时还可以有效预防由大量无效数据所引起的针对取证系统的拒绝服务攻击。

首先,从制定取证需求,缩小证据范围的角度对按需取证机制对DFR2进行了测试。为说明测试效果, DFR2中增加了记录syslog的调试信息,以此来增加系统的负载。统计了10 h的DFR2运行结果发现,取证后端平均1 h获得的包数为30 146个。分析得知,大量的信息是由于服务syslogd和sendmail记录日志文件所产生的open和writev系统调用数据。因此,增加对目标文件/var/log/procmail。log和 /var/log/maillog不进行取证的按需取证策略之后,取证后端平均1 h获得的包数为2 201个,降低近92.7%, 有效缩小了证据数据查找范围。

图7给出了取证分析组件进行证据分析和关联操作并对入侵过程进行犯罪重现的实例,可视化部分利用Graphviz工具完成。从图中可以清晰地看出攻击者的攻击过程,首先是利用useradd和groupadd命令增加系统管理用户及设定相应权限,继而通过passwd重新设置了用户口令。为了进一步安装攻击脚本,用命令uname查看了内核版本信息,之后通过FTP在远程主机172.16.*.*下载了admin.vbs脚本,并分别编写了cnnsc.asp和ggsm.asp这2个webshell, 利用这2个webshell, 可以方便地操作服务器上的文件。接下来,该攻击者通过执行tar和gzip命令将vbs脚本和winshell打包为hk.tgz, 并转移到/usr/local目录下面进行备份,便于日后继续使用该后门。最后,攻击者删除/root/.bash_history文件,销毁了历史命令记录。

图7

	Figure Option ViewDownloadNew WindowDownload As Powerpoint Slide
	图7 犯罪重现实例示意图

图8显示了在多源证据融合的测试中得到的一组DoS(denial of service)溢出攻击的证据图。DFR2首先根据通过网络数据交互关系发现关联主机,从而确定了攻击目标是207.103.*.*这台主机。继而DFR2发现系统中记录了很多AR利用SQLSERVER的UDP溢出攻击记录,由此可以判断网络中存在相应的DoS溢出攻击,继而检查溢出数据包的源地址,并利用Graphviz工具刻画出相应的证据图。

图8

	Figure Option ViewDownloadNew WindowDownload As Powerpoint Slide
	图8 DoS攻击证据图

最后,采用虚拟机VMware来辅助完成犯罪重现的功能测试,首先在虚拟机上部署DFR2系统,并利用VMware的快照存储功能记录 t₁时刻的系统快照,然后在 t₂时刻模拟攻击者在虚拟机上安装用于数据包构造和发送的libnet函数库与用于协议还原的libnids函数库,上述过程分别在/usr/include/与/usr/local/include目录下建立了下拷贝了若干头文件,并拷贝编译好的静态库libnet.a与libnids.a至系统目录/usr/lib/和/usr/local/lib下。在 t₃时刻选择DFR2的犯罪重现功能后,系统状态得到还原,从而DFR2的犯罪重现功能得到了验证。

与DFR2的事件采集功能类似, Snare也是通过一个运行在Linux操作系统的可动态加载的内核模块提供系统调用级的事件审计和事件日志的功能,由于Snare开源,因此被许多著名取证分析软件作为基础底层事件采集平台(如forensix), 具有很强的代表性,因此,采用Snare和DFR2进行了对比测试,并收集了不增加系统调用劫持情况下, Linux操作系统原始的系统调用延迟数据,以此说明Snare和DFR2在进行系统调用劫持过程中的性能开销对比。图9给出了测试结果(Snare没有对old_mmap系统调用进行处理,因此图中没有标注)。图中Linux作为Linux从图中可以看出,增加审计功能后,系统调用的处理延迟有所增加,对比于Snare, 除系统调用mkdir外, DFR2在处理每个系统调用的延迟时间都要优于Snare。

图9

	Figure Option ViewDownloadNew WindowDownload As Powerpoint Slide
	图9 系统调用延迟时间对比

由于磁盘的读写性能是影响系统的主要瓶颈,为从宏观角度衡量DFR2对目标系统的性能影响,利用执行磁盘拷贝命令dd对DFR2进行了相关测试,同时也收集了不增加系统调用劫持情况下, Linux操作系统运行dd命令时的CPU以及内存占用率,以此说明Snare和DFR2在进行系统调用劫持过程中的对操作系统正常工作的影响。测试中dd的输入与输出缓冲区均设置为1 B, 目标文件大小864 Mb。图10和图11分别给出了dd执行过程中Snare和DFR2的CPU和内存占用率的对照关系。显然,增加系统审计功能Snare和DFR2之后, CPU和内存的占用率并无明显提升,对操作系统正常运行的影响很小。

图10

	Figure Option ViewDownloadNew WindowDownload As Powerpoint Slide
	图10 CPU占用率对比

图11

	Figure Option ViewDownloadNew WindowDownload As Powerpoint Slide
	图11 内存占用率对比