Защита информации, виртуальные частные сети (VPN). Технология ViPNet.

Задавшись целью отыскать показательный пример ожесточенной борьбы производителей на телекоммуникационном рынке, достаточно проанализировать ситуацию, сложившуюся вокруг стека протоколов IPSec. В водоворот, порожденный соответствующим стандартом IETF, с каждым месяцем вовлекаются все новые силы.

Свой вклад в разыгравшуюся стихию вносят далеко не бесхитростные компании-конкуренты. Как только встает вопрос о взаимодействии продуктов IPSec, обнаруживается, что эти фирмы готовы сесть за стол переговоров и согласовать текст очередной порции спецификаций. Подливают масла в огонь и минимум четыре организации, сделавшие себе имя на тестировании: как это ни странно, они частенько занимают диаметрально противоположные позиции. Не остаются в стороне около дюжины объединений пользователей, хотя, надо признать, роль последних явно не соответствует их истинному весу.

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

Образованная в IETF группа IPSec Working Group работает уже семь лет. Обычно подобная структура в составе консорциума выполняет поставленные перед ней задачи за год-полтора,  - замечает Рон Калли, ведущий менеджер по средствам сетевой обработки корпорации Microsoft.

По правде говоря, существуют веские причины, осложняющие деятельность указанной рабочей группы. Стандарт на средства защиты данных в IP-сетях, первоначально создававшийся исключительно для версии IPv6, - материя непростая. К тому же конечная цель деятельности IPSec Working Group со временем претерпела значительные изменения.

Разработка стандарта отняла столько времени прежде всего из-за того, что технологии, на которые ориентировались члены группы, не стояли на месте, - рассказывает Эндрю Ньюман, старший аналитик из Йельского университета. - Первая версия стандарта создавалась в ту пору, когда в надежной защите данных не было особой необходимости.

Однако с тех пор многое изменилось. Сегодня типичная компания использует протокол IP в локальных сетях, при организации удаленного доступа, для подключения разбросанных офисов и в приложениях электронной коммерции. Современные организации буквально наводнены многочисленными серверами удаленного доступа (RAS), инфраструктурами для обмена общедоступными ключами и средствами преобразования сетевых адресов. И охватить подобное нагромождение единой системой информационной безопасности, да еще безукоризненно соответствующей стандарту, - тяжелая задача.

Впрочем, те же аргументы справедливы и в отношении любой другой широко распространенной стандартизованной технологии, особенно если речь заходит о взаимодействии продуктов разных поставщиков. За то время, пока велась работа над протоколами IPSec, технология Secure Sockets Layer (SSL) успела прорасти из посеянных семян и превратиться в цветущее поле. Да и язык XML доказал, что различные производители при всей антагонистичности своих маркетинговых позиций способны быстро скооперироваться, когда в этом возникает острая необходимость.

Но тогда почему возник затор на пути обеспечения взаимодействия продуктов, основанных на IPSec? Как могло получиться, что после стольких выставок и публичных демонстраций состояние дел в области совместимости остается в лучшем случае неопределенным?

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

Философия безопасности

Если верить многочисленным маркетинговым заявлениям поставщиков, ситуация с совместимостью продуктов IPSec на самом деле гораздо лучше, чем кажется. По правде говоря, определенная степень взаимодействия средств IPSec действительно достигнута, однако оно проявляется только в том случае, когда требуется организовать туннельную передачу между шлюзами с фиксированными IP-адресами и имеется возможность обмениваться ключами вне сети. Если производители утверждают, что их продукты способны взаимодействовать с изделиями других компаний или даже демонстрируют сертификаты с печатями International Computer Security Association (ICSA), можете не сомневаться: речь идет всего лишь о поддержке стандарта IPSec.

Базовая функциональность уже реализована, причем случилось это не вчера, - замечает Боб Московитц, сопредседатель IPSec Working Group и один из руководителей ICSA. - Тем не менее многие проблемы до сих пор остаются нерешенными. Например, применение протоколов Internet Key Exchange (IKE) с заранее согласованными ключами требует статических IP-адресов, а это не позволяет работать по коммутируемым телефонным линиям.

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

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

Участники дебатов разделились на три лагеря. Одни настаивают на использовании протокола туннелирования Layer 2 Tunneling Protocol (L2TP). Другие призывают модифицировать согласующие процедуры IKE, чтобы обеспечить поддержку более ранних методов идентификации, используемых в Internet; в рамках данного направления уже предложено несколько вариантов технологии. Наконец, представители третьей группы пытаются убедить своих оппонентов в необходимости обеспечить поддержку протокола Dynamic Host Configuration Protocol в процедурах IKE; их предложения суммированы в проекте стандарта, который был представлен на рассмотрение IETF в декабре прошлого года.

Чтобы выяснить, какова в этом вопросе позиция того или иного производителя, достаточно проанализировать его общие воззрения в области защиты данных.

Скажем, корпорация Microsoft, в свое время вместе с Cisco Systems способствовавшая появлению на свет протокола L2TP, сегодня возглавляет ряды сторонников комбинированного подхода на базе L2TP/IPSec. L2TP возник в результате своеобразного скрещивания протокола Point-to-Point Tunneling Protocol фирмы Microsoft и технологии Layer 2 Forwarding компании Cisco.

Фирма TimeStep, традиционно позиционирующая себя в качестве поставщика VPN-продуктов для IP-сетей, разработала проект спецификаций IETF с предварительным названием IKE-XAUTH, в котором основной упор сделан на применение метода Remote Access Dial-In User Service (RADIUS) в процедурах IKE. Добавка XAUTH возникла как сокращение от eXternal AUTHorization (внешняя авторизация). Более того, TimeStep уже выпустила версию своего шлюза Permit Enterprise Version 2.0, основанную на указанных спецификациях.

Среди других расширений архитектуры IKE заслуживают упоминания Hybrid Mode компании Check Point Software (в ней также используется метод авторизации XAUTH) и Crack корпорации Network Alchemy.

Направление, связанное с протоколом DHCP, сегодня возглавляет компания RedCreek Communications. Разработчики из RedCreek отмечают, что предложенный ими метод (а ему посвящены уже две рабочие спецификации) позволяет настроить конфигурацию и идентифицировать клиентскую систему удаленного доступа, воспользовавшись уже существующими протоколами и процедурами IKE в немодифицированном виде. Компания RedCreek была в числе первых производителей, поддержавших самую раннюю версию IKE под названием ISAKMP/Oakley.

Эта трехполюсная картина оказалась несколько смазанной после того как некоторые апологеты протокола L2TP решили поддержать RedCreek. Корпорации Intel, Microsoft и Sun Microsystems активно участвовали в подготовке первой версии спецификаций DHCP, а Microsoft - и второй версии.

Между тем очевидно, что та же Microsoft направляет всю свою мощь на поддержку технологии, использующей L2TP. Судя по всему, фирма при этом ничем не рискует, ведь в предварительном варианте L2TP все равно предусмотрено применение протокола DHCP.

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

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

Еще один часто повторяемый аргумент заключается в том, что метод L2TP over IPSec повышает долю служебных данных в общем объеме трафика. Парируя это обвинение, представители Microsoft утверждают, что протокол L2TP допускает сжатие заголовков пакетов, так что суммарный размер передаваемых пакетов возрастает всего на один байт.

На перспективность рассматриваемой схемы указывают некоторые аналитики, не участвующие в работе IETF. Их доводы сводятся к тому, что L2TP сегодня активно используется для инкапсуляции в IP-пакеты самых разных типов трафика, а кроме того, он получил широкое распространение в корпоративных сетях.

Во многих компаниях окончательный переход на IP еще не состоялся, - утверждает Эрик Зайнс, аналитик из компании TeleChoice. - В них по-прежнему применяются IPX и SNA. В отличие от IPSec, протокол L2TP не предназначен для формирования туннелей на втором уровне модели OSI. Почему бы в таком случае не использовать в корпоративной сети сразу оба протокола?

Сторонники модернизации протоколов IKE (в целях ужесточения процедуры авторизации) указывают на элегантность такого решения с точки зрения пользователей, особенно тех, в чьих компаниях не поддерживается протокол L2TP. В подобной ситуации дело ограничится написанием дополнительного кода, а достигнутое за счет этого расширения функциональных возможностей позволит поддерживать устаревшие системы защиты, включая RADIUS.

Но и у этой идеи нашлись недоброжелатели, ссылающиеся на плохую проработку предварительных спецификаций. Их главный аргумент связан со схемой преобразования сетевых адресов (NAT).

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

Между тем процедуры обмена ключами IKE фактически нивелируют преимущества NAT, поскольку IP-адрес помещается в зашифрованную часть пакета. В лучшем случае это означает, что внутренние адреса окажутся выставлеными на всеобщее обозрение, в худшем возникнут проблемы с маршрутизацией пакетов, поскольку содержащиеся в них IP-адреса будут зашифрованы.

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

Отсутствие объективности

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

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

Даже Московитц, ранее участвовавший в заседаниях IPSec Working Group в качестве основного представителя интересов пользователей, ныне также выступает на стороне производителей. Свою деятельность в IETF он начинал, будучи сотрудником корпорации Chrysler. Председателем рабочей группы Московитц остается и по сей день, однако его основная должность теперь иная - он возглавляет организованную в ICSA лабораторию тестирования IPSec-продуктов на совместимость. Опыт бывшего пользователя при тестировании трудно переоценить, однако ICSA - коммерческая организация и сохраняющиеся проблемы в области взаимодействия продуктов приносят ей немалый доход. (Достаточно сказать, что стоимость тестирования каждого устройства составляет около 25 тыс. долл.) По этой причине многие члены рабочей группы обвиняют Московитца в непоследовательности.

Более того, ассоциация ICSA тестирует на соответствие спецификациям IPSec (а точнее, части этих спецификаций) только те продукты, которые уже присутствуют на рынке. Она же занимается рядом других аспектов защиты данных. ICSA не публикует результаты своей деятельности, однако известно, что большая часть продуктов не проходит предусмотренные для них тесты. Это обстоятельство сильно раздражает производителей, которые ждут от ассоциации помощи в достижении совместимости с существующим стандартом и его новыми версиями.

Страсти накалились до такой степени, что несколько изготовителей приняли решение о создании параллельной организационной структуры, получившей название Virtual Private Network Consortium (VPNC). Ее возглавил Пол Хофман, известный своей активной деятельностью в консорциуме Internet Mail Consortium. "Все члены новой организации выражают крайнее недовольство работой ICSA, эта ассоциация совершенно не оправдала возлагавшихся на нее надежд", - говорит он. И тут же добавляет: "Однако если члены ICSA примут решение оказывать реальное содействие преодолению проблем совместимости, в существовании консорциума VPNC отпадет всякая необходимость".

Между тем руководитель ICSA расценивает сложившуюся ситуацию как стремление разделить поставщиков на плохих и хороших. Хофман представляет все так, будто именно ему удалось сдвинуть дело с мертвой точки, а ICSA только тем и занималась, что вставляла палки в колеса, - объясняет Московитц. - В действительности мы возвращаем протестированные устройства их производителям и даем свое заключение относительно недостатков, которые следует устранить. Мы не стремимся надевать на себя белые одежды, но и не хотим представать в образе козла отпущения. На мой взгляд, нет ничего зазорного в существовании двух похожих организаций.

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

В налаживании непродолжительных контактов фирмам может помочь IPSec Developers Forum. Эта организация, созданная в феврале 1998г. компанией RADGUARD, позволяет двум изготовителям провести попарное тестирование разрабатываемых продуктов. Участие в IPSec Developers Forum бесплатное.

Аналогичную работу проводит американский Национальный институт по стандартам и тестированию (NIST). На его Web-сервере размещены инструментальные средства, которые позволяют поставщикам протестировать продукты IPSec на соответствие стандарту, воспользовавшись реальным соединением Internet. Например, производители могут проверить функционирование своих продуктов в одиночном сеансе согласования параметров защищенной передачи.

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

К счастью, и здесь существует одно исключение. Ассоциация ICSA публикует свои комментарии к продуктам, получающим сертификат с ее печатью. В этих документах детально описаны условия тестирования, а также процедуры настройки конфигурации и управления, которые позволили достичь взаимодействия. Эти длинные описания заставляют компании продолжать совершенствовать предлагаемые реализации стандарта IPSec.

Web-серверы таких организаций, как VPNC, IPSec Developers Forum и NIST, являются для пользователей ценнейшим ресурсом, поскольку они позволяют по крупицам восстановить истинную картину, которая сложилась в сфере взаимодействия различных реализаций IPSec. Консорциум VPNC публикует таблицы, из которых видно, какие устройства разных производителей успешно прошли тест на взаимодействие друг с другом, а IPSec Developers Forum и NIST сообщают результаты испытаний по запросам пользователей. Кроме того, на сервере NIST доступны технические спецификации, в соответствии с которыми проводится тестирование; они будут полезны сетевым инженерам, стремящимся повысить свою квалификацию в области защиты данных средствами IPSec.

Итак, сегодня настала пора пользователям активно вмешаться в сложившуюся ситуацию. Будущее сетей удаленного доступа создается именно сейчас и, к сожалению, практически без участия тех, кому с этими сетями придется иметь дело.
Джулия БОРТ (Журнал "Сети")

Microsoft, VeriSign и WebMethods представили новый стандарт сетевой безопасности.

Компании Microsoft, VeriSign и WebMethods будут совместно продвигать новую технологию, которая, по их мнению, позволит вывести безопасность в интернет на новый уровень, сообщает ECommerce Times. Технология, названная XKMS (key management specification), призвана значительно облегчить работу веб-мастера по обеспечению безопасности сайта. 

Она упростит построение систем аутентификации для обеспечения безопасности платежей в интернете. Новая технология основана на активно продвигаемом Microsopft стандарте XML (Extensible Markup Language). Технология XKMS широко использует ЭЦП, так что возможность использования ее российским интернет-компаниями останется под вопросом, пока в России не будет принят закон об ЭЦП. 
(источник - http://www.cnews.ru, опубликовано 30.11.20002)

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

Подробности и инструкция для желающих принять участие в акции здесь.
 

Полнофункциональные демо-версии продуктов ViPNet Desk, ViPNet Office, ViPNet Tunnel находятся по адресу 
http://www.infotecs.ru/demo.htm

Если у вас есть какие-нибудь пожелания или вопросы по поводу дальнейших выпусков рассылки, мы с удовольствием 
рассмотрим их.