none
Публикация Exchange 2010 RRS feed

  • Вопрос

  • Доброго дня , коллеги!

    Имею Exchange 2010. На текущий момент реализация такова: сервер установлен со всеми ролями (кроме Edge , разумеется) на одном сервере. Используется свой CA для выдачи сертификатов. Я хочу приобрести сертификат для того, чтоб не получать предупреждение о непроверенном сертификате при входе в OWA из вне.

    Сейчас стоит файрвол, и организован проброс портов 80, 443, 25, 465, 119. Понимаю, что это небезопасно, посему принял решение устанавливать в DMZ Edge, и уже согласовывать Edge и основной почтовый сервер. 

    Насколько я понял, Edge выполняет только функцию доставки почты, собственно на нём и следует ставить антивирус и спамконтроль, и не выполняет функций организации доступа OWA, autodiscover.

    Когда стоят TMG, то с публикацией почтовика проблем не было - TMG имеет соответствующий функционал, а также позволяет устанавливать сертификат для внешнего доступа. Т.е. на ТМГ располагается внешний сертификат, а на самом почтовом сервере - внутренний.

    К сожалению, мой файрвол не имеет функций реверсивного проксирования, соответственно, опубликовать Exchange аналогичным способом как с ТМГ не представляется возможным.

    Я так понимаю, мне необходимо поднимать свой другой веб сервер с функцией реверсивного проксирования, размещать на этом сервере внешний сертификат, и уже на этом сервере натравливать на внутренний.

    Подскажите, может я не прав или имеется варианты проще и лучше ? 

    28 июля 2016 г. 6:48

Ответы

  • Edge на мой субъективный взгляд, это дырявый ограниченный антиспам и антивирус, если нужна надежная защита, то нужен сторонний продукт, типа касперского.

    Публикация лучше пробросов хотя бы тем, то позволяет защититься от ddos аткаки, которую вам может устроить даже мобильное устройство. Кроме того, IIS ARR может поределять какой СЕРВИС (owa,ecp,ews) жив и подключать клиента именно к живому серверу. Так же есть отказоустойчивый вариант с двумя IIS ARR.

    Можете почитать инструкцию по настройки.

    • Помечено в качестве ответа Zubkov Alexey 28 июля 2016 г. 10:13
    28 июля 2016 г. 8:02
  • Edge имеет встроенный функционал по антиспаму и он активирован по умолчанию. В принципе он закрывает все базовые потребности в фильтрации почты, но многим кажется неудобным.

    По поводу публикации почитайте статью: https://blogs.technet.microsoft.com/exchange/2013/07/19/part-1-reverse-proxy-for-exchange-server-2013-using-iis-arr/ 


    • Помечено в качестве ответа Zubkov Alexey 28 июля 2016 г. 10:13
    28 июля 2016 г. 7:10

Все ответы

  • Edge имеет встроенный функционал по антиспаму и он активирован по умолчанию. В принципе он закрывает все базовые потребности в фильтрации почты, но многим кажется неудобным.

    По поводу публикации почитайте статью: https://blogs.technet.microsoft.com/exchange/2013/07/19/part-1-reverse-proxy-for-exchange-server-2013-using-iis-arr/ 


    • Помечено в качестве ответа Zubkov Alexey 28 июля 2016 г. 10:13
    28 июля 2016 г. 7:10
  • А вот здесь намекают, что реверс прокси вообще не нужен при некоторых условиях :)

    Life in a Post TMG World – Is It As Scary As You Think?

    В любом случае, для решения вашей задачи можно создать второй сайт в IIS и на него повесить покупаемый сертификат. Вот здесь описывается процедура для Exchange 2013. Общий принцип будет аналогичен и для Exchange 2010.


    Blog - Smtp25.ru
    Полезные ссылки - Links

    28 июля 2016 г. 7:31
    Отвечающий
  • IIS ARR ничем от простого проброса по большому счету не отличается в плане безопасности.

    Он все равно не умеет преаутентификацию.

    А чем вам небезопасен простой проброс портов? Ваш отдел безопасности против этого?

    И еще вопрос, вы сказали когда стоял ТМГ, его снесли зачем-то или что под этим имеется ввиду? Он еще до 2020 года поддерживается.


    scientia potentia est
    My blog


    28 июля 2016 г. 7:35
  • Edge на мой субъективный взгляд, это дырявый ограниченный антиспам и антивирус, если нужна надежная защита, то нужен сторонний продукт, типа касперского.

    Публикация лучше пробросов хотя бы тем, то позволяет защититься от ddos аткаки, которую вам может устроить даже мобильное устройство. Кроме того, IIS ARR может поределять какой СЕРВИС (owa,ecp,ews) жив и подключать клиента именно к живому серверу. Так же есть отказоустойчивый вариант с двумя IIS ARR.

    Можете почитать инструкцию по настройки.

    • Помечено в качестве ответа Zubkov Alexey 28 июля 2016 г. 10:13
    28 июля 2016 г. 8:02
  • кстати, хотел уточнить - вы собираетесь все это делать только ради зелененькой строчки браузера?))

    Если руководство недовольно, то можно один раз добавить на всех их компах сертификат в доверенные и проблем больше не будет.

    И да, если все же станете решать задачу прямым пробросом портов - внутренние dns-имена в сертификатах от публичных ЦС не поддерживаются. 

    28 июля 2016 г. 8:03
  • как вариант, изменить все внутренние URL. был, к примеру, autodiscover.domain.local, а будет autodiscover.domain.ru (соответственно, на ваших DNS серверах поднять зону domain.ru. Купленный сертификат установить на Exchange для IIS (при необходимости на остальные сервисы). В этом случае проброс порта 443 нормально работает.

    Do not multiply entities beyond what is necessary

    28 июля 2016 г. 8:28
  • Edge на мой субъективный взгляд, это дырявый ограниченный антиспам и антивирус, если нужна надежная защита, то нужен сторонний продукт, типа касперского.

    Публикация лучше пробросов хотя бы тем, то позволяет защититься от ddos аткаки, которую вам может устроить даже мобильное устройство. Кроме того, IIS ARR может поределять какой СЕРВИС (owa,ecp,ews) жив и подключать клиента именно к живому серверу. Так же есть отказоустойчивый вариант с двумя IIS ARR.

    Можете почитать инструкцию по настройки.

    один сервер, ничего не поможет в отказоустойчивости)

    Плюс мне кажется, что скорее железка загнется от DDOS, чем Exchange, он все-таки в последних версиях защищен от подобных механизмов.


    scientia potentia est
    My blog

    28 июля 2016 г. 8:44
  • Edge на мой субъективный взгляд, это дырявый ограниченный антиспам и антивирус, если нужна надежная защита, то нужен сторонний продукт, типа касперского.

    Публикация лучше пробросов хотя бы тем, то позволяет защититься от ddos аткаки, которую вам может устроить даже мобильное устройство. Кроме того, IIS ARR может поределять какой СЕРВИС (owa,ecp,ews) жив и подключать клиента именно к живому серверу. Так же есть отказоустойчивый вариант с двумя IIS ARR.

    Можете почитать инструкцию по настройки.

    один сервер, ничего не поможет в отказоустойчивости)

    Плюс мне кажется, что скорее железка загнется от DDOS, чем Exchange, он все-таки в последних версиях защищен от подобных механизмов.


    scientia potentia est
    My blog

    Я ж написал, что отказоустойчивый вариант с двумя IIS (или в виртуальной среде, с небольшими ньюансами). Что касается DDOS, то тут должен первым умереть IIS ARR, закрыв собой почтовый сервер)) Exchange от DDOS защищен, но пролемы в работе почты могут наблюдаться и очень приличные. А вот то, что мобильный клиент, по EAS может положить сервер и наплодить логов, это реально =) 
    • Изменено Guznin KA 28 июля 2016 г. 9:15
    28 июля 2016 г. 9:15
  • Edge имеет встроенный функционал по антиспаму и он активирован по умолчанию. В принципе он закрывает все базовые потребности в фильтрации почты, но многим кажется неудобным.

    По поводу публикации почитайте статью: https://blogs.technet.microsoft.com/exchange/2013/07/19/part-1-reverse-proxy-for-exchange-server-2013-using-iis-arr/ 


    благодарю за информацию, буду изучать.

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

    28 июля 2016 г. 10:04
  • IIS ARR ничем от простого проброса по большому счету не отличается в плане безопасности.

    Он все равно не умеет преаутентификацию.

    А чем вам небезопасен простой проброс портов? Ваш отдел безопасности против этого?

    И еще вопрос, вы сказали когда стоял ТМГ, его снесли зачем-то или что под этим имеется ввиду? Он еще до 2020 года поддерживается.


    scientia potentia est
    My blog


    подписки на нём у нас не было, соответственно о фильтрации нежелательных сайтов и пр не было и речи. кое как крутились но не оно. плюс - всё равно отказываться в будущем, поэтому перешли сразу на другой файрвол.
    28 июля 2016 г. 10:07
  • Edge на мой субъективный взгляд, это дырявый ограниченный антиспам и антивирус, если нужна надежная защита, то нужен сторонний продукт, типа касперского.

    Публикация лучше пробросов хотя бы тем, то позволяет защититься от ddos аткаки, которую вам может устроить даже мобильное устройство. Кроме того, IIS ARR может поределять какой СЕРВИС (owa,ecp,ews) жив и подключать клиента именно к живому серверу. Так же есть отказоустойчивый вариант с двумя IIS ARR.

    Можете почитать инструкцию по настройки.

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

    балгодарю за русский мануал. почитаю.

    28 июля 2016 г. 10:08
  • кстати, хотел уточнить - вы собираетесь все это делать только ради зелененькой строчки браузера?))

    Если руководство недовольно, то можно один раз добавить на всех их компах сертификат в доверенные и проблем больше не будет.

    И да, если все же станете решать задачу прямым пробросом портов - внутренние dns-имена в сертификатах от публичных ЦС не поддерживаются. 

    совершенно верно - хочу зелёленький :) зелёный - к счастью :)

    внутренние имена внешними ЦС не поддерживаются , эт я в курсе, потому и задал здесь вопрос - а как же мне всё сделать.

    В домене локальный корневой сертификат добавлен разумеется, у всех зелёненькая, но хочется чтоб и снаружи, чтоб по феншую :) 

    28 июля 2016 г. 10:10
  • Вовсе необязательно заворачивать внутренних клиентов на внешку. Все решается переконфигурирование виртуальных каталогов Exchange на использование публичных имен.

    Do not multiply entities beyond what is necessary

    28 июля 2016 г. 10:12
  • как вариант, изменить все внутренние URL. был, к примеру, autodiscover.domain.local, а будет autodiscover.domain.ru (соответственно, на ваших DNS серверах поднять зону domain.ru. Купленный сертификат установить на Exchange для IIS (при необходимости на остальные сервисы). В этом случае проброс порта 443 нормально работает.

    Do not multiply entities beyond what is necessary

    не очень вариант. хочется "красивые налево, умные направо".
    28 июля 2016 г. 10:12
  • ну без нормального публикующего прокси иначе никак. можете использовать, к примеру, бесплатный kemp vlm, правда там ограничение 20 Мбит и 50 SSL сессий, но, думаю, вам хватит. ссылка

    Do not multiply entities beyond what is necessary

    28 июля 2016 г. 10:19
  • ну без нормального публикующего прокси иначе никак. можете использовать, к примеру, бесплатный kemp vlm, правда там ограничение 20 Мбит и 50 SSL сессий, но, думаю, вам хватит. ссылка

    Do not multiply entities beyond what is necessary

    я бегло посмотрел - функций IIS ARR мне будет чуть более чем достаточно.

    как я понял - на серваке с ролью EDGE (чтоб не поднимать новый) я просто подниму IIS c ARR, и настрою замену урлов. при этом внешний сертификат привяжу к этому ИИС, а внутренний останется на старом, и все буду счастливы. А проброс портов перенастрою на этот новый сервер. вроде так и вроде просто. а на деле - узнаем :) 

    28 июля 2016 г. 13:39
  • Почему то не получается.

    Вроде всё по инструкциям, а оно не пашет :(

    Думал что не работает - попробовал редирект - работает.

    Чую что проблема в этих регулярных выражениях.

    Даже выяставляя полностью wildcard (*) всё равно rewrite не отрабатывает, или я не понимаю как и что нужно сделать.

    Прошу знающих объяснить популярно. Нужно пробросить mail.domain.ru/owa autodiscover.domain.ru/ с сервера в ДМЗ на сервер во внутренней сети.

    Надо ли какие то настройки производить на стороне внутреннего сервера ? ибо вроде как бы получалось, но выдавал ошибки типа "502 - web server received an invalid response while acting as a gateway or proxy server."

    29 июля 2016 г. 12:56
  • Почему то не получается.

    Вроде всё по инструкциям, а оно не пашет :(

    Думал что не работает - попробовал редирект - работает.

    Чую что проблема в этих регулярных выражениях.

    Даже выяставляя полностью wildcard (*) всё равно rewrite не отрабатывает, или я не понимаю как и что нужно сделать.

    Прошу знающих объяснить популярно. Нужно пробросить mail.domain.ru/owa autodiscover.domain.ru/ с сервера в ДМЗ на сервер во внутренней сети.

    Надо ли какие то настройки производить на стороне внутреннего сервера ? ибо вроде как бы получалось, но выдавал ошибки типа "502 - web server received an invalid response while acting as a gateway or proxy server."

    IIS ARR настраиваете?
    29 июля 2016 г. 13:10
  • IIS ARR настраиваете?

    Эмм...

    По порядку расскажу.

    Ставлю АРР через вебинсталер.

    Запускаю консоль ИИС. Далее дефолт сайт - привязки хттп, хттпс(сюда мой купленный сертификат). Тут же - url rewrite. Делаю правило новое (blank rule) - в нем совпадения по wildcards, pattern *. Условия - никаких не ставлю(для эксперимента, в идеале должны быть для owa, autodiscover). Режим rewrite. Адрес реврайта https://mail.domain.local/{R:0}

    В самом arr cache настроек не производил.

    Чую, что проблема либо в паттернах, либо надо включать прокси в "арр кеш". Либо я вообще не врубаюсь как пашет эта фигня.

    На уровне сервера думал делать(а не сайта), то по идее тогда мой сертификат тут не будет участвовать. А мне нужно чтоб здесь был купленный, чтоб зелененький замок был. 

    Может быть еще проблема в том,что для эусперимента я на файрволе использую порты 40443,40080, и их пробрасываю на дмз как 443 и 80 соответственно? Не думаю,  но все же. Либо простой реврайт на уровне сайта не пашет с https?

    Или все таки ферму использовать? 

    Сижу,не врубаюсь. Не хочется поднимать отдельный сервак на дебиане чисто для реверспрокси:(

    31 июля 2016 г. 7:44
  • кажется проблема была в том, что я не добавил сертификат своего внутреннего коревого центра сертификации на EDGE сервер, где крутится IIS с ARR :)
    31 июля 2016 г. 9:37
  • Действительно,  проблема была в том, что е добавил локальный корневой центр в доверенные, т.к. На самом эксейндж используется сертификат от внутреннего центра сертификации.

    В ароцессе работы появилось несколько хотелок - можно ли средствами ARR сделать упрощение публикации owa: чтоб заходить не domain.com/owa а просто domain.com?  Средствами ИИС с эксчейнджем не помогают,т.к. Используется локальное имя. 

    Кужа копнуть в сторону пояснения принципа работы и настроек ARR? Хочется блокировать запросы, не подпадающие под критерии. С регулярными вырвжениями беда, не разбираюсь в них:(

    31 июля 2016 г. 20:37
  • IIS ARR ничем от простого проброса по большому счету не отличается в плане безопасности.

    Он все равно не умеет преаутентификацию.

    А чем вам небезопасен простой проброс портов? Ваш отдел безопасности против этого?

    И еще вопрос, вы сказали когда стоял ТМГ, его снесли зачем-то или что под этим имеется ввиду? Он еще до 2020 года поддерживается.


    scientia potentia est
    My blog


    ARR отличается от простого проброса 443 порта тем, что может использовать другой сертификат, не тот, который установлен на сервере Exchange. То есть, на Exchange можно оставить старый сертификат, с внутренним именем сервера Exchange в домене (на которое вам сторонний поставщик сертификат не даст), а на ARR - покупной сертификат стороннего поставщика.

    Ну, а TMG сейчас AFAIK легально приобрести нельзя - можно только старый, ранее приобретённый, использовать.


    Слава России!

    31 июля 2016 г. 22:15
  • кажется проблема была в том, что я не добавил сертификат своего внутреннего коревого центра сертификации на EDGE сервер, где крутится IIS с ARR :)

    Хорошо, что разобрались. Ту ссылку, что я дал на инструкцию, можно смело использовать, это рабочий конфиг ARR, если все делаете по пунктам и что-то не работает, проблемы может быть только две: вы где-то ошиблись или проблема в третьей стороне(сетка, fw и т.п.). Я сам регулярно настраиваю по этой инструкции. 

    M.V.V. _

    Добавлю, что IIS ARR может проверять сервисы(owa,ecp,EAS и т.д.) по HealthCheck URL и если сервис умер, то он не будет туда пробрасывать, а будет пробрасывать на другой сервер в ферме. 


    • Изменено Guznin KA 1 августа 2016 г. 8:02
    1 августа 2016 г. 8:02
  • Хорошо, что разобрались. Ту ссылку, что я дал на инструкцию, можно смело использовать, это рабочий конфиг ARR, если все делаете по пунктам и что-то не работает, проблемы может быть только две: вы где-то ошиблись или проблема в третьей стороне(сетка, fw и т.п.). Я сам регулярно настраиваю по этой инструкции. 

    Добавлю, что IIS ARR может проверять сервисы(owa,ecp,EAS и т.д.) по HealthCheck URL и если сервис умер, то он не будет туда пробрасывать, а будет пробрасывать на другой сервер в ферме. 

    у меня Exchange 2010, и он единственный. ну да ладною. вроде всё работает. нужно разбираться в регулярных выражениях для более чётких правил.

    Благодарю

    4 августа 2016 г. 5:17