Как я проверяю безопасность почтового сервера

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

Инвентаризация: от домена до порта

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

В реестр заношу имя узла, назначение, операционную систему, почтовые компоненты, ответственного и источник данных о версии. Проверяю DNS-записи MX и фактические маршруты, затем сравниваю внешний перечень портов с тем, что службы должны принимать. Порт 25 обычно обслуживает передачу почты между серверами; 587 предназначен для отправки писем почтовыми клиентами. Для чтения IMAP часто используют 143 с возможностью STARTTLS или 993 с TLS сразу. Это стандартные назначения, а не гарантия того, что именно так настроен конкретный сервер. Порт — табличка на двери, не акт проверки.

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

• Составьте список узлов и их владельцев.
• Зафиксируйте роли, версии и точки входа.
• Сверьте DNS, фактические службы и порты.
• Проверьте отправку и приём контрольных писем.
• Сверьте SPF, DKIM и DMARC для домена.

Версии ПО: CVE сверяю с бюллетенем

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

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

Я не обновляю почтовый сервер посреди рабочего дня только потому, что в ленте появилось громкое сообщение. Сначала подтверждаю применимость и читаю инструкцию по обновлению именно установленной версии, затем согласую окно, резервную копию и проверку после работ. Если исправления пока нет, фиксирую временное ограничение доступа или другой вариант из advisory и назначаю дату повторной проверки. Для систем на Zimbra отдельно пригодится чек-лист обновления: один общий список пакетов не заменяет процедуру конкретного продукта.

• Запишите продукт, ветку и источник пакета.
• Сверьте CVE с диапазоном затронутых версий.
• Проверьте advisory производителя и дистрибутива.
• Учтите backport исправления в пакет.
• Назначьте приоритет по экспозиции и доступному исправлению.

Порты и TLS: что доступно снаружи

На каждом внешнем почтовом интерфейсе я проверяю согласованные версии TLS, сертификат, имя узла, срок действия и всю цепочку доверия. Для клиентского доступа стандартные схемы различают явный переход на TLS и TLS с начала соединения: IMAP на 143 может использовать STARTTLS, а 993 начинает с TLS сразу. RFC для электронной почты рекомендует защищённое соединение; TLS 1.0 и 1.1 формально выведены из употребления, а для почтового доступа минимальный ориентир — TLS 1.2. Это не повод обещать, что «всё зашифровано»: результат зависит от настроек службы и поведения клиента. Я проверяю внешнюю точку подключения и сравниваю её с конфигурацией сервера.

Для SMTP отдельно разделяю приём почты от других серверов и отправку пользователями. Порт 25 связан с межсерверной передачей, а 587 — с отправкой сообщений клиентами; шифрование на них не делает сервер автоматически безопасным и не подтверждает, что аутентификация включена там, где нужна. Проверяю, не работает ли сервер как открытый ретранслятор для посторонней отправки, и сопоставляю допустимые исключения с назначением системы. Доступ без пароля из доверенного сегмента может быть осознанной настройкой, но этот сегмент должен быть описан и ограничен. «Так сложилось» — не правило межсетевого экрана.

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

• Проверьте TLS на каждом опубликованном сервисе.
• Сверьте имя, срок и цепочку сертификата.
• Различайте SMTP relay на 25 и submission на 587.
• Проверьте отсутствие открытого SMTP-релея.
• Зафиксируйте старые клиенты и план перехода.

Админ-доступы и пароли

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

Для админ-панели включаю многофакторную проверку, если её поддерживает продукт и можно безопасно развернуть для всех привилегированных пользователей. Если встроенной MFA нет, ограничиваю административный вход управляемой сетью или узким набором доверенных адресов и включаю доступ через корпоративную систему идентификации, если она есть. Входы администраторов и сервисных учёток проверяю по журналам. Для обычных паролей я не назначаю ротацию «каждые 30 дней» без причины: актуальные рекомендации NIST не требуют менять пароль по календарю. Смена нужна при признаках компрометации, утечке или нарушении политики; слабые и повторно используемые пароли надо выявлять отдельно.

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

• Назначьте владельца каждой привилегированной учётке.
• Отключайте неиспользуемые записи после согласования.
• Включите MFA там, где она поддерживается.
• Проверьте ограничение неудачных входов и восстановление доступа.
• Меняйте секреты при компрометации, а не по календарю.

Логи: признаки, а не приговор

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

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

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

Резервные копии: восстановление важнее галочки

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

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

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

• Копируйте письма и необходимые настройки.
• Держите копию в отдельном домене отказа.
• Ограничьте доступ и защитите копию от изменения.
• Проверьте восстановление ящика и конфигурации.
• Зафиксируйте реальное время и результат теста.

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