Sunday, May 27th, 2018

Создание параллельной конфигурации брандмауэра ISA в Netscreen DMZ

Published on Февраль 12, 2009 by   ·   Комментариев нет

На протяжении многих лет существовали вопросы относительного того, как настроить брандмауэр ISA в “hardware DMZ”. Я должен признать, что этот вопрос сильно не волновал меня до тех пор, пока я не выяснил, для чего администратору брандмауэра ISA может понадобиться такая конфигурация. Казалось бы, что проще создать не параллельную конфигурацию, а последовательную конфигурацию, когда брандмауэр ISA располагается непосредственно за аппаратным брандмауэром, осуществляя тем самым более высокий уровень защиты для ресурсов.

Однако, недавно я участвовал в обсуждении, на котором один администратор рассказал о своих проектных задачах и хотел узнать, как лучше достигнуть желаемого результата. Вы можете прочитать наше обсуждение на http://forums.isaserver.org/Where_to_put_my_ISA_with_Netscreen???/m_2002002953/tm.htm

В этом обсуждении Ken сказал, что он использует брандмауэр Netscreen и что он хочет внедрить брандмауэр ISA. В настоящее время между брандмауэрами Netscreen в главном и дочерних офисах существует VPN соединение. Задачи, которые он хотел бы возложить на брандмауэр ISA должны быть следующими:

  • Использование брандмауэра ISA в качестве Web фильтра с помощью SmartFilter
  • Использование брандмауэра ISA для Web кэширования для сетевых корпоративных клиентов
  • Публикация сайтов Outlook Web Access (OWA) в корпоративной сети
  • Публикация RPC/HTTP или обеспечение безопасности Exchange RPC

Для этих проектных задач необходимы возможности модели безопасности брандмауэра ISA, которых нет в Netscreen. Они включают:

  • Web прокси фильтр брандмауэра ISA, который позволяет ему использовать дополнительный фильтр SmartFilter
  • Web прокси фильтр брандмауэра ISA, также позволяет брандмауэру ISA работать как устройство кэширования
  • Web прокси фильтр брандмауэра ISA позволяет брандмауэру ISA осуществлять SSL передачи, и проверку соединений прикладного уровня, которые скрыты для брандмауэра Netscreen
  • Брандмауэр ISA допускает предварительную аутентификацию пользователей, до того как были осуществлены соединения с Web серверами в корпоративной сети. Это позволяет уберечься от злоумышленников, которые используют анонимные соединения для получения доступа к сайту
  • Фильтр Exchange RPC брандмауэра ISA, который обеспечивает доступ для пользователей всех версий клиента Outlook к Exchange Server из любого места в мире, не используя VPN соединения или компрометирующей инфраструктуры безопасности

У Ken есть два требования, касающиеся его текущей инфраструктуры:

  • Использование устройства Netscreen для VPN соединений
  • Чтобы IP адрес шлюза по умолчанию был IP адресом устройства Netscreen

Я подумал об этих требованиях и нарисовал несколько диаграмм. Решение, которое наилучшим образом удовлетворяет требованиям Ken, показано на рисунке 1. Этот проект может быть охарактеризован следующим образом:

  • И брандмауэр Netscreen и брандмауэр ISA располагаются после маршрутизатора Internet
  • И Netscreen и ISA брандмауэр имеют внешние интерфейсы с IP адресами из списка блокированных адресов
  • Netscreen имеет три NIC: первая NIC соединена с Internet (ее внешний интерфейс), вторая NIC соединена с корпоративной сетью, третья NIC подсоединена к периметру сети, соединяющей брандмауэры Netscreen и ISA
  • Периметр сети между брандмауэрами ISA и Netscreen использует частные адреса, и корпоративная сеть также использует частные адреса
  • Брандмауэр ISA имеет два интерфейса: первая NIC соединена с DMZ, соединяющей брандмауэр ISA и устройство Netscreen, а другой интерфейс соединен с интернет
  • VPN соединения между Netscreen главного и дочерних офисов

    Как настроить паралельную конфигурацию?

    Рисунок 1

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

Netscreen главного и дочернего офисов соединены с помощью VPN соединения. Я предполагаю, что машины в дочерних офисах имеют доступ к Internet с помощью своего собственного устройства Netscreen и используют VPN соединения только для доступа к серверу ресурсов в главном офисе корпоративной сети. Однако, если это не верно, и Ken хочет заставить клиентские системы в дочерних офисах использовать брандмауэр ISA для доступа к Internet, то мы можем это организовать. Как мы увидим позже, мы можем использовать конфигурацию Web прокси и клиента брандмауэра, чтобы выполнить такую работу.

Теперь вы можете удивиться, почему у нас осталось требование использовать внутренний интерфейс Netscreen в качестве шлюза по умолчанию. Причина для этого заключается в том, что VPN шлюзы работают в качестве маршрутизатора, и для того, чтобы переслать соединения в главный офис, мы должны установить Netscreen в качестве шлюза для компьютеров подсетей.

Брандмауэр ISA имеет внутренний интерфейс по периметру сети (часто называемый “hardware” брандмауэром DMZ сети) и внешний интерфейс, таким же ID сети как и внешний интерфейс Netscreen. По умолчанию внутренняя сеть брандмауэра ISA определяется всеми IP адресами по периметру сети, которые в нашем случае являются IP адресами, связанными с внутренним интерфейсом брандмауэра ISA, DMZ интерфейсом Netscreen, и всеми адресами корпоративной сети.

Лонфигурация

Рисунок 2

Теперь мы должны определить маршруты для взаимодействия между различными сетями. Для Netscreen необходимы следующие взаимодействия:

  • Взаимодействие между корпоративной сетью главного и дочерних офисов
  • NAT взаимодействие между корпоративной сетью главного офиса и интернет
  • Взаимодействие между корпоративной сетью и периметром сети между Netscreen и брандмауэром ISA

Для брандмауэра ISA необходимы следующие взаимодействия:

  • NAT взаимодействие между внешней сетью по умолчанию и интернет. Обратите внимание, что брандмауэр ISA ничего не знает о периметре сети. Конечно, если вы хотите разместить серверы на этом периметре сети, вы можете определить набор компьютеров, и использовать этот набор для контроля доступа, но это не входит в наш сценарий и дизайн
  • Если брандмауэр ISA позднее определить, как сервер удаленного доступа к VPN, то необходимо задать взаимодействие между клиентами VPN и внутренней сетью по умолчанию

Я упомянул взаимодействие для клиентов VPN, потому что Ken может захотеть в последствии использовать возможности сервера удаленного доступа к VPN брандмауэра ISA вместо того, чтобы использовать для этих целей Netscreen. В отличие от Netscreen, брандмауэр ISA позволяет вам использовать более тонкую настройку контроля доступа для пользователей VPN. В дополнение, брандмауэр ISA может производить проверку соединений, как на пакетном так и на прикладном уровне.

Не создается паралельная лонфигурация игры

Рисунок 3

Теперь давайте взглянем на пути для запросов/ответов для различных соединений к и из корпоративной сети и интернет.

На рисунке 4 показаны пути запросов/ответов для соединений между главным и дочерними офисами. Это простое соединение по ссылке VPN, созданной между VPN шлюзами главного и дочерних офисов. Это текущая конфигурация Kenа и нам не надо что-либо менять здесь.

Crjkmrj cnjbn брандмауэр netscreen

Рисунок 4

На рисунке 5 показаны пути запросов/ответов для клиентов внутренней сети. Т.к. основная причина для использования брандмауэра ISA заключается в использовании Web фильтрации и улучшенного мониторинга пользовательской активности, то мы хотим, чтобы все соединения проходили через брандмауэр ISA. Мы можем сделать это, если все клиентские системы будут клиентами брандмауэра и Web прокси.

Конфигурации клиентов Web прокси и брандмауэра ISA предоставляют клиентским подсистемам доступ к интернет независимо от конфигурации клиентского шлюза по умолчанию. Причина для этого заключается в том, что только клиентам Web proxy и брандмауэра необходимо знать о маршрутах к внутреннему интерфейсу брандмауэра ISA.

Т.к. все клиенты настроены для использования Netscreen в качестве шлюза по умолчанию, а Netscreen знает маршрут к IP адресу внутреннего интерфейса брандмауэра ISA, а затем соединения от клиентов Web proxy брандмауэра просто направляются на внешний интерфейс брандмауэра ISA.

Netscreen dmz

Рисунок 5

Пути запросов/ответов для правил публикации Web и Server показаны на рисунке 6. Здесь соединения из интернет направляются на внешний интерфейс брандмауэра ISA. Затем брандмауэр ISA направляет соединения по периметру сети между брандмауэрами ISA и Netscreen, а затем отправляет через Netscreen в корпоративную сеть. Ответы проходят через Netscreen на брандмауэр ISA, а брандмауэр ISA возвращает ответы в интернет.

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

Причина для этого заключается в том, что брандмауэр ISA не является шлюзом по умолчанию для корпоративных сетевых серверов. Если мы оставим оригинальный IP адрес внешнего клиента без изменений, то ответы от опубликованных сервером будут посылаться на внутренний интерфейс Netscreen, а затем направляться с внешнего интерфейса Netscreen внешнему клиенту. Т.к. внешний клиент сделал запрос к внешнему IP адресу брандмауэра ISA, а не к внешнему адресу брандмауэра Netscreen, то ответ будет отвергнут внешним клиентом, как неразрешенное входящее соединение.

Если мы заменим IP адрес в запросе внешнего клиента на IP адрес внутреннего интерфейса брандмауэра ISA, то сервер вернет ответ на брандмауэр ISA. А затем брандмауэр ISA перешлет ответ внешнему клиенту в интернет.

Как настроить паралельную конфигурацию?

Рисунок 6

Я должен упомянуть, что это не единственно возможный дизайн, который удовлетворяет требованиям Ken. Например, вы можете также использовать решение, показанное на рисунке 7. В действительности это более предпочтительная конфигурация, т.к. в этом случае устройство Netscreen не является единственной точкой доступа к интернет, а существуют альтернативные шлюзы в случае, если Netscreen становится недоступным. В этой конфигурации не требуется менять настройки шлюзов корпоративных компьютеров, и по-прежнему можно использовать конфигурации клиентов брандмауэра и Web прокси для контроля доступа и использования входящего и исходящего трафика.

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

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

Лонфигурация

Рисунок 7

Перед тем, как мы закончим, давайте еще раз посмотрим на возможный сценарий, который Кен захочет использовать. Т.к. Кен хочет иметь жесткий контроль на исходящим доступом в главном офисе, он может захотеть распространить этот контроль на все клиентские подсистемы в дочерних офисах. Он может сделать это, установив клиентские конфигурации клиентов Web прокси и брандмауэра во всех дочерних офисах.

На рисунке 8 показаны пути запросов/ответов для этих соединений. Клиенты Web прокси и брандмауэра в дочерних офисах настроены на IP адрес внутреннего интерфейса брандмауэра ISA. Соединения от клиентов брандмауэра и прокси дочерних офисов пересылаются по VPN, а затем через внутренний интерфейс брандмауэра ISA по периметру сети между интерфейсом DMZ брандмауэра Netscreen и внутренним интерфейсом брандмауэра ISA. Затем, брандмауэр ISA пересылает соединения в интернет, а ответы возвращаются тем же самым путем.

Для того, чтобы это заработало, существуют некоторые основные требования и ограничения:

  • Во всех случаях брандмауэр ISA должен быть членом домена. Это лучшая рекомендация для всех случаев, когда требуется контроль доступа входящего и исходящего трафика
  • Клиентские системы в сети дочерних офисов должны быть членами того же домена Active Directory, что и брандмауэр ISA
  • IP адреса, используемые в дочерних офисах должны быть включены в описание внутренней сети для брандмауэра ISA
  • Клиенты SecureNAT брандмауэра ISA не поддерживаются
  • Во всех сценария, обсуждаемых в этой статье (за исключением того, который показан на рисунке 7), все прямые соединения посылаются на Netscreen. Вся безопасность, применяемая к прямым соединениям (Direct Access) ограничена возможностями Netscreen.

    Параллельная конфигурация

    Рисунок 8

Резюме

В этой статье я сфокусировался на проблеме, которую Кен озвучил на доске сообщений ISAserver.org. У Кена существовали VPN соединения между двумя устройствами Netscreen, а он хотел использовать мощные возможности по контролю доступа брандмауэра ISA, а также возможности брандмауэра ISA для поддержки правил публикации для входящего доступа к ресурсам Microsoft Exchange Server. Т.к. существует большое количество решений этой проблемы, я пришел к выводу, что лучшее из них, это использование преимуществ DMZ интерфейса его Netscreen. Эта конфигурация удовлетворяет всем его требованиям, а также оставляет возможность для использования преимуществ брандмауэра ISA для обеспечения безопасности в главном и дочерних офисах.

www.isaserver.org


Смотрите также:

Tags: , , , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]