У меня есть несколько систем под управлением Centos 6 с установленным rkhunter. У меня есть ежедневный cron, который запускает rkhunter и отправляет отчеты по электронной почте.
Я очень часто получаю такие отчеты:
---------------------- Start Rootkit Hunter Scan ----------------------
Warning: The file properties have changed:
File: /sbin/fsck
Current inode: 6029384 Stored inode: 6029326
Warning: The file properties have changed:
File: /sbin/ip
Current inode: 6029506 Stored inode: 6029343
Warning: The file properties have changed:
File: /sbin/nologin
Current inode: 6029443 Stored inode: 6029531
Warning: The file properties have changed:
File: /bin/dmesg
Current inode: 13369362 Stored inode: 13369366
Насколько я понимаю, rkhunter обычно сообщает об изменении хэша и / или дате модификации отсканированных файлов, поэтому это наводит меня на мысль, что реальных изменений нет.
Мой вопрос: есть ли на машине какие-то другие действия, которые могут изменить индексный дескриптор (запуск ext4), или это действительно yum вносить регулярные (~ раз в неделю) изменения в эти файлы в рамках обычных обновлений безопасности?
Обновление файлов часто выполняется путем записи нового файла в том же каталоге с последующим переименованием файла поверх старого. Этот метод обычно применяется ко всему, что установлено через диспетчер пакетов, но также и к любому обновлению исполняемых файлов и библиотек, даже если они были обновлены по другим причинам.
Такой способ обновления файлов гарантирует, что любой процесс, открывающий файл, получит либо старый, либо новый, и не увидит никаких изменений в файле, который они открыли. Это означает, что каждый раз, когда он обновляется, у вас фактически будет новый файл с тем же именем, поэтому номер inode изменился.
Я предполагаю, что это причина того, что эти файлы имеют новый номер inode.
Одной из причин могло быть обновление безопасности. Но есть и другая возможность, которую я впервые заметил в Fedora Core 1, и она вполне могла в какой-то момент попасть в Centos.
Исполняемые файлы и библиотеки предварительно связываются, чтобы они могли запускаться быстрее и использовать меньше памяти. Во время этого процесса адрес загрузки рандомизируется, чтобы немного усложнить использование уязвимостей безопасности. Задание cron будет периодически повторять процесс с новыми случайными адресами, вызывая обновление всех предварительно связанных исполняемых файлов и библиотек.
Другой вариант, который я нашел, - полностью отключить эти тесты свойств. Если вы редактируете /etc/rkhunter.conf и ищите DISABLE_TESTS строку и измените ее на:
DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps properties"
В properties test - это тот, который проверяет и возвращает ложные срабатывания хэшей файлов.
Измененный номер inode обычно означает, что файл был заменен. Как вы говорите, это могло произойти из-за ожидаемого обновления. Я бы проверил, что md5sum этих файлов соответствуют таковым в распространяемых версиях. Если у вас есть другая сопоставимая система, ее проще всего сравнить с ней.
Взгляните на принятый ответ на rkhunter сообщает об изменении свойств файла, но я не вижу, чтобы они были обновлены yum чтобы узнать, из какого пакета эти двоичные файлы.
Было бы не слишком удивительно, если бы эти двоичные файлы были из дистрибутива, который был обновлен из-за проблемы с другим двоичным файлом, который был изменен, но двоичные файлы, которые вы перечисляете, были включены в новую версию пакета без изменений. В вашем отчете также показан двоичный файл, в котором содержимое был изменилось?
Я клонировал диск на диск большего размера и получил предупреждения о файлах с разными номерами inode. Я удалил rkhunter из системы, переустановил и снова запустил сканирование без предупреждений об изменении номеров inodes