AIX文件系统目录权限更改追查–JFS JFS2文件系统数据恢复报告

一、事件背景

AIX机器非root用户无法登陆（telnet、ssh、ftp），检查后发现/etc目录权限被更改成640（代表所有者有读写权限但无执行权限，所有者所在的组的组成员只有写权限，其他人没有权限），原始状态下权限应该是755。通过操作系统下现有的各种日志文件分析没能查出具体原因。按照常规的思路分析，/etc目录权限的更改通常情况下是具备root权限才能操作，直接调用的系统命令chmod来完成。检查现有的/.sh_history文件，没有发现相应的chmod命令对/etc目录的权限更改。还有一种可能就是运行脚本来进行更改，脚本文件中也一定包含有chmod命令对/etc目录的操作。在现有的环境下，经过多方排查仍然没有查出真相，决定借助AIX下JFS2文件系统底层数据恢复技术作进一步排查和分析。

二、故障系统LV镜像

AIX操作系统安装在一个146GB的硬盘上，单个PV分配给ROOTVG，在ROOTVG下，划分了7个文件系统，mount节点分别是：/（root）、/home、/usr、/var、/tmp、/opt、/fix。分别对7个文件系统进行dd镜像成7个文件：root.dat、home.dat、usr.dat、var.dat、tmp.dat、opt.dat、fix.dat。把7个镜像文件拷入移动硬盘中，所有的数据恢复、信息搜索和信息收集都在这7个镜像文件中进行，不对原故障系统进行任何操作。

三、数据恢复及取证思路

故障发生时间点为2009年11月23日上午7:00到7:35，重点获取这个时间段文件系统中发生的事件包括删除文件、移动文件、更新文件以及相关的操作命令等信息。/etc目录所属的文件系统是/（root），所有的操作命令记录大都记录在/（root）文件系统中，所以root.dat文件是整个分析过程的重点。

四、技术介绍

1、UINX文件系统中，所有的文件和目录都是由inode来描述，inode可以算得上文件和目录的灵魂。在JFS2文件系统中，inode大小通常占用512个字节，inode包含最重要的信息有：inode编号、文件或目录大小、文件属性（权限等信息）、四个时间（last data accessed、last status changed、last data modified、created）、数据指针、inode连接数等。

2、根据JFS2文件系统架构，一个文件系统的所有inode跟普通文件类似，根据需求分配空间，我们可以把某个文件系统的所有inode提取出来，保存成一个文件，根据需要对这个文件进行分析。

3、在JFS2文件系统中，当对文件或目录进行删除操作时，文件或目录名称都没有改变，文件的inode信息变化不是很大，通常只是对时间进行更新、把inode连接数更新为0（inode连接数是指有多少个文件在共用这个inode，一个inode可以供多个文件使用，但是一个文件只能对应一个inode），其他的信息一般不更改，其中最重要的是数据指针没有更改，这才有删除文件以后有重新恢复的可能。

4、在数据取证的过程中，有时单单依赖文件系统分析还不够，还需要对裸文件进行数据分析提取，比如root.dat文件，抛开文件系统层，直接对root.dat文件进行字节级（十六进制）搜索查询，UINX系统操作命令日志记录一般都是以ASCII编码保存在磁盘中。例如：chmod这个命令在日志中的存放十六进制为：“63 68 6D 6F 64”。

五、操作结果

1、重点查询root文件系统的文件更新情况：

2009-11-23号7点以前更改的文件有1364个文件；

2009-11-23号7点到7点35分新创建的文件有两个，即：/etc/phoenix.snap_err.11230710.out和/etc/phoenix.snap_info.11230710.out

2009-11-23号7点35分以后更改的文件有85个，这些文件大都在/etc目录及子目录下，这是由于故障系统reboot过，大多数文件随着系统reboot而更新相应的时间。

2、在root.dat文件中手工提取类似于.sh_history的文件4个，保存为log-9296-9303.txt，log-5824.txt，log-11392.txt，log-24616.txt，其中log-9296-9303.txt中的操作像最近的操作，可分析这些文件中的相关操作。

3、在root.dat文件中，从inode和directory记录中搜索，没有发现被删除文件的痕迹。

4、对其它6个文件进行搜索，没有发现/etc目录权限更改的相应命令，这种搜索涵盖操作命令日志内容以及脚本内容。

六、结论

1、在2009-11-23号7点到7点35这个时间段，/（root）文件系统没有文件删除操作。

2、通过相关人员对log-9296-9303.txt、log-5824.txt，log-11392.txt，log-24616.txt仔细检查，没有发现/etc目录权限更改指令。

七、最后结果

经过多方排查，认定snap操作存在BUG，在运行过程中更改/etc目录权限，没有成功更改回来造成的。

作者：覃廷良，达思数据恢复技术专家，转载请联系作者convoydata@gmail.com，如果实在不想联系作者，至少请保留版权(出自http://www.bnuol.com)，谢谢。