Облачный антиспам-шлюз: MX в облако, спам упал с 85% до 2%

Разговор с клиентом начался банально: «у нас Exchange тормозит, посмотрите». Посмотрели. Exchange не тормозил - он был занят. Из примерно шестисот писем в час, которые приходили на сервер, около пятисот были спамом. Антиспам на самом Exchange справлялся кое-как: фильтровал, складывал в карантин, жевал ресурсы - и всё равно пропускал процентов пятнадцать мусора прямо в ящики. Итого: сервер перегружен, пользователи недовольны, спам всё равно есть.

Проблема была не в Exchange и не в настройках. Проблема была в архитектуре: фильтровать надо до того, как письмо доехало до твоего сервера.

Как устроен облачный шлюз

Механика проста. Меняешь MX-записи домена - они начинают указывать не на твой Exchange, а на облачную инфраструктуру провайдера. Весь входящий поток идёт сначала туда, фильтруется, и только чистые письма приезжают на твой сервер по SMTP с ограниченного диапазона IP. Исходящие тоже можно пустить через шлюз - тогда и они проходят проверку, и репутация IP домена поддерживается чужой инфраструктурой.

Мы остановились на Symantec.cloud - у него на тот момент была приличная репутационная база и нормальная документация. Kaspersky Hosted Security рассматривали как альтернативу, но у клиента уже была история с Symantec по другим продуктам, решили не множить вендоров.

Что делали

Работа разбилась на несколько шагов.

Первое - настройка коннектора. В Exchange создали отдельный receive-коннектор, принимающий почту только с диапазонов IP Symantec.cloud. Всё, что приходит не оттуда - отбивается. Это важно: если оставить открытый порт 25, смысл шлюза теряется наполовину.

Второе - исходящий поток. Настроили send-коннектор для маршрутизации исходящих через шлюз. Здесь есть нюанс с SPF: при такой схеме исходящие письма уходят с IP шлюза, а не с твоего сервера, поэтому SPF-запись нужно обновить заблаговременно. Сделали это за сутки до переключения MX.

Третье - переключение MX. TTL понизили за двое суток до изменения - до 300 секунд. В день переключения поменяли записи, поставили приоритет так, чтобы почта шла только через шлюз, без запасного прямого MX на Exchange. Запасной прямой MX - это дыра: спамеры умеют находить резервные записи с высоким приоритетом и ломиться напрямую.

Четвёртое - карантин и политики. В консоли шлюза настроили политики: явный спам - в карантин на шлюзе (не доезжает до Exchange вообще), подозрительное - с меткой в тему, вирусы и фишинг - удалять без доставки. Пользователи получили доступ к своему карантину через веб-интерфейс - могут сами проверить, не зарезал ли шлюз нужное письмо.

Что получилось

Первые несколько дней было интересно смотреть на статистику в консоли. Поток на Exchange упал раз в шесть по количеству сообщений - большинство спама просто не добирается. Нагрузка на сервер заметно снизилась: очередь транспорта, которая раньше периодически вспухала, теперь пустая.

Уровень спама в ящиках пользователей упал с ~85% до ~2%. Эти два процента - либо что-то совсем свежее, что шлюз не успел добавить в базу, либо легитимные рассылки, которые пользователь сам когда-то подписал. Ложных срабатываний за первые две недели было несколько штук - все нашли в карантине и освободили.

Отдельный бонус: шлюз поглощает всплески. Когда кто-то решает закидать домен клиента миллионом писем - эту атаку видит инфраструктура Symantec, а не Exchange.

Где слабые места

Честно - есть несколько вещей, которые нужно держать в голове.

Зависимость от третьего сервиса. Если шлюз лёг - почта не идёт вообще. У Symantec.cloud SLA нормальный и несколько точек присутствия, но это не ваша инфраструктура. Нужно мониторить доступность независимо.

Шифрование трафика между шлюзом и Exchange. По умолчанию не обязательно включено - стоит настроить TLS для этого hop-а явно, особенно если письма содержат чувствительные данные.

Сложные сценарии с shared mailboxes и aliasами. Если у домена несколько алиасов или есть внутренняя маршрутизация - нужно аккуратно проверить, что шлюз правильно понимает, какие адреса существуют. Иначе он может отбивать письма на несуществующие с его точки зрения ящики, что Exchange потом вернёт бэунсом.

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