Коротко. Системный журнал отвечает на вопрос «кто вошёл», подсистема аудита Linux на вопрос «кто и что сделал». Пишите не всё подряд, а семь категорий событий с понятными ключами, фильтруйте служебные процессы, следите за счётчиком потерянных событий и увозите журнал с машины. И помните про флаг чтения ротированных файлов: без него поиск покажет пустоту там, где события есть.

Вопрос приходит обычно после инцидента или перед проверкой: кто подключался к серверу под административной учётной записью, кто менял конфигурацию, кто читал файл с паролями. Администратор идёт в системный журнал и обнаруживает, что там есть факт входа и больше почти ничего. Разбираем, откуда берутся ответы на такие вопросы в Linux и почему включённый аудит часто показывает не то, что от него ждут.

Симптом

На вопрос «кто это сделал» ответа нет. Видно, что конфигурация изменилась, но не видно кем и когда. Видно, что служба перезапускалась, но не видно по чьей команде. Файл с ключами кто-то читал, но кто именно, установить нечем.

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

Почему обычных журналов мало

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

  • Действия под административной учётной записью не видны. Записывается, что пользователь вошёл, а дальше он работает с полными правами, и в журнале остаётся тишина.
  • Команда и её последствия это разные вещи. Механизм повышения прав пишет, какая команда запущена. Что она сделала с файлами, он не пишет. Редактор, открытый через него, менял один файл или десять, из журнала не видно.
  • Чтение файлов не фиксируется вовсе. Факт, что кто-то открыл файл с ключами и скопировал содержимое, обычными средствами не регистрируется.
  • Кто именно, а не под кем. Несколько администраторов переходят в одну и ту же административную учётную запись, и после этого их действия неразличимы.

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

Что писать

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

Категория Что регистрируем Зачем
Вход и выход успешные и неуспешные попытки, источник подключения подбор пароля, вход в нерабочее время
Повышение прав переход к административной учётной записи, запуск от её имени кто именно работал с полными правами
Учётные записи и группы создание, изменение, удаление, смена пароля появление посторонней учётной записи
Критичные конфигурации изменения настроек служб, правил доступа, планировщика несогласованное изменение
Секреты и ключи обращение к каталогам с ключами и сертификатами утечка учётных данных
Подсистема аудита изменение и выключение правил, остановка службы попытка замести следы
Время перевод системных часов подделка порядка событий

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

Четыре грабли, на которых теряют события

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

Поиск смотрит только в текущий файл. Самая обидная грабля. Штатная утилита поиска по умолчанию читает только активный журнал. Как только он провернулся по ротации, вчерашние события исчезают из выдачи, хотя файлы лежат на диске рядом. Человек делает вывод, что аудит не работает, и отключает его. Лечится флагом, который велит утилите читать в том числе ротированные файлы:

ausearch -k izmenenie_konfigov --input-logs -ts yesterday

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

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

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

Диагностика

Четыре команды, чтобы понять текущее состояние.

auditctl -s          # работает ли служба, сколько событий потеряно
auditctl -l          # какие правила реально загружены
aureport --summary   # сводка за период
ausearch -k kluchi --input-logs -ts this-week

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

Что смотрим Чем Норма
Потерянные события auditctl -s, поле lost ноль и не растёт
Загруженные правила auditctl -l совпадают с тем, что в конфигурации
Размер журнала и ротация каталог журналов аудита ротация работает, диск не кончается
Доставка в хранилище поиск событий по ключу в хранилище события за сегодня есть

Что сделать

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

Чего не делать

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