Network World

Принять участие в тестировании были приглашены все известные поставщики продуктов для построения сетей VPN на базе протокола SSL, но некоторые производители и решения все же остались за рамками испытаний. Корпорация Cisco занята радикальной модернизацией своей довольно старой линейки VPN-устройств. Обновление ее аппаратной части состоялось летом 2004 года, вместе с выпуском модели ASA 5520, но модернизация ПО еще не завершена. Symantec сослалась на отсутствие свободных устройств, которые могут быть отданы на тестирование.

Нам очень хотелось опробовать SSL-Explorer, основанный на открытом коде. Однако ограничения по срокам, значительные временные затраты на поддержку продукта с открытым кодом и большое число участников проекта вынудили нас отказаться от этой затеи.

Приглашения были отправлены также компаниям Citrix, Watchguard и Permeo (в январе стало известно, что последнюю покупает Blue Coat Systems). Как оказалось, их разработки не поддерживают ряд функций, являющихся ключевыми для нашего тестирования. А значит, сопоставить их с остальными решениями не представляется возможным. Итак, в испытаниях участвовали устройства 11 производителей: AEP, Array, Aventail, Caymas, Check Point, F5, Fortinet, Juniper, Nokia, Nortel и SonicWall.

Взаимодействие на уровне приложений

Достижение взаимодействия на уровне приложений и клиентов — одна из сложнейших задач развертывания сети SSL VPN. Результаты более 1400 раундов тестирования выявили заметный прогресс в решении проблем экспорта приложений по удаленным соединениям разных типов.

Поскольку классическая технология SSL VPN обеспечивает доступ пользователей к Web-приложениям, мы проверяли способность каждого из продуктов взаимодействовать с девятью такими приложениями. Лучшие результаты продемонстрировали продукты SA фирмы Juniper (50 из 65 тестов), Secure Access System корпорации Nokia (46), Netilla Security Platform компании AEP (45), EX-1500 производства Aventail (44) и Firepass от F5 (42). В самом конце списка оказались SPX Series компании Array (23 теста), SSL-VPN 2000 фирмы SonicWall (20). А устройство Fortigate-360 производства Fortinet не прошло ни одного теста — несмотря на героические усилия инженеров компании.

Проблемы в области взаимодействия практически всегда вызваны ошибками перекодировщика SSL VPN, который модифицирует потоки данных на HTML, Java, JavaScript или Flash, поступающие в браузер.

Большинство поставщиков продуктов SSL VPN предлагают свои варианты обхода ошибок перекодировщика. Широко распространенным методом является загрузка на локальный компьютер небольшого приложения, которое должно восприниматься Web-браузером в качестве proxy-сервера. Указанное приложение туннелирует трафик обратно на шлюз SSL VPN, не требуя перекодировки. Чтобы оценить успешность реализации этой идеи, мы проверили, насколько эффективно каждый продукт справляется с терминальными службами Microsoft и Citrix, а также с трафиком SSH.

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

Не участвовавшие в тестировании фирмы Citrix и Permeo вообще отказались от использования перекодировщиков, поэтому их устройства требуют применения клиентов для доступа к приложениям.

Файловые сервисы. Общим требованием к устройствам SSL VPN является возможность просмотра файлов, хранящихся на сервере. Это предполагает базовое преобразование протоколов между файловыми сервисами на одной стороне защищенного соединения и Web-страницами — на другой.

Мы тестировали продукты с SMB- и FTP-серверами. Первый тест проще, и его прошли почти все устройства, за исключением разработок Fortinet и SonicWall. Правда, мы снизили баллы компаниям Array и Nortel, поскольку их решения оказались несовместимыми с клиентами Macintosh. Разочаровала нас и разработка Connectra фирмы Check Point. При работе в среде Windows с Internet Explorer этот продукт предлагает файл-браузер, который в точности воспроизводит интерфейс Windows Explorer, что следует признать несомненным успехом программистов. Однако если вы не пользуетесь программой Internet Explorer, то не только не увидите привычного интерфейса, но и вообще будете лишены какого-либо оконного интерфейса.

Испытания с FTP-серверами оказались малоинформативными: большинство поставщиков вообще не обеспечивают их поддержку. Исключения составляют продукты Nokia, Nortel и SonicWall.

На полпути от Web-браузера к полноценному клиенту расширения сети находятся технологии переадресации портов и приложений. Их использование основано на том, что большая часть приложений имеет простую архитектуру «клиент-сервер» и генерирует потоки TCP-пакетов. В результате для работы по сети SSL VPN не требуется полный сетевой доступ: достаточно туннеля, настроенного под конкретное приложение.

Испытания проводились с четырьмя клиент-серверными приложениями: Windows Terminal Services, Citrix Presentation Server, Telnet и SSH. Поскольку поставщики выработали множество стратегий работы с этими приложениями, мы предоставили им свободу выбора, вместо того чтобы настаивать на непременном использовании переадресации портов. В результате нам пришлось иметь дело с несколькими Java-апплетами, специальными клиентами для Terminal Services и Presentation Server и даже с приемами, которые больше смахивали на искусство черной магии.

Явным победителем стал продукт Netilla Security Platform фирмы AEP (24 балла из 28 возможных). За ним с небольшим отрывом последовали разработки Nokia (23), Juniper (22) и Check Point (20). Наихудшие результаты продемонстрировали устройства Fortinet (6) и SonicWall (3).

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

Истинное туннелирование. Средство расширения сети, или формирования полноценного туннеля третьего уровня, сегодня рассматривается в качестве базового компонента любого продукта SSL VPN. Сетевые менеджеры применяют данную технологию, чтобы не возиться с описанием каждого приложения, востребованного пользователями VPN-сети. Кроме того, к таким приложениям, как VoIP, технология переадресации портов вообще неприменима.

С помощью SIP-телефонов мы изучали функционирование туннелей третьего уровня для различных клиентских платформ (Windows 2000, Windows XP и Macintosh). Результат можно сформулировать так: функционирование туннелей оставляет желать лучшего, если только вы не являетесь администратором. Чтобы предоставить удаленным пользователям доступ к приложениям путем расширения сети, вам придется либо заранее инсталлировать на их ноутбуках клиентское ПО, либо обеспечить им стопроцентный контроль над вычислительными системами.

К нашему удивлению, клиент фирмы Fortinet успешно взаимодействовал с несколькими приложениями под управлением Windows XP, но отказался работать с протоколом SIP несмотря на крайне лояльные настройки брандмауэра. А компании SonicWall и Caymas явно недолюбливают пользователей Firefox и требуют для инсталляции своих клиентов работы с Internet Explorer. Что касается остальных продуктов, после установки клиентского ПО работа с приложениями VoIP через SSL-туннель шла, как по маслу.

Взаимодействие с приложениями

Масштабируемость и высокая готовность

Мы рассматривали несколько функций обеспечения масштабируемости и готовности. В первом случае речь идет о поддержке конфигураций активный/пассивный (больше известной как ведущий/ведомый) и активный/активный. Во втором — о средствах выравнивания нагрузки, обычно внешних. Продукты, требующие применения таких средств, обычно поддерживают масштабируемость путем разделяемого доступа к параметрам конфигурации.

Идея высокой готовности на удивление проста: сервис должен функционировать при сбое какого-либо компонента, прежде всего самого шлюза SSL VPN. Зато реализация этой идеи сопряжена с рядом проблем. Одна из них — тиражирование значений конфигурационных параметров: любое изменение конфигурации одного устройства должно быть оперативно разослано всем остальным устройствам.

Высокая готовность нередко обеспечивается при помощи виртуального IP-адреса, соответствующего сервису высокой готовности. Такой адрес приписывается паре устройств VPN-сети. Одно из них (активное, или ведущее) отвечает за весь трафик, поступающий на этот адрес, а другое (пассивное, или ведомое) берет на себя функции ведущего устройства при отказе последнего. В случае сбоя передать виртуальный IP-адрес новому узлу не составляет труда, как, впрочем, и синхронизовать параметры конфигурации между двумя устройствами. Проблема — лишь в том, что обработка отказа должна выполняться незаметно для конечного пользователя. А это заставляет поддерживать текущее состояние пользовательских сеансов при сбое одного из устройств.

В сетях SSL VPN такие сеансы бывают двух типов: основанные на Web-приложениях и связанные с расширением сети/переадресацией портов. При туннелировании Web-приложений существуют два типа данных о состоянии, имеющих отношение к обеспечению высокой готовности.

Первый — криптографический файл cookie, именуемый также идентификатором сеанса, который служит для повторной аутентификации браузера при обращении к новой Web-странице. Хакер, укравший такой идентификатор, на протяжении всего сеанса сможет выдавать себя за легального пользователя, чем и объясняется большая опасность межсайтовых сетевых атак для устройств SSL VPN.

Второй тип информации о состоянии — файлы cookie, являющиеся частью пользовательского сеанса. Они используются Web-сайтами, которые выполняют какие-либо действия с сеансо-ориентированными приложениями (например, при работе с электронной почтой через Web). Эти сведения хранятся непосредственно на устройствах SSL VPN и не отсылаются на компьютер конечного пользователя, чтобы они не достались новому потребителю и вообще не были задействованы не по назначению. Такая схема реализована только в наиболее защищенных VPN-решениях.

При возникновении события, угрожающего доступности вычислительных ресурсов, криптографические файлы cookie должны находиться на резервном устройстве SSL VPN. Сегодня эта возможность предусмотрена компаниями Aventail, Caymas, Fortinet, Juniper и Nokia. Работая с продуктами AEP, Array и Nortel, пользователь должен выполнить процедуру повторной аутентификации самостоятельно. Nortel обещает устранить этот изъян в версии 5.5 своего шлюза VPN Gateway 3070, который появится на рынке уже в январе.

Высокая готовность и расширение сети. Мы не останавливаемся подробно на стабильности TCP-соединений, поскольку она не играет особой роли в сетях SSL VPN на базе Web, но ее значение для технологий расширения сети и переадресации портов трудно переоценить. В данном случае нет нужды думать о файлах cookie, зато следует побеспокоиться о приложениях более высокого уровня. Скажем, если сеанс Terminal Services запущен через расширение сети SSL VPN, при закрытии сеанса соответствующее соединение может попросту исчезнуть.

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

Другой вариант — прозрачное восстановление соединения, основанное на использовании стека «IP поверх TCP». Протокол IP сам по себе не отличается надежностью, но расположенный ниже TCP способен восстановить разорванное соединение так, что сеансы и приложения, находящиеся выше IP, «заметят» лишь небольшую задержку или потерю нескольких пакетов. Другими словами, восстановление соединения при сбое устройства SSL VPN инициируется клиентом прозрачно для протоколов более высоких уровней.

Среди протестированных продуктов прозрачное восстановление соединения в расширенной сети поддерживают лишь разработки Aventail и Juniper. Нас разочаровало решение фирмы Array, требующее ручного тиражирования информации об изменениях конфигурации. А продукт компании Caymas обрабатывает обновления только в определенные моменты . Наша уверенность в том, что каждый производитель точно знает, как именно он обеспечивает высокую готовность, заметно пошатнулась. Как можно говорить о высокой готовности, если сведения об изменении конфигурации не рассылаются автоматически?

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

Масштабируемость тесно связана с высокой готовностью и означает доступность сервиса SSL VPN для большего числа пользователей и одновременных сеансов, чем при работе единичного устройства. Поставщики, реализовавшие схему «ведущий-ведомый», не гарантируют хорошей масштабируемости своих решений, поскольку в этой схеме половина устройств простаивает (находится в резерве).

Масштабируемость требует новой функции — выравнивания нагрузки. В своих продуктах ее предусмотрели лишь F5, Nokia и Aventail. (Интегрированное средство выравнивания имеется и в универсальном устройстве сетевой защиты производства Fortinet, но оно не работает в сетях SSL VPN.) Правда, решение Aventail может включать в себя лишь два сетевых узла, тогда как разработки F5 и Nokia свободны от этого ограничения. Так, F5 предлагает выделить одно устройство (это может быть пара «ведущий-ведомый») под выравнивание нагрузки, чтобы оно переадресовывало сеансы на другие устройства или пары устройств.

Во всех остальных случаях для распределения соединений между несколькими VPN-устройствами необходимо задействовать внешние средства выравнивания нагрузки. При этом в разработках Array, Juniper и Nortel предусмотрено автоматическое тиражирование параметров конфигурации в пределах кластера VPN-устройств, а AEP, Caymas, Check Point, Fortinet и SonicWall предлагают пользователям синхронизовать конфигурации вручную.

Безопасность оконечных устройств

Сети SSL VPN содержат встроенные средства защиты от вредоносного кода. Выступая в роли proxy-серверов, они блокируют прямой доступ пользователей в сеть, и наиболее серьезные угрозы становятся неактуальными. Это особенно важно в свете того, что средства защиты оконечных устройств в протестированном нами оборудовании спроектированы и реализованы очень плохо. Они оказываются работоспособными лишь в небольшом числе случаев.

Защиту оконечных устройств можно обеспечить несколькими способами. Компании вроде AEP и Array целиком полагаются на разработки фирмы Sygate (сегодня принадлежащей Symantec), в которых реализуется централизованная модель контроля над безопасностью. Основная идея на редкость бесхитростна: если вы уже используете продукты Sygate для каких-либо целей (скажем, в качестве персонального брандмауэра), они могут быть легко интегрированы в сеть SSL VPN. Производители типа Aventail интегрируют продукты третьих фирм в свои решения, предоставляя пользователям некоторую свободу выбора. Наконец, Caymas, Check Point, F5, Fortinet, Juniper, Nokia и Nortel в той или иной степени самостоятельно разрабатывают ПО для защиты оконечных устройств, иногда в комбинации с OEM-продуктами (например, инструментарием компании Opswat).

Мы выделяем два аспекта защиты оконечных устройств: проверка целостности (соответствие системы, подключающейся к сети, требованиям безопасности) и наличие защитных сервисов (средств очистки кэшей, виртуальных настольных ПК и др.). В ходе тестирования мы интересовались преимущественно первым аспектом. Продукты, по сути, должны были лишь удостовериться в наличии на пользовательском ПК под Windows современных антивирусных приложений и скорректировать политику безопасности (например, при отсутствии антивирусного ПО пользователям разрешался доступ только к определенным разделам нескольких Web-серверов).

Ни один продукт не прошел данный тест полностью. Устройства Array, Caymas, Check Point, F5, Juniper и Nortel не распознавали нашу корпоративную антивирусную программу Sophos, если Windows XP работала в режиме непривилегированного пользователя. А решения AEP и Fortinet продемонстрировали такой же результат даже при наличии прав администратора. Более того, даже распознав ПО Sophos, разработки Aventail, Caymas, Nokia и Nortel не смогли сообщить, насколько актуален имеющийся на компьютере пользователя файл вирусных сигнатур.

Некоторые продукты блокировали сетевой доступ безо всяких к тому оснований и выдавали ошибочную диагностику. По отношению к устройствам производства Array и Aventail причина этого крылась в их неспособности взаимодействовать с браузером Firefox. Наконец, лишь несколько устройств позволили нам прописать требуемую политику безопасности.

Компания SonicWall вообще не реализовала в своей разработке SSL-VPN 2000 функции проверки защищенности пользовательских компьютеров. Устройство Fortigate-3600 фирмы Fortinet позволяет активизировать политику безопасности только на клиенте расширения сети. При этом производитель предлагает богатый набор защитных сервисов, запускаемых на шлюзе, в том числе собственную антивирусную программу и средство предотвращения сетевых атак. Счастливыми исключениями из правила стали продукты Connectra корпорации Check Point, позволяющие выявлять угрозы на прикладном уровне, и Firepass фирмы F5 с собственным антивирусным ПО и ограниченными возможностями обнаружения угроз.

Анализ ситуации с защитой компьютеров пользователей стоит начать с определения политики безопасности, т.е. с описания процедуры проверки защищенности оконечных систем. В лучшем случае такую процедуру стоит запускать перед регистрацией пользователя, дабы выявить программы, фиксирующие последовательности нажатия клавиш. Соответствующую возможность предлагают AEP, Array, Aventail, Check Point, F5, Juniper и Nokia.

Компания Nokia заслуживает отдельного упоминания, поскольку она реализовала две политики защиты пользовательских компьютеров. Одна используется для сценариев с расширением сети, а другая может быть распространена на все прочие технологии, включая proxy-серверы и переадресацию портов. Фирма Aventail помимо собственных разработок включила в свое решение три продукта независимых производителей.

Общий вывод сводится к тому, что функции защиты пользовательских компьютеров в сетях SSL VPN следует применять с большой осторожностью. Вам вряд ли удастся реализовать надежные сервисы виртуальных частных сетей в «гремучей смеси» жестко контролируемых корпоративных систем и случайной комбинации настольных компьютеров под Windows и Macintosh, карманных ПК и мобильных телефонов.

Взаимодействие с клиентскими платформами

Рекомендации покупателю оборудования SSL VPN

  • Определите приложения, которые будут использоваться в сети VPN. Проведите всеобъемлющее тестирование взаимодействия шлюзов, иначе вы будете неприятно удивлены, когда гендиректор захочет поработать с приложением корпоративной сети из Web-киоска, установленного в аэропорту.
  • Уясните предпочтения пользователей. Они не всегда работают с Windows и Internet Explorer. Если вы хотите предоставить пользователям свободу выбора (от КПК до компьютеров Macintosh), определитесь с этим заранее.
  • Определите политику безопасности. Продукт должен делать то, что вам нужно, и в этом отношении решения разных компаний очень сильно разнятся. Описание политики еще до покупки позволит отбросить неприемлемые варианты.
  • Составьте список требуемых методов доступа. Если вам нужен удаленный доступ с расширением сети, наверняка встанет вопрос о мониторинге защищенности оконечных устройств. Убедитесь, что выбранное решение предоставляет такую возможность. Поскольку Web-приложения не ограничивают доступ пользователей в сеть, их использование наряду с технологией переадресации портов делает проблему безопасности оконечных устройств не столь актуальной.
  • Ощущения пользователей имеют куда большее значение, чем управление. Удостоверьтесь в том, что конечные пользователи будут довольны. Добиться этого гораздо сложнее, чем научиться управлять еще одним новым продуктом.

Процедура тестирования

Прежде всего мы определили простую политику безопасности, ориентируясь на нужды компании с тремя основными группами пользователей, каждая — со своими требованиями к безопасности и работе приложений. При этом мы применили сочетание детального контроля над доступом (некоторые Web-серверы были лишь частично доступны некоторым группам пользователей) и политики защиты оконечных устройств (на компьютерах под Windows должно было действовать антивирусное ПО с последними обновлениями). Устройствам SSL VPN предлагалось защищать различные типы ресурсов: Web-приложения, почтовые серверы, сервисы Windows-терминалов, Citrix Presentation Manager, серверы Telnet и SSH, файл-серверы SMB и FTP под Windows, а также сеть VoIP.

Процедура тестирования состояла из семи этапов. На первом мы проверили взаимодействие устройств SSL VPN с пятью системами аутентификации — RADIUS-сервером, LDAP-сервером Sun iPlanet, доменом Windows Active Directory, идентификационным сервером RSA SecureID и небольшим PKI, основанным на OpenSSL c цифровыми сертификатами. На втором этапе мы попытались активировать политику безопасности на устройстве SSL VPN. Хотя политика безопасности нередко корректируется с учетом технических возможностей используемых решений, в ходе тестирования мы отказались от компромиссов (как, впрочем, и от отключения некоторых функций продуктов с целью улучшить результаты тестов). Сначала были применены базовые правила доступа для групп пользователей, а затем к ним добавились правила защиты оконечных устройств.

Третий этап объединил 135 тестов на взаимодействие с разными комбинациями браузеров, операционных платформ и приложений. Взаимодействие клиентского ПО тестировалось с шестью клиентскими системами. Это два ноутбука Dell под Windows XP с браузерами Internet Explorer 6 и Firefox 1.0.7 (на одном из ноутбуков были прописаны права администратора, а на другом — обычного пользователя), ноутбук IBM ThinkPad под Windows 2000 с браузером Internet Explorer 5.5, ноутбук Apple PowerBook с операционной системой OS X 10.4 и браузерами Firefox и Safari, КПК Treo 650 под управлением Palm OS с встроенным браузером Blazer v.4 и коммуникатором Nokia 9500 (ОС Symbian) с встроенным браузером Opera.

Приложения, имитировавшие разнообразие прикладного ПО в корпоративной среде, выполнялись на девяти разных Web-серверах. Специальная сеть, состоявшая из четырех серверов под Windows 2003, была построена для проверки взаимодействия с Citrix Presentation Server и Windows Terminal Services. Наконец, в испытаниях участвовали серверы на базе мэйнфрейма и программный SIP-телефон компании CounterPath (бывшая Xten Networks), функционировавший под управлением Windows 2003.

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

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

На шестом этапе рассматривались возможности обеспечения высокой готовности и масштабируемости. Проводились тесты для различных типов отказов VPN-продуктов и пользовательских сред. А завершило тестирование измерение производительности каждого из устройств.