英语原文共 12 页

InnoDB数据库取证：从重做日志增强数据操作查询的重建

关键词：

MySQL、InnoDB、传统法医学、数据库、日志文件

摘要：

InnoDB存储引擎是MySQL最广泛使用的存储引擎之一。本文讨论了利用innodb数据库的重做日志进行法庭innodb分析的可能性，以及从mysql定义的数字取证文件中提取所需信息的可能性，以便进行这种分析。由于重做日志是数据库存储引擎的内部日志文件，因此不容易在未检测到的情况下更改，因此可以采用此取证方法。

日志文件对于具有管理员权限的对手非常有用，否则，通过操作用于审计和控制目的的传统日志文件，可以覆盖对手的跟踪。基于原型实现，我们展示了针对数据库发出的插入、删除和更新语句恢复的方法。

1.简介和背景

在执行SQL语句时，InnoDB存储引擎将部分语句保存在多个存储位置（Pavlou和Snodgrass，2008年11月）。因此，涉及这些地点的法医分析可以揭示最近的活动，有助于创建过去事件的（部分）时间表，并恢复删除或修改的数据（Stahlberg等人，2010年）。尽管这一事实在计算机取证研究和几种取证工具（Francia和Clinton，2005年6月）以及方法（Francia等人，2006年；Jin和Lotspiech，2003年11月；McDonald等人，2008年4月；Yen等人，2009年）中广为人知，但对数据库系统的系统分析最近才开始（Kieseberg等人，2011a；Kieseberg等人，2011b；Olivier，2009年3月；Wright和Burleson，2008年）。尽管如此，到目前为止，这些方法都没有包含InnoDB重做日志中存储的数据，这些日志不仅构成了有关事务的丰富信息库，甚至允许重建数据库的以前状态。

因为版本5.5 InnoDB是MySQL数据库的默认存储引擎。它是事务安全的，支持提交、回滚和崩溃恢复（Storage Engines，2010；Widenius和Axmark，2002）。事务安全意味着每一个数据变更都被实现为一个原子微事务（MTR），它被记录下来用于重做。因此，每次数据操作都会导致至少一次调用mtr_commit（）函数，该函数将日志记录写入InnoDB重做日志。由于MySQL5.1版，InnoDB使用一种特殊的算法（2008年5.1.x版中的更改）压缩了写入的数据，在我们的研究中，我们对redo日志文件进行了反汇编，这些文件在内部用于崩溃恢复，以便识别和恢复用于数字取证的事务。

本文的内容基于我们对最新战神会议的贡献（Fruehwirt等人，2012年），其中我们概述了使用的基本方法。在第2节中，我们描述了在第4节分析中使用的日志文件的一般结构，在第3节中，我们详细介绍了识别最近操作的方法，以及使用重做信息恢复覆盖的数据。此外，除了方法soutlinedin（Fruehwirtetal.，2012），我们还介绍了收集第4节中表结构和键所需基本信息的方法。第5节通过分析示例条目，详细演示了我们的法医方法的能力。第6部分总结了我们的工作，并展望了未来关于开发用于恢复更复杂语句类型的其他方法的计划。

2.日志文件结构

2.1.一般结构

作为默认行为，InnoDB使用两个日志文件ib_logfile0和ib_logfile1，如果在激活innodb_file_per_table选项的情况下启动MySQL，则每个日志文件的默认大小为5兆字节（使用per table tablesac，11.08.2010）。两个文件具有相同的结构，InnoDB在它们之间旋转，最终覆盖旧数据。与数据文件（Fru–Hwirt等人，2010）相似，日志文件被分成几个片段（见图1）：

1）一个包含日志文件一般信息的头块。

2）保护日志文件不受损坏的两个检查点。

3）包含实际日志数据的几个日志块。

头段块与两个检查点和paddingisoften结合在一起，长度为2048字节。每个日志块包含一个头部、一个尾部和几个日志块条目。由于每个日志块的长度正好为512字节，因此可以将日志块条目拆分并存储在两个日志块中（有关详细信息，请参阅日志块头的描述）。

2.2.标题栏

日志文件的第一部分由头块组成，头块包含有关该文件的一般信息。此块的固定长度为48字节，从偏移量0x00开始，即在文件头的开头。表1概述了头块的内容。

2.3.检查点

InnoDB在日志文件中使用检查点系统。它将数据库页面的更改和修改从双写入缓冲区（mysql performance blog，11.08.2010；Bannon et al.，2002；Kruckenberg and Pipes，2005）刷新为小批，因为在一个批中处理所有内容会阻碍用户在检查点过程中发布的SQL语句的处理。

崩溃恢复：检查点系统对于崩溃恢复至关重要：每个日志文件中的两个检查点是轮流写入的。由于此方法，在恢复的情况下，始终存在至少一个有效的检查点。在崩溃恢复期间（Innodb checkpoints, 2010; Tuuri, April 2009），innodb加载两个检查点并比较其内容。每个检查点包含一个8字节长的日志序列号（LSN）。LSN保证数据页包含对数据库的所有以前的更改（即具有较小LSN的所有条目）。因此，未写入磁盘的每个更改都必须存储在日志中，以便进行故障恢复或回滚。InnoDB被迫创建检查点，以便将数据刷新到磁盘（Tuuri, April 2009）

日志文件中的位置：这两个检查点分别位于地址为0x200和0x400的日志文件ib_logfile0和ib_logfile1中。每个检查点具有相同的结构，固定长度为304字节。检查点结构的详细说明见表2。将日志数据刷新到磁盘时，当前检查点信息将写入当前未完成的日志块头。

2.4。木块的结构

日志文件条目存储在日志块中（日志文件不是按页组织的，而是按块组织的）。每个块分配512字节的数据，从而在执行InnoDB时实现标准磁盘扇区大小（(Zaitsev, April 2009）。每个块分为三部分：日志块头、数据和日志块尾。此结构由InnoDB使用。

为了提供更好的性能并允许在日志中快速导航。

在下面的分章中，我们将讨论头记录和尾记录的结构，在第节中，我们将演示如何从日志块的实际内容重建以前的查询。

1）每个块的前14个字节称为日志块头。此头包含InnoDB存储引擎管理和读取日志数据所需的所有信息（参见表3）。在每512字节之后，innodb会自动创建一个新的头，从而生成一个新的日志块。由于包含头块的日志文件头、检查点和附加填充正好是2048字节长，所以日志文件中第一个日志块头的绝对地址是0x800。日志块头：

如第2.3节所述，当前活动的日志块始终保存对当前活动检查点的引用。每次将日志内容刷新到磁盘时都会更新此信息。

2）日志块尾部只包含一个校验和，用于验证日志块的有效性（见表4）。木块拖车：

3）如果日志条目太大，无法容纳当前活动的512字节块中剩余的空间，则将其拆分为两个日志块。为此，当前活动块将被填满，直到日志块尾所需的最后四个字节。然后生成一个新的日志块，其中包含一个日志块头和拆分日志条目的其余内容。日志块头中位置0x04和0x05处的偏移量用于指定下一个日志条目的开始，即拆分条目结束后的字节（参见图2）。这是为了识别下一个条目的开始而不必在前面引用日志块，从而大大增强日志文件中的导航。在日志块上拆分日志条目：

所有日志条目。此外，它们在大多数法医分析案件中都具有重要意义。

日志条目说明：由于日志条目中相关字段的长度、数量和位置都是高度可变的，因此我们不为相关数据字段提供任何偏移。为了提供一定的清晰度，字段按升序编号，相同类型的字段（例如包含长度定义的可变字段数）具有相同的值。

3.1.报表标识

所有日志条目都可以通过其日志条目类型进行标识，日志条目类型由每个条目的第一个字节提供。在源代码中可以找到所有现有日志条目类型的完整列表。但是，为了进行法医分析，所需的所有信息只能从一些独特的日志条目中获得（见表5）。

对于每个数据操作语句，innodb至少创建一个类型为mlog_undo_insert的新日志条目。此日志类型存储受影响表的标识号、语句类型的标识符（insert、update、delete），以及主要取决于特定语句类型的附加信息（请参见表6）。

用于标识语句的最重要字段是保存数据操作类型的

资料编号：[5277]