Что я делаю, когда почта начинает рассылать спам

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

Сначала выясните, кто именно отправляет письма

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

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

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

Я отдельно проверяю, не отправляет ли письма легальная система уведомлений или рассылки: у неё может быть свой технический пользователь, расписание и согласованный список адресатов. Сравниваю отправителя, тему, характер получателей и время запуска с тем, что владелец процесса считает нормальным. Если сервис приложения неожиданно использует личный ящик сотрудника, это уже отдельный риск доступа. Результат проверки записываю как наблюдение: «подтверждено», «не подтверждено» или «нужно проверить». Такая дисциплина не даёт превратить каждое необычное письмо в легенду о захвате сервера.

• Зафиксировать время и часовой пояс
• Сопоставить журналы входа и отправки
• Проверить очередь и правила пересылки
• Уточнить платформу, сборку и обновления

Сохраните журналы до очистки и перезапуска

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

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

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

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

• Экспортировать почтовые и системные журналы
• Сохранить заголовки и идентификаторы писем
• Скопировать данные вне затронутой системы
• Вести хронологию действий и результатов

Ограничьте отправку по подтверждённому источнику

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

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

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

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

• Ограничить отправку затронутой учётной записи
• Отозвать сеансы и проверить пароли приложений
• Сохранить очередь перед очисткой
• Оставить приём почты, если он не затронут

Назначьте ответственных и фиксируйте решения

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

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

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

• Назначить координатора и исполнителей
• Согласовать канал для срочной связи
• Фиксировать решения и время действий
• Уведомлять адресатов только по проверенным данным

Восстанавливайте почту после проверки копии

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

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

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

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

• Проверить копию и её состав
• Выполнить восстановление вне рабочей системы
• Установить исправления до возврата в сеть
• Проверить входящую и исходящую доставку

Закройте причину и подготовьте повторное восстановление

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

Для Postfix есть конкретная настройка inet_protocols: она задаёт, какие IP-протоколы сам Postfix использует для входящих и исходящих соединений. Значение ipv4 ограничивает Postfix IPv4, но не отключает IPv6 во всей операционной системе и не заменяет проверку сетевых правил. Я не считаю включённый IPv6 признаком атаки и не предлагаю выключать его без схемы сети, проверки DNS и требований к доставке. Если почтовый сервер должен использовать IPv6, его правила и журналы проверяются так же предметно. Параметр и его ограничения описаны в документации Postfix.

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

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

• Отозвать лишние доступы и правила
• Включить контроль исходящей почты
• Проверять восстановление копий отдельно
• Сверить SPF, DKIM и DMARC

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