Сегодня VPN уже перестали быть принадлежностью исключительно крупных предприятий и широко применяются в компаниях любых размеров. Такую популярность им обеспечила предоставляемая мобильным сотрудникам возможность обращаться к ресурсам внутренней сети, недоступным для пользователей вне брандмауэра. Туннель VPN, проложенный через брандмауэр, фактически расширяет корпоративную сеть для удаленных пользователей. Однако у VPN есть один недостаток. Если не принять необходимых мер предосторожности, недобросовестные пользователи могут проникнуть через VPN в корпоративную сеть. Кроме того, VPN может стать лазейкой для "червя".
Всегда найдутся компании, в которых успешно применяются VPN, хотя многие предприятия могут обойтись и без них. В данной статье мы рассмотрим два сценария, в которых традиционно используются VPN (корпоративная электронная почта и внутренние Web-узлы), а затем будут представлены эффективные альтернативы.
Корпоративная электронная почта
Базой для применения VPN в настоящее время остается электронная почта. Как правило, удаленные пользователи звонят по специальному бесплатному номеру, предоставленному поставщиком VPN или Internet-провайдером, вводят специальные учетные данные, а затем подключаются к VPN-шлюзу, указывая обычные имя пользователя и пароль. После того, как соединение установлено, пользователи могут запустить почтового клиента (например, Microsoft Outlook) и обратиться к серверу электронной почты. Это довольно неуклюжий сценарий, но, к счастью, у него есть альтернативы.
RPC over HTTP. В Windows Server 2003, Windows XP Service Pack 1 (SP1) и более поздних версиях Exchange Server 2003 и Outlook 2003 реализована концепция удаленных вызовов процедур (Remote Procedure Call over HTTP - RPC over HTTP). RPC - базовый протокол, действующий между клиентами Exchange и Outlook. Прокладывая туннель RPC через брандмауэр HTTP-соединения, можно обращаться к серверам Exchange из-за брандмауэра. Пользователям по-прежнему необходимо подключаться к Internet, но эта задача не вызывает затруднений благодаря наличию широкополосных каналов связи в жилых домах, активных точек Wi-Fi в кафе, залах ожидания аэропортов и номерах гостиниц. Установив соединение с Internet, пользователи могут открыть Outlook 2003 и получить доступ к папке "Входящие" и другим папкам, как будто они работают в корпоративной сети или через VPN.
Существует много сценариев применения RPC over HTTP. Простейший способ, описанный в данной статье, предполагает, что имеется единственный сервер, член домена Exchange, который функционирует с Exchange 2003 SP1 или более поздней версией. Если имеется несколько серверов Exchange, либо один или несколько серверов Exchange являются одновременно контроллером домена, рекомендуется обратиться к статье Microsoft TechNet "Exchange Server 2003 RPC over HTTP Deployment Scenarios" (http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/ex2k3rpc.mspx).
На сервере Exchange следует открыть оснастку System Manager консоли Microsoft Management Console (MMC), выбрать сервер Exchange из узла Servers, щелкнуть на нем правой кнопкой мыши и выбрать пункт Properties из контекстного меню (Экран 1). Появится предупреждение, что внешние (front-end) серверы Exchange не настроены. В конфигурации с одним сервером это предупреждение можно игнорировать, поэтому следует убрать сообщение с экрана, щелкнув на кнопке OK. Щелкните на кнопке Apply, чтобы применить параметр, а затем закройте диалоговое окно Properties, нажав OK.
Если отсутствуют внешние серверы Exchange, функционирующие в качестве серверов-посредников RPC over HTTP, то необходимо дополнительно настроить сервер Exchange. Первый шаг - установить RPC over HTTP Proxy (для Windows 2003) на сервере Exchange. Для этого следует открыть утилиту Add or Remove Programs панели управления, щелкнуть на вкладке Add/Remove Windows Components, прокрутить вниз список компонентов до Networking Services, щелкнуть на кнопке Details, выбрать RPC over HTTP Proxy и последовательно нажать OK, Next и Finish.
Второй шаг - настроить методы проверки подлинности для RPC over HTTP Proxy. Чтобы запустить оснастку MMC IIS, следует щелкнуть Start, Administrative Tools, Internet Information Server (IIS) Manager. В оснастке нужно перейти к узлу Default Web Site, развернуть его, выбрать виртуальный каталог RPC и щелкнуть на нем правой кнопкой мыши. Выберите пункт Properties из контекстного меню. В диалоговом окне RPC Properties необходимо выбрать вкладку Directory Security и щелкнуть на кнопке Edit в разделе Authentication and access control. Убедитесь, что в диалоговом окне Authentication Methods сброшен флажок Enable anonymous access. В RPC over HTTP пользователи должны самостоятельно проходить проверку подлинности. Можно выбрать режим встроенной проверки подлинности Windows или режим Basic, либо оба этих метода. Предпочтительно применить Basic authentication for RPC over HTTP. В результате пароли и имена пользователя будут передаваться по сети открытым текстом, но зато трафик RPC over HTTP можно шифровать с использованием Secure Sockets Layer (SSL). Применение встроенной проверки подлинности Windows эффективно в некоторых сценариях, но может привести к неполадкам, которые с трудом поддаются диагностике. Если выбран метод Basic authentication, система выдает предупреждение. Следует щелкнуть на кнопке Yes, чтобы продолжить работу, а затем нажать OK, Apply и OK.
Третий этап - настройка портов для RPC over HTTP Proxy. На сервере Exchange следует запустить из командной строки команду Ipconfig/all и записать имя компьютера и имя домена. Затем нужно открыть редактор реестра и перейти в раздел HKEY_LOCAL_MACHINESOFTWAREMicrosoftRpcRpcProxy. Дважды щелкните на параметре и придайте ему вид
:6001-6002; . :6001-6002; :6004; . :6004;
где hostname и domainname - значения, записанные после выполнения команды Ipconfig/all. При этом возникает типичная опасность: редактирование реестра может лишить систему стабильности. Запишите старые значения всех параметров и будьте готовы применить их снова в случае необходимости.
Чтобы клиенты Outlook 2003 могли подключиться к серверам Exchange 2003 через RPC over HTTP, нужно внести в параметры клиента ряд изменений. В Outlook 2003 следует выбрать Tools из панели меню, а затем Email Accounts. Установите флажок View or change existing e-mail accounts, щелкните на кнопке Next, выберите учетную запись электронной почты типа Exchange, нажмите Change, а затем More Settings. В диалоговом окне Microsoft Exchange Server следует перейти на вкладку Connection, установить флажок Connect to my Exchange mailbox using HTTP и щелкнуть на кнопке Exchange Proxy Settings. В диалоговом окне Exchange Proxy Settings (Экран 2) нужно ввести URL-адрес для сервера-посредника Exchange и назначить параметры соединения. После того, как клиент и сервер настроены, обмен данными между Outlook 2003 и Exchange 2003 возможен без VPN.
OWA. Если нежелательно устанавливать RPC over HTTP, или сотрудники компании работают со старыми версиями Outlook, либо Windows 2000 и Exchange 2000, пользователи все же могут дистанционно обращаться к электронной точке через Outlook Web Access. Чрезвычайно удобный метод OWA обеспечивает доступ к почтовому ящику "Входящие" и оперативным папкам пользователей из простого браузера. Чтобы обратиться к OWA из браузера, пользователю достаточно ввести имя сервера Exchange с добавлением /exchange (например, https://mail.contoso.com/exchange).
Чтобы обеспечить доступ к электронной почте через OWA из-за брандмауэра, необходимо опубликовать сервер Exchange (то есть сделать его доступным для пользователей Internet). Проще всего для этого задействовать ISA Server 2006 или аналогичный брандмауэр прикладного уровня, который обеспечивает анализ трафика OWA в поисках опасности. Опубликовать узлы OWA не составит труда, если использовать мастера, которые есть в составе ISA Server. Вместе с OWA рекомендуется всегда применять SSL-сертификаты, чтобы обеспечить конфиденциальность электронной почты, передаваемой между сервером Exchange и браузерами пользователей. Также желательно отключить блокировку учетных записей. Если блокировка учетных записей запрещена, злоумышленник может предпринять атаку с отказом в обслуживании (DoS) против любого пользователя, имя которого ему известно.
И, наконец, чтобы свести к минимуму обращения в справочную службу, полезно настроить брандмауэр на перенаправление всего трафика, поступающего по адресу FQDN OWA-сервера, в виртуальный каталог exchange на сервере Exchange. В результате пользователи не будут забывать добавлять /exchange в URL-адрес, вводимый в браузер. Кроме того, рекомендуется направлять всех пользователей, которые забывают ввести https:// или вводят просто http://, на SSL-защищенный узел.
Внутренние Web-узлы
Многие предприятия строят Web-узлы intranet, чтобы обмениваться данными (например, о датах отпуска, внутренних телефонных каталогах) между членами группы или для использования в качестве внутренних справочных сайтов для документирования политик, публикации цен на продукты и услуги и т.д. Часто такие Web-узлы открыты для всех пользователей и располагают минимальными мерами безопасности или не защищены вовсе. Неограниченный доступ вполне приемлем для Web-узлов, доступных только из локальной сети, но явно непозволительно публиковать такие сайты в Internet, не приняв меры по управлению доступом, особенно если данные относятся к разряду конфиденциальных или служебных. В таком случае предприятия могут задействовать VPN. Пользователи должны подтвердить свои права, чтобы установить VPN-соединение. После они становятся доверенными и получают анонимный доступ к внутренним Web-узлам. Однако существуют и альтернативные решения.
Если Web-узлы размещены на Web-серверах IIS 6.0, которые являются членами того же домена или леса, что и пользователи, администратор Web-сервера может отключить анонимный доступ и потребовать, чтобы пользователи прошли проверку подлинности. Если на Web-узле используется метод встроенной проверки подлинности Windows, то Web-узел можно опубликовать в Internet через брандмауэр. Если брандмауэр относится к прикладному уровню (например, ISA Server 2006), то правила доступа можно настроить таким образом, чтобы открыть для доступа из Internet лишь определенные части или каталоги Web-узла, и анализировать HTTP-трафик в поисках опасного содержимого. Пользователь, который пытается подключиться к Web-узлу, должен ввести свои учетные данные.
Рекомендуется применять SSL-сертификаты, чтобы обеспечить конфиденциальность данных, пересылаемых между Web-узлом и браузером пользователя. ISA Server может завершить SSL-сеанс в брандмауэре, а затем обеспечить посредничество при подключении к Web-узлу. SSL-сертификат для Web-узла устанавливается в ISA Server, который представляет Web-узел в браузере пользователя. Такая удобная конфигурация позволяет ISA Server анализировать трафик Web-узла, установить ограничения для доступа на основе путей и отыскивать опасный контент.
Разместив SSL-сертификат, можно назначить проверку подлинности Basic для Web-узлов. Использовать SSL-сертификаты в режиме Basic необязательно, но их рекомендуется применить, потому что учетные данные пользователей будут пересылаться открытым текстом между браузером и Web-узлом. Режим Basic полезен, так как позволяет подключаться к Web-узлам пользователям клиентов, отличных от Windows, или браузеров, отличных от Microsoft Internet Explorer (IE). Недостаток проверки подлинности Basic заключается в том, что если SSL-соединение заканчивается в брандмауэре, то соединение между брандмауэром и Web-узлом во внутренней сети не шифруется. В результате злоумышленник с сетевым монитором (или даже внутри компании) сможет перехватить учетные данные, если брандмауэр не установит SSL-соединение с Web-узлом.
Одна из трудностей, которые возникают, когда необходимо настроить Web-узел на проверку подлинности, заключается в том, что приходится постоянно запрашивать имена и пароли пользователей. Если Web-узел настроен на использование встроенной проверки подлинности Windows, а пользователи работают с IE, можно настроить IE на пересылку учетных данных пользователей при каждом HTTP-соединении. По умолчанию такая конфигурация действует для узлов в зоне локальной интрасети (Экран 3). Достаточно добавить общедоступный URL-адрес каждого опубликованного Web-узла в зону локальной сети в браузере IE пользователей. Может показаться, что данный сценарий таит угрозу безопасности, но в действительности это не так: как и при встроенной проверке подлинности Windows, используются NTLM-хэши, и между браузером и Web-узлом не происходит обмена учетными данными в чисто текстовом формате. Если существует опасение, что NTLM-хэш, пересылаемый по сети при попытке установить HTTP-соединение, может быть применен для перехвата пароля пользователя, можно защитить NTLM-хэш с помощью SSL.
Если SSL-соединение завершается не в брандмауэре, а в самом Web-узле, то можно настроить Web-узел на проверку подлинности пользователей с применением клиентского сертификата транспортного уровня безопасности (TLS). В этом случае пользователь должен иметь сертификат X.509v3, изданный Центром сертификации (CA), которому доверяет Web-узел. Этот сертификат может применяться для проверки подлинности клиента. При отсутствии инфраструктуры PKI, которая обеспечивает выдачу сертификатов пользователям, рекомендуется обратиться к собственным службам сертификации Microsoft в составе Windows 2003 и Windows 2000. Развернуть и использовать их чрезвычайно просто. Дополнительные сведения о применении Certificate Services для проверки подлинности клиентов можно найти в статье "Certificates and Exchange, Part 1" (InstantDoc ID 93440).
Сочетание SSL и TLS обеспечивает ряд преимуществ. Первое заключается в том, что пользователям не нужно вводить учетные данные, вместо них используется сертификат. Второе состоит в том, что большинство браузеров почти на каждой клиентской платформе поддерживает SSL с TLS. Третье - сертификаты обеспечивают проверку подлинности с использованием SSL/TLS для Web-серверов, отличных от IIS 6.0 (например, Apache). Четвертое - возможность сопоставлять сертификаты, изданные независимыми центрами CA, с учетными записями пользователей, что освобождает администратора от необходимости формировать и обслуживать инфраструктуру PKI. И, наконец, можно использовать сертификат в смарт-карте или миниатюрном устройстве памяти (например, Rainbow iKey), что позволит пользователям работать с любой машиной, не вводя учетных данных, которые могут быть перехвачены регистраторами нажатий на клавиши и другими шпионскими программами. (Для использования смарт-карты требуется компьютер с устройством чтения смарт-карт, а такие устройства, как iKey, просто подключаются к любому свободному USB-порту.)
Другие факторы
Отказываясь от VPN при публикации Web-узлов и сервера Exchange с использованием RPC over HTTP Proxy, следует учитывать еще несколько факторов. Во-первых, это привычка пользователей вставлять в сообщения электронной почты ссылки на Web-узлы, которые могут быть преобразованы, только если пользователь находится в корпоративной сети (например, https://hr, http://sales). Нельзя требовать от пользователей, чтобы они помнили полное имя Internet для Web-узлов intranet, особенно, если Web-узлов много.
Другая проблема заключается в том, что когда пользователи используют полное имя (FQDN) Internet в сообщениях электронной почты для ссылки на Web-узлы, URL-адреса не удается преобразовать в корпоративной сети из-за различных пространств имен DNS. Например, внутреннее пространство имен DNS может быть corp.contoso.com, а пространство имен Internet - просто contoso.com, и сайт может иметь в Internet имя sales.contoso.com, а в intranet - sales.corp.contoso.com.
С этой проблемой связана проблема использования в Web-узлах имен узлов для ссылки на другие Web-узлы. Если Web-узел опубликован в Internet и содержит ссылку с именем узла, а не полное имя, или внутреннее имя FQDN, которое нельзя преобразовать из Internet, то ссылка выглядит неверной. В ISA 2006 появилось решение для этих проблем. С помощью ISA 2006 можно динамически изменять ссылки и отказаться от VPN благодаря функциям, рассмотреть которые в данной статье мы не можем. В частности, из портала, который запрашивает у пользователей учетные данные, можно обращаться к внутренним Web-узлам через единую процедуру входа (Single Sign-On - SSO).
Уменьшение степени риска
VPN - полезное и гибкое средство для доступа удаленных и мобильных пользователей к корпоративным ресурсам, таким как электронная почта и Web-узлы intranet. Однако они могут представлять угрозу безопасности, потому что клиенты VPN получают неограниченный доступ. Описанные в данной статье решения могут оказаться более подходящими для удаленных и мобильных пользователей, так как обеспечивают полный, безопасный доступ к необходимым деловым ресурсам и уменьшают степень риска для предприятия.
Джон Хоуи (jhowie@microsoft.com) - директор подразделения World Wide Services and IT Technical Community for Security в компании Microsoft. Имеет более чем 15-летний опыт работы в области информационной безопасности и сертификаты CISSP, CISM и CISA.