rkhunter предупреждает об изменении inode, но никаких изменениях даты модификации файла
У меня есть несколько систем рабочий Centos 6 с установленным rkhunter. У меня есть ежедневный крон, работающий 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 будет обычно сообщать об измененном хеше и/или дате модификации на просканированных файлах к, таким образом, это приведет меня думать, что нет никакого реального изменения.
Мой вопрос: есть ли некоторое другое действие по машине, которая могла внести inode изменение (работающий ext4) или является этим действительно yum создание регулярного (~ один раз в неделю) изменяется на эти файлы как часть нормальных обновлений системы защиты?
Обновление файлов часто осуществляется путем записи нового файла в тот же каталог с последующим переименованием файла поверх старого. Этот метод обычно применяется ко всему устанавливаемому через менеджер пакетов, а также к любым обновлениям, выполняемым в исполняемых файлах и библиотеках, даже если они были обновлены по другим причинам.
Этот способ обновления файлов гарантирует, что любой процесс, открывающий файл, получит либо старый, либо новый, и не увидит никаких изменений в открытом им файле. Это действительно означает, что каждый раз при обновлении у вас будет новый файл с тем же именем, поэтому номер inode изменился.
Думаю, это и есть причина, по которой эти файлы имеют новый номер inode.
Обновление системы безопасности может быть одной из причин. Но есть и другая возможность, которую я впервые увидел на Fedora Core 1, и которая вполне могла бы в какой-то момент попасть в Centos.
Исполняемые файлы и библиотеки предварительно скомпонованы таким образом, что они могут запускаться быстрее и использовать меньше памяти. В ходе этого процесса адрес загрузки рандомизируется, чтобы немного усложнить использование уязвимостей безопасности. Задание cron будет периодически повторять процесс с новыми рандомизированными адресами, вызывая обновление всех предварительно связанных исполняемых файлов и библиотек.
.Измененный номер кода обычно означает, что файл был заменен. Это может быть, как вы говорите, связано с ожидаемым обновлением. Я бы проверил, что md5-суммы этих файлов совпадают с md5-суммами распространяемых версий. Если у вас есть другая сопоставимая система, Возможно, проще всего с этим сравнивать.
Взгляните на принятый ответ на rkhunter сообщает об изменении свойств файла, но я не вижу, чтобы они были обновлены yum для проверки, из какого пакета эти двоичные файлы.
Было бы не слишком удивительно, если бы эти двоичные файлы были из дистрибутива, который был обновлен из-за проблемы с другим двоичным файлом, который был изменен, но двоичные файлы, которые вы перечислили, были включены в новую версию пакета без каких-либо изменений. Показал ли ваш отчет также какой-то двоичный файл, в котором содержимое было изменено?
Den anden mulighed, jeg fandt, var at deaktivere disse egenskabstest fuldstændigt. Hvis du redigerer /etc/rkhunter.conf og leder efter DISABLE_TESTS linjen og ændrer den til:
DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps properties"
egenskaberne testen er den, der kontrollerer og returnerer falske positive på fil-hashes.
Я клонировал диск на диск большего размера и получил предупреждения о файлах с разными номерами inodes. Я удалил rkhunter из системы, переустановил и снова запустил сканирование без предупреждений об изменении номеров индексов