Судебная экспертиза на тоннах изменений файла
До моего сведения дошло, что мой CentOS 5.6 5.11 VPS содержит более 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
Весь остаток сентября был менее 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 на все меньшие и меньшие периоды времени, перезапуская поиск, пока не получу разумное количество результатов для просмотра вручную, но я, вероятно, понятия не имею, на что смотрю - я Я действительно не эксперт по 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 и другие вещи, которые выглядят. вполне нормально. Это кому-нибудь что-нибудь говорит? Ничто из того, что я видел в списке, не выглядит подозрительно; Я не эксперт, но это больше похоже на невинное обновление. Но я не знаю, как будет происходить обновление, кроме входа в оболочку или Webmin.
2 ответа
Этот вопрос находится на пути к закрытию как дубликат " Как мне поступить с скомпрометированным сервером", и я думаю, что это ошибка, потому что очень правильный совет в этом вопросе - обнулить сервер и восстановить с заведомо исправного носителя. Тем не менее, нет абсолютно никаких доказательств того, что эта система была взломана.
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, и что файлы в связанных пакетах также должны иметь их, и что эти 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)
Asides:
Если выходные данные этой команды содержат стену общих библиотек и исполняемых файлов, которые не могут быть связаны с обновлением ОС, наиболее вероятной причиной является наложение руткита поверх вашей операционной системы.
Другая возможность (которую вы должны меньше учитывать) - это невежественный администратор, который запускает жадный rsync из другой системы в эту. Это вряд ли будет восстановление из архивной копии (программное обеспечение для резервного копирования,
tarи т. д.), поскольку те, как правило, хорошо о чествованииmtime,Если вы не можете понять это, у вас нет выбора, кроме как рассматривать это как вторжение.