ШЛЮЗЫ SSL VPN

Виртуальные частные сети (VPN), построенные на базе протокола Secure Sockets Layer (SSL), обычно преподносятся в качестве инфраструктуры, в которой надежная защита данных обеспечивается чуть ли не автоматически.

При тестировании шлюзов для сетей SSL VPN семи производителей (AEP, F5 Networks, NetScreen Technologies, Netilla, Nokia, Symantec и Whale Communications) мы интересовались тем, в какой мере конфигурация этих продуктов поддерживает защищенный удаленный доступ к корпоративным приложениям.

Сразу отметим, что некоторые разработки прекрасно подходят для применения в корпоративной среде. Победителем испытаний оказался шлюз производства NetScreen, имеющий великолепные средства поддержки приложений, хорошие механизмы контроля доступа и достаточную степень совместимости с сетевым оборудованием, которое было установлено в тестовой сети. Высокие оценки получили также разработки Nokia, Symantec и F5 — прежде всего благодаря широкому спектру поддерживаемых ими приложений.

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

Приложения повсюду

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

Когда дело дошло до выполнения функций прокси-серверов и преобразования трафика приложений, между тестировавшимися продуктами обнаружились существенные различия. В явных аутсайдерах оказались шлюзы производства AEP и Whale Communications. Разработка Nokia была единственным устройством, способным выполнять преобразования между форматами FTP, NFS (Network File System) и файл-серверами корпорации Microsoft. Продукты F5, NetScreen и Symantec поддерживают только часть указанных форматов. А вот шлюз фирмы Netilla, в отличие от всех остальных, обеспечивает преобразование между сервисами Windows Terminal Services и широким набором эмуляторов терминалов, включая telnet, Secure Shell (SSH) и IBM 3270; соответствующие функции получили у нас самые высокие оценки. Компании F5 и NetScreen также включили поддержку telnet и SSH в свои продукты, но ее реализация не произвела на нас особого впечатления, поскольку эти эмуляторы работали лишь в 25% случаев.

Широкая функциональность шлюзов SSL VPN потребует от пользователя, подбирающего устройство для своей сети, четкого представления о том, преобразование трафика каких приложений ему необходимо в первую очередь. Скажем, шлюзы Symantec и F5 способны обрабатывать сообщения электронной почты, что позволяет отправлять электронную корреспонденцию при помощи приложения, инсталлированного непосредственно на шлюзе. К сожалению, функция работы с электронной почтой через Web, реализованная компанией Symantec, перестает действовать, если ящик пользователя переполнен сообщениями.

Шлюзы SSL VPN, не имеющие встроенных средств работы с почтой через Web, позволяют подключаться к корпоративному почтовому приложению, будь то Microsoft Outlook, iNotes фирмы IBM или приложение с открытым кодом SquirrelMail. Как показали тесты на совместимость, функциональная насыщенность подобного ПО порождает свои проблемы. Администратор оказывается перед нелегким выбором: сделать ставку на программу, поддерживающую многочисленные функции работы с корпоративной почтой через Web, но не отличающуюся простотой, либо приобрести систему поддержки Web-почты с ограниченной функциональностью, которая имеет дружественный интерфейс и совместима с мало распространенными вариантами или старыми версиями браузеров.

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

Однако чем активнее вы прибегаете к технологии прямого доступа, тем более сложной и сопряженной с дополнительными рисками становится реализация сети SSL VPN. Чтобы внедрить механизмы переадресации портов и расширения сети, шлюз SSL VPN должен установить определенное ПО на компьютере пользователя. Такое решение порождает проблемы с работой операционной системы, совместимостью браузеров и информационной безопасностью. Например, пользователь приложения Microsoft Internet Explorer с высоким уровнем защиты вообще не сумеет прибегнуть к помощи рассматриваемых механизмов, а полномочиями изменять этот уровень конфигурации он может и не обладать.

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

Протестированные шлюзы SSL VPN, за исключением продуктов AEP и Netilla, в том или ином виде поддерживают механизм переадресации портов, но во многих случаях этого недостаточно. Простейшим примером может служить протокол FTP, использующий для идентификации сервера IP-адреса и номера портов, а для передачи данных — и клиентские сокеты. Механизм переадресации портов поддерживает не всех клиентов FTP, если только шлюз не распознает трафик FTP и не вставляет заново IP-адреса в пересылаемые пакеты.

Информацию о типе трафика средства переадресации портов могут получать от шлюзов прикладного уровня (Application Layer Gateway, ALG), которые обычно имеются в брандмауэрах. Разработчики оборудования SSL VPN предпринимают попытки наделить средства переадресации портов возможностями ALG в двух функциональных областях. Одна из них — поддержка электронной почты, прежде всего интерфейса MAPI (для клиентов Microsoft Exchange) и компонентов Notes Smart Suite. Именно по этому пути пошли NetScreen, Nokia и Symantec. Другая область — поддержка удаленных компьютеров средствами терминального сервиса Citrix; соответствующие решения можно обнаружить в шлюзах NetScreen и Nokia.

Вместо того чтобы наделять свои устройства интеллектуальными функциями ALG, многие компании сделали ставку на технологию расширения сети, при использовании которой удаленный компьютер подключается к сети в обход шлюза SSL VPN. Такая возможность реализована во всех протестированных продуктах, за исключением разработок Nokia и Whale.

Поддержка электронной почты, по-видимому, является наиболее популярной функцией шлюзов SSL. В процессе тестирования нам удалось обнаружить еще один способ ее реализации. Для стандартных протоколов электронной почты (вроде SMTP, POP и IMAP) компании AEP, NetScreen, Nokia и Symantec включили в свои шлюзы прокси-серверы. Основная идея заключается в том, что пользователь будет направлять трафик клиентских почтовых приложений на шлюз SSL VPN и шифровать почтовые сообщения, передаваемые между клиентской станцией и шлюзом, при помощи стандартных механизмов POP-over-SSL, IMAP-over-SSL и SMTP-over-SSL. Тем самым станет повышаться уровень защищенности почтовых транзакций.

Проблемы совместимости

Рост популярности Web-приложений заметно усложнил жизнь поставщикам систем информационной защиты. Излишняя податливость браузеров к приему и выводу на экран неполных Web-страниц, некорректных сценариев на JavaScript и просто неряшливо написанных Java-приложений привела к появлению целого поколения прикладных программ, которые не имеют особого смысла с точки зрения разработчика ПО, но вполне работоспособны. Совладать с подобными приложениями без шлюза SSL VPN практически невозможно. Мы протестировали 20 приложений для семи комбинаций «браузер-сервер» и обнаружили существенные различия в функционировании шлюзов.

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

Для начала мы выбрали пять базовых Web-приложений, часть из которых включала в себя фрагменты, написанные с применением JavaScript. Единственной компанией, которая обеспечила поддержку всех пяти прикладных программ на семи платформах, оказалась Nokia. Продукты F5 и NetScreen работали с четырьмя приложениями, а разработки Whale и Symantec — с двумя и тремя. Неудовлетворительную оценку получил шлюз производства AEP как не поддерживающий два ключевых приложения, одно из которых было написано на JavaScript, а другое функционировало на Web-сервере с поддержкой протокола SSL. Остальные производители реализовали поддержку серверов со средствами SSL, но оценка продукта фирмы Netilla была снижена из-за его плохих графических возможностей.

От базовых приложений мы перешли к двум пакетам электронной почты: Outlook Web Access 2003 и iNotes версий 6.0 и 6.5. И на этот раз ближе всего к нашим ожиданиям оказался продукт Nokia, за коим следовали разработки AEP и Symantec (правда, шлюз фирмы Symantec вызвал нештатное завершение работы браузера Netscape сразу после запуска ПО iNotes). Новизной версии Outlook 2003 можно объяснить определенные проблемы в функционировании всех шлюзов. Впрочем, больше всего нас интересовало, способны ли эти шлюзы работать в качестве стандартного решения независимо от того, какое ПО эксплуатируется в сети.

Довольно скоро стало ясно, что поставщики и не стремились к тому, чтобы их продукты можно было использовать без предварительной настройки. Мы хотели ограничить испытания рамками конфигураций SSL-шлюзов, установленными самими производителями. Однако большинство шлюзов имеют ряд неочевидных настроек, призванных улучшить их совместимость с другим сетевым оборудованием. Вот, например, шлюз фирмы Netilla. При выборе приложения вы можете задать ускоренное или полное преобразование HTML-страниц. Единственная фраза по этому поводу, которую нам удалось найти в документации, такова: «Ускоренное преобразование приемлемо для большинства приложений». Зато в документации компании Whale настройке средств работы с прикладным ПО уделено 75 страниц!

В третьей серии тестов фигурировали три Web-приложения, написанные на Java и использовавшие одну из разновидностей технологии Flash. Результаты оказались поистине удручающими. Шлюзы производства F5, NetScreen и Symantec хотя бы какое-то время взаимодействовали с каждой из данных программ, а продукты AEP, Netilla, Nokia и Whale вообще отказались это делать. Вывод напрашивается сам собой: современные приложения, при создании которых активно используются Java и Flash, пока не «уживаются» со шлюзами SSL VPN — по крайней мере, без применения технологий переадресации портов и расширения сети.

В четвертой серии тестов проверялась способность шлюзов взаимодействовать с файл-серверами Microsoft, FTP и NFS на уровне преобразования трафика приложений. На сей раз проставить оценки оказалось не так-то просто, поскольку не каждое устройство поддерживает все перечисленные протоколы. Эти продукты чересчур интеллектуальны для решения подобных задач. Скажем, внешне довольно привлекательная функция навигации по файл-серверу фирмы F5 не смогла корректно работать с браузером Safari. Разработка фирмы Netilla, по сути дела, поддерживает только браузер Internet Explorer в среде Windows. Шлюз производства Whale не справился со старыми версиями Internet Explorer и Netscape Navigator. Наконец, у шлюзов от Nokia и Symantec возникли проблемы совместимости с FTP-серверами. Со стандартным FTP-сервером под Unix они работали вполне корректно, а вот попытка переключиться на сервер OpenVMS вызвала непреодолимые трудности.

В последней серии тестов проверялась поддержка технологий переадресации портов и расширения сети, причем вмешательство представителей компаний не допускалось. Пользователей компьютеров Apple стоит предупредить: даже те устройства, которые, по утверждению производителей, работают с ОС Macintosh на уровне переадресации портов (а соответствующие заявления можно услышать от NetScreen и Nokia), в действительности способны на это лишь частично.

Что же касается среды Windows, здесь средства переадресации портов (если таковые имелись) работали без сучка без задоринки. Так, продукты F5, NetScreen, Nokia и Symantec прекрасно справлялись с переадресацией одно- и многопортовых приложений. Шлюз компании Whale отказался работать с браузером Netscape, выдав сообщение, что запустить процесс переадресации может только привилегированный пользователь. Это ограничение представляется вполне разумным, но проблема в том, что мы зарегистрировались в системе с правами администратора.

В отношении средств расширения сети тоже не все было гладко. Продукты NetScreen и Netilla не вызвали нареканий, а вот шлюз от AEP не поддерживал запущенное нами приложение, основанное на протоколе UDP. Устройство фирмы F5 иногда работало, но иногда мы не видели ничего, кроме голубого экрана Windows 2000. Проблемы обнаружились и у VPN-продукта компании Symantec, прежде всего из-за отсутствия документации и клиентского ПО.

Результаты тестов на взаимодействие недвусмысленно свидетельствуют, что данным устройствам еще далеко до универсальных простых в использовании шлюзов, поддерживающих разнообразные корпоративные приложения. Нехитрые Web-страницы и базовые компоненты на JavaScript лучшими из шлюзов загружались вполне корректно. Когда же дело доходило до технологий Java, Flash, переадресации портов, расширения сети и файловых сервисов, трудности становились непреодолимыми, а о совместимости не могло быть и речи.

Контроль доступа

Шлюзы SSL VPN должны предоставлять администратору разнообразные средства управления защитой приложений. Все протестированные продукты позволяют разрешить или запретить доступ к приложениям установленным группам пользователей. Простейший вариант управления доступом реализовали компании AEP, F5 и Netilla. Шлюз от Netilla позволяет определить Web-приложение как набор URL-указателей. Аналогичный подход исповедуют и разработчики из AEP. Фирма F5 также реализовала доступ на основе групп, но особенности созданного ею интерфейса ограничивают число последних. Кроме того, каждый пользователь должен принадлежать только к одной группе.

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

Еще один подход к организации контроля за доступом — не ограничиваться отдельными потребителями или их группами. В его реализации безусловным лидером является корпорация Nokia, хотя отдельные элементы можно обнаружить в шлюзах производства NetScreen и Whale. Продукт Nokia позволяет не только разрешить или запретить доступ к ресурсу той или иной группе пользователей, но и определить допустимые операции с этим ресурсом. Переход от самого общего к детальному контролю прав доступа осуществляется одним щелчком мыши. Скажем, доступ к конкретному файлу можно разрешить только тем пользователям, которые прошли аутентификацию по протоколу LDAP и имеют на своих компьютерах обновленную версию антивирусного ПО.

На первый взгляд средства контроля доступа от компании Whale весьма примитивны, но истинная сила ее продукта заключается в наличии брандмауэра, функционирующего на уровне приложений. Администратор может расчленить отдельный указатель URL и детально проанализировать обнаруженные ошибки (например, проверить параметры данных, посылаемых для заполнения формы, и заблокировать некорректные сведения). Работать с таким инструментарием непросто, поэтому в помощь администратору предлагаются наборы правил, заранее настроенных на работу с популярными приложениями. К сожалению, для использовавшихся нами программ Outlook 2003 и iNotes таких правил не оказалось. Эти приложения начали работать лишь после того, как мы полностью отключили функции брандмауэра.

Наибольшее разочарование нас постигло при тестировании средств контроля доступа к файл-серверам. Возможности управления таким доступом у шлюзов Whale и Netilla не выдерживают никакой критики. Если пользователь получил доступ к файл-серверу под Windows, ограничить его доступ к отдельным ресурсам попросту невозможно. Работая со шлюзами NetScreen, Nokia и Symantec, администратор может определить права чтения или записи на уровне отдельных файлов. К продукту фирмы F5 прилагается ПО, позволяющее сканировать файлы на предмет их заражения вирусами.

Выбор продукта

Выбрать по результатам тестирования безусловного фаворита оказалось непросто. Хотя разработки AEP, Netilla и Whale нас не особенно впечатлили, каждая из них имеет свои достоинства. Так, Whale предлагает прекрасный брандмауэр прикладного уровня, а Netilla — самый богатый набор функций, обеспечивающих преобразование трафика приложений. Тем не менее эти продукты воспринимаются как искусственно отнесенные к категории шлюзов SSL VPN. Применять их уместно лишь в тех ситуациях, когда существующими корпоративными приложениями востребованы их сильные стороны.

Шлюз фирмы F5 порадовал нас простым интерфейсом и богатой функциональностью. Основной его недостаток (слабые средства контроля доступа) компания обещает устранить в следующих версиях.

Сотрудники NetScreen, Nokia и Symantec приложили немало труда для разработки шлюзов SSL VPN «с нуля». Их усилия увенчались появлением на свет вполне работоспособных продуктов.