 |
|
|
|
Настраиваем удаленный доступ к сети с помощью MS ISA 2004
Настраиваем удаленный доступ к сети с помощью MS ISA 2004 Возможность доступа к необходимым бизнес-ресурсам из любой точки мира – одно из условий успешной работы компании. Но это не должно быть в ущерб безопасности. Рассмотрим реализацию технологий удаленного доступа с помощью MS ISA 2004. Ставим задачу В предыдущей статье [1] мы разобрались с основными моментами развертывания межсетевого экрана ISA Server 2004 при подключении к Интернету, предоставили доступ в Интернет из локальной сети. Теперь настало время организовать удаленный доступ к локальным ресурсам. Предположим, у нас есть некоторое веб-приложение, например, система заказов on-line. Нужно организовать защищенный доступ к этому ресурсу с помощью SSL. Также сотрудники компании ездят в командировку и иногда работают из дома, поэтому им необходимо предоставить доступ по VPN. А еще у компании есть филиал, сотрудникам которого также требуется доступ в локальную сеть центрального офиса. Приступим к решению всех этих задач. Защищаем веб-трафик Итак, нам необходимо организовать защищенный доступ к веб-ресурсам сети. В отличие от публикации обычных веб-ресурсов, не использующих SSL, здесь существует ряд характерных особенностей, о которых читайте дальше. Можно публиковать защищенные веб-серверы, используя правила публикации веб-серверов по протоколу SSL. Публикация защищенных серверов требует немного больше предварительной работы, поскольку нужно получить сертификат веб-сайта для публикуемого ресурса, связать этот сертификат с сайтом на опубликованном веб-сервере и затем связать этот сертификат с сервером ISA, чтобы последний мог выдать себя за этот веб-сервер. Это позволяет ISA обеспечивать высокую степень защиты для веб-сайтов, опубликованных с помощью правил публикации ресурсов по протоколу SSL. Далее мы обсудим следующие моменты:
Начнем с сопряжения протокола SSL – это свойство ISA, позволяющее ему выполнять на прикладном уровне проверку состояния SSL-соединений. Дело в том, что традиционные межсетевые экраны с отслеживающей соединения фильтрацией (например, аппаратные решения) не могут выполнять проверку прикладного уровня SSL-соединений, проходящих через них. Межсетевой экран ISA поддерживает два метода SSL-сопряжения:
Сопряжение SSL-c-SSL обеспечивает защищенное SSL-соединение от начала до конца. Сопряжение SSL c HTTP гарантирует защищенное соединение между веб-клиентом и экраном ISA, а затем разрешает пересылку открытого текста между ISA и опубликованным веб-сервером. Основы сертификации Зачастую, упоминания центров сертификации (ЦС) (Certificate Authorities) и инфраструктуры открытого ключа (PKI, Public Key Infrastructure) достаточно, чтобы многие администраторы отказались даже от обсуждения SSL-протокола. Причиной этому является то, что многие системные администраторы плохо знакомы с этими технологиями и предпочитают обходиться без них. Однако на самом деле все не так уж и сложно. Служба Сertificate Server входит в состав Microsoft Windows Server 2003, и при необходимости ее всегда можно установить. При установке Microsoft Certificate Server (Сервер сертификации Microsoft) может быть выбрана одна из четырех ролей:
Корневой и подчиненный центры сертификации предприятия могут быть установлены только на серверах-членах службы каталогов Active Directory. В контексте статьи предполагается, что мы используем Active Directory, и соответственно можем использовать Enterprise CA, поэтому применение Standalone CA далее не рассматривается. Если вы не знакомы со средствами администрирования центров сертификации, описание процесса выписки и создания сертификата вы можете найти в источниках [2, 3]. Импорт сертификатов веб-сайтов в хранилище сертификатов на сервере ISA Межсетевой экран ISA должен быть способен выдать себя за опубликованный веб-сервер и идентифицировать себя на удаленном клиенте как опубликованный сервер. Другими словами, ISA становится посредником при создании защищенного соединения между удаленным клиентом и веб-сервером. Ключевым компонентом такой имитации служит полное доменное имя (FQDN) веб-сайта, на который выписывается сертификат. Для выполнения этой задачи нужно установить сертификат веб-сайта на сервере ISA. Первый шаг – экспорт сертификата с сайта защищенного веб-сервера. [3] Когда экспортируете сертификат, убедитесь, что включен приватный ключ. Одна из самых распространенных причин отказа в работе правил публикации веб-серверов – экспорт сертификата веб-сайта без его приватного ключа. Затем сертификат веб-сайта импортируется в хранилище сертификатов на сервере ISA. Сразу после импортирования сертификата веб-сайта в это хранилище сертификатов он становится доступным для связывания с веб-приемником. Необходимо помнить, что, если нельзя связать сертификат с веб-приемником, значит сертификат импортирован некорректно. Запрос сертификата пользователя После импорта сертификата необходимо сконфигурировать межсетевой экран для представления сертификата пользователям веб-сайта, которые этого требуют. В нашем случае именно такой сайт. Для того чтобы сконфигурировать межсетевой экран для представления сертификата пользователям, необходимо сначала запросить сертификат для учетной записи сервиса Firewall. Так как нельзя воспользоваться оснасткой Certificates (Сертификаты) консоли ММС для запроса сертификата учетной записи, воспользуемся возможностью импортировать пользовательский сертификат, применяя веб-сайт регистрации. Чтобы запросить сертификат для брандмауэра ISA с веб-сайта регистрации, мы должны сначала создать учетную запись пользователя для сервера ISA. Создайте учетную запись пользователя с именем isafirewall в службе каталогов Active Directory до выполнения следующих процедур. Далее необходимо выполнить следующие шаги, чтобы запросить сертификат для учетной записи сервиса Firewall. Для этого откройте консоль администрирования ISA, на вкладке «Tasks» выберите «Show System Policy Rules». В списке «System Policy Rules» щелкните правой кнопкой мыши «Allow all HTTP traffic from ISA Server to all networks (for CRL downloads)» и левой кнопкой мыши команду «Edit System Policy». Тем самым мы разрешили весь HTTP-трафик от брандмауэра ISA ко всем сетям, для загрузок списков сертификатов пользователей. Нажмем кнопку «Apply» для сохранения изменений и обновления политики брандмауэра. Затем применим новую конфигурацию, нажав «Apply New Configuration» (рис. 1).
Рисунок 1. Редактирование системных политик Мы сконфигурировали межсетевой экран для предоставления сертификата пользователя. Теперь необходимо получить сертификат. Для этого откройте браузер на сервере ISA и введите http://<certificateserver>/certsrv, где certificateserver – имя или IP-адрес ЦС предприятия в корпоративной сети. В диалоговом окне «Connect to» введите верительные данные учетной записи isafirewall и щелкните мышью кнопку «ОК». Далее на странице «Welcome» щелкните кнопкой мыши на ссылку «Request a certificate». Затем выбираем «User Certificate». Устанавливаем сертификат, нажав «Install this certificate» (рис. 2).
Рисунок 2. Редактирование системных политик После установки сертификат необходимо экспортировать, для этого в разделе браузера «Internet options» зайдите на вкладку «Content», далее «Certificates». Выбрав isafirewall, нажмите кнопку «Export». Экспорт необходимо осуществлять вместе с секретным ключом, указав «Export Private Key». После этого, указав пароль для файла сертификата, мы получаем необходимый файл. Обратите внимание: полученный файл нужно хранить в безопасном месте, так как он может быть использован для получения несанкционированного доступа к ресурсам сети. Наконец, приступаем к завершающему этапу подготовки к публикации веб-ресурса по протоколу SSL, импортируем сертификат в учетную запись сервиса Firewall. Для этого откройте новую консоль MMC, выберите в меню «File» опцию «Addr/Remove Snap-in», далее оснастка Certificates. После подключения оснастки выбирайте параметр «Services account». Затем – сервис Microsoft Firewall из списка Service account. Теперь сертификат связан с учетной записью сервиса Firewall. Возможно, возникнет необходимость блокировать правило системной политики, созданное нами ранее, чтобы нечаянно не воспользоваться обозревателем на межсетевом экране ISA. Создание правила публикации веб-сервера по протоколу SSL Итак, утомительные манипуляции с установкой сертификатов завершены, теперь можно создать правило публикации веб-сервера, защищенного протоколом SSL. Делается это следующим образом. В консоли администрирования откройте узел Firewall Policy, затем выберите вкладку «Tasks», далее «Publish a Secure Web Server» (опубликовать защищенный веб-сервер). После этого вам предстоит ответить на вопросы мастера установки. Здесь почти все действия аналогичны публикации веб-ресурса без использования SSL, описанного в [1]. Какие отличия? На странице Publishing Mode есть два переключателя: SSL Bridging и SSL Tunneling (рис. 3).
Рисунок 3. Публикация защищенного веб-ресурса Сопряжение (bridging), которое в некоторых источниках именуется SSL-проксированием, более безопасное, так как обеспечивает защищенное от начала до конца (end-to-end) шифрованное соединение, в то же время, разрешая ISA выполнять как отслеживающую состояние соединений фильтрацию (аналогично традиционным межсетевым экранам), так и отслеживающую состояние соединения проверку на уровне приложений. То есть полученный пакет сначала расшифровывается, затем проверяется на уровне приложений и потом снова зашифровывается и отправляется на хост-получатель. Такая проверка позволяет на уровне приложений просмотреть содержимое каждого пакета и удостовериться в том, что он не содержит неавторизованных подключений. Поэтому для решения нашей задачи необходимо выбрать именно этот режим публикации. Что же касается SSL-туннелирования, то в этом режиме ISA не может осуществлять контроль за проходящим через него контентом. Поэтому старайтесь не использовать тунеллирование до тех пор, пока не потребуется опубликовать приложения, не совместимые с веб-прокси HTTP 1.1. Подробнее о SSL-bridging и SSL-tunneling можно прочесть в статье [4]. На странице Bridging Mode (режим сопряжения) есть три переключателя:
Вариант Secure connection to clients устанавливает соединение как сопряжение SSL c HTTP. Он защищает соединение веб-клиента с ISA, но разрешает передачу незащищенного открытого текста между экраном и опубликованным веб-сервером. Вариант Secure connection to Web server позволит выполнить сопряжение HTTP c SSL. Соединение между веб-клиентом и межсетевым экраном устанавливается по протоколу HTTP, а соединение между сервером ISA и веб-сервером – по протоколу SSL. Вариант Secure connection to clients and Web server наиболее защищенный и предпочтительный. Он разрешает сопряжение SSL c SSL, в котором и соединение веб-клиента с ISA, и соединение между ISA и опубликованным веб-сервером защищаются протоколом SSL. В нашем случае наиболее предпочтительным будет третий вариант. После завершения работы мастера остается только применить изменения, и веб-ресурс будет опубликован через защищенное соединение. Основы VPN Теперь приступим к организации удаленного доступа к ресурсам локальной сети с помощью VPN. Одно из главных преимуществ применения VPN-соединения по сравнению с клиент-серверным веб-приложением заключается в том, что VPN-пользователи, находящиеся далеко от локальной сети, могут получить доступ ко всем ресурсам корпоративной сети. Программное обеспечение VPN-клиента встроено во все современные операционные системы Windows. VPN-пользователю не нужны никакие специальные программные средства для подключения к любому из этих сервисов и нет необходимости создавать специальные приложения прокси, разрешающие вашим пользователям подсоединяться к этим ресурсам. Существует два вида VPN-соединений: клиент-сервер и узел-узел. Первый вариант позволяет подключать удаленную рабочую станцию к сети с помощью защищенного соединения. Второй вариант позволяет соединять сети через защищенный туннель. Перед настройкой… Я опишу настройку обоих вариантов использования VPN. Но перед тем как начать описание настройки, необходимо обсудить несколько вопросов. Прежде всего нужно постоянно помнить о том, что удаленный доступ всегда является наиболее уязвимым в защите корпоративной сети от внешних вторжений. Поэтому надо ограничивать доступ пользователей, подключенных через VPN к локальной сети, предоставляя только необходимые для работы сервисы. В частности, для соединений клиент-сервер, если пользователь, удаленно подключившийся к локальной сети, является, к примеру, сотрудником бухгалтерии, то ему должен быть доступен только сервер бухгалтерии, если менеджер, то только сервер отдела продаж и так далее. Аналогично и для соединений узел-узел, филиалам и удаленным офисам должны быть доступны только те ресурсы, которые им необходимы в работе, не более. Выбор протокола Следующий аспект – это протокол, используемый для VPN-соединения. Для соединения узел-узел можно использовать PPTP и L2TP/IPSEC, но большинство разработанных сторонними фирмами VPN-шлюзов не поддерживают протоколы PPTP и L2TP/IPSec для межшлюзовых VPN-каналов. Вместо этого они требуют применения туннельного режима протокола IPSec для VPN-соединения. Межсетевой экран ISA 2004 в отличие от предыдущей версии ISA 2000 поддерживает туннельный режим протокола IPSec, таким образом позволяя создавать VPN-соединения узел-узел между VPN-шлюзом ISA и шлюзом стороннего производителя. Кроме того, что вы можете применять протокол РРТР или протокол L2TP/IPSec с высоким уровнем защиты для создания каналов типа узел в узел между двумя ISA Server/VPN-шлюзами, также ISA 2004 позволяет использовать плохо защищенное соединение с применением туннельного режима протокола IPSec для подключения к VPN-шлюзам сторонних фирм. Тут необходимо сделать небольшую оговорку, туннельный режим протокола IPSec поддерживается только для VPN-соединений конфигурации узел-узел. Клиент-серверные VPN-соединения удаленного доступа, тем не менее, используют только протоколы РРТР или L2TP/IPSec. Туннельный режим протокола IPSec уязвим для нескольких хорошо известных атак, а протокол L2TP/IPSec требует более строгой аутентификации и не подвержен этим атакам. Таким образом, если есть выбор, гораздо лучше применять набор протоколов L2TP/IPSec для VPN-соединений конфигурации узел в узел. Аутентификация Еще один аспект, также связанный с безопасностью, это аутентификация, используемая в VPN-соединениях. В межсетевом экране ISA Server 2004, когда создаются VPN-соединения удаленного доступа и межшлюзовые VPN-соединения, можно использовать секретные ключи (pre-shared keys) для аутентификации. Все машины VPN-клиентов, на которых выполняется обновленное программное обеспечение VPN-клиента для протокола L2TP/IPSec, могут использовать секретный ключ для создания соединения удаленного доступа VPN-клиента по протоколу L2TP/IPSec с ISA 2004/VPN-сервером. VPN-шлюзы ОС Windows 2000 и Windows Server 2003 также можно настроить для применения секретного ключа и установки соединений узел в узел. Секретные ключи являются популярным средством аутентификации. Их преимущество – простота первоначальной настройки, так как достаточно лишь распространить ключ между участниками соединения. Однако имеется и ряд недостатков. Например, при использовании в соединениях клиент-сервер, в случае изменения ключа на сервере, необходимо будет вручную внести изменения на всех клиентах, в противном случае установка соединения будет невозможна. Другим средством аутентификации является использование инфраструктуры открытого ключа PKI (Public Key Infrastructure). Технология использует сертификаты, о которых уже шла речь в первой части этой статьи [1], поэтому в примерах настроек, приведенных далее, не будем рассматривать использование PKI. Подробнее об этом способе вы можете прочитать в [5]. Другим возможным вариантом реализации VPN является использование протокола PPTP, для которого не требуется ни PKI, ни pre-shared key. Об этом методе и пойдет речь далее. Приступая к реализации, прежде всего определимся с вариантами развертывания VPN. Будем организовывать сначала доступ по VPN в локальную сеть организации для удаленных клиентов, а затем реализуем соединение узел-узел для филиала компании. Клиент-сервер Первым делом при организации VPN-подключения клиентов необходимо в консоли администрирования ISA выбрать меню «Tasks» (задачи) и затем «Enable VPN Client Access». Затем необходимо применить изменения, нажав «Apply New Configuration». Настройка VPN-сервера На вкладке «Tasks» выбираем «Configure VPN Client Access», далее на вкладке «General» в диалоговом окне «VPN Clients Properties» измените значение параметра «Maximum number of VPN clients allowed» с 5 на 10 (рис. 4).
Рисунок 4. Разрешаем доступ клиентам по VPN Версия Standard Edition брандмауэра ISA поддерживает до 1000 параллельных VPN-соединений. Далее добавляем группы, выбрав вкладку «Group» и нажав кнопку «Add». В диалоговом окне «Select Groups» нажимаем кнопку «Locations», указываем домен, потом нужно указать группу пользователей, которым будет разрешен удаленный доступ. В общем случае это может быть группа Domain Users. Обращаю ваше внимание на то, что сервер ISA должен быть членом домена. Если он не находится в домене, то для подтверждения подлинности можно использовать RADIUS-аутентификацию или локальные группы пользователей. На вкладке «Protocols» устанавливаем «Enable РРТР». Тем самым соединение будет осуществляться с помощью PPTP. Затем включаем «User Mapping» и флажок «When username does not contain a domain, use this domain», указав имя домена. Эта опция полезна в случаях, когда было введено только имя пользователя, без домена. Далее необходимо применить изменения. Теперь на вкладке «Tasks» щелкните кнопкой мыши строку «Select Access Networks». В диалоговом окне «Virtual Private Networks (VPN) Properties» выберите вкладку «Access Networks». Обратите внимание на то, что установлен флажок «External» (внешняя). Это означает, что внешний интерфейс ожидает входящие соединения от VPN-клиентов. Настройка IP-адресации Это важный шаг, в случае неверной настройки проблемы с доступом для VPN-клиентов обеспечены. Выбираем вкладку «Address Assignment», в раскрывающемся списке указываем «Use the following network to obtain DHCP, DNS and WINS services» элемент «Internal». Затем выбираем вкладку «Authentication» (аутентификация) Должен быть установлен только флажок «Microsoft encrypted authentication version 2 (MS-CHAPv2)». Необходимо применить настройки, нажав «Apply», и перегрузить сервер ISA. После перезагрузки ISA получит блок IP-адресов от DHCP-сервера во внутренней сети. Доступ для VPN-клиентов Создается как стандартное правило доступа, где в качестве исходящих протоколов указываются All Outbound protocols, а в качестве источника в правиле доступа – VPN Clients. Настройка доступа по VPN на клиентской машине производится с помощью стандартного мастера Windows. Узел-узел Итак, мы организовали доступ удаленным сотрудникам, и теперь осталось предоставить доступ к ресурсам локальной сети удаленному офису. Для этого мы воспользуемся соединением с использованием PPTP (Point-to-Point Tunneling Protocol). Шаг 1. Сконфигурируйте межсетевой экран ISA в центральном офисе Для этого в консоли администрирования ISA 2004 открываем раздел «Virtual Private Networks», в закладке «Tasks -> Add Remote Site Network». Далее с помощью мастера создания новой сети указываем настройки удаленной сети. Обращаю ваше внимание на то, что имя, данное при настройке мастера, затем будет использоваться для соединения по требованию. На странице «VPN» выбираем протокол PPTP. Далее на странице «Remote Site Gateway» укажите IP-адрес удаленного межсетевого экрана, также вы можете использовать полное доменное имя FQDN. Затем разрешим из локальной сети инициировать соединения с удаленным офисом «Local site can initiate connections to remote site using these credentials» и укажем учетную запись, которая будет использоваться для аутентификации на удаленном межсетевом экране. В завершение настройки укажите диапазон IP-адресов, которые используются в удаленной сети. Шаг 2. Создайте сетевое правило в центральном офисе В административной консоли открываем узел «Confiuration -> Networks». На панели «Details» выбираем вкладку «Tasks». Далее создаем новое сетевое правило. Затем с помощью мастера производим стандартные настройки, при этом в качестве сети назначения указываем сеть удаленного офиса. На странице «Network Relationship» выбираем вариант «Route». Правило создано.
Рисунок 5. Создаем сеть «узел-узел» Шаг 3. Создайте правила доступа в центральном офисе Запускаем в разделе Firewall policy мастер создания нового правила доступа. Далее стандартный процесс создания правила, в качестве сети назначения также указываем удаленный офис. После завершения работы мастера необходимо предоставить доступ VPN-клиентам. Для этого в закладке «VPN-Clients» указываем «Enable VPN Client Access». Шаг 4. Создайте в центральном офисе учетную запись VPN-шлюз Для этого необходимо, чтобы у учетной записи пользователя было то же имя, что и у интерфейса вызова по требованию. То есть необходимо создать локальную учетную запись на сервере ISA, имя которой будет совпадать с именем интерфейса. В свойствах этой учетной записи нужно разрешить доступ Dial-In. Шаг 5. Сконфигурируйте межсетевой экран ISA в филиале Для этого необходимо повторить те же шаги, что и для центрального офиса, с той лишь разницей, что начинать надо с создания сети удаленного офиса на брандмауэре филиала. Шаг 6. Создайте сетевое правило в филиале Здесь действия будут аналогичны произведенным при настройке правил для центрального офиса, только сеть-источник и сеть-назначения меняются местами. Шаг 7. Создайте правила доступа в филиале Это правило также аналогично созданному ранее для центрального офиса. Шаг 8. Создайте в филиале учетную запись VPN-шлюза Прежде всего создаем учетную запись пользователя, которую VPN-шлюз центрального офиса сможет использовать для аутентификации при установке соединения. Имя также должно совпадать с именем интерфейса. Шаг 9. Активизируйте каналы типа узел в узел Для активизации соединения необходимо с рабочей станции, находящейся в удаленном офисе, попытаться пропинговать узел в сети главного офиса. Если соединение конфигурации узел в узел заканчивается неудачей, убедитесь, что вы правильно определили назначения допустимых IP-адресов для VPN-клиентов и шлюзов. Обычная причина сбоев VPN-соединений заключается в том, что серверы ISA не могут получить адрес от DHCP-сервера и нет адресов, отведенных для пула статических адресов. В этой ситуации ISA назначает VPN-клиентам и шлюзам IP-адреса в диапазоне автосети (APIPA, 169.254.0.0/16). Если обоим концам туннеля назначены адреса из этого диапазона, интерфейсы вызова по требованию обеих машин размещаются в одной и той же сети, что вызывает сбой в линии связи конфигурации узел в узел, так как при этом пакеты не могут определить маршрут к узлу назначения. Завершая разговор Итак, мы рассмотрели возможности межсетевого экрана ISA 2004, позволяющие обеспечить удаленный доступ к ресурсам локальной сети. Теперь вы можете обеспечить защищенный доступ по SSL к веб-ресурсам локальной сети, а также по VPN ко всем необходимым сетевым службам. Например, с помощью описанных в статье функций сервера ISA можно организовать удаленный доступ пользователей к почте через веб-интерфейс. А после создания доступа по VPN сотрудники филиалов смогут без лишних затрат времени работать с документами, находящимися в центральном офисе компании. В следующей статье вы узнаете о тонкой настройке различных компонентов ISA 2004, что позволит существенно оптимизировать работу межсетевого экрана и сети в целом.
|
Андрей Бирюков
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
