Руткіти — це шкідливі програми, які приховують свою присутність у системі на рівні ядра або файлової системи. Регулярне сканування за допомогою 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-файлу немає або в нього немає біта на виконання — щоденні перевірки просто не запускаються, незалежно від того, що показав ручний прогін.