Перейти к основному содержимому

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

Когда использовать​

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

Рассылка собирается из двух частей. Почтовый сервер задаётся в файле окружения диспетчера vStack Center на управляющей ВМ. Включение, получатели и порог важности задаются в интерфейсе журнала. Без сервера форма в интерфейсе сохраняется без ошибок, но письма не уходят. Это самая частая причина жалоб «настроили, а писем нет».

Предусловия​

  • SMTP-сервер, который принимает письма от управляющей ВМ без аутентификации. Логина, пароля и режима шифрования диспетчер не принимает;
  • доступ по SSH к управляющей ВМ с правами root;
  • роль Cluster master для сохранения настроек рассылки. Security Admin настройки видит, но сохранить не может;
  • версия vStack Center — 3.0.3 или новее.

Шаги​

Шаг 1. Задайте почтовый сервер на управляющей ВМ​

Добавьте параметры в файл окружения диспетчера /usr/local/etc/vstack_center_dispatcher.env:

SMTP_HOST=192.0.2.25
SMTP_PORT=25
SMTP_SEND_FROM=vstack-security@example.com
SMTP_TIMEOUT=15000
ПараметрЗначение
SMTP_HOSTАдрес SMTP-сервера. Пустое значение или отсутствие строки выключает отправку
SMTP_PORTПорт, по умолчанию 25
SMTP_SEND_FROMАдрес отправителя. Без него письма уходят от no-reply@vstack.com, и почтовый сервер организации может отклонить письмо от чужого домена
SMTP_TIMEOUTТаймаут соединения в миллисекундах, по умолчанию 15000

Исходящие соединения управляющей ВМ по умолчанию не ограничены. Если вы их закрыли, откройте порт SMTP-сервера.

Шаг 2. Перезапустите диспетчер и проверьте лог​

service vstack_center_dispatcher restart

Диспетчер читает параметры только при запуске. В логе в каталоге /var/log/vstack-center-dispatcher/ найдите одну из строк:

СтрокаЧто значит
SMTP initialized: host=…, port=…Почтовый транспорт создан, можно переходить к интерфейсу
SMTP_HOST not set — email notifications disabledДиспетчер параметр не прочитал: проверьте имя файла и строку SMTP_HOST

Строка SMTP initialized не значит, что сервер доступен. Диспетчер подключается к нему только при отправке письма.

Шаг 3. Включите рассылку в журнале​

  1. Откройте Sites → нужный кластер → Security Event Log.
  2. Нажмите Actions над таблицей и выберите Notification settings.
  3. Включите переключатель Enable email notifications.
  4. В поле Recipients введите адрес и нажмите Enter. Адрес встанет в список под полем. Так добавляются несколько адресов, лишний снимается крестиком.
  5. В поле Minimum severity for email выберите порог.
  6. Нажмите Save. Появится сообщение «Notification settings updated».

Изменение настроек попадает в журнал событием config.security_settings_changed. Правка файла окружения на шаге 1 идёт мимо API, и в журнал не пишется.

Шаг 4. Выберите порог важности​

Письмо приходит о событии, у которого важность не ниже порога. Порог по умолчанию — alert. Событий уровня emergency в справочнике нет, поэтому при пороге alert письма приходят только о пяти нарушениях целостности.

ПорогО чём придут письма
alert (по умолчанию)integrity.file_violation, integrity.config_violation, integrity.vm_config_violation, integrity.manifest_invalid, integrity.log_chain_broken
criticalвсё выше, плюс auth.account_locked, system.disk_space_exhausted, os.kernel_panic и другие события уровня critical
error и нижевсё выше, плюс нештатные остановки узла и средства виртуализации (os.shutdown_unclean, system.service_stopped_unclean) и прочие события выбранного уровня

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

Несовпадение контрольной суммы образа при импорте (integrity.image_sha256_mismatch) идёт с важностью warning, хотя относится к категории целостности. Письмо о нём придёт только при пороге warning и ниже.

Порог ниже error даст поток писем о каждом рядовом событии: неудачный вход имеет уровень warning, успешный — info.

Что приходит в письме​

Тема — [vStack Security] <наименование события> — <код уровня>, например [vStack Security] Блокировка учётной записи — critical. Наименование берётся из справочника типов на русском языке.

Тело — простой текст:

Событие безопасности
Наименование: Блокировка учётной записи
Уровень: Критическое состояние (critical)
Дата/время: 2026-10-09T08:15:42.118305+00:00
Субъект: operator (uid=17)
Объект: user/17 (operator)
Результат: success
IP: 198.51.100.40

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

При разборе письма учитывайте три особенности:

  • время в письме — момент формирования письма в UTC, а не время записи в журнале. Обычно разница в доли секунды, но сверять по нему записи до миллисекунды нельзя;
  • номера записи и UUID события в письме нет. Запись в журнале находят фильтром по типу события и времени — см. «Как читать журнал и фильтровать события»;
  • письмо уходит после того, как запись сохранена. Если запись откатилась, письма не будет. Медленный или недоступный сервер запись в журнал не задерживает.

Проверка результата​

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

  1. Поставьте порог critical.
  2. Заведите тестовую учётную запись и исчерпайте на ней лимит неудачных попыток входа. В журнале появится auth.account_locked.
  3. В логе диспетчера на каждого получателя появится email notify: sent to <адрес> или email notify: failed to send to <адрес> с причиной.
  4. Проверьте ящик получателя.
  5. Разблокируйте или удалите тестовую учётную запись и верните порог, если нужен другой.

Строка sent to значит, что письмо принял SMTP-сервер, а не что оно дошло до ящика. Если в логе sent to, а письма нет, ищите его в спаме и в журнале почтового сервера.

Если не получилось​

Настройки сохранены, писем нет. Найдите в логе диспетчера запись о последнем запуске. Если там SMTP_HOST not set — email notifications disabled или нет строки SMTP initialized, почтовый сервер не задан. На событиях выше порога в логе при этом появляется email notify: SMTP not available. Выполните шаги 1 и 2.

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

В логе failed to send to <адрес>. SMTP-сервер недоступен или отклонил письмо. Причина — в той же строке. Частые: сервер требует аутентификацию или TLS, отправитель из чужого домена (задайте SMTP_SEND_FROM), порт закрыт. Повторной отправки нет: письмо об этом событии потеряно, запись в журнале осталась.

После обновления vStack Center письма перестали приходить. Файл окружения диспетчера генерируется заново при каждом развёртывании конфигурации управляющей ВМ, в том числе при обновлении, и строки SMTP_* из него пропадают. После каждого обновления проверяйте строку SMTP initialized в логе и при необходимости повторите шаги 1 и 2.

Настройки не сохраняются (-24007). Адрес получателя введён с ошибкой либо не нажат Enter и адрес не попал в список.

В меню Actions нет пункта Notification settings. У роли нет привилегии View Security Notify Settings. Сохранять настройки может только Cluster master.

Ограничения​

  • Логина, пароля и TLS для SMTP диспетчер не поддерживает. Если почтовый сервер организации требует аутентификацию, нужен промежуточный релей, который принимает письма от управляющей ВМ без неё.
  • Повторной отправки нет. Сбой доставки виден только в логе диспетчера, в журнале безопасности и в интерфейсе его нет.
  • Почтовый сервер задаётся только в файле окружения. Через интерфейс и API его не настроить, и обновление его стирает.

Методы API​

Операции этой страницы в API: security-event-notify-settings-get, security-event-notify-settings-set — см. Справочник API.

См. также​