Мониторинг целостности файлов

Что это на самом деле выявляет, что могут пропустить логи

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

Компромисс в том, как это используется

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

Как изменения файлов вписываются в повседневный мониторинг, см. здесь: руководство по мониторингу сервера и анализу логов.

Как построить надёжную эталонную базу в AIDE

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

Что именно контролируется, задают правила в aide.conf. Правило это список атрибутов, соединённых знаками плюс: p для прав, u и g для владельца и группы, s для размера и sha256 для контрольной суммы, а строка выбора связывает путь с правилом. Знак ! в начале исключает путь:

Critical = p+u+g+s+sha256
/etc Critical
/usr/bin Critical
/usr/sbin Critical
!/var/log/.*

Стройте эталон сразу после завершения укрепления и до развёртывания приложений, чтобы первый снимок отражал состояние, которому вы доверяете. Затем следуйте руководству по хранению: оно советует перенести новую базу в защищённое место, например на носитель только для чтения, а файл конфигурации не держать на целевой машине. Для VPS это значит скопировать оба файла на другой хост, а не оставлять рядом с защищаемыми файлами. Ограничивайте охват: логи, кэши и загрузки меняются постоянно, а руководство по мониторингу объясняет, почему шум сводит смысл контроля на нет.

Что чистый отчёт доказывает, а что нет

Контроль целостности файлов это обнаружение, а не предотвращение. NIST SP 800-94 описывает его как периодический расчёт контрольных сумм критичных файлов и сравнение их с эталонными значениями и подчёркивает, что он может лишь постфактум установить, что файл уже изменён, например системный бинарный файл подменён троянской программой или руткитом. То же руководство предупреждает, что некоторые продукты привязываются к именам файлов, поэтому злоумышленник, переименовав файлы, может их ослепить, и отделяет такой контроль от агентов, которые следят за попытками доступа к файлам и умеют останавливать подозрительные.

Три привычки сохраняют пользу сигнала. Запускайте проверку по расписанию и отправляйте результат за пределы сервера, потому что отчёт, оставшийся на скомпрометированной машине, можно подправить. Запускайте её сразу после каждого планового обновления, сверяйте различия с тем, что вы действительно меняли, и только потом выполняйте aide --update и сохраняйте новую базу. Необъяснимое различие в /usr/bin или /etc/ssh считайте инцидентом: сохраните улики и действуйте по руководству по реагированию на взлом. Руководство по управлению патчами объясняет, как планировать обновления, чтобы ожидаемые изменения легко отличались от неожиданных.

Связанные термины: SIEM, Реагирование на инциденты, UID 0, RECOVERED и VERIFIED, auditd (аудит Linux), journalctl (просмотр журнала systemd).