Криминалистическая экспертиза тонны изменений файлов

Этот вопрос скоро будет закрыт как дубликат Как мне поступить с взломанным сервером, и я думаю, что это ошибка, потому что очень правильный совет в этом вопросе - ядерная бомба на сервере и восстановление с заведомо исправных носителей. Тем не мение, нет абсолютно никаких доказательств того, что эта система была взломана.

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 имели очень похожие mtimes, и действительно, что файлы в связанных пакетах также должны были иметь их, и что эти времена не будут соответствовать дате, когда пакеты были установлены.

Если вы можете подтвердить, что ваша система действительно находится на C5.10 / 5.11, вы можете перестать паниковать; вы не представили никаких доказательств того, что с вашей системой случилось что-то плохое.

редактировать: OsakaWebbie, вы подтвердили, что теперь система работает на 5.11, и я считаю, что это не проблема. Время изменения показанных вами файлов точно такое, как вы ожидаете.

Для справки - и очень важно, чтобы вы это понимали - C5.11 не является основным выпуском C5. C6 - это другой основной выпуск по сравнению с C5, но C5.11 - это просто полностью исправленный C5.6 (или любая другая версия C5). Ты можешь прочитайте об этом достаточно подробно в более раннем ответе, который я написал о версиях C / RH если хотите, но, по всей вероятности, вы довели систему до 5.11, когда сделали это yum update в конце сентября / начале октября. Вы можете подтвердить это с помощью grep centos-release /var/log/yum.log*, если хочешь.

Я собираюсь в основном C&P ответить на мой ответ от не связанный вопрос. Думаю, это лучший дом для него. Приведенные ниже инструкции предполагают, что вы уже выполнили инструкции для Как мне поступить с взломанным сервером? если это применимо. В случае сомнений всегда отключайте сетевой кабель.

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

%T@ Время модификации, эпохальные секунды (для сортировки)

%t Время модификации, читается человеком

%p Полный путь к файлу

Приправить по вкусу. Запускайте одновременно только одну смонтированную файловую систему или столько, сколько считаете нужным.

Это дает вам отсортированный по временным меткам аудит самых последних изменений файлов. Иногда это может дать вам представление о других вещах, которые происходили во время неизвестного события. Это, конечно, не пуленепробиваемое, и может вообще ничего не раскрывать, но я иногда нахожу это чрезвычайно полезным для определения того, какая работа выполнялась в то время, когда произошло неизвестное событие. (т.е. кто-то выполняет rm -Rf /lib вместо того rm -Rf lib)

В сторону:

• Если выходные данные этой команды содержат множество общих библиотек и исполняемых файлов, которые не могут быть связаны с обновлением ОС, наиболее вероятной причиной является наложение руткита поверх вашей операционной системы.

• Другая возможность (которую вам следует менее склонно рассматривать) - это невежественный администратор, запускающий жадный rsync из другой системы в эту. Вряд ли будет восстановление из архивной копии (ПО для резервного копирования, tarи т. д.), поскольку они, как правило, хороши для соблюдения оригинала mtime.

• Если вы не можете этого понять, у вас нет другого выбора, кроме как рассматривать это как вторжение.