Маршрутизация исходящей почты средствами Cisco ESA



    В некоторых случаях необходимо сделать маршрутизацию почты на основании отправителя. Англоязычный термин для данной задачи – 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, так как данные лицензии включают стойкое шифрование. Ввоз таких продуктов на территорию РФ требует получения разрешения от ФСБ, поэтому, как правило, время поставки таких лицензий увеличивается.

    CBS
    63,30
    Компания
    Поделиться публикацией

    Похожие публикации

    Комментарии 10

      0
      А для входящих писем насколько гибко можно настроить маршрутизацию? Можно ли указать список адресов, письма которым должны отправляться на один сервер, а для всех остальных на другой с проверкой существования адреса?
        +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). Причём, эта проверка осуществляется до того, как письмо будет обработано фильтром.

        0
        Сейчас играюсь с демкой и столкнулся с проблемой отправки почты при «народном резервировании каналов»: когда маршрутизатор переключается на второго ISP у ESA остаётся старый MX в EHLO. По RFC за это блокировать не должны и тот же SA по-умолчанию лишь накидывает пару баллов, но постмастера всякие попадаются.
        Я правильно поминаю, что корректного решения эта проблема не имеет? Либо пиринг с BGP, либо косытли со скриптами для маршрутизации через Virtual Gateway?
          0
          ESA отвечает на HELO/EHLO тем именем, которое прописано в настройках интерфейса (hostname). Соответственно, можно настроить второй интерфейс на ESA с нужным именем, соответствующим публикации через резервного провайдера. Правда, тогда потребуется создать для него новый Listener, и, соответственно, придётся поддерживать две HAT и RAT таблицы. Ну и, само собой, все интерфейсы ESA должны быть в разных IP-подсетях.
            0
            Она разве будет перебрать интерфейсы при невозможности подключиться через один из них?
            В документации нашел только про маршрутизацию через altsrchost либо перебором с rate limiting, но там разные очереди для каждого интерфейса.
              0
              Я, видимо, неправильно понял ваш вопрос. Вы сейчас говорите про исходящую почту? или про входящую?
                0
                Про исходящую.
                  0
                  Да, тогда да. Я, к сожалению, не знаю какого-либо способа поправить запись в EHLO динамически или заставить ESA выбирать исходящий интерфейс динамически (в зависимости от состояния провайдеров, подключенных к маршрутизатору). У ESA есть маршрут по умолчанию, и для отправки писем она всегда будет выбирать тот интерфейс, который находится ближе к next-hop из маршрута по умолчанию. Перебора интерфейсов она делать не будет.
                    0
                    Поправлюсь. Для отправки писем ESA будет выбирать интерфейс, который ближе к next-hop. Это поведение по умолчанию. Однако, в командной строке можно настроить, чтобы ESA всегда использовала определённый интерфейс для отправки, не зависимо от статических маршрутов и маршрута по умолчанию. Это делается командой deliveryconfig.
                      0
                      Спасибо за пояснения.
                      ESA оставил приятное впечатление, он как выключатель для спама — включил и спам больше не приходит даже на info. А в настройках есть вообще всё, что можно требовать от такой системы.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое