Аудит безопасности почтового сервера: пошаговый план для ИБ-специалиста

В 2024 году 68% всех вредоносных атак начинались именно с электронной почты. Это не случайность: почта - это точка, где техническая защита встречается с человеческим доверием. Письмо от «знакомого» с PDF-счетом или ссылкой на «корпоративный портал» не вызывает подозрений, пока не становится поздно.

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

Вот минимальный набор инструментов, для успешного аудита почты.

Внешние проверки без доступа к серверу. Утилита `mxcheck` проверяет DNS-записи (SPF, DKIM, DMARC, MTA-STS), поддержку StartTLS и состояние сертификата, открытые порты 25/465/587, наличие в блэклистах и уязвимость к SMTP Smuggling. Это первый шаг: если DMARC в режиме `p=none` или сертификат истекает через неделю, сначала закрываем базу. Следует понимать, что `mxcheck` - средство первичного технического обследования, а не полноценный аудитор почтовой инфраструктуры.

Проверка конфигурации и ОС. `Lynis` даёт представление о состоянии самого  хоста: лишние сервисы, устаревшие пакеты, слабые политики паролей. Для почтового сервера критично, чтобы на нём не крутилось ничего лишнего

Анализ журналов. Без чтения логов аудит превращается в гадание. Смотрите не только `/var/log/mail.log`, но и журналы аутентификации. Множественные неуспешные попытки SMTP-аутентификации могут указывать на перебор паролей или Password Spraying и требуют анализа исходных IP-адресов, учётных записей, частоты обращений и сопутствующих событий.

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

Прежде чем проверять шифры, узнайте: какие домены обслуживает сервер, какие пользователи имеют ящики, какие внешние сервисы интегрированы (рассылки, CRM, helpdesk). Узнать об этом больше вы сможете в этом цикле статей.

Проверка шифрования SMTP. Необходимо проверить поддержку STARTTLS при межсерверной передаче почты на порту 25 и используемые политики обязательного TLS (RFC 3207 предлагает использование opportunistic TLS для публичных МТА серверов). Для клиентской отправки через SMTP Submission на портах 587(STARTTLS) и 465 (Implicit TLS) следует обеспечить обязательное шифрование, чтобы исключить перехват данных авторизации. Также необходимо исключить использование устаревших версий SSL/TLS и небезопасных наборов шифров.

Три вещи, которые нужно проверить в первую очередь:

• Проверить срок действия TLS-сертификатов, доверенность цепочки и соответствие имён серверов. Особое внимание уделить политике проверки сертификатов при межсерверной передаче почты, поскольку некорректная конфигурация может приводить к отказам в доставке при использовании MTA-STS, DANE или других механизмов обязательной TLS-защиты.
• SPF, DKIM, DMARC. SPF без DMARC — это половина контроля. DMARC в режиме мониторинга не защищает от подмены отправителя. Для важных доменов (например, с которых идут счета и договоры) по-хорошему политика должна быть как минимум `quarantine`, а лучше `reject`. Но на практике это не всегда работает. Лучше сначала поставить ‘none' и посмотреть отчеты, собрать информацию. Не все владельцы доменов корректно настраивают DNS-записи, что впоследствии может привести к проблемам с доставкой легитимных писем (в случае если будет стоять политика ‘quarantine' или `reject`.
• Проверить отсутствие Open Relay: неавторизованные внешние SMTP-клиенты не должны иметь возможности пересылать сообщения на сторонние домены. Для предварительной проверки можно использовать mxcheck, но итоговые выводы необходимо подтвердить анализом правил SMTP-релея и конфигурации аутентификации. 

Почтовый сервер не должен быть доступен из интернета по SSH. Порты управления — только из выделенной подсети администраторов. Веб-интерфейс (если есть) — за VPN или как минимум с MFA. Если веб-почта смотрит в интернет напрямую, проверьте,   нет ли на ней уязвимостей перебора и не отключена ли блокировка после неудачных попыток.

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

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

Для примера, находки можно условно распределить по следующим уровням приоритета:

1. Критичный: открытый релей, утекшие учётки сотрудников с доступом к почте.
2. Высокий: устаревший TLS, отсутствие MFA для веб-почты, неограниченные попытки входа.
3. Средний: отсутствие ротации логов, лишние сервисы на хосте.

Для большей эффективности следует еще продумать следующие
механизмы защиты почтовой инфраструктуры:

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

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