对大量文件更改的取证

Question

我注意到我的 CentOS 5.6 5.11 VPS 在今年 9 月的 3 天内有超过 16,000 个带有时间戳的文件。我不知道为什么会这样，因为在那段时间我没有通过 SSH 登录（也没有任何其他登录，这会非常令人担忧）并且在那段时间 Webmin 中没有任何操作记录。这是我改变系统文件所做的唯一两种方法。服务器似乎运行良好，但应该没有其他人可以访问（当然，主机除外），所以我想知道发生了什么。

我在文件中捕获了带有这些日期的文件，因此：

touch -t 201409160000 start.tmp
touch -t 201409190000 stop.tmp
find / -type f -newer start.tmp \! -newer stop.tmp -exec ls -la {} \; > sep-16-18.txt

但是我如何处理这些信息？音量太疯狂了！

[root](21:05:55)[~]$ grep "Sep 16" -c sep-16-18.txt
6079
[root](21:06:30)[~]$ grep "Sep 17" -c sep-16-18.txt
2580
[root](21:06:40)[~]$ grep "Sep 18" -c sep-16-18.txt
7653

整个 9 月剩下的时间总共不到 500 个文件，所以在月中发生了一些激进的事情。

几乎所有文件都在/usr/目录中：

/usr/:  16130
/lib/:     49
/sbin/:    49
/etc/:     45
/lib64/:   37
All others: 3

但是 /usr/ 下子目录的细分非常广泛：

/usr/lib/:     6514
/usr/include/: 5109
/usr/share/:   3438
/usr/lib64/:    853
/usr/bin/:      105
/usr/sbin/:      61
/usr/libexec/:   36
/usr/kerberos/:  14

也许具有最早时间戳的文件可能会有所启发（也许它开始了级联），但我似乎无法find按时间对结果进行排序。我可以反复将 start.tmp 和 stop.tmp 重置为越来越小的时间段，重新运行 find 直到我手动查看合理数量的结果，但我可能不知道我在看什么 - 我反正我真的不是 Linux 专家。也许有人可以给我一些关于我应该问我的服务器的“问题”的提示。看起来好像重新安装了 Linux 什么的，但是......

更新：对于那些询问的人，这里是前几个带有 16 日时间戳的文件。第一个似乎无关，但从 15:04 开始，在接下来的几分钟内更新（或创建，我想）超过 5000 个文件：

1410846366 Tue Sep 16 14:46:06 2014 /etc/default/nss
1410847466 Tue Sep 16 15:04:26 2014 /usr/include/features.h
1410847466 Tue Sep 16 15:04:26 2014 /usr/include/gnu-versions.h
1410847466 Tue Sep 16 15:04:26 2014 /usr/include/limits.h
1410847466 Tue Sep 16 15:04:26 2014 /usr/include/values.h
1410847466 Tue Sep 16 15:04:26 2014 /usr/lib64/libc.so
1410847467 Tue Sep 16 15:04:27 2014 /usr/include/bits/xopen_lim.h
1410847467 Tue Sep 16 15:04:27 2014 /usr/include/gnu/libc-version.h
1410847467 Tue Sep 16 15:04:27 2014 /usr/include/gnu/lib-names.h
1410847467 Tue Sep 16 15:04:27 2014 /usr/include/gnu/stubs.h
1410847468 Tue Sep 16 15:04:28 2014 /usr/include/gconv.h
1410847468 Tue Sep 16 15:04:28 2014 /usr/include/iconv.h
1410847473 Tue Sep 16 15:04:33 2014 /usr/lib64/gconv/gconv-modules
1410847475 Tue Sep 16 15:04:35 2014 /usr/include/bits/locale.h
1410847475 Tue Sep 16 15:04:35 2014 /usr/include/langinfo.h
1410847475 Tue Sep 16 15:04:35 2014 /usr/include/locale.h
1410847475 Tue Sep 16 15:04:35 2014 /usr/include/xlocale.h
1410847476 Tue Sep 16 15:04:36 2014 /usr/share/i18n/charmaps/ANSI_X3.110-1983.gz
1410847476 Tue Sep 16 15:04:36 2014 /usr/share/i18n/charmaps/ANSI_X3.4-1968.gz
1410847476 Tue Sep 16 15:04:36 2014 /usr/share/i18n/charmaps/ARMSCII-8.gz
1410847476 Tue Sep 16 15:04:36 2014 /usr/share/i18n/charmaps/ASMO_449.gz

之后，它会继续处理一些长度的字符映射和与区域设置相关的文件，然后是更多的包含文件，然后在大约 5500 个这种类型的文件之后它需要休息一会儿，然后才会有更多的 .so 文件和其他看起来像的东西很正常。这会告诉任何人吗？我在列表中看到的没有一个看起来可疑；我不是专家，但它看起来更像是一个无辜的更新。但我不知道除了 shell 登录或 Webmin 之外如何进行更新。

Answer 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 是完全合理的，并且实际上关联包中的那些文件也应该具有它们，并且这些 mtime 不会对应于日期软件包已安装。

如果你能确认你的系统确实在C5.10/5.11，你就可以停止恐慌了；你没有提供任何证据表明你的系统发生了任何不好的事情。

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

作为参考 - 理解这一点非常重要 - C5.11 不是 C5 的主要版本。C6 是与 C5 不同的主要版本，但 C5.11 只是一个完全修补的 C5.6（或任何其他版本的 C5）。如果您愿意，您可以在我写的关于 C/RH 版本控制的早期答案中详细阅读此内容，但很可能您yum update在 9 月下旬/10 月初这样做时将系统升级到 5.11。您可以确认与grep centos-release /var/log/yum.log*，如果你喜欢。