AIDE: контроль целостности файлов в Linux и проверка изменений

Если злоумышленник заменил системную утилиту или изменил конфигурацию, обычно это замечают не сразу. AIDE решает эту задачу простым способом: запоминает состояние выбранных файлов (права, владельца, размер, время изменения, хэш) и при следующей проверке показывает, что добавилось, исчезло или изменилось. Ниже порядок настройки и результаты проверки на тестовом каталоге.

Статья опирается на логику направления «Безопасность конечных устройств» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Проверка выполнена с AIDE 0.18.3 в контейнере Debian 12, после неё всё удалено.

Что должно получиться

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

Конфигурация

В боевой системе используется файл /etc/aide/aide.conf и пакетные правила; для проверки мы взяли минимальный файл для тестового каталога /watch. Принцип тот же: группы атрибутов и список путей.

# Минимальная конфигурация AIDE для проверки целостности (тестовый каталог /watch)
database_in=file:/var/lib/aide/aide.db
database_out=file:/var/lib/aide/aide.db.new
gzip_dbout=yes
report_url=stdout

# что сравнивать: права, владелец, размер, время изменения, хэши
Content = p+u+g+s+m+sha256
# для журналов проверяем только права и владельца
Logs = p+u+g

/watch/etc Content
/watch/bin Content
/watch/log Logs
!/watch/etc/cache

• Content — права, владелец, группа, размер, время изменения и хэш SHA-256: для бинарных файлов и конфигураций.
• Logs — только права и владелец: содержимое и размер журналов меняются постоянно, хэш для них даст шум.
• Строка с ! исключает путь (кэш, временные файлы).

Что включать в реальную систему: /etc, /bin, /sbin, /usr/bin, /usr/sbin, /boot, ключи и конфигурации служб (/root/.ssh, /etc/ssh). Каталоги с постоянно меняющимися данными (/var/log, /var/cache, /tmp, базы данных) исключайте или проверяйте только права.

Эталонная база и проверка

aide --init --config /etc/aide/aide.conf
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
aide --check --config /etc/aide/aide.conf

Инициализация создаёт базу (в тесте — 6 записей) под именем aide.db.new; её нужно переименовать в aide.db, иначе проверять будет не с чем. Сразу после создания базы проверка вернула код 0. Затем мы внесли изменения:

Коды возврата

Код возврата AIDE — набор битов: 1 — есть добавленные файлы, 2 — удалённые, 4 — изменённые; значения суммируются. В тесте: добавление и изменения дали 5 (1+4), после удаления файла — 7. Коды от 14 и выше означают ошибку: при опечатке в имени группы (Contnt) инициализация вернула 17 и сообщение с файлом и номером строки, при отсутствии базы проверка вернула 18. Скрипт, который расшифровывает код:

#!/usr/bin/env bash
# Проверка целостности AIDE: расшифровка кода возврата (битовая маска).
CONF="${1:-/etc/aide/aide.conf}"
aide --check --config "$CONF"
rc=$?
(( rc == 0 )) && echo "aide: изменений нет"
(( rc & 1 ))  && echo "aide: добавлены файлы"
(( rc & 2 ))  && echo "aide: удалены файлы"
(( rc & 4 ))  && echo "aide: изменены файлы"
(( rc >= 14 )) && echo "aide: ошибка запуска или конфигурации (код $rc)"
exit $rc

Для мониторинга достаточно отличать «0» от «не 0», а подробности смотреть в отчёте. Отправляйте отчёт на почту или в систему журналов: правила обнаружения в Wazuh могут реагировать на текст отчёта.

Обновление базы

После плановых изменений (обновление пакетов, правка конфигурации) эталон нужно обновить: aide --update создаёт новую базу aide.db.new, её переименовывают в aide.db. Команда --update сама возвращает код различий (в тесте 7), поэтому не считайте это ошибкой. Главное правило: обновляйте базу только после просмотра отчёта. Иначе вы запишете в эталон то, что оставил злоумышленник.

Самое слабое место AIDE — сама база: тот, кто получил root, может подменить и её. Храните копию базы и контрольную сумму на другом носителе или сервере (подпись GPG) и сравнивайте с ней.

Порядок внедрения

1. Определите критичные узлы: серверы с доступом из интернета, управляющие серверы, узлы с данными.
2. Установите AIDE из пакетов дистрибутива и подберите пути и группы атрибутов.
3. Создайте эталонную базу на чистой, только что обновлённой системе и сохраните копию вне сервера.
4. Настройте ежедневную проверку по расписанию (cron или таймер systemd), результат отправляйте в систему мониторинга.
5. Сопоставляйте отчёт с планом работ: каждое изменение объяснено заявкой или обновлением, необъяснённое — повод для расследования.
6. Обновляйте базу после просмотра отчёта и фиксируйте, кто это сделал.
7. Дополните защиту: базовая настройка системы (Debian), ограничение прав (sudo).

Диагностика

Где это в модели зрелости

Материал относится к направлению «Безопасность конечных устройств» (материалы направления, карта зрелости). Уровень 2 требует базовых мер защиты серверов и контроля их состояния: контроль целостности показывает несанкционированные изменения, которые иначе остаются незамеченными.

Как проверить

1. На критичных серверах создана эталонная база, её копия хранится вне сервера.
2. Проверка запускается по расписанию, результат попадает в мониторинг.
3. Тестовое изменение файла из списка (например, добавление строки в конфигурацию) отражается в отчёте.
4. Каждое изменение в отчёте сопоставляется с заявкой или обновлением.
5. База обновляется только после просмотра отчёта.

Источники

• Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
• Документация AIDE: aide.github.io; исходный код: github.com/aide/aide.