У контролю цілісності є незручна властивість: йому потрібен еталон, знятий із системи, про яку відомо, що вона чиста. Якщо сервер працює три роки, а питання про злам виникло лише сьогодні, знімати цей еталон уже пізно — ви зафіксуєте як норму те, що там є.

Проте на Debian та Ubuntu еталон уже існує, і він не ваш: кожен встановлений пакет несе контрольні суми власних файлів. Порівняння з ними не потребує ні налаштування, ні попереднього знімка і працює на будь-якій системі будь-якої миті. Інструмент називається debsums.

Як користуватися

sudo apt install debsums
sudo debsums -c

Прапорець -c виводить лише файли, які не збіглися з еталоном. Без нього вивід — це порядковий звіт про кожен файл у системі, десятки тисяч рядків.

Перевірка триває кілька хвилин і навантажує диск, тож на робочому сервері її варто запускати зі зниженим пріоритетом:

sudo ionice -c3 nice -n19 debsums -c

Як читати результат

Порожній вивід означає, що кожен перевірений файл збігається з тим, що встановив дистрибутив. Непорожній вивід треба розібрати, і знахідки поділяються на два дуже різні класи.

Конфігураційні файли в /etc. Їх змінювати — звичайна робота: ви правили sshd_config, налаштовували nginx, додавали параметри ядра. Такі відмінності очікувані. Щоб вони не плуталися під ногами, є окремий режим:

sudo debsums -e -c

-e перевіряє лише конфігураційні файли — часом корисно, щоб побачити список усього, що ви на цій машині змінювали.

Виконувані файли й бібліотеки. Відмінність у /usr/bin, /usr/sbin, /bin чи /usr/lib — це те, заради чого перевірка й запускалася. Легітимні причини є, але їх небагато: файл правили руками під час налагодження, застосували сторонній патч, пакет оновлювався саме під час перевірки. Якщо не підходить жодна, час розбиратися серйозно.

Класичні цілі підміни — ls, ps, netstat, ss, find, sshd. Підмінена версія ховає зі свого виводу потрібні рядки, і будь-яка ваша наступна перевірка перестає говорити правду.

Покриття неповне — і про це треба знати

Обмеження, про яке зазвичай не згадують: контрольні суми постачають не всі пакети. Файли з таких пакетів не перевіряються взагалі й у звіті не з’являться за жодних обставин. Список видно так:

sudo debsums -l

Тому чистий звіт debsums означає «у перевіреній частині все гаразд», а не «систему не змінювали». Те саме стосується всього, встановленого поза менеджером пакетів: зібраного з вихідного коду, завантаженого бінарником, поставленого скриптом із сайту розробника — за це debsums за визначенням не стежить, і саме тут потрібен AIDE.

Регулярний запуск

Пакет постачає готове завдання, яке вмикається в /etc/default/debsums:

CRON_CHECK=weekly

Раз на тиждень — розумна частота: перевірка помітно навантажує диск, а системні файли між оновленнями змінюються рідко. Щоденний запуск не додає нічого, крім навантаження.

Якщо файл справді підмінили

Перший порив — перевстановити пакет і повернути оригінал:

sudo apt install --reinstall coreutils

Команда правильна, але не як перша дія. Підмінений системний бінарник означає, що в когось був root, і відновлення файла цієї проблеми не розв’язує — воно лише знищує сліди. Порядок має бути зворотним: спершу збережіть копію підозрілого файла й час його зміни, подивіться, що ще змінилося в той самий період, перевірте завдання cron, ключі SSH і список користувачів. Відновлювати — лише після цього.

Варто пам’ятати й межі методу: якщо систему скомпрометовано глибоко, то й сам debsums, і бібліотеки, які він використовує, могли бути підмінені разом з усім іншим. Перевірка зсередини не дає абсолютної гарантії — її дає завантаження із зовнішнього носія. Для повсякденної роботи цього все ж досить: переважна більшість атак автоматизована й не така витончена.

Його місце в загальній картині

debsums хороший тим, що йому нічого не потрібно й він працює одразу — що робить його зручною відправною точкою для сервера, історії якого ви не знаєте. Його слабкість — неповне покриття й незнання всього, що поставлено поза пакетами. Пара «debsums плюс AIDE» закриває обидві сторони: готовий еталон дистрибутива для системних файлів і ваш власний знімок для решти.

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