Это предупреждение означает, что хэш-сумма, размер или дата изменения файла больше не совпадают с данными, сохраненными в базе утилиты Rootkit Hunter. Чаще всего это ложное срабатывание (False Positive) после обычного обновления пакетов в системе (например, обновления пакета systemd или sysvinit).
Чтобы исключить компрометацию системы, выполните проверку по шагам:
1. Верификация файла через пакетный менеджер
Проверьте целостность файла с помощью штатных средств дистрибутива, чтобы убедиться, что он совпадает с официальным репозиторием:
- Для Debian / Ubuntu:
Узнайте, какому пакету принадлежит файл, и проверьте его контрольную сумму:dpkg -S путь_к_файлуsudo debsums -s sysvinit-utils # подставьте имя пакета, если оно отличается (Еслиdebsumsничего не вывел — файл оригинальный).
- Для RHEL / CentOS / Rocky Linux:
rpm -Vf путь_к_файлу(Отсутствие вывода означает, что файл чист).
2. Проверка истории обновлений
Убедитесь, что пакет, содержащий этот файл, действительно обновлялся недавно. Посмотрите логи пакетного менеджера:
grep -i «systemd» /var/log/apt/history.log # для Ubuntu/Debian
# или
grep -i «sysvinit» /var/log/dpkg.log
# или
dnf history list # для RHEL-систем
3. Обновление базы данных rkhunter
Если проверка подтвердила, что файл легитимен (изменился из-за обновлений), обновите снимок свойств файлов в базе данных rkhunter, чтобы предупреждение исчезло при следующих проверках:
sudo rkhunter --propupdКак автоматизировать процесс на будущее
Чтобы rkhunter не спамил предупреждениями после каждого легитимного обновления системы, настройте интеграцию с пакетным менеджером:
- Откройте конфигурационный файл
/etc/rkhunter.conf. - Найдите и раскомментируйте директиву управления пакетами (для Debian/Ubuntu):
PKGMGR=DPKG(Для RPM-систем укажитеPKGMGR=RPM). - В файле
/etc/default/rkhunter(если он есть) убедитесь, что включено автоматическое обновление базы после работы:APT_AUTOGEN="true"
Если dpkg-query сообщает: no path found matching pattern
Эта ошибка обычно означает, что файл либо символическая ссылку (symbolic link), которая указывает на механизм альтернатив Linux (/etc/alternatives/*), либо он был установлен вручную в обход пакетного менеджера (например, скомпилирован из исходников).
В современных дистрибутивах Linux (Ubuntu/Debian) классический клиент telnet по умолчанию не устанавливается, так как он небезопасен.
Давайте быстро проверим, есть ли вообще этот файл физически, и решим, что делать:
1. Проверьте физическое наличие файла
Выполните команду, чтобы узнать, существует ли файл и является ли он ссылкой:
ls -la /usr/bin/telnetЕсли файл существует, но dpkg его не знает
Это подозрительный сценарий. Если файл лежит в системной директории, но пакетный менеджер о нем ничего не знает, это может быть признаком стороннего вмешательства (или ручной установки администратором).
Как проверить подозрительный файл, если dpkg молчит?
Если файл существует, проверьте его тип и дату изменения:
file путь_к_файлу
stat путь_к_файлу(Команда stat покажет точное время изменения файла Modify. Сравните его с датами обновления системы).
Если вывод команды stat покажет не сам бинарный файл, а всего лишь символическая ссылку (symbolic link), которая указывает на механизм альтернатив Linux (/etc/alternatives/*):
1. Найдите финальный исполняемый файл
Механизм альтернатив ведет на конечный бинарник. Давайте узнаем, куда именно указывает эта цепочка ссылок:
readlink -f путь_к_файлу2. Проверьте этот финальный файл через dpkg
Когда вы получите реальный путь из первой команды (например, /usr/bin/telnet.netkit), подставьте его в пакетный менеджер:
dpkg -S /путь/к/финальному/файлу