Назад | Перейти на главную страницу

Exchange 2007 CAS - преимущества ISA Server над портом пересылки 443

Я работаю над развертыванием Exchange 2007 в существующей среде Exchange 2003. Microsoft не поддерживает размещение сервера клиентского доступа (CAS) Exchange 2007 в сети периметра / DMZ. Вместо этого Microsoft предлагает разместить ISA-сервер в сети периметра / DMZ и использовать его для обратного обращения прокси-запросов к CAS-серверу.

В чем преимущество использования сервера ISA в качестве обратного прокси по сравнению с перенаправлением порта 443 из внешней сети через периметр / DMZ на сервер CAS во внутренней сети? Будут ли у меня проблемы с сертификатом SSL, если я перенаправлю порт? Есть ли другие порты, которым нужна переадресация?

Обновить: Я обнаружил следующие два преимущества Вот:

Когда вы публикуете приложение через ISA Server, вы защищаете сервер от прямого внешнего доступа, потому что имя и IP-адрес сервера недоступны для пользователя. Пользователь обращается к компьютеру ISA Server, который затем пересылает запрос на сервер в соответствии с условиями правила публикации сервера.

Мост SSL защищает от атак, которые скрыты в соединениях с шифрованием SSL. Для веб-приложений с поддержкой SSL после получения запроса клиента ISA-сервер расшифровывает его, проверяет и разрывает SSL-соединение с клиентским компьютером. Правила веб-публикации определяют, как ISA Server передает запрос объекта на опубликованный веб-сервер. Если правило безопасной веб-публикации настроено для пересылки запроса с использованием защищенного HTTP (HTTPS), ISA Server инициирует новое соединение SSL с опубликованным сервером. Поскольку компьютер ISA Server теперь является SSL-клиентом, он требует, чтобы опубликованный веб-сервер ответил серверным сертификатом.

Добавляя вторую часть к вопросу, являются ли они оправданием для покупки второго сервера, лицензирования, настройки, устранения неполадок и т. Д. Как вы это сделали в своей среде, особенно в небольших (<200 пользователей) средах?

Основное преимущество использования ISA Server в качестве обратного прокси - это безопасность, но, конечно, это имеет больше смысла, если у вас есть более одного приложения для публикации; если вам нужно только сделать ваш сервер Exchange CAS доступным извне, возможно, покупка, внедрение и управление ISA будет немного излишним.

Использование ISA вместо простой пересылки TCP-порта 443 дает следующие преимущества:

  • Предварительная аутентификация. Пользователи могут быть аутентифицированы самим ISA Server, и затем запрос будет перенаправлен на фактический опубликованный сервер, только если эта аутентификация будет успешной; это блокирует неаутентифицированных пользователей даже от попыток вмешаться в ваше веб-приложение, спасая вас, например. от возможных ошибок при входе в приложение.
  • HTTP фильтрация. Стандартные HTTPS-соединения проходят через сетевой брандмауэр без какого-либо анализа, потому что трафик, конечно, зашифрован; с ISA соединения HTTPS выполняются от клиента к прокси-серверу ISA, а затем повторно открываются ISA на веб-сервере, что позволяет ISA проверять и очищать фактический трафик HTTP; это запрещает "странные" запросы к вашим опубликованным приложениям, избавляя вас от множества ошибок приложения (переполнение буфера и т. д.).
  • URL-фильтрация. Если вы откроете TCP-порт 80 и / или 443 для внутреннего веб-сервера, клиент может запросить у веб-сервера все, что ему нужно (домен, сайт, путь, файл и т. Д.); ISA-сервер может быть настроен на прием только определенных URL-адресов, поэтому, если у вас есть веб-сервер, на котором размещено несколько сайтов, или какой-то внутренний веб-сайт, или какое-то частное хранилище и т. Д., Вы можете быть уверены, что только запросы типа "https://webmail.mydomain.com/owa"может достичь его.
  • Перенаправление HTTPS. Хорошо, это не главная проблема, но, говоря об URL-адресах, сколько пользователей забывают поставить эту букву «s» после «HTTP»? Вы можете автоматически перенаправлять HTTP-трафик на HTTPS с помощью ISA.
  • Балансировки нагрузки. Если у вас есть несколько веб-серверов для одного и того же приложения, ISA Server может балансировать их нагрузку как единый опубликованный веб-сайт без необходимости в аппаратных или программных балансировщиках сетевой нагрузки; эта балансировка нагрузки также происходит на уровне HTTP, а не на уровне TCP, поэтому она может лучше управлять сеансами клиентов.
  • Все остальные функции ISA Server. Конечно. Но не забывайте о них. Вы можете настроить правила веб-публикации так, чтобы разрешить только определенных пользователей, только в определенное время, только из определенных диапазонов IP и т. Д .; вы также можете опубликовать множество внутренних веб-серверов на одном внешнем IP-адресе и т. д .; есть много вещей, которые вы можете делать с ISA после его реализации, кроме публикации сервера Exchange CAS.

ISA дорого стоит в развертывании и не имеет особого смысла, если вы собираетесь использовать его только для входящих подключений.

Имеет смысл кэшировать исходящие запросы 1000 пользователей, особенно для страниц с большим объемом, таких как Google, MSN, порталы и т. Д. Но для входящих вы можете сделать то же самое с гораздо меньшими затратами.

Как упоминал TheCleaner, вы можете просто заблокировать свой веб-сервер / CAS, независимо от того, Windows это или * nix.

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

Основное резюме: если у вас уже есть хорошее периферийное устройство, не беспокойтесь об этом. Если нет, то что-то вроде pfSense не займет больше времени на настройку, чем ISA, занимает гораздо меньше места (может успешно работать на виртуальной машине со 128 МБ ОЗУ), и вам не нужно лицензировать Windows и платить дополнительную лицензию на ISA.

Лично я перестал использовать ISA немного после выхода издания 2004 года. Хотя функциональность и «легкость» интеграции с продуктами MS являются плюсом, существующий аппаратный брандмауэр при правильной настройке может быть столь же безопасным.

Я обнаружил, что ISA в миксе просто добавляла еще один уровень сложности и фактически привносила немного медленности.

Поэтому я рекомендую использовать MIP (сопоставленный IP-адрес) с сервером CAS только для тех портов, которые необходимы (80/443 и т. Д.) Для ролей.

Аргумент, который я слышал, заключается в том, что наличие ISA посередине предотвращает попытки людей взломать ваш сервер CAS, но если ваш сервер CAS настроен правильно, и особенно если вы используете SCW для Windows на сервере CAS, в конце концов, После установки и запуска у вас действительно не будет больше проблем с безопасностью, если у вас будет ISA посередине.

Теперь ... Доктор. Шиндер и другие будут категорически не согласны и будут убеждать вас установить ISA-сервер, но я нахожу забавным то, что большинство людей, не относящихся к «администраторам Windows», которые являются экспертами по сетям / брандмауэрам, просто не используют их ... это мне кое-что говорит. .