rkhunter предупреждает об изменении индекса, но дата изменения файла не изменяется

8

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

Мой вопрос: есть ли какие-либо другие действия на компьютере, которые могут вносить изменения в inode (работает ext4), или это действительно yumрегулярные (~ раз в неделю) изменения этих файлов как часть обычных обновлений безопасности?

centos yum rkhunter Ник Коттрелл
источник

Ответы:

8

Обновление файлов часто выполняется путем записи нового файла в тот же каталог с последующим переименованием файла поверх старого файла. Этот метод обычно применяется ко всему, что установлено через менеджер пакетов, но также и к любому обновлению, выполняемому для исполняемых файлов и библиотек, даже если оно обновляется по другим причинам.

Этот способ обновления файлов гарантирует, что любой процесс, открывающий файл, получит либо старый, либо новый, и не увидит ничего изменяющегося в файле, который они открыли. Это означает, что каждый раз, когда он обновляется, у вас фактически будет новый файл с тем же именем, следовательно, номер инода изменился.

Я думаю, это причина того, что у этих файлов новый номер инода.

Обновление безопасности может быть одной из причин. Но есть еще одна возможность, которую я впервые наблюдал в Fedora Core 1, и которая в какой-то момент вполне могла превратиться в Centos.

Исполняемые файлы и библиотеки предварительно связаны между собой, так что они могут запускаться быстрее и использовать меньше памяти. Во время этого процесса адрес загрузки рандомизируется, чтобы сделать использование уязвимостей безопасности немного сложнее. Задание cron будет периодически повторять процесс с новыми рандомизированными адресами, вызывая обновление всех предварительно связанных исполняемых файлов и библиотек.

kasperd
источник
2
Да, предварительная ссылка кажется наиболее вероятным объяснением здесь.
Майкл Хэмптон
Есть ли хороший способ справиться с этим, хотя? Если бы у меня был только cron, rkhunter --propupdто я мог бы пропустить хак и лишить законной силы весь смысл rkhunter, верно?
Ник Коттрелл
1
@NicholasTolleyCottrell rpmобрабатывает его, сначала проверяя целостность prelinkисполняемого файла, а затем вызывает prelinkисполняемый файл с аргументами, чтобы отменить предварительную связь с вводом из предварительно связанного исполняемого файла и выводом на стандартный вывод. Затем rpmможете проверить целостность этого вывода. Не знаю, можно ли применить этот подход rkhunter.
Касперд
1
Посмотрите эту ветку для получения контрольной суммы, которая не будет перескакивать: linuxquestions.org/questions/linux-security-4/… . Я отошел от rkhunter как инструмент на основе cron. У него много полезных проверок, но невозможность отключить проверки, которые составляют ложные срабатывания, делает его почти бесполезным для привлечения вашего внимания, где это необходимо, так как я просто привыкаю игнорировать его отчеты по электронной почте. Я все еще нахожу это иногда полезным как инструмент, запускаемый вручную.
mc0e
2

Другой вариант, который я нашел, - полностью отключить эти тесты свойств. Если вы редактируете /etc/rkhunter.confи ищете DISABLE_TESTSстроку и меняете ее на:

DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps properties"

Этот propertiesтест проверяет и возвращает ложные срабатывания хэшей файла.

Ник Коттрелл
источник
1

Изменение номера индекса обычно означает, что файл был заменен. Это может быть, как вы говорите, из-за ожидаемого обновления. Я бы проверил, что md5sums этих файлов соответствуют распределенным версиям. Если у вас есть другая сопоставимая система, это может быть проще всего сравнить с этим.

Взгляните на принятый ответ в отчетах rkhunter об изменении свойств файла, но я не вижу, чтобы они были обновлены yum для того, чтобы проверить, из какого пакета эти бинарные файлы.

Было бы не слишком удивительно, если бы эти двоичные файлы были из дистрибутива, который был обновлен из-за проблемы с другим двоичным файлом, который был изменен, но список двоичных файлов был включен в новую версию пакета без изменений. В вашем отчете также был какой-то бинарный файл, в котором содержание было изменено?

mc0e
источник
Нет, на самом деле, похоже, я только что узнал, что свойства файла изменились, но никогда не изменилось содержимое.
Ник Коттрелл
-1

Я клонировал диск на больший диск и получил предупреждения о файлах с разными номерами inode. Я удалил rkhunter из системы, переинсталлировал и снова запустил сканирование без предупреждений о том, что номера инодов меняются

Уилл Смит
источник