«Почтовый сервер — это больше не просто средство коммуникации, а полноценная точка входа в корпоративную сеть. Большинство успешных атак начинается с электронного письма, и это не баг, а фича электронной почты. Стандартные протоколы и доверительные модели создавались в другую эпоху, а вирусы этим пользуются. Реальная защита — это не включение одного «волшебного» фильтра, а настройка взаимосвязанных механизмов, которые ставят под контроль каждый бит входящего трафика, от заголовков письма до содержимого вложений.»
Какие именно угрозы проходят через почту
Классические антивирусы плохо справляются с современными угрозами из почтового трафика. Злоумышленники используют не просто файлы с вирусами, а целые цепочки доставки, рассчитанные на человеческий фактор и слабые места в автоматической фильтрации.
- Файлы-обманки: Вложения с двойными расширениями (например, «invoice.pdf.exe»), запакованные в архивы с паролем (который указан в теле письма), чтобы обойти сигнатурный анализ. Маскировка под документы офисного пакета с макросами остаётся излюбленным методом.
- Целевой фишинг и BEC: Сообщения, точно имитирующие стиль и контекст внутренней или партнёрской переписки. Цель — не массовая рассылка, а точечное попадание в конкретного сотрудника с доступом к финансам или данным.
- Эксплойты для почтовых клиентов: Уязвимости в обработке HTML-контента, изображений или шрифтов в Outlook, Thunderbird или веб-интерфейсах могут привести к выполнению кода при простом просмотре письма, без открытия вложений.
- Использование шифрования и облачных ссылок: Вредоносная ссылка ведёт не напрямую на зловредный сайт, а, например, на легитимный облачный сервис (Google Drive, Dropbox), где лежит вредоносный файл. Шифрование письма с помощью S/MIME или PGP скрывает его содержимое от промежуточных систем фильтрации.
Многоуровневая фильтрация почтового трафика
Единственный эффективный подход — это создание последовательных рубежей обороны, где каждый следующий слой ловит то, что пропустил предыдущий.
Слой 1: Сетевая и протокольная фильтрация (MTA)
Защита начинается ещё до того, как письмо попадёт в почтовый ящик. На уровне сервера исходящей/входящей почты (Mail Transfer Agent — MTA) настраиваются основные механизмы проверки.
- Проверка по спискам репутации (DNSBL, RBL): Сервер сверяет IP-адрес отправителя с публичными и приватными чёрными списками.
- SPF, DKIM, DMARC: Эти технологии проверяют, не подделано ли доменное имя отправителя. Особенно важен DMARC, который указывает серверу получателя, что делать с письмами, не прошедшими проверки (отклонить, поместить в карантин). Полная настройка DMARC с политикой «reject» резко снижает объём спама и фишинга.
- Грейлистинг (Greylisting): Временный отказ в приёме письма от незнакомого сервера. Легитимные серверы повторят попытку позже, а многие спам-боты — нет.
# Пример проверки состояния служб антивирусной фильтрации на сервере (PowerShell)
Get-Service *Malware*, *Filter* | Select-Object Name, Status, StartType
Слой 2: Контентный анализ и антивирусное сканирование
После принятия письма MTA передаёт его на сканирование. Ключевой момент — настройка не просто «включено/выключено», а политик обработки.
Антивирусные движки: Используйте как минимум два разных движка для сканирования (например, встроенный в почтовый сервер и сторонний). Это повышает шансы обнаружения. Обновление баз вирусных сигнатур должно происходить несколько раз в день, в идеале — в потоковом режиме.
# Включение и настройка фильтра вредоносных программ в Microsoft Exchange
Set-MalwareFilteringServer -Identity "ВАШ_СЕРВЕР" -BypassFiltering $false
Set-MalwareFilterPolicy -Identity "Default" -Action DeleteMessage -CustomNotifications $true -EnableInternalSenderAdminNotifications $true
Фильтрация по типам файлов: Блокируйте выполнимые файлы (.exe, .msi, .js, .vbs, .ps1) и архивы с исполняемым содержимым. Будьте осторожны с офисными документами, поддерживающими макросы (.docm, .xlsm) — их стоит либо блокировать, либо отправлять в песочницу.
Слой 3: Продвинутая защита: песочница и анализ поведения (ATP)
Когда сигнатурные методы бессильны, в дело входит динамический анализ. Технологии вроде Microsoft Defender для Office 365 (Safe Attachments) или аналогичные решения других вендоров помещают подозрительное вложение в изолированную виртуальную среду (песочницу) и отслеживают его поведение: пытается ли файл изменить реестр, установить соединение с командным сервером, зашифровать файлы.
| Этап анализа в песочнице | Что проверяется |
|---|---|
| Статический анализ | Распаковка архива, извлечение метаданных, поиск скрытых скриптов. |
| Эмуляция среды | Запуск файла в ОС, имитирующей рабочую станцию пользователя. |
| Мониторинг поведения | Регистрация всех системных вызовов, попыток доступа к сети, создания процессов. |
| Формирование вердикта | Решение на основе накопленных данных: пропустить, заблокировать, поместить в карантин. |
# Создание политики Safe Attachments в PowerShell
New-SafeAttachmentPolicy -Name "Строгая проверка вложений" -Action DynamicDelivery -Enable $true
# DynamicDelivery доставляет письмо пользователю, но заменяет вложение на заглушку, пока файл проверяется в песочнице.
Слой 4: Защита от фишинга и анализ URL (Safe Links)
Опасность может заключаться не во вложении, а в ссылке в теле письма. Технология «безопасных ссылок» работает по принципу «перехвата».
- Все URL в письмах, проходящих через защищённый сервер, заменяются на адреса внутреннего прокси-сервиса.
- Когда пользователь нажимает на ссылку, запрос сначала идёт в службу проверки, которая в реальном времени сверяет конечный адрес с базами вредоносных и фишинговых сайтов.
- Только после этого пользователь либо перенаправляется на исходный сайт (если он безопасен), либо видит предупреждение.
# Настройка политики Safe Links для внутренней и внешней почты
New-SafeLinksPolicy -Name "Глобальная проверка ссылок" -EnableSafeLinksForTeams $true -TrackClicks $true -DoNotRewriteUrls "*.yourcompany.ru"
Политики, обучение и реакция: что остаётся за автоматикой
Даже самая совершенная автоматика не даст 100% защиты. Остаётся зона ответственности администратора и пользователей.
- Сегментация прав: Учётные записи для административной работы с почтовым сервером не должны использоваться для повседневных задач (просмотр почты, веб-сёрфинг).
- Регулярный аудит логов: Недостаточно настроить и забыть. Анализ журналов фильтрации (количество заблокированных писем, срабатывания песочницы, ложные срабатывания) помогает вовремя скорректировать политики.
- Информирование пользователей — последний рубеж. Регулярные короткие инструкции о том, как выглядит подозрительное письмо, куда его переслать (например, в отдел ИБ), могут предотвратить инцидент.
Защита почтового сервера — это не продукт, который можно купить, а непрерывный процесс настройки, мониторинга и адаптации. Угрозы эволюционируют, и ваша система фильтрации должна делать то же самое.