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

Харденинг почтового сервера начинается с инвентаризации: какие службы действительно нужны, кто к ним подключается и как устроена отправка писем. Я покажу, как ограничить доступ, проверить SMTP relay и обновлять систему без универсального списка портов и выдуманных гарантий.

Что даёт харденинг почтового сервера

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

В моей работе порядок такой: фиксирую версию ОС и почтовой платформы, сверяю поддержку и рекомендации производителя, записываю внешние точки доступа, роли пользователей, резервную копию конфигурации и способ отката. Затем меняю по одной группе настроек и проверяю конкретный почтовый сценарий. Это помогает понять, какое изменение повлияло на результат. Харденинг уменьшает поверхность доступных служб, но не заменяет резервное копирование, обновления, контроль учётных записей и наблюдение за очередью. Универсальный «безопасный набор» портов, который подходит любой почтовой системе, — удобная сказка для чек-листа, а не результат аудита.

• Инвентаризация служб и версий
• Проверка источников доступа
• Резервная копия конфигурации
• Изменения с проверкой и планом отката

Условный кейс: агентство «Событие», 24 рабочих места

В исходных данных есть условный клиент: московское агентство мероприятий «Событие», 24 рабочих места. Это пример плана работ, а не отчёт о состоявшемся аудите. В исходных данных не указаны почтовая платформа, операционная система, версии, сетевые правила или найденные уязвимости. Я не буду приписывать клиенту Postfix, Mailcow, открытый FTP или конкретные CVE. Сначала в отчёте должны появиться реальные названия продуктов и версии, дата последних обновлений, список доступных извне служб, способ входа администратора и схема доставки писем.

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

• Условные исходные данные: 24 рабочих места
• Снять версии до изменения конфигурации
• Согласовать окно и критерии приёмки

Какие почтовые порты действительно нужны

Порт 25 обычно нужен для обмена почтой между серверами. Порт 587 предназначен для отправки писем почтовым клиентом, а 465 использует SMTP submission с неявным TLS; это разные режимы, хотя в старой статье их часто сваливают в один пункт. Для чтения почты применяют, например, IMAPS на 993 или POP3S на 995. RFC 6409 описывает submission на 587, RFC 8314 — защищённый доступ и неявный TLS на 465. Я открываю только те роли, которыми пользуется конкретная система и её клиенты, с учётом того, где завершается TLS.

У официальной документации Mailcow в списке входящих портов есть не только 25, 465, 587, 993 и 995, но и 80/443 для веб-служб, 110/143 для POP3/IMAP и 4190 для ManageSieve. Это перечень конкретного продукта, а не команда выставить каждый порт в интернет: POP, открытые соединения без TLS или фильтры на сервере могут быть не нужны, а веб-интерфейс может требовать отдельного ограничения по сети. Порт 25 нельзя отключать по чужому короткому списку, если через него ваш сервер принимает письма от внешних почтовых серверов. Я проверяю назначение слушателя, сетевую границу и фактические подключения; правило «оставить только пять» легко ломает доставку и ничего само по себе не доказывает о безопасности.

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

• 25 — SMTP между почтовыми серверами
• 587 — отправка из почтового клиента
• 465 — submission с неявным TLS
• 993 и 995 — защищённый доступ, если используется
• 80, 443 и 4190 — только по нужным функциям

Как защитить панель и учётные записи

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

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

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

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

SMTP relay, старые аккаунты и пароли

Входящая почта от чужих серверов обычно приходит на порт 25 без учётной записи пользователя: сервер принимает её для обслуживаемых доменов. Из этого не следует, что он должен пересылать любое письмо на любой внешний адрес. Открытый relay — это именно разрешённая неавторизованному источнику пересылка почты для постороннего получателя. Если используется Postfix, за политику пересылки отвечает smtpd_relay_restrictions; документация описывает стандартное ограничение для удалённых адресов клиентами, которые не относятся к доверенной сети и не прошли SASL-аутентификацию. На портах пользовательской отправки действуют свои правила. Я проверяю их отдельно и сверяю с доверенными сетями, доменами и способом отправки, а не включаю SMTP AUTH для всего входящего интернета. Подробнее — в статье про ограничения SMTP relay в Postfix.

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

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

• Принимать письма только для своих доменов
• Разделить входящий SMTP и отправку клиентов
• Проверить доверенные сети и SASL
• Сверить неиспользуемые роли с владельцами
• Сменить пароль при признаках компрометации

Обновления и проверка доставки после изменений

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

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

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

• Сверить версию с бюллетенем вендора
• Сохранить конфигурацию и план отката
• Проверить входящую и исходящую почту
• Посмотреть очередь и журналы

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