Руткиты — это вредоносные программы, которые скрывают своё присутствие в системе на уровне ядра или файловой системы. Регулярное сканирование с помощью rkhunter и chkrootkit позволяет обнаружить компрометацию сервера.

Установка и настройка rkhunter

apt install rkhunter -y

# Обновить базу данных хешей
rkhunter --update
rkhunter --propupd  # Сохранить текущие свойства файлов как эталон

# Запустить полное сканирование
rkhunter --check --sk --rwo  # --sk = пропустить нажатия клавиш, --rwo = только предупреждения

Важные настройки /etc/rkhunter.conf

MAIL-ON-WARNING=admin@example.com
MAIL_CMD=mail -s "[rkhunter] Warning on $(hostname)"
CRON_DAILY_RUN=yes

# Исключить ложные срабатывания
SCRIPTWHITELIST=/usr/sbin/adduser
ALLOWHIDDENFILE=/etc/.gitconfig
PKGMGR=DPKG  # Использовать dpkg для проверки пакетов

Установка и использование chkrootkit

apt install chkrootkit -y
chkrootkit
# Вывод: INFECTED означает потенциальную угрозу
# Вывод: not infected — чисто

Автоматическое сканирование по расписанию

# /etc/cron.daily/rkhunter-check
#!/bin/bash
/usr/bin/rkhunter --cronjob --update --quiet 2>&1 |   mail -s "rkhunter Daily Report - $(hostname)" admin@example.com

chmod +x /etc/cron.daily/rkhunter-check

Что делать при обнаружении угрозы

Изолировать сервер — отключить от сети (не выключать!)
Сделать образ диска для forensics-анализа
Проверить запущенные процессы: ps aux, netstat -tulnp
Проверить cron и автозапуск: crontab -l, systemctl list-units
Восстановить из чистого бэкапа на новый сервер

Лучшая практика: Запускайте rkhunter --propupd сразу после установки чистой системы и после каждого обновления пакетов. Это создаёт актуальный эталон для сравнения при следующем сканировании.

Ложные срабатывания rkhunter — частое явление. Каждое предупреждение нужно исследовать, прежде чем делать выводы о компрометации. Начните с проверки через dpkg -V пакет.

Разбор типичных предупреждений сканеров

Warning: The command '/usr/bin/which' has been replaced by a script: /usr/bin/which — классическое ложное срабатывание на Debian и Ubuntu, где /usr/bin/which — обычный shell-скрипт, а не бинарник. rkhunter ожидает бинарный файл и путает штатную особенность дистрибутива с подменой злоумышленником.
Warning: The SSH configuration option 'PermitRootLogin' has been set to 'yes' — это предупреждение о самой настройке sshd, а не о заражении. Исправляется правкой /etc/ssh/sshd_config, а не поиском руткита на диске.
Warning: The file properties have changed for: /usr/sbin/adduser с указанием текущего и сохранённого хеша — сообщает, что файл изменился после последнего rkhunter --propupd. Само по себе это не значит компрометацию, если изменение пришло от планового обновления пакета через apt.
The following suspicious files and directories were found: — заголовок раздела в выводе chkrootkit, под которым перечисляются конкретные находки. Пустой список сразу под этим заголовком — и есть ожидаемый чистый результат.
Итоговая сводка System checks summary в конце вывода rkhunter показывает число предупреждений и путь к подробному логу /var/log/rkhunter.log — туда стоит смотреть при любом Warning, а не гадать по обрывкам консольного вывода.

rkhunter и chkrootkit: в чём разница

Критерий	rkhunter	chkrootkit
Проверка контрольных сумм файлов	Да, через базу `--propupd`	Нет
Проверка конфигурации sshd и sudo	Да	Нет
Поиск известных руткитов по сигнатурам	Да, обновляемая база	Да, отдельный встроенный список
Автоматизация по расписанию	Готовый скрипт в `/etc/cron.daily`	Нужно настраивать вручную
Активность поддержки проекта	Обновляется регулярно	Обновляется заметно реже
Удобно использовать вместе	Основной инструмент	Дополнительная сверка другим движком сигнатур

Когда сканеры руткитов не защищают

Как единственный метод защиты — и rkhunter, и chkrootkit ищут уже известные сигнатуры и типичные следы; таргетированный руткит, написанный под конкретную цель, может пройти мимо обоих сканеров незамеченным.
Проверка уже скомпрометированной системы её же собственными утилитами — если атакующий получил root, он мог подменить сами бинарники rkhunter или chkrootkit либо библиотеки, которые они используют, и тогда сканер честно отчитается «чисто», хотя это уже неправда. Для реального расследования нужен образ диска и анализ с внешнего носителя.
Контейнеры и immutable-инфраструктура, где сервер пересоздаётся из образа при каждом деплое — ручное сканирование на руткиты внутри контейнера теряет смысл; там упор делают на неизменяемость образа и проверку целостности до запуска, а не после.
Продакшен с жёстким SLA по нагрузке в момент полного сканирования — --check обходит всю файловую систему и может дать заметную дисковую нагрузку; такие проверки планируют на окно низкой нагрузки, а не запускают вручную в пик трафика.

Проверка, что сканирование реально настроено

# Убедиться, что база свойств файлов существует и не пустая
ls -la /var/lib/rkhunter/db/rkhunter.dat

# Проверить дату последнего обновления сигнатур
rkhunter --versioncheck

# Прогнать разовую проверку и сразу посмотреть итоговую сводку
rkhunter --check --sk --rwo | tail -20

# Убедиться, что задача на ежедневный автоматический прогон реально существует
ls -la /etc/cron.daily/rkhunter-check

Чистый результат — это ноль предупреждений в сводке System checks summary, файл базы с недавней датой изменения и исполняемый файл в cron.daily с правами rwxr-xr-x. Если cron-файла нет или у него нет бита на выполнение — ежедневные проверки попросту не запускаются, независимо от того, что показал ручной прогон.