top of page

​

Edge Transport Server.

​

Edge - компонент опциональный. Т.е. в принципе его можно и не ставить. Задачи Edge:

- получить почту из интернета, отфильтровать на вирусы/спам и прокинуть внутрь организации.

- получить почту изнутри, отфильтровать на вирусы и прокинуть наружу.

Вместо Edge вы можете поставить ORF или другие аналогичные продукты.

Edge это единственная роль, которая не совмещается с другими ролями Exchange.

Edge должен быть установлен на компьютере, не являющимся членом домена. В принципе, установить то можно, но смысла от этого никакого. Edge выносится в димилитаризованную зону. Зона эта, как правило, отделена файерволом. Поэтому каждый лишний открытый порт - это уязвимость. Если машина будет в домене, то таких портов будет куча (88 для кербероса, куча портов для RPC КД и прочее).

У Edge есть встроенный антиспам. Антивируса нет. Т.е. надо сверху что-то ставить (Касперского, Microsoft Forefront Endpoint Protection или другие).

У Edge есть функция Address Rewriting. К примеру у нас есть 10 почтовых доменов, все юзеры шлют почту в интернет. С помощью этой функции можно сделать так, чтобы вся почта уходила от одного домена, к примеру microsoft.com. Снаружи приходит на microsoft.com, внутри расходится по другим доменам. Типа перезаписывание адреса. Это удобно в процессе консолидации, когда несколько организаций съезжаются в одну. 

Перед установкой Edge нужно соблюсти несколько правил: 

1. Edge должен иметь FQDN. Если компьютер не входит в домен, у него есть только hostname. Поэтому надо взять суффикс домена и вручную прописать в свойствах компьютера. Это нужно, чтобы Edge мог нормально разрешать имена внутри организации. Ведь когда вы делаете запрос, вы пишете FQDN или короткое имя. Когда короткое, он берет основной суффикс компьютера и подставляет к запросу.

2. Порты.

​

​

Порты Edge

Меню изучения Exchange 2010

На файерволе между DMZ и внутренней сетью надо открыть:

- 25 порт, в обе стороны;

- 53 (TCP,UDP), чтобы работало разрешение имен. Можно открыть только в сторону Hub'a;

- 50636. По этому порту идёт синхронизация между Hub'ом и Edge'м. Его можно открывать только в одном направлении - от Hub'a на Edge. Чуть позже мы рассмотрим, какую информацию Hub передает по этому порту. 

На файерволе между DMZ и интернетом надо открыть:

- 25 порт, в обе стороны;

- 53 (TCP,UDP), чтобы работало разрешение имен. Здесь надо открыть в обе стороны, т.к. Edge будет обращаться за MX-записями.

3. Edge должен иметь возможность разрешать имена внутри организации (т.е. достучаться до DNS-сервера) и разрешать имена в интернете (т.е. MX). Edge не входит в домен. Следовательно, на внутреннем DNS-сервере он не регистрируется. Поэтому вы должны создать запись типа А на внутреннем DNS-сервере, чтобы внутренние Exchange-серверы могли разрешить имя Edge-сервера в его IP.

​

   Обычно Exchange хранит свою информацию в AD. Edge - это Exchange. Но доступа к AD  у него нет. А информацию где-то хранить надо. Для это используется AD LDS (Active Directory Lightweight Directory Services, Облегченные службы каталога Active Directory), ранее известные как Active Directory Application Mode (ADAM). AD LDS - это каталог. ADAM ранее ставилась дополнительно, а сейчас AD LDS это одна из ролей Windows-сервера.

AD LDS в обязательном порядке устанавливается на компьютер, где будет установлен Edge, т.к. Edge использует AD LDS для хранения своего конфига. Коннекторы, имена обслуживаемых доменов, настройки антиспама и прочее - всё это будет храниться в AD LDS. Вы, в принципе, с AD LDS дела иметь не будете. 

Edge сразу после установки - "лысый". Введите в EMS команду  Get-AcceptedDomain. Результата не будет, т.к. нет ни одного обслуживаемого домена. Введите Get-SendConnector. Тоже ничего нет. А ведь Edge'у надо знать, какие домены он обслуживает. Также ему нужны коннекторы и прочее. Можно конечно домены прописать ручками, т.к. их немного и меняются они нечасто. Но ведь есть пользователи, которые меняются постоянно. Edge'у надо знать, есть такой пользователь внутри сети или нет. Вы же не будете ручками синхронизировать сотни пользователей.

Так вот. Чтобы Edge начал работать с вашим Hub'ом, Edge надо "подписать" на сайт AD.

Вкратце как это делается: на Edge создаем файл, в который Edge выгружает информацию о себе (текущую дату, ключ, которым шифруется и порт, по которому он слушает подключения). Переносим этот файл на любой Hub, находящийся в том сайте AD, на который Edge будет подписан. Т.е. помните, Edge подписывается не на конкретный Hub, а на сайт. Т.е. когда Edge примет почту из интернета, он прокинет её на один из Hub'ов, которые расположены в этом сайте. То же самое и с Hub'ами. Когда им нужно отправить почту в интернет, они льют её на Edge. После импорта файла запускается процедура синхронизации и на Edge выгружается список всех пользователей, список всех обслуживаемых почтовых доменов и на Edge автоматически создаются все необходимые коннекторы. Эта синхронизация будет затем происходить автоматически.

Теперь давайте разбираться на практике.

Создаем файл "приглашения", используя команду New-EdgeSubscription с ключом -FileName. И откроем созданный файл.

Что интересного есть в файле? Здесь указаны короткое имя Edge-сервера и его FQDN. Указан CertificateBlob. Указана продолжительность времени, в течении которого этот файл нужно импортировать (<Duration>). Т.е. если вы за сутки этот файл не успели импортировать, можете формировать новый. И также указан порт, по которому принимаются подключения (50636).

Переносим этот файл на наш Hub, т.е. на van-ex1.

Импорт файла на Hub'е можно сделать через EMC.

Указываем на какой сайт AD мы делаем привязку и указываем путь к файлу.

Помните - Edge может быть подписан только на один сайт AD. Вернее Edge может быть подписан только на один сайт AD в один момент времени. Т.е. можете потом удалить подписку и создать на новый сайт.

Итого, всё что Edge получает, он закидывает на Hub конкретного сайта.

Обратите внимание на галку внизу, которая позволяет автоматически создавать коннекторы.

​

Теперь возвращаемся на Edge и проверяем конфигурацию, повторяя команды, вводимые ранее. Подписка создана, поэтому теперь мы видим результат.

Протестируем работу. Отправим письмо в интернет, например на адрес @specialist.ru. Оно теперь застрянет в очереди на Edge-сервере.

Кстати, обратите внимание на очередь. Помните мы отправляли письма на @live.ru и они болтались на Hub'е van-ex1. Видите, теперь они перекочевали в очередь на Edge.

​

     Для мониторинга синхронизации есть хороший командлет Start-EdgeSynchronization, т.е. запуск синхронизации с Edge'м.

Синхронизация идёт по двум направлениям:

1. Recipients. Т.е. это почтовые ящики.

2. Configuration. Т.е. изменение коннекторов, обслуживаемых доменов и т.д.

Посмотрите на скриншот. В момент этой синхронизации никаких изменений не было, счётчики по нулям.

Давайте для примера удалим какой-нибудь из обслуживаемых доменов (Organization Configuration -> Hub Transport -> Accepted Domains) и снова запустим синхронизацию.

Как видите, изменения произошли в блоке Configuration.

Scanned говорит нам, сколько изменений обнаружено. 

Как мы говорили ранее, Edge может быть подписан только на один сайт AD. Но на один сайт можно подписать два Edge'а. Зачем? Для отказоустойчивости.

​

Антиспам.

​

Антиспам фильтры в Edge работают так себе. По хорошему лучше наворачивать что-нибудь типа ORF, Forefront, Kaspersky и прочее. Forefront хорош тем, что это и антиспам и антивирус в одном лице. Тоже самое и у Касперского.

Но, в принципе, работать со штатными средствами Edge работать тоже можно. В любом случае, то, что мы будем сейчас обсуждать, в той или иной степени используется в любых антиспам-решениях.  

Итак, кто-то отправляет нам письмо. Смотрим.

Первое, что срабатывает на Edge - это блок антиспам проверок, который называется Connection Filtering (фильтрация на уровне соединений). Это проверка ещё до того, как письмо попало внутрь организации.

Списки в Connection Filtering, которые описаны ниже, применяются в том же порядке, в котором они описаны.

IP Allow List - это список разрешенных IP-адресов (диапазон или конкретный IP-шник).

IP Block List - список заблокированных адресов.

Для примера добавим какой-нибудь комп в Block List и отправим с него почту. 

​

Коннектимся с ПК с заблокированным IP к Edge: telnet van-edg 25 

ehlo

mail from:bg@ya.ru

Получаем отбой. У нас нет разрешений. 

RBL (Realtime blacklist) - это сервис, как правило в интернете, который мониторит рассылку почты. Есть платные RBL , есть бесплатные. Но задача у всех одна - чтобы сформировалась база IP-шников, с которых рассылается спам. Вы можете подключить себе RBL-провайдера. И тогда будет следующее. Кто-то устанавливает с вами соединение. Ваш сервер смотрит его IP, обращается к RBL-провайдеру, RBL-провайдер говорит, есть ли у него такой IP в базе. Если есть, то разговор окончен. Это спам.

RBL'ы хороши тем, что настраиваются достаточно просто. Вы находите какого-нибудь провайдера (например spamhaus.org) и прописываете его доменное имя в настройках Edge. Всё. 

Плохи RBL'ы тем, что ни один из них не знает всех спам-адресов. Поэтому приходится указывать двух-трех и более провайдеров. А когда их много, может возникнуть проблема ложного срабатывания.

Как проверить, есть ли вы в каких-нибудь списках RBL? Набираем в поисковике RBL Search и выбираем сайт (например dnsbl.info).  Указываем свой IP и ждём. Сайт пробегает по известным RBL-провайдерам и скажет вам, где вы засветились. Идёте на сайт RBL-провайдера, который вас заблочил и пишете заявку (Removal Request), чтобы вас выкинули. 

Чтобы добавить RBL-провайдеров в Edge, выберите IP Block List Providers. Скриншот был выше.

Для мониторинга работы прописанных вами провайдеров, можно выполнить скрипт get-AntispamTopRBLProviders.ps1, который лежит в C:\Program Files\Microsoft\Exchange Server\V14\Scripts. Выполните его из PowerShell и он выведет на экран всех провайдеров, которые прописаны в системе и сколько писем отбито каждым.

​

Возвращаемся к разбору схемы работы антиспам фильтров.

После того, как RBL отработал, срабатывает проверка Sender Filtering (фильтрация по отправителю). Это проверка поля "From".

На вкладке Blocked Senders можно сделать банальную блокировку конкретного почтового домена или адреса. Обратите внимание на галку внизу - Блокировать, если поле From пустое.

На вкладке Action указываем действие, которое будет выполнено, если человек оказался в Blocked Senders.

Reject - сразу отклоняем.

Второй вариант (Stamp message...) - пометить, что сообщение не прошло проверку и прокинуть его дальше. В самом конце, когда все проверки пройдут, каждому сообщению выставляется рейтинг. То, что письмо провалило конкретную проверку, скажется на этом рейтинге. Потом оно может быть заблокировано или попасть в карантинный ящик. 

Следующий этап - Recipient Filtering (фильтрации по получателю). Здесь смотрится поле To (Кому).

Здесь можно явно прописать список адресов, для которых почту принимать не нужно. Также можно поставить галку "Блокировать сообщения получателям, которых не существует в каталоге". Это означает, что если Edge не знает о почтовом ящике, письмо принимать не надо. Но будьте осторожны. Если вы создали ящик, а синхронизация ещё не прошла, будет отлуп.

Следующий этап - Sender ID Filtering. Это SPF запись. 

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

Админ должен прописать SPF-запись в своей внешней зоне, в которой перечисляется, с каких адресов разрешено отправлять почту от имени его домена.

Если каждый админ это сделает, то всё становится очень просто. Когда кто-то присылает вам почту от @microsoft.com, ваш сервер идет на DNS-сервер и спрашивает "Скажи мне SPF-запись для домена microsoft.com". Ему возвращается результат. Он сравнивает IP сервера, который отправил ему почту и то, что прописано в зоне. Если совпадает - хорошо. Не совпадает - иди вон.

Проблема в том, что не все прописывают SPF.

Как выглядит SPF-запись?

Она формата txt.

Набираем nslookup и вводим set q=txt

Указываем домен, например miaton.ru

Получаем запись вида

v=spf1 mx mx:mx.miaton.ru ~all 

v=spf1 везде будет абсолютно одинаково.

mx говорит, что все сервера, перечисленные в mx-записях, могут рассылать почту. На самом деле не факт, что перечисленные сервера могут рассылать почту, т.к. mx это всё же прием почты, а рассылка может идти откуда угодно.

Далее идёт указание явного mx - mx:mx.miaton.ru. В конце нужно поставить -all. Это жесткое отрицание, т.е. если кто-то не состоит в нашем списке, от него принимать нельзя. В нашем примере указано ~all, что означает "Проверить, но не отшибать".

​

Чтобы сделать SPF-запись самому, можно воспользоваться онлайн SPF Wizard'ом. Возьмем к примеру https://www.mtgsy.net/dns/spfwizard.php

Отвечаем на вопросы.

1. Никакие сообщения с этого домена рассылаться не должны. Т.е. мы зарегистрировали себе домен, но для почты его не используем. Тогда поставим галку, чтобы никто не смог от нашего имени рассылать почту. Нам это не надо.

2. Будет ли нашу почту рассылать провайдер. Не надо.

3. Включить MX-записи. 

4. Явно включить какой-нибудь хост.

5. Включить IP-адреса.

Нажимаем "Сгенерировать".

Получаем v=spf1 mx a:mail.tvoydomain.ru ip4:10.10.0.10 ~all

Сюда включены все MX-записи, включена запись типа A, включен один IP-адрес. В конце вместо ~all можете поставить -all

Берем эту запись и идем на наш DNS-сервер. Создаем в необходимой нам зоне запись типа txt.

Вставляем полученную SPF-запись. Сохраняем.

Для настройки проверки SPF на EDGE, открываем Sender ID и на вкладке Action указываем, что делать, если SPF провален.

Reject - письмо не принимается, разрывается связь, NDR уходит.

Delete - письмо принимается, удаляется, NDR не отправляется.

Stamp... - прокинуть дальше.

Следующий этап проверки - Content Filtering. Проверка по контенту.

Если вы на Edge включите Windows-обновления, то увидите, что вместе с патчами под Windows, приходят обновления контент-фильтров.

Контент-фильтры - это характерные слова, встречающиеся в спаме, большое количество ссылок (например на вредоносные программы), наличие письма, состоящего только из изображений и прочее.  

В Edge открываем Content Filtering и переходим на вкладку Custom Words.

Здесь находится белый и черный список слов. Черный список слов - письмо принимать нельзя. Белый список - прокидывает письмо через контент-фильтр. К примеру, если у вас идет какая-нибудь рассылка с определенной темой, можете добавить это слово в белый список и письмо не будет проверяться контент-фильтром.

На вкладке Exceptions прописываем исключения. Здесь указываем ящики, при получении письма на которые, контент-фильтр срабатывать не должен. 

Вкладка Exceptions.

Когда контент-фильтр прошел (а перед ним и все остальные проверки), письму выставляется рейтинг SCL (рейтинг вероятности). Т.е. с какой вероятностью это письмо является спамом. Рейтинг от 1 до 9. Рейтинг=1 - письмо нормальное. Рейтинг=9 - письмо является спамом.

Наша задача указать, как вести себя Edge'у при различном рейтинге SCL. Например, поместить в карантин при 9. Или отклонить при 7. И т.д. 

Как понять, было ли письмо? И если было, то прошло ли оно или было отбито? Если было отбито, то почему?

Воспользуемся командлетом Get-AgentLog. Если он возвращает ошибку, это означает только то, что: у вас на сервере не установлены антиспам-агенты, либо ни одно письмо еще не прошло. 

Вводим Get-AgentLog.

На каждое письмо формируется блок данных (выделено белым). Мы в тестовой среде, поэтому у нас писем совсем немного. А в производственной среде их могут быть тысячи. Поэтому используйте ключ startday endday и через FormatList можно выбрать сообщения, подпадающие под определенные условия (например, сообщения, которые были reject.) 

На картинке пометил и проставил цифры, в каком порядке удобнее эти логи читать.

Разберем ещё пример.

В 2:03 с адреса 10.10.0.20 с адреса irud@lenta.ru ушло письмо на адрес irud@specialist.ru. Оно было принято (Action:AcceptMessage). Почему policy is disable? Потому что это исходящая почта.

Помимо перечисленных проверок на нашей схеме, в Edge есть ещё одна интересная штука - Sender Reputation. Это проверка, которая срабатывает не моментально, а только, когда приходит несколько писем с одного адреса.

Сюда входит проверка на Open Proxy. Что это такое?

Ваш сервер отправляет почту (куда угодно) только, если его просит об этом внутренний пользователь. Если кто-то может попросить сервер со стороны, т.е. кто-то левый, и сервер начнёт рассылать почту, это как раз и есть Open Proxy (и Open Relay). Этим пользуются спамеры. Они находят какой-нибудь безотказный сервер и через него начинают слать почту. Так вот. Ваш сервер проверяет другой сервер на наличие Open Relay, т.е. обращается к нему и просит куда-нибудь доставить почту (например себе). Если нашему  серверу в этом не откажут, значит мы имеем дело с Open Proxy (или Open Relay). Поэтому на 24 часа он попадает в блок-лист.

На вкладке Action можно выставить уровень детализации проверки.

Итак, мы рассмотрели какие механизмы используются на Edge. Пришло время обговорить, чего же в Edge нет.

Grey Listing. Отложенное письмо. Идеология следующая. Спамер делает рассылку почты, идя по списку. Когда он обращается к вам, вы рубите первое соединение, в надежде на то, что легитимный сервер начнет делать доставку повторно. Спамеру некогда отслеживать, кто принял или не принял письмо. У него миллиардная очередь. Поэтому повтора не будет. Наш сервер при первом отлупе запоминает IP и в течении короткого времени не принимает с него почту (на тот случай, если спамер тут же попробует снова отправить). А потом ждёт повторно письмо.

Grey Listing - штука очень эффективная, но со своим недостатком - сразу замедляется доставка писем к вам. Если вы хотите установить Grey Listing на Exchage, то в помощь вам сторонние решения. Или на MSDN посмотрите Greylisting Sample Agent (https://msdn.microsoft.com/en-us/library/bb402057%28v=exchg.80%29.aspx?f=255&MSPPError=-2147217396). Я его не пробовал, но можно прикрутить.

​

И в заключении главы.

Внутри организации Exchange есть такой параметр, как SCLJunkThreshold.

У нас он равен 4 (по умолчанию).

Этот параметр означает, что если пользователю приходит письмо с рейтингом SCL выше 4-х, оно гарантированно попадает в Junk E-mail (Нежелательная почта).

Допустим Edge говорит о том, что пропускать почту внутрь организации нужно, если SCL Limit = 7 или ниже. Exchange это не учтёт и всё что имеет 5 и 6 будет попадать в Junk E-mail у 

пользователя. 

И ещё один момент. У пользователя есть Allow List и Block List, которые он сам сделал. Ситуация следующая. Пользователь может влиять на Edge. Например, пользователь часто жалуется, что у него какие-то письма не доходят. Он вбивает в Allow List нужные адреса. Администратор может запустить команду Update-SafeList с указанием учетки (я для примера указал учетку администратора). Эта команда берет из почтового ящика Allow

List и подготавливает его для применения. При первой же синхронизации, которую можно выполнить командой Start-EdgeSynchronization, этот список уходит на Edge. В таком случае этот список будет влиять на проверку по контенту. Т.е. для каждого конкретного пользователя, почта будет проходить, несмотря на рейтинг.

​

Переходите к следующей странице: High Availability.

bottom of page