Контроль целостности Linux-сервера с AIDE: установка, правила и автоматические проверки в 2026 году

AIDE создаёт эталонную базу файлов Linux-сервера и сравнивает её с текущим состоянием системы. Инструмент обнаруживает добавление, удаление и изменение файлов, включая изменения содержимого, хешей, прав доступа, владельца, группы, размера, времени модификации, inode и расширенных атрибутов.

Рабочая схема выглядит так: администратор устанавливает AIDE, выбирает критичные каталоги, исключает виртуальные файловые системы и заведомо изменяющиеся данные, проверяет конфигурацию, создаёт baseline после проверки сервера, запускает aide --check через systemd timer, разбирает отчёт и только после подтверждения плановых изменений обновляет базу.

AIDE помогает заметить несанкционированную замену системного бинарного файла, изменение /etc/ssh/sshd_config, появление неизвестного systemd unit или ослабление прав на конфигурацию. Инструмент не блокирует атаку, не заменяет резервное копирование, централизованное журналирование, контроль доступа и мониторинг. Локальная база и отчёты требуют отдельной защиты, поскольку при полном захвате хоста злоумышленник может попытаться изменить или удалить их.

Как AIDE контролирует целостность Linux-сервера

AIDE, Advanced Intrusion Detection Environment, хранит сведения о выбранных файлах в базе. При проверке он повторно читает файловую систему, вычисляет актуальные атрибуты и сравнивает их с baseline. Результат попадает в отчёт с категориями Added, Removed и Changed.

Для сервера с SSH, веб-сервисом и systemd обычно начинают с /etc, системных каталогов с исполняемыми файлами, /boot и unit-файлов. Полный список зависит от роли хоста. На сервере баз данных потребуется отдельно оценить конфигурацию СУБД, скрипты резервного копирования и каталоги с исполняемыми расширениями.

Что именно проверяет AIDE

Набор проверяемых атрибутов задаётся правилами в aide.conf. Типичная запись может включать следующие свойства:

• Хеш содержимого. Показывает изменение данных внутри файла. Для новых конфигураций обычно выбирают SHA-256 или более сильный алгоритм, доступный в конкретной сборке AIDE.
• Размер. Помогает быстро заметить добавление данных, обрезку файла или замену бинарного объекта.
• Время модификации, mtime. Показывает, когда файл менялся. Этот атрибут полезен для корреляции с деплоем и журналами, но сам по себе не доказывает изменение содержимого.
• Права доступа. Изменение режима с 0644 на 0666 или добавление бита исполнения может быть существенным событием.
• Владелец и группа. Смена владельца конфигурации или systemd unit может дать процессу лишний доступ.
• Inode и тип файла. Помогают зафиксировать замену обычного файла, каталога, символической ссылки или другого объекта.
• ACL и extended attributes. Эти свойства нужно включать, если сервер использует POSIX ACL, SELinux или другие расширенные атрибуты файловой системы.

Изменение хеша говорит о смене содержимого. Изменение только mtime указывает на другую операцию, например пересохранение файла или восстановление метаданных. Отчёт нужно читать по сочетанию атрибутов, а не реагировать на одну строку.

MD5 и SHA-1 встречаются в старых конфигурациях и пакетах. Для контроля целостности новых профилей выбирайте SHA-256, SHA-512 или другой современный алгоритм, который поддерживает установленная версия AIDE. Хеш не защищает базу от подмены, если злоумышленник получил права root и доступ к файлу baseline.

Какие файлы имеет смысл защищать в первую очередь

Минимальный профиль должен охватывать файлы, изменение которых влияет на вход в систему, повышение привилегий, запуск служб или поведение приложений:

• /etc, включая SSH, sudo, PAM, сеть, systemd и конфигурации демонов;
• /boot, включая конфигурацию загрузчика и initramfs, если эти файлы доступны в системе;
• /bin, /sbin, /usr/bin и /usr/sbin;
• /lib, /lib64 и соответствующие каталоги библиотек;
• /usr/lib/systemd/system, /etc/systemd/system и каталоги drop-in конфигураций;
• каталоги конфигурации веб-сервера, reverse proxy, агента мониторинга и других критичных приложений;
• скрипты деплоя, резервного копирования и обслуживания, если они запускаются с правами root.

На хосте с Nginx добавьте фактические каталоги конфигурации и пользовательские systemd unit-файлы. На сервере Docker отдельно проверьте конфигурацию демона, systemd unit контейнерных сервисов и управляющие скрипты. Каталоги с большими рабочими данными не нужно включать автоматически, если их содержимое меняется по штатному процессу.

Для общей проверки hardening и аудита системы используйте отдельный чек-лист безопасности Linux-сервера: практическое руководство по hardening и аудиту Linux. AIDE закрывает контроль целостности, а аудит проверяет более широкий набор настроек.

Ограничения контроля целостности

AIDE сравнивает состояние файлов с базой. Он не определяет намерения процесса, не блокирует запись, не анализирует сетевой трафик и не заменяет EDR или систему управления конфигурациями.

Локальное хранение создаёт несколько рисков:

• при компрометации root злоумышленник может заменить baseline после изменения файла;
• отчёт в локальном журнале может быть удалён или отфильтрован;
• таймер можно остановить, отключить или заменить;
• избыточные правила создают большой поток ложных срабатываний;
• слишком широкие исключения скрывают изменения в важных каталогах.

Храните копии базы и отчётов на отдельной системе с ограниченной записью. Контролируйте доступ к unit-файлам, журналам и каталогу AIDE. События о выполнении проверки передавайте в систему мониторинга или SIEM. Резервная копия базы не заменяет расследование, но помогает сравнивать состояния и обнаруживать попытки подмены.

Установка AIDE на Debian, Ubuntu и RHEL-подобные системы

Названия пакетов, расположение базы и вспомогательные команды отличаются между дистрибутивами. Перед созданием автоматизации проверьте пути локально через command -v, dpkg -L или rpm -ql.

Установка через apt

Для Debian и Ubuntu выполните установку от root:

sudo apt update
sudo apt install aide

Проверьте бинарный файл и версию:

command -v aide
aide --version
dpkg -L aide | sed -n '1,120p'

Пакет может предложить автоматически создать базу или запустить инициализацию через системный скрипт. Сначала проверьте /etc/aide/aide.conf, список исключений и состояние сервера. Baseline, созданный до проверки конфигурации, часто приводит к шумным отчётам и закрепляет нежелательные изменения.

В Debian и Ubuntu рабочая база часто располагается в /var/lib/aide, но фактический путь задаётся конфигурацией и параметрами сборки пакета. Не подставляйте этот путь в unit-файлы без проверки.

Установка через dnf

Для RHEL, Rocky Linux, AlmaLinux, CentOS Stream и Fedora используйте:

sudo dnf install aide
command -v aide
aide --version
rpm -ql aide | sed -n '1,160p'

В старых окружениях вместо dnf может использоваться yum:

sudo yum install aide

Команды aideinit, aide --init, расположение aide.db и имя systemd unit зависят от пакета. Проверьте доступные варианты:

command -v aideinit || true
systemctl list-unit-files | grep -i aide
man aide
man aide.conf

Если команда grep недоступна в минимальном образе, просмотрите вывод systemctl list-unit-files вручную. Для производственного сервера зафиксируйте фактические пути и версии в документации change management.

Проверка окружения перед настройкой

До редактирования правил проверьте базовые условия:

hostnamectl
 timedatectl status
 test -d /run/systemd/system && echo systemd-ok
 df -h /var /tmp
 test -r /etc/aide/aide.conf && echo config-readable
id

В команде с hostnamectl лишний пробел перед timedatectl не нужен, поэтому в рабочем скрипте используйте такой вариант:

hostnamectl
timedatectl status
test -d /run/systemd/system && echo systemd-ok
df -h /var /tmp
test -r /etc/aide/aide.conf && echo config-readable
id

Проверка времени нужна для корреляции отчёта с обновлениями и деплоями. Убедитесь, что на разделе с базой достаточно свободного места. Полный проход по большому серверу может потребовать заметных ресурсов CPU, диска и памяти.

Настройка правил AIDE в aide.conf

Конфигурация описывает макросы атрибутов, правила для путей и исключения. Синтаксис и доступные имена наборов могут различаться, поэтому ориентируйтесь на комментарии в локальном aide.conf и вывод aide --version.

Выбор атрибутов: содержимое, права и владельцы

Для системных бинарных файлов нужен криптографический хеш. Для конфигураций добавьте права, владельца, группу, размер и время изменения. Для каталогов полезны метаданные, но проверка хеша самого каталога не означает проверку содержимого всех вложенных файлов.

Удобно определить несколько наборов:

# Пример наборов. Проверьте имена атрибутов в aide.conf вашей версии.
Full = p+i+n+u+g+s+m+c+acl+xattrs+sha256
Config = p+i+n+u+g+s+m+c+acl+xattrs+sha256
Metadata = p+i+n+u+g+s+m+c

Обозначения обычно имеют такой смысл: p, права; i, inode; n, имя; u, владелец; g, группа; s, размер; m, mtime; c, ctime. Поддержка acl, xattrs и конкретного хеша зависит от версии.

Не включайте максимальный набор механически. Если система часто меняет ctime из-за штатных операций, отчёт может быстро стать шумным. Для критичных путей лучше оставить полный набор, а для менее значимых каталогов использовать метаданные или отдельный профиль.

Пример минимального профиля для критичных путей

Ниже приведена основа для сервера с SSH, веб-службой и systemd. Пути нужно сверить с конкретной системой.

@@define DBDIR /var/lib/aide
@@define LOGDIR /var/log/aide

database=file:@@{DBDIR}/aide.db
database_out=file:@@{DBDIR}/aide.db.new

Full = p+i+n+u+g+s+m+c+acl+xattrs+sha256
Config = p+i+n+u+g+s+m+c+acl+xattrs+sha256

/etc Full
/boot Full
/bin Full
/sbin Full
/usr/bin Full
/usr/sbin Full
/lib Full
/lib64 Full
/usr/lib/systemd/system Full
/etc/systemd/system Full
/etc/ssh Config
/etc/sudoers Config
/etc/sudoers.d Config
/etc/nginx Config

Если каталог отсутствует, AIDE может сообщить предупреждение или ошибку, в зависимости от правил и версии. Проверьте наличие путей:

for path in /etc /boot /bin /sbin /usr/bin /usr/sbin /lib /lib64 /usr/lib/systemd/system /etc/systemd/system /etc/ssh /etc/sudoers.d /etc/nginx; do
    test -e "$path" && echo "present: $path" || echo "missing: $path"
done

В некоторых системах /bin, /sbin и /lib связаны с каталогами внутри /usr. Повторное включение таких путей может увеличить время проверки и число дубликатов в отчёте. Проверьте символические ссылки и оставьте набор, который соответствует вашей схеме файловой системы.

Какие каталоги исключать из проверки

Виртуальные и временные файловые системы обычно не включают в baseline:

• /proc, псевдофайловая система процессов;
• /sys, интерфейс ядра и устройств;
• /dev, устройства и динамические узлы;
• /run, runtime-состояние служб;
• /tmp и /var/tmp, временные данные;
• кэши пакетного менеджера и приложений;
• очереди, lock-файлы и каталоги с постоянно изменяющимися PID;
• рабочие данные баз, очередей и пользовательских загрузок, если их не требуется проверять через AIDE.

Пример исключений:

!/proc
!/sys
!/dev
!/run
!/tmp
!/var/tmp
!/var/cache
!/var/lock
!/var/run

Исключение /var/log требует отдельного решения. Высокая частота записи не делает журналы бесполезными для контроля. Защищайте конфигурацию логирования, права на журналы и централизованную доставку событий. Сами логи лучше проверять средствами log management, auditd или SIEM.

Не исключайте каталог приложения только потому, что в нём часто происходят изменения. Выделите конфигурации, исполняемые скрипты и плагины в отдельные правила. Динамические данные вынесите в отдельный путь и контролируйте их другим инструментом.

Проверка конфигурации до создания baseline

Перед инициализацией проверьте синтаксис и доступность базы. Варианты команд зависят от версии:

aide --config-check
# Если такой режим отсутствует:
aide --help | sed -n '1,160p'

Запустите тестовый проход без замены эталона:

aide --check

На ещё не инициализированной системе команда может завершиться ошибкой из-за отсутствия базы. Это ожидаемо. Проверьте, что ошибка связана именно с отсутствием baseline, а не с неверным путём, правами или синтаксисом.

Просмотрите потенциально шумные места:

find /etc /boot /usr/lib/systemd/system -xdev -type f | sed -n '1,120p'
find /proc /sys /dev /run -maxdepth 1 -type f 2>/dev/null

После проверки в правилах должны остаться критичные файлы, а виртуальные файловые системы и постоянные runtime-данные должны быть исключены. Не переходите к созданию baseline, пока не объяснены предупреждения.

Создание и защита эталонной базы baseline

Baseline нужно создавать после завершения плановых изменений и проверки чистоты системы. База фиксирует состояние хоста на момент инициализации. Если на сервере уже есть подозрительные изменения, AIDE запишет их как норму.

Проверка системы перед инициализацией

Сверьте состояние сервера с журналом работ:

• проверьте последние обновления пакетов;
• сопоставьте активные systemd-сервисы с ожидаемым списком;
• проверьте SSH-ключи, локальные учётные записи и правила sudo;
• просмотрите недавние события аутентификации и повышения привилегий;
• зафиксируйте изменения конфигурации и результаты деплоя;
• проверьте запущенные процессы, сетевые слушатели и задания cron.

Для базовой инвентаризации используйте:

systemctl --type=service --state=running
ss -lntup
getent passwd
sudo -l
journalctl --since "24 hours ago"

Команда sudo -l показывает права текущего пользователя и может потребовать пароль. Не публикуйте её вывод вместе с чувствительными настройками.

Инициализация базы AIDE

На одних пакетах используется aideinit, на других прямой вызов aide --init. Сначала проверьте справку:

aideinit --help 2>/dev/null || true
aide --help | sed -n '1,160p'

Типовая последовательность с прямой инициализацией:

sudo aide --init
sudo find /var/lib/aide -maxdepth 1 -type f -ls

Инициализация обычно создаёт новый файл с суффиксом .new, например aide.db.new. Не переименовывайте файл вслепую. Сначала определите фактическое имя базы в конфигурации:

grep -E '^[[:space:]]*(database|database_out)' /etc/aide/aide.conf
sudo find /var/lib/aide /var/lib/aide* -maxdepth 2 -type f -ls 2>/dev/null

Если пакет предоставляет aideinit, используйте его штатный сценарий:

sudo aideinit
sudo find /var/lib/aide /var/lib/aide* -maxdepth 2 -type f -ls 2>/dev/null

После проверки созданного файла замените рабочую базу способом, который принят в вашем пакете. Для типичного каталога:

sudo install -o root -g root -m 0600 /var/lib/aide/aide.db.new /var/lib/aide/aide.db
sudo ls -l /var/lib/aide/aide.db

Путь в команде примерный. Используйте путь, который вы получили из aide.conf и вывода пакета.

Защита локальной и удалённой копии

Ограничьте доступ к базе и отчётам:

sudo chown -R root:root /var/lib/aide /var/log/aide
sudo chmod 0700 /var/lib/aide /var/log/aide
sudo chmod 0600 /var/lib/aide/aide.db

Каталог и имя файла могут отличаться. Проверьте результат:

namei -l /var/lib/aide/aide.db
stat /var/lib/aide/aide.db

Единственная копия baseline на контролируемом сервере не подходит для расследования компрометации. Сохраняйте копию на удалённом хранилище, куда сервер не может произвольно удалять старые версии. Ограничьте права записи, добавьте версионирование и журнал операций.

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

Сервер можно разместить в облачной инфраструктуре с отдельными дисками, резервным хранилищем и изолированными сетями, например в Timeweb Cloud. Провайдер не решает задачу контроля целостности автоматически, поэтому правила AIDE, удалённые отчёты и доступ к baseline нужно настраивать самостоятельно.

Автоматические проверки через systemd timer

Ручной запуск быстро перестаёт работать как регулярный процесс. systemd service запускает проверку, а timer задаёт расписание и сохраняет результат в journal.

Unit для запуска aide --check

Сначала узнайте путь к бинарному файлу:

command -v aide

Создайте service unit /etc/systemd/system/aide-check.service с таким содержимым:

[Unit]
Description=AIDE integrity check
After=local-fs.target

[Service]
Type=oneshot
ExecStart=/usr/bin/aide --check

Путь /usr/bin/aide замените результатом команды command -v aide. Запуск идёт от root, поскольку AIDE должен читать защищённые каталоги и метаданные.

Ненулевой exit code нужно учитывать. Для AIDE он может означать найденные изменения или ошибку проверки. В журнале должны остаться и код завершения, и полный вывод команды. Не подавляйте ошибку через || true, иначе мониторинг не увидит сбой.

Расписание и параметры systemd timer

Создайте /etc/systemd/system/aide-check.timer:

[Unit]
Description=Daily AIDE integrity check

[Timer]
OnCalendar=*-*-* 03:15:00
Persistent=true
RandomizedDelaySec=15m
Unit=aide-check.service

[Install]
WantedBy=timers.target

Persistent=true запускает пропущенную задачу после возвращения сервера в рабочее состояние. RandomizedDelaySec=15m добавляет случайную задержку и помогает не запускать одинаковые проверки на большом количестве хостов одновременно.

Для критичного сервера выбирайте ежедневную проверку. Для редко меняющейся системы может подойти еженедельное расписание:

OnCalendar=Sun *-*-* 03:15:00

Частота зависит от скорости изменений, требований аудита и допустимого времени обнаружения. Таймер не должен запускаться чаще, чем сервер способен стабильно обрабатывать полный проход.

Проверка состояния и журналов

Загрузите unit-файлы и включите timer:

sudo systemctl daemon-reload
sudo systemctl enable --now aide-check.timer
sudo systemctl list-timers aide-check.timer

Выполните тестовый запуск вручную:

sudo systemctl start aide-check.service
sudo systemctl status aide-check.service --no-pager
sudo journalctl -u aide-check.service --no-pager -n 200

Проверьте, что timer активен:

systemctl is-enabled aide-check.timer
systemctl is-active aide-check.timer
systemctl show aide-check.timer -p NextElapseUSecRealtime -p LastTriggerUSec

Если отчёт перенаправляется в файл, проверьте права каталога и наличие самого файла. Для первичной настройки лучше оставить stdout и stderr в journal. Так проще увидеть код завершения и ошибки доступа.

Автоматизацию системных проверок, включая systemd timers, Ansible и передачу событий в CI/CD, можно связать с общим процессом аудита: руководство по автоматизации аудита безопасности.

Уведомления о найденных изменениях

Запись в journal полезна для локальной диагностики, но сама по себе не гарантирует, что администратор увидит событие. Уведомления должны содержать имя сервера, время проверки, exit code, список изменённых путей и ссылку на полный отчёт внутри вашей системы мониторинга.

Отправка отчёта по email

Для небольших серверов можно использовать оболочку, которая сохраняет вывод и отправляет письмо при обнаружении изменений или ошибке:

#!/bin/sh
set -eu

REPORT=$(mktemp)
trap 'rm -f "$REPORT"' EXIT

set +e
/usr/bin/aide --check >"$REPORT" 2>&1
RC=$?
set -e

if [ "$RC" -ne 0 ]; then
    /usr/bin/mailx -s "AIDE report: $(hostname)" admin@example.invalid <"$REPORT"
fi

cat "$REPORT"
exit "$RC"

Адрес admin@example.invalid замените адресом вашей команды. Команда mailx требует настроенного MTA или SMTP-клиента. Без Postfix, другого MTA либо внешнего почтового транспорта письмо останется локальным или не будет доставлено.

В производственной системе храните полный отчёт отдельно от краткого уведомления. В письмо можно отправлять первые строки и статус, а детальный вывод передавать в защищённый log collector.

Интеграция с мониторингом

Система мониторинга должна контролировать несколько сигналов:

• timer существует и находится в состоянии active;
• service запускался в ожидаемое время;
• последний запуск завершился с допустимым кодом;
• с сервера поступает регулярное событие;
• в отчёте нет изменений в критичных путях без заявки.

Событие можно передавать через агент мониторинга, log collector, webhook или локальный обработчик. Минимальный набор полей: hostname, timestamp, результат проверки, exit code, число добавленных, удалённых и изменённых объектов, перечень критичных путей и идентификатор change record.

Для общей проверки учётных записей, SSH, firewall и журналов используйте чек-лист аудита Linux-сервера. AIDE должен передавать результаты в этот процесс, а не существовать изолированно.

Защита от незаметного отключения проверок

Контролируйте доступность таймера с внешней стороны. Локальная команда systemctl is-active не поможет, если злоумышленник получил root и подменил сам systemd или его журналы.

Практическая схема контроля:

• внешний мониторинг проверяет, что событие AIDE приходит ежедневно;
• конфигурация unit-файлов хранится в системе управления конфигурациями;
• изменения /etc/systemd/system попадают в отчёт и журнал изменений;
• отсутствие события за заданный интервал создаёт отдельное предупреждение;
• отчёты отправляются в систему, где сервер не имеет права удалить историю.

Как разбирать отчёт AIDE

Отчёт нужно сопоставлять с реальными операциями на сервере. Строка Changed: сама по себе не отвечает на вопрос, был ли файл изменён легитимно. Сначала зафиксируйте результат, затем определите тип изменения и его источник.

Added, Removed и Changed: что означает каждый статус

• Added. В области контроля появился новый файл или каталог. Это может быть новый unit после установки пакета, скрипт деплоя или неизвестный объект.
• Removed. Объект исчез. Проверьте удаление пакета, ротацию, изменение конфигурации или признаки вмешательства.
• Changed. Изменился один или несколько атрибутов существующего объекта.

В блоке изменения ищите конкретные признаки:

• sha256 или другой checksum изменился, содержимое файла отличается;
• mtime изменился, файл был записан или его время модификации корректировали;
• permissions изменились, режим доступа стал другим;
• владелец или группа изменились;
• размер изменился без смены хеша, что может указывать на особенности чтения или конфигурации правил;
• ACL или extended attributes изменились, что требует проверки политики доступа и SELinux.

Особое внимание уделяйте /etc/ssh, /etc/sudoers, /etc/systemd/system, системным бинарным файлам и скриптам, которые запускаются от root.

Плановое изменение или потенциальный инцидент

Используйте последовательную проверку:

1. Зафиксируйте полный отчёт и время запуска.
2. Составьте список изменённых файлов и атрибутов.
3. Проверьте заявку на изменение, деплой и окно обслуживания.
4. Сопоставьте изменения с историей пакетного менеджера.
5. Проверьте журналы systemd, SSH, sudo и приложения.
6. Определите процесс или оператора, который мог изменить файл.
7. Примите решение о подтверждении, откате или расследовании.

После apt upgrade или dnf update изменения системных библиотек, бинарников и unit-файлов могут быть ожидаемыми. После деплоя изменённая конфигурация приложения тоже может быть штатной. Неожиданное изменение SSH-конфигурации, sudoers, systemd unit или системного бинарника требует более строгой проверки.

Что делать при подозрительном изменении

Не обновляйте baseline сразу. Новая база запишет подозрительное состояние как эталон и уничтожит удобную точку сравнения.

1. Сохраните отчёт AIDE в защищённом хранилище.
2. Зафиксируйте состояние хоста, процессы, сетевые соединения и активные сессии.
3. Ограничьте доступ к серверу по процедуре реагирования на инциденты.
4. Сверьте хеши и содержимое с доверенным пакетом или эталонным образом.
5. Проверьте журналы аутентификации, sudo, systemd и пакетного менеджера.
6. Привлеките средства расследования и сохраните артефакты до очистки системы.

При подозрении на компрометацию root нельзя считать локальный AIDE достоверным источником в одиночку. Сравнивайте результаты с удалёнными логами, внешним мониторингом и доверенной копией baseline.

Обновление baseline после плановых изменений

Baseline обновляют после подтверждённого изменения. Перед заменой базы должен существовать понятный ответ на три вопроса: кто изменил систему, зачем это потребовалось и какие файлы должны попасть в новый эталон.

Обновление после apt upgrade или dnf update

Сначала сохраните историю операции. Для Debian и Ubuntu:

grep -E ' upgrade | install | remove ' /var/log/dpkg.log | tail -n 80
sudo apt history 2>/dev/null | sed -n '1,80p'

Для RHEL-подобных систем:

sudo dnf history
sudo dnf history info last

Сопоставьте список пакетов с отчётом AIDE. Проверьте, что изменения относятся к ожидаемым файлам. После подтверждения сформируйте новую базу. В некоторых версиях доступна команда:

sudo aide --update

Она обычно записывает новую базу в файл с суффиксом .new. Если aide --update отсутствует или ведёт себя иначе, используйте штатную последовательность из справки пакета и проверьте результат через find, stat и конфигурацию.

Обновление после изменения конфигурации или деплоя

Добавьте AIDE в процедуру релиза:

1. зафиксируйте список файлов и причину изменения;
2. выполните деплой или измените конфигурацию;
3. запустите aide --check;
4. сопоставьте отчёт с change record;
5. сохраните отчёт;
6. создайте новую базу;
7. проверьте следующую автоматическую проверку.

Для конфигураций, которые меняются при каждом релизе, заранее определите владельца процесса. AIDE не должен создавать конфликт между контролем и управляемым деплоем. В системе управления конфигурациями храните и сам aide.conf, но доступ к рабочей базе ограничивайте отдельно.

Безопасная замена базы

Сохраните старую базу, создайте копию новой и проверьте права:

DBDIR=/var/lib/aide
STAMP=$(date +%Y%m%d-%H%M%S)

sudo cp -p "$DBDIR/aide.db" "$DBDIR/aide.db.$STAMP"
sudo sha256sum "$DBDIR/aide.db" | sudo tee "$DBDIR/aide.db.$STAMP.sha256"
sudo chown root:root "$DBDIR/aide.db.$STAMP" "$DBDIR/aide.db.$STAMP.sha256"
sudo chmod 0600 "$DBDIR/aide.db.$STAMP" "$DBDIR/aide.db.$STAMP.sha256"

После этого проверьте новый файл, созданный командой инициализации или обновления. Заменяйте рабочий baseline атомарно, в пределах одного файлового раздела:

sudo chown root:root "$DBDIR/aide.db.new"
sudo chmod 0600 "$DBDIR/aide.db.new"
sudo mv -f "$DBDIR/aide.db.new" "$DBDIR/aide.db"
sudo stat "$DBDIR/aide.db"

Если новый файл находится в другом каталоге или на другом разделе, команда mv может выполнить копирование с удалением, а не атомарную замену. Сначала создайте временный файл в том же каталоге, проверьте его, затем замените рабочий файл. Причину обновления, список ожидаемых изменений, старый хеш и новый хеш запишите в change record.

Практическая схема эксплуатации AIDE

Ниже приведён регламент, который можно использовать при настройке нового Linux-сервера.

Минимальный чек-лист перед вводом в эксплуатацию

• Пакет AIDE установлен, бинарный файл и версия проверены.
• Путь к aide.conf и рабочей базе подтверждён локально.
• В правила включены /etc, SSH, sudoers, systemd unit-файлы и системные бинарники.
• Исключены /proc, /sys, /dev, /run, временные каталоги и обоснованные кэши.
• Конфигурация прошла проверку, предупреждения объяснены.
• Система проверена перед созданием baseline.
• База создана после завершения плановых изменений.
• Владелец базы, режим доступа и каталог хранения проверены.
• Защищённая копия отправляется на удалённое хранилище.
• Service и timer включены, расписание отображается через systemctl list-timers.
• Вывод проверки доступен через journalctl.
• Уведомление или событие мониторинга доходит до ответственного адресата.
• Тестовое изменение критичного файла обнаруживается.
• После теста baseline восстановлен только после проверки отчёта.

Типичные ошибки в настройке AIDE

• Проверка запускается без актуальной базы. Сначала создайте baseline после проверки системы.
• В область контроля попали виртуальные файловые системы. Добавьте явные исключения для /proc, /sys, /dev и /run.
• Исключено слишком много путей. Не убирайте конфигурации и скрипты только из-за частых изменений, выделите их в отдельные правила.
• Не настроена почта. mailx не доставляет сообщения без рабочего MTA или SMTP-транспорта.
• В unit указан неверный путь. Получите его через command -v aide.
• Timer существует, но не запускается. Проверьте systemctl status, systemctl list-timers и journalctl -u.
• Ненулевой exit code подавляется. Мониторинг теряет сигнал об изменении или ошибке.
• Baseline обновляется без анализа отчёта. Подозрительное состояние закрепляется как норма.
• Единственная копия базы хранится локально. При компрометации root её можно удалить или подменить.
• Проверяется только AIDE. Контроль целостности не заменяет логи, резервное копирование, hardening, управление конфигурациями и реагирование.

Когда AIDE нужно дополнить другими средствами

AIDE подходит для контроля файлов и метаданных, но полноценная защита Linux-сервера требует нескольких независимых механизмов:

• централизованное хранение журналов и SIEM для событий, которые нельзя доверять локальному хосту;
• резервное копирование с проверкой восстановления;
• управление конфигурациями через Ansible или другой контролируемый процесс;
• контроль учётных записей, SSH, sudo и сетевых правил;
• сканирование уязвимостей и проверка hardening;
• мониторинг доступности systemd timer и поступления отчётов;
• процедура реагирования на инциденты с сохранением артефактов.

Практический чек-лист аудита помогает связать AIDE с проверкой доступа, обновлений, SSH, firewall и журналов. Это снижает риск оценивать состояние сервера по одному показателю.

Начинайте с ограниченного профиля критичных путей. После тестовой эксплуатации добавляйте каталоги, которые действительно дают полезный сигнал. Каждое исключение фиксируйте с причиной, а каждое обновление baseline связывайте с подтверждённым изменением.