对大量文件更改进行取证

Question 1

这个问题即将被关闭，因为它重复了如何处理被入侵的服务器，我认为这是错误的，因为这个问题中非常正确的建议是删除服务器并从已知良好的媒体恢复。然而，没有任何证据表明该系统已被破坏。

OsakaWebbie，您承认您对操作系统版本判断有误；系统版本为 5.11。鉴于此，您列出的所有文件都是软件包的一部分glibc-headers，除了/usr/lib64/libc.so是的一部分glibc-devel，该软件包与同步移动glibc-headers并且通常同时构建。

我本想在 C5 系统上完成此操作，但我手头没有。在最新的 C6 系统上，有关的信息glibc-headers是

[me@lory 2012]$ rpm -qi glibc-headers
Name        : glibc-headers                Relocations: (not relocatable)
Version     : 2.12                              Vendor: CentOS
Release     : 1.149.el6                     Build Date: Wed 15 Oct 2014 03:00:58 BST
Install Date: Fri 24 Oct 2014 20:42:04 BST      Build Host: c6b9.bsys.dev.centos.org
[...]

注意构建和安装日期。现在让我们看看相关文件：

[me@lory 2012]$ for file in `rpm -ql glibc-headers`; do ls -la $file ; done
[...]
-rw-r--r--. 1 root root 2416 Oct 15 02:44 /usr/include/gnu-versions.h
-rw-r--r--. 1 root root 3057 Oct 15 02:44 /usr/include/gnu/lib-names.h
-rw-r--r--. 1 root root 1337 Oct 15 02:44 /usr/include/gnu/libc-version.h
-rw-r--r--. 1 root root 315 Oct 15 02:44 /usr/include/gnu/stubs.h
-rw-r--r--. 1 root root 6991 Oct 15 02:44 /usr/include/grp.h
-rw-r--r--. 1 root root 4611 Oct 15 02:44 /usr/include/gshadow.h
-rw-r--r--. 1 root root 1949 Oct 15 02:44 /usr/include/iconv.h
-rw-r--r--. 1 root root 4990 Oct 15 02:44 /usr/include/ieee754.h
[...]

请注意，所有文件的时间戳都相同，并且比 RPM 中嵌入的构建日期早几分钟。由此我们得出结论：RPM 控制系统文件的修改时间是其在创建 RPM 的构建系统上的修改时间；由于构建是一个整体过程，因此 RPM 中的所有文件都应具有非常相似的更新时间，并且相关软件包中的文件也应具有这些更新时间，这是完全合理的，并且这些 mtime 与软件包安装的日期不对应。

如果您可以确认您的系统确实处于 C5.10/5.11，那么您就可以不再惊慌；没有证据表明您的系统发生了任何不好的事情。

编辑：OsakaWebbie，您确认系统现在为 5.11，我认为这不是问题。您显示的文件的修改时间与您预期的完全一致。

作为参考 - 理解这一点非常重要 - C5.11 不是 C5 的主要版本。C6 与 C5 是不同的主要版本，但 C5.11 只是完全修补的 C5.6（或任何其他版本的 C5）。您可以在我之前写的关于 C/RH 版本控制的回答中详细阅读了这一点如果您愿意的话，但当您在 9 月底 / 10 月初执行此操作时，您很可能已将系统升级到 5.11。如果愿意，yum update您可以使用来确认。grep centos-release /var/log/yum.log*

Answer

这个问题即将被关闭，因为它重复了如何处理被入侵的服务器，我认为这是错误的，因为这个问题中非常正确的建议是删除服务器并从已知良好的媒体恢复。然而，没有任何证据表明该系统已被破坏。

OsakaWebbie，您承认您对操作系统版本判断有误；系统版本为 5.11。鉴于此，您列出的所有文件都是软件包的一部分glibc-headers，除了/usr/lib64/libc.so是的一部分glibc-devel，该软件包与同步移动glibc-headers并且通常同时构建。

我本想在 C5 系统上完成此操作，但我手头没有。在最新的 C6 系统上，有关的信息glibc-headers是

[me@lory 2012]$ rpm -qi glibc-headers
Name        : glibc-headers                Relocations: (not relocatable)
Version     : 2.12                              Vendor: CentOS
Release     : 1.149.el6                     Build Date: Wed 15 Oct 2014 03:00:58 BST
Install Date: Fri 24 Oct 2014 20:42:04 BST      Build Host: c6b9.bsys.dev.centos.org
[...]

注意构建和安装日期。现在让我们看看相关文件：

[me@lory 2012]$ for file in `rpm -ql glibc-headers`; do ls -la $file ; done
[...]
-rw-r--r--. 1 root root 2416 Oct 15 02:44 /usr/include/gnu-versions.h
-rw-r--r--. 1 root root 3057 Oct 15 02:44 /usr/include/gnu/lib-names.h
-rw-r--r--. 1 root root 1337 Oct 15 02:44 /usr/include/gnu/libc-version.h
-rw-r--r--. 1 root root 315 Oct 15 02:44 /usr/include/gnu/stubs.h
-rw-r--r--. 1 root root 6991 Oct 15 02:44 /usr/include/grp.h
-rw-r--r--. 1 root root 4611 Oct 15 02:44 /usr/include/gshadow.h
-rw-r--r--. 1 root root 1949 Oct 15 02:44 /usr/include/iconv.h
-rw-r--r--. 1 root root 4990 Oct 15 02:44 /usr/include/ieee754.h
[...]

请注意，所有文件的时间戳都相同，并且比 RPM 中嵌入的构建日期早几分钟。由此我们得出结论：RPM 控制系统文件的修改时间是其在创建 RPM 的构建系统上的修改时间；由于构建是一个整体过程，因此 RPM 中的所有文件都应具有非常相似的更新时间，并且相关软件包中的文件也应具有这些更新时间，这是完全合理的，并且这些 mtime 与软件包安装的日期不对应。

如果您可以确认您的系统确实处于 C5.10/5.11，那么您就可以不再惊慌；没有证据表明您的系统发生了任何不好的事情。

编辑：OsakaWebbie，您确认系统现在为 5.11，我认为这不是问题。您显示的文件的修改时间与您预期的完全一致。

作为参考 - 理解这一点非常重要 - C5.11 不是 C5 的主要版本。C6 与 C5 是不同的主要版本，但 C5.11 只是完全修补的 C5.6（或任何其他版本的 C5）。您可以在我之前写的关于 C/RH 版本控制的回答中详细阅读了这一点如果您愿意的话，但当您在 9 月底 / 10 月初执行此操作时，您很可能已将系统升级到 5.11。如果愿意，yum update您可以使用来确认。grep centos-release /var/log/yum.log*

Question 2

我将主要对来自不相关的问题。我认为这是它更好的归宿。以下说明假设您已经遵循了我该如何处理受到感染的服务器？如果适用的话。如有疑问，请务必断开网线。

find /filesystem1 /filesystem2 -xdev -printf '%T@ %t %p\n' | sort -n

%T@修改时间，纪元秒（用于排序）

%t修改时间，人类可读

%p完整文件路径

根据口味调味。一次在一个已安装的文件系统上运行，或者在您认为相关的多个文件系统上运行。

这样做的目的是为您提供按时间戳排序的对文件的最新修改的审核。这有时可以让您了解未知事件发生时发生的其他事情。它当然不是万无一失的，也可能根本不会透露任何东西，但我偶尔发现这在识别未知事件发生时正在执行的工作方面非常有用。（即有人rm -Rf /lib代替执行rm -Rf lib）

补充：

如果此命令的输出包含大量无法与操作系统更新关联的公用库和可执行文件，则最可能的原因是 rootkit 被覆盖在您的操作系统之上。
另一种可能性（您不太可能会考虑）是无知的管理员从另一个系统向此系统运行贪婪的 rsync。这不太可能是从存档副本（备份软件tar等）进行的还原，因为它们通常善于尊重原始文件mtime。
如果你想不通，你就只能将其视为入侵。

Answer