"Почтовый сервер, это больше не просто средство коммуникации, а полноценная точка входа в корпоративную сеть. Большинство успешных атак начинается с электронного письма, и это не баг, а фича электронной почты. Стандартные протоколы и доверительные модели создавались в другую эпоху, а вирусы этим пользуются. Реальная защита, это не включение одного «волшебного» фильтра, а настройка взаимосвязанных механизмов, которые ставят под контроль каждый бит входящего трафика, от заголовков письма до содержимого вложений."
Какие именно угрозы проходят через почту
Классические антивирусы плохо справляются с современными угрозами из почтового трафика. Злоумышленники используют не просто файлы с вирусами, а целые цепочки доставки, рассчитанные на человеческий фактор и слабые места в автоматической фильтрации.
- Файлы-обманки: Вложения с двойными расширениями (например, «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% защиты. Остаётся зона ответственности администратора и пользователей.
- Сегментация прав: Учётные записи для административной работы с почтовым сервером не должны использоваться для повседневных задач (просмотр почты, веб-сёрфинг).
- Регулярный аудит логов: Недостаточно настроить и забыть. Анализ журналов фильтрации (количество заблокированных писем, срабатывания песочницы, ложные срабатывания) помогает вовремя скорректировать политики.
- Информирование пользователей — последний рубеж. Регулярные короткие инструкции о том, как выглядит подозрительное письмо, куда его переслать (например, в отдел ИБ), могут предотвратить инцидент.
Защита почтового сервера, это не продукт, который можно купить, а непрерывный процесс настройки, мониторинга и адаптации. Угрозы эволюционируют, и ваша система фильтрации должна делать то же самое.