Кто менял настройки Zimbra: собираю цепочку событий

Чтобы выяснить, кто менял настройки Zimbra, я сохраняю журналы, проверяю административные права и связываю вход, операцию и результат по времени. Один успешный вход ещё не доказывает авторство изменения. Покажу порядок проверки, границы инструментов и условный разбор для питомника «Лист и корень», где важнее восстановить события, чем назначить виновного.

Какие журналы нужны после изменения настроек Zimbra

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

В документации Zimbra для событий аутентификации указан /opt/zimbra/log/audit.log, для работы почтового приложения — /opt/zimbra/log/mailbox.log, для MTA и сообщений состояния — /var/log/zimbra.log. Это разные источники. Вход в учётную запись, ошибка приложения и судьба письма отвечают на разные вопросы. Универсального главного журнала main.log я в этот список не добавляю. Перед поиском проверяю наличие файлов на нужных узлах и доступность архивов. Каталог с большим объёмом записей сам по себе ещё не означает, что нужное событие там есть.

Я отделяю вход в административный интерфейс от входа в Linux. Системный журнал входов зависит от дистрибутива и настроенного сборщика; один путь нельзя обещать для любой установки. Если изменение могло прийти через оболочку, ищу следы системной сессии и повышения привилегий. Если через приложение — сопоставляю его журналы и доступные сведения о запросе. У служебной автоматизации тоже бывает собственная учётная запись. Отсутствие записи в одном файле пока означает только отсутствие записи в этом файле. Громкое заключение из тишины получается быстро, проверяется долго.

Я отдельно отмечаю состояние журналирования на момент события: какие категории собирались, какие архивы сохранились, были ли разрывы в доставке. Настройка, включённая после сбоя, поможет следующему расследованию, но прошлое не допишет. Базовую настройку журнала аудита разбираем отдельно; здесь задача уже другая — восстановить административное изменение по сохранившимся свидетельствам. Если нужной детализации тогда не было, я прямо записываю ограничение в отчёт. Это полезнее красивой истории, которую нечем проверить.

• Аутентификация: /opt/zimbra/log/audit.log
• Работа приложения: /opt/zimbra/log/mailbox.log
• MTA и состояние: /var/log/zimbra.log
• Оболочка и права Linux: системный журнал своей установки

Как проверить, какие аккаунты могли менять настройки

Список администраторов я снимаю до изменения прав, чтобы сохранить исходное состояние. Документированная команда получения административных учётных записей — zmprov gaaa. На сервере с установленной Zimbra администратор Linux с разрешённым переключением пользователя может выполнить:

su - zimbra
zmprov gaaa

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

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

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

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

• Снять текущий список через zmprov gaaa
• Сверить владельцев, делегированные права и системный доступ
• Отделить персональные записи от автоматизации
• Закрыть лишний доступ и сохранить описание действий

Как сохранить следы и связать вход с изменением

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

Дальше строю временную шкалу. Привожу отметки к одному часовому поясу, проверяю расхождение часов между узлами и сохраняю исходное время рядом с пересчитанным. В таблицу заношу источник записи, аккаунт или процесс, наблюдаемую операцию, затронутый объект и результат. Если из строки известно только о входе, в графе операции так и пишу. Если операция подтверждена, но субъект не установлен, это отдельный пробел. Я не заполняю его предположением из соседней строки. Расследование должно оставаться понятным тому, кто не участвовал в первом разборе.

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

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

• Сохранить журналы, архивы и состояние настройки
• Сверить часы и собрать временную шкалу
• Связать субъект, операцию, объект и результат
• Отметить пробелы и альтернативные объяснения

Что действительно показывают скрипты и auditd

Сторонний zm-audit-log.pl существует: исходный код опубликован в репозитории Jim Dunphy. Он разбирает записи аутентификации и формирует сводку по аккаунтам, способам входа и адресам. В нём предусмотрена обработка файлов audit.log* через --all. Это удобный помощник для первичного просмотра, а не встроенная функция включения аудита. Я проверяю его работу на копии известных записей и сопоставляю отчёт с исходными строками. Если формат конкретной установки отличается от ожидаемого, часть событий может не попасть в сводку. Имя со словом audit не расширяет возможности программы.

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

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

Проверку уязвимостей я веду отдельной задачей. CVE-2026-73570 подтверждён у вендора и в NVD: описанная проблема касается Zimbra до 10.1.20 при установленном zimbra-snmp и включённых SNMP-уведомлениях; исправление указано в 10.1.20. Наличие такой версии исправления не означает, что сегодня нужно остановиться именно на ней: актуальные обновления сверяют отдельно. Найденная уязвимость не доказывает её использование в данном инциденте. Сканирование тоже не отвечает, кто менял настройку. В отчёте я связываю эти задачи только при наличии конкретных свидетельств эксплуатации.

• zm-audit-log.pl: сводка доступных событий аутентификации
• auditd: системные события по заранее действующим правилам
• Проверка уязвимостей: отдельная задача
• Исходные записи: основание для каждого вывода

Как я разобрал бы изменение почты в питомнике

Возьму условный питомник растений «Лист и корень» в Подмосковье, 23 рабочих места. Это учебный сценарий, а не отчёт о реальном клиенте. Для примера задаю Zimbra 10.1.20, две персональные административные записи и одну старую служебную. В журнале изменений есть согласованная правка антиспама, но после неё сотрудники сообщают о попадании ожидаемых писем в спам. Версия и число аккаунтов здесь — условия примера. В настоящем расследовании я запишу фактическую сборку, состав узлов и параметры из инвентаризации; количество рабочих мест не подменяет количество почтовых ящиков.

Пусть в условной шкале в 10:00 зарегистрирована заявка, в 10:07 есть вход служебной записи, а в 10:12 сохранённое состояние уже отличается от предыдущего. Все отметки относятся к одному дню и одному часовому поясу. Я сохраняю записи этого интервала и сравниваю изменённые параметры с заявкой. Если найден только вход, исполнитель правки ещё не установлен. Проверяю задачи автоматизации и персональные системные сессии. Доступ старого аккаунта действительно требует проверки, однако его возраст не превращает подозрение в доказанный взлом. Так учебная шкала учит проверять связь, а не угадывать виновного.

Для проверки влияния я использую согласованные тестовые письма и смотрю их прохождение через MTA, результат обработки и конечную папку. Возвращаю только подтверждённо ошибочный параметр к сохранённому рабочему значению, записав время и основание отката. Если после этого обработка изменилась ожидаемым образом, связь симптома с параметром стала убедительнее. Авторство правки остаётся отдельным вопросом. Я не объявляю причиной вирус, старый пароль или случайного внешнего посетителя без данных. Условные часы показывают порядок работы, но не служат обещанием закончить любое расследование за такой же срок.

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

• Условие: питомник, 23 рабочих места, Zimbra 10.1.20
• 10:00 — заявка; 10:07 — вход; 10:12 — новое состояние
• Откат подтверждённого параметра и контроль доставки
• Вывод об исполнителе с указанием степени подтверждения

Как сохранить историю для следующего расследования

Я проверяю ротацию отдельно для каждого источника. В документации Zimbra описаны и механизмы журналирования Java, и системный logrotate; нельзя поручить все файлы одной общей настройке. Конкретный формат конфигурации сверяю с установленной версией. Для расследования нужны доступные архивы, достаточный срок хранения и наблюдение за свободным местом. Этот срок выбирают по задачам компании и скорости обнаружения инцидентов, а не по удобному числу из чужой статьи. Если диск уже заполнен, сначала оцениваю остановившиеся процессы и сохраняю нужные следы, затем освобождаю место по согласованному порядку.

Копии журналов отправляю в отдельное хранилище с защищённой передачей и ограниченными правами. Доступ на изменение истории по возможности отделяю от обычного администрирования почты. При этом отдельная машина сама по себе не делает архив неизменяемым: нужны настроенные права и проверка того, кто может удалять записи. Я контролирую доставку журналов и умею отличать отсутствие событий от обрыва сбора. Проверка простая по смыслу: выполняем согласованное действие, находим его в источнике и затем в сохранённой копии. Фраза «куда-то отправляется» плохо работает как адрес архива.

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

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

• Ротация и хранение проверены для каждого источника
• Сбор в отдельное хранилище подтверждён контрольным событием
• У сигналов есть ответственный и порядок реакции
• После обновлений проверяется полнота истории

Частые вопросы