我注意到，我的CentOS 5.6 5.11 VPS在今年九月的三天时间里，有超过一万六千个有时间戳的档案。 我不明白这是为什么，因为那段时间我没有通过SSHlogin（也没有任何其他login，这会非常令人担忧），并且在那段时间没有Webmin中的操作logging。 这些是我可以做任何改变系统文件的唯一两种方式。 服务器似乎运行良好，但没有其他人应该有访问（当然除了主机），所以我想知道发生了什么事情。
我用文件中的这些date捕获了这些文件：
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
九月份的整个月份总共不到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结果进行sorting。 我可以反复重置start.tmp和stop.tmp到越来越小的时间段，重新运行查找，直到我有合理数量的结果来手动查看，但我可能不知道我在看什么 – 我反正真的不是Linux专家。 也许有人可以给我一些关于什么“问题”我应该问我的服务器的提示。 看起来好像Linux被重新安装了，但是…
更新：对于那些问，这里是第16个时间戳的前几个文件。 第一个似乎没有关系，但是从15:04开始，在接下来的几分钟里，超过5000个文件被更新（或创build，我想）：
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的这种types的文件之后需要rest一会儿之前更多.so文件和其他东西很正常。 这是否告诉任何人？ 我在列表中没有看到任何人看起来可疑。 我不是专家，但看起来更像是一个天真的更新。 但是我不知道除了shelllogin或Webmin以外如何进行更新。
这个问题的关键在于如何处理受损服务器 ，我认为这是一个错误，因为在这个问题上非常正确的build议是从已知好的介质中加载服务器并恢复。 但是， 绝对没有证据表明这个系统已经被破坏了。
OsakaWebbie，你已经承认你的操作系统版本是错误的; 该系统在5.11。 给出的是，你列出的文件都是glibc-headers包的一部分，除了/usr/lib64/libc.so ，它是glibc-devel一部分，这是一个通过glibc-headers传递的包，通常是build在同一时间。
我会在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 [...]
请注意构build和安装date。 现在让我们看看有问题的文件：
[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 [...]
请注意，这些文件的所有时间戳都是相同的，并且在将生成date放入RPM中前几分钟。 由此我们可以得出结论： RPM控制的系统文件的修改时间是在创buildRPM的构build系统上的修改时间 ; 由于构build是一个单一的过程，因此RPM中的所有文件都应该具有非常相似的m时间，而且确实相关的包中的文件也应该有这些时间，而这些时间将不对应于包被安装 。
如果你能确认你的系统确实在C5.10 / 5.11，你可以停止恐慌; 你没有提供任何证据表明你的系统发生了什么坏事。
编辑 ：OsakaWebbie，你已经确认系统现在在5.11，我提交这个是不是问题。 您所显示文件的修改时间与您期望的完全相同。
作为参考 – 这是非常重要的，你明白这一点 – C5.11不是C5的主要版本。 C6是与C5不同的主要版本，但C5.11只是一个完整的C5.6（或任何其他版本的C5）。 如果你愿意的话，你可以在C / RH版本编写的早期答案中详细阅读这个问题 ，但如果你在9月底/ 10月初yum update了yum update话，你很可能把系统带到了5.11。用grep centos-release /var/log/yum.log*确认，如果你喜欢的话。
我主要是从一个无关的问题来看C＆P的答案。 我认为这是一个更好的家园。 提供以下说明，假定您已经按照如何处理受损服务器的说明进行操作。 如果适用。 如有疑问，请务必断开networking电缆。
find /filesystem1 /filesystem2 -xdev -printf '%T@ %t %p\n' | sort -n
%T@修改时间，纪元秒（用于sorting）
%t修改时间，人类可读
%p完整文件path
季节去品尝。 一次运行一个已安装的文件系统，或者按照您认为相关的次数运行。
这样做是给你一个时间戳sorting审计最近的文件修改。 这有时可以让你了解未知事件发生的其他事情。 这当然不是防弹的，也许根本不会透露任何东西，但是我偶尔会发现这个非常有用的function，可以确定在发生未知事件时正在进行的工作。 （即有人执行rm -Rf /lib而不是rm -Rf lib ）
旁白：
如果此命令的输出包含一系列不能与操作系统更新关联的公共库和可执行文件，最可能的原因是rootkit覆盖在操作系统之上。
另一个可能性（你不应该考虑）是一个无知的pipe理员从另一个系统运行一个贪婪的rsync到这个。 这不太可能是一个归档副本（备份软件， tar等）的恢复，因为那些通常是尊重原始的mtime 。
如果你不能弄清楚，你别无select，只能把它当作入侵。