Как читать попытки входа в Zimbra и не пропустить взлом

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

Какие логи Zimbra смотреть при подозрении на подбор

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

Если подозрение связано с веб-клиентом или авторизацией в ящике, сопоставляйте mailbox.log и audit.log с журналами веб-прокси и MTA; конкретный набор зависит от схемы сервера. При проблеме запуска mailboxd отдельно полезен zmmailboxd.out, но он не заменяет аудит входов. /var/log/maillog и /var/log/auth.log — не обязательные универсальные точки для Zimbra: имена и маршрутизация системных журналов зависят от дистрибутива и конфигурации syslog. Не копируйте чужую команду поиска вслепую. Найдите события тестовым входом под своей учетной записью и проверьте, в какой файл они попали.

Фиксируйте временной диапазон, часовой пояс, имя сервера и часовой разрыв между узлами. В многосерверной схеме внешний прокси может быть источником адреса, видимого mailboxd; без учета доверенных прокси можно ошибочно приписать попытки самому прокси или потерять исходный адрес клиента. Сохраняйте исходные журналы в отдельном месте с ограниченным доступом и настройте ротацию так, чтобы они не исчезли до разбора. Лог помогает восстановить последовательность событий, но сам по себе не гарантирует полноту расследования и не доказывает, кто физически сидел за подключением.

• `/var/log/zimbra.log` — прежде всего MTA и системные события.
• `/opt/zimbra/log/mailbox.log` — события mailboxd.
• `/opt/zimbra/log/audit.log` — события аудита аутентификации.
• Сверьте реальные пути и ротацию на своей установке.

Как выглядит массовый подбор — и чего он не доказывает

Автоматизированный подбор часто оставляет серии неудачных попыток: один источник перебирает несколько имен или много источников обращаются к одному сервису. Встречаются несуществующие адреса и общеупотребительные имена, но это лишь признаки для сортировки событий. У атакующего могут быть реальные адреса из утечки, а ботнет может распределять попытки между адресами. Поэтому схема «один IP — случайные логины — значит безопасно» не работает. Она описывает один частый шаблон, а не выдает заключение о безопасности.

Число ошибок тоже не диагноз. Сотни записей могут быть следствием повторов почтового клиента со старым паролем, неверной настройки устройства или внешнего сканирования. С другой стороны, редкие попытки могут быть целенаправленными. Ищите последовательность: имя учетной записи, протокол или точку входа, источник, время, результат авторизации и соседние события. Сравнивайте с известными действиями пользователей и плановыми проверками. Если адрес клиента меняется из-за мобильной сети или прокси, IP сам по себе особенно слабая улика.

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

• Повторяющиеся отказы — повод группировать события.
• Случайные имена и один источник не доказывают безвредность.
• Spraying распределяет редкие попытки по учетным записям.
• Проверяйте и отказ, и успешную авторизацию.

Когда подозревать компрометацию учетной записи

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

После подозрительного успеха проверяйте не только сам факт входа. Ищите изменения настроек ящика, новые правила пересылки, неизвестные делегирования, отправленные письма, изменения пароля и повторные авторизации через другие протоколы. В Zimbra соответствующие следы могут находиться в разных журналах; документация по Authentication Log Events показывает, как сопоставлять события mailbox и MTA. Проверьте, не затронуты ли другие учетные записи с теми же учетными данными. Успешная авторизация — серьезный сигнал, но для вывода о масштабе нужен разбор действий после неё.

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

• Сверьте успешный вход с владельцем аккаунта.
• Проверьте правила пересылки, делегирование и отправленные письма.
• Сохраните журналы и смените пароль при признаках компрометации.

Условный кейс: как не перепутать шум и риск

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

Допустим, первая группа — частые отказы на случайные имена, а вторая — редкие обращения к реальным адресам. Это заставляет проверить реальные аккаунты в первую очередь, но не подтверждает password spraying автоматически. Ищем, действительно ли повторяется ограниченный набор паролей — в открытых логах сами пароли обычно не должны фигурировать; сопоставляем характер отказов и временные интервалы, смотрим доступные аудит-события. Затем проверяем, не появились ли успешные авторизации и подозрительные изменения в ящиках. Только после этого можно описать наблюдаемую картину без выдуманных процентов и географических догадок.

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

• Сгруппировать события по учетной записи, времени и источнику.
• Отдельно проверить успешные входы.
• Не приписывать атаке географию без проверки прокси.
• Записать выводы и оставшиеся неизвестными факты.

Что настроить после разбора логов

Сначала проверьте базовые вещи: сервер и компоненты обновляются по поддерживаемой для вашей установки процедуре, доступ к административным интерфейсам ограничен, резервные копии проверяются восстановлением. Открывайте только нужные сервисы, но не применяйте список портов из чужой статьи как готовую конфигурацию: набор зависит от роли узла и того, как пользователи подключаются. Например, 993 обычно используют для IMAPS, 995 — для POP3S, 443 — для HTTPS, однако наличие этих портов не описывает все необходимые потоки почтовой системы. Сверьте опубликованный наружу набор со схемой именно вашего развертывания.

Ограничение частоты и блокировка источников могут снизить поток автоматических попыток, но требуют аккуратной настройки. Вендор публиковал инструкцию по Fail2Ban для Zimbra; в ней отдельно сказано настроить originating IP (OIP) до конфигурации Fail2Ban и учесть топологию прокси. Без этого можно банить адрес прокси вместо источника или затронуть своих пользователей. Решение также зависит от firewall и правил маршрутизации. Поэтому не добавляйте произвольный jail по шаблону из форума на рабочий сервер: проверьте совпадение логов, тестируйте правило и держите способ отката.

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

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

• Проверьте доступность обновлений и резервного восстановления.
• Настройте OIP до Fail2Ban и проверьте поведение блокировки.
• Включите MFA там, где её поддерживает ваша конфигурация.
• Собирайте события входа и регулярно проверяйте оповещения.

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