В некоторых случаях необходимо сделать маршрутизацию почты на основании отправителя. Англоязычный термин для данной задачи – Sender Based Routing. Эта задача может быть решена разными способами: различные внешние релеи для почтового сервера, специальные агенты в случае использования MS Exchange (например, Sender Based Routing Agent for Exchange Server) и т.д. В данной заметке хотел поделиться вариантом решения задачи средствами Cisco Email Security Appliance (далее ESA) – бывшим IronPort ESA.

Задача Sender Based Routing актуальна в том случае, когда на одном почтовом сервере необходимо использовать несколько доменов отправителей/получателей. А актуальна она по следующей причине. Подавляющее большинство антиспам-систем проверяет наличие PTR-записи для IP-адреса отправителя. Для одного IP-адреса крайне не рекомендуется иметь несколько PTR-записей. Поэтому, письма от каждого домена почтового сервера нужно отправлять со своего собственного IP-адреса, для которого существует единственная PTR-запись. В противном случае, велика вероятность, что антиспам-система на стороне получателя отбросит письмо. Вот тут и встаёт вопрос, а как же можно раскидывать письма от одного почтового сервера по разным IP-адресам (в частности, отправлять через разных Интернет-провайдеров) на основании домена отправителя?

В моём конкретном примере задача была поставлена следующим образом: нужно отправлять письма определённого домена MS Exchange с IP адреса стороннего провайдера. Другими словами, на сервере MS Exchange предполагалось использовать новый дополнительный домен отправителей/получателей, письма от которых нужно отправлять с IP-адреса удалённого офиса, находящегося в другой стране.

В центральном офисе, где находится сервер MS Exchange, для выхода в Интернет используется МСЭ Cisco ASA. В удалённо офисе также стоит Cisco ASA. Между офисами настроен VPN Site-to-Site по технологии IPsec.

Примерная схема отправки писем представлена ниже:

image

Письма от домена @ abc.ru должны отправляться через локального провайдера Main ISP с адреса 1.1.1.1, письма от домена @ xyz.ru должны уходить через VPN до удалённого офиса и там выходить в Интернет через локального провайдера Remote ISP с адресом 9.9.9.9. В данной заметке не будет рассматриваться построение VPN Site-to-Site на Cisco ASA и организацию выхода в Интернет через удалённого провайдера, так как данная тема подробно описана как в официальной документации на cisco.com, так и на многочисленных форумах.

Изначально в данной сети заказчика Cisco ESA использовался исключительно как анти-спам решение. Через Cisco ESA проходила только входящая корреспонденция. Отправление писем осуществляется в обход Cisco ESA: сервер MS Exchange слал письма напрямую, куда указывает шлюз по умолчанию, т.е. на Cisco ASA в нашем случае.

Сразу хочется заметить, в организации входящей почты для доменов @ abc и @ xyz никакой хитрости нет. Достаточно опубликовать MX запись для @ abc под адресом основного провайдера (Main ISP), MX запись для @ xyz под адресом удалённого провайдера (Remote ISP) и корректно настроить маршрутизацию и публикации Cisco ESA.

В описываемом примере в инфраструктуре заказчика уже был развёрнут Cisco ESA, который может быть использован как внешний релей для исходящей почты. Поэтому, в первую очередь, я задался вопросом, поможет ли он решить задачу Sender Based Routing? Как выяснилось – да. Данную задачу можно решить, используя фильтры исходящей почты на ESA – Outgoing Content Filters:

image


Cisco ESA даёт возможность настроить фильтр таким образом, чтобы определённые Email-сообщения отправлялись с другого IP-адреса. На скриншотах ниже представлена настройка Outgoing Content Filters:

image

image

Как видно из первого скриншота «Add Condition», Cisco ESA предоставляет широкие возможности отбора писем для применения к ним требуемого действия (из «Add Action»). Причём, можно создавать наборы условий и применять к ним логику AND или OR. Для решения моей задачи достаточно было указать в условии, чтобы в поле MAIL FROM письма содержалась фраза @ xyz. В качестве действия («Add Action») необходимо указать Deliver from IP Interface, и выбрать второй (пока не использующийся) интерфейс Cisco ESA с другим IP адресом. Этот интерфейс называется Data 2. Остаётся только сохранить созданный фильтр под именем, например, Redirect-Filter, и применить созданный фильтр к политике по умолчанию для исходящих писем в разделе Outgoing Mail Policies:

image

Таким образом получилось настроить Cisco ESA так, чтобы письма от домена домена @ xyz отправлялись с IP-адреса интерфейса Data 2, в то время как письма от домена @ abc будут отправляться в IP-адреса первого интерфейса – Data 1. Для того, чтобы можно было отправлять письма через Cisco ESA, нужно не забыть указать IP-адреса MS Exchange в RELAYLIST таблицы HAT (Host Access Table):

image

Остаётся настроить MS Exchange для отправки всех писем через Cisco ESA (указать Cisco ESA в качестве Smart Host) и донастроить VPN между офисами для шифрования трафика между IP-адресом интерфейса Data 2 Cisco ESA (с которого отправляются письма домена @ xyz) и Интернет. Фактически, в настройках Cisco ASA нужно добавить IP-адрес интерфейса Data 2 в соответствующий crypto access-list и, при необходимости, поправить правила NAT.

Таким образом, в данной заметке рассмотрели на конкретном примере, как можно использовать Cisco ESA для решения задачи Sender Based Routing. Основная идея предлагаемого решения – отправлять письма первого домена с IP-адреса интерфейса Data 1 Cisco ESA, письма второго домена – c IP-адреса интерфейса Data 2. После присвоения письмам разных IP-адресов появляется возможность маршрутизировать такие письма на сетевом оборудовании любым удобным и доступным способом. В описанном случае, трафик маршрутизировался на Cisco ASA с помощью crypto access-lists, и пакеты заворачивались в VPN-туннель. На маршрутизаторах для этих целей можно использовать Policy Based Routing или VRF.

В заключении хотелось бы отметить, что для реализации описанного функционала на Cisco ESA не требуется приобретение никакой дополнительной лицензии. Достаточно наличия самой обычной лицензии Cisco Email Security Inbound, которая необходима для обеспечения функций антиспама.

Чуть более подробно схема лицензирования Cisco ESA описана здесь:
Схема лицензирования Cisco ESA предлагает три вида лицензии: Inbound, Outbound и Premium (Inbound + Outbound), а также набор A-la-Carte лицензий для открытий дополнительных фич (Image Analyzer, дополнительный антивирус McAfee, дополнительный файловый антивирус от SoureFIRE – AMP, и т.д.). Лицензия Inbound необходима для обеспечения функций антиспама. Если быть точнее, данная лицензия открывает функционал антиспам, антивирус (Sophos) и фильтры угроз нулевого дня (Outbreak Filters). Судя по названию лицензий можно подумать, что для отправки писем через Cisco ESA требуется лицензия Outbound. Но это не так. Для отправки писем через Cisco ESA и использования фильтров исходящей почты (Outbound Content Filters) достаточно иметь лицензию Inbound. Лицензия Outbound необходима только для открытия функционала шифрования писем и защиты от утечки информации (Encryption и Data Loss Prevention). Причём, лицензия Outbound, а, следовательно, и лицензия Premium, попадает категорию С3, так как данные лицензии включают стойкое шифрование. Ввоз таких продуктов на территорию РФ требует получения разрешения от ФСБ, поэтому, как правило, время поставки таких лицензий увеличивается.

Комментарии (2)


  1. navion
    17.09.2015 15:42

    А для входящих писем насколько гибко можно настроить маршрутизацию? Можно ли указать список адресов, письма которым должны отправляться на один сервер, а для всех остальных на другой с проверкой существования адреса?


    1. Boris_Uskov
      17.09.2015 16:38
      +1

      Да, можно. В статье я рассказывал про Outgoing Content Filters. Существуют также Incoming Content Filters, которые как раз можно применять для входящих писем. Так вот, можно создать такой фильтр, который будет выполнять вашу задачу.

      Приведу пример скриншотов настроек. В add condition фильтра можно указать адрес получателя, группу получателей в AD или предопределённый список получателей (dictionary):



      В Add Action можно выбрать действие Send to Alternate Destination Host:



      Далее остаётся применить созданный фильтр к политике для входящих писем в разделе Incoming Mail Policies.

      Что касается проверки существования адреса, она будет осуществляться не зависимо от выбранного «Destination host», если это задано в настройках на Cisco ESA. Проверка существования адреса осуществляется запросом в корпоративный Active Directory (так называемый LDAP Acceptance Query). Причём, эта проверка осуществляется до того, как письмо будет обработано фильтром.