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

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

Встановлення й перша база

sudo apt install aide aide-common
sudo aideinit

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

sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Далі перевірка запускається так:

sudo aide --check

Що виключити, щоб звіт лишався читабельним

Налаштування живуть у /etc/aide/aide.conf і в каталозі /etc/aide/aide.conf.d/. Штатна конфігурація Debian перевіряє забагато, і перше, що треба зробити, — прибрати те, що постійно змінюється саме собою:

  • /var/log — змінюється щосекунди;
  • увесь /var/lib — бази даних, стан пакетів, стан служб;
  • /var/cache, /tmp, /proc, /sys, /run;
  • каталоги завантажень і кешу сайту — їхній вміст змінюють відвідувачі.

Перевіряти з найсуворішими налаштуваннями варто вузький список:

  • /bin, /sbin, /usr/bin, /usr/sbin — виконувані файли системи;
  • /lib, /usr/lib — бібліотеки;
  • /etc — конфігурація;
  • /root/.ssh і каталоги .ssh ваших користувачів;
  • код сайту, але без каталогів завантажень і кешу.

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

Де тримати базу

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

Розумний мінімум для одного сервера:

  • копіювати базу на іншу машину після кожного оновлення й запускати перевірку з підставленою копією;
  • або принаймні зберігати контрольну суму бази окремо й звіряти її перед перевіркою:
sha256sum /var/lib/aide/aide.db

Навіть такий простий захід перетворює тиху підміну на помітну подію.

Оновлення бази — свідома дія

Після легітимних змін — оновлення системи, викладання нової версії сайту — базу перебудовують:

sudo aide --update
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

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

Розклад і навантаження

Пакет aide-common сам ставить щоденне завдання. Перевірка навантажує диск і процесор на кілька хвилин, тож її варто запускати в тиху годину і зі зниженим пріоритетом:

0 4 * * * ionice -c3 nice -n19 /usr/bin/aide --check

Як читати звіт

Три розділи: додані, видалені та змінені файли. Для кожної зміни показано, що саме відрізняється: вміст, права, власник, час.

На що реагувати першим:

  • зміна будь-якого файла в /bin, /sbin, /usr/bin поза вікном оновлення;
  • нові файли в системних каталогах;
  • зміни в authorized_keys, /etc/passwd, /etc/sudoers, /etc/crontab і /etc/cron.d;
  • файл /etc/ld.so.preload, що з’явився, — сам собою він не з’являється ніколи.

Сотня змінених файлів одразу після apt upgrade — це нормально, і позначка часу звіту це підтверджує. Три змінені файли в /usr/bin у середу без жодних оновлень — привід зупинитися й розібратися.

AIDE і debsums

Інструменти розв’язують сусідні задачі, але еталон у них різний. AIDE порівнює з вашим власним знімком — тому бачить зміни в будь-яких файлах, включно з кодом сайту. debsums порівнює з контрольними сумами з пакетів дистрибутива — тому бачить підмінені системні файли взагалі без попереднього налаштування, але нічого не знає про те, що ви поставили поза пакетами. Тримати обидва розумно; на практиці першим зазвичай іде debsums, бо йому не потрібні ні конфігурація, ні база.

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