Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Проблемы интероперабельности решений на основе IPSec

Майк Фратто

Поддержка корпоративных пользователей, применяющих различные технологии удаленного доступа — коммутируемые линии, кабельные модемы или линии DSL, — а также работающих в ЛВС удаленных офисов, с каждым днем становится все более и более необходимой. Требования безопасности телекоммуникаций конечных пользователей независимо от их местоположения — вот основная причина наблюдаемого в настоящее время усложнения этих технологий. Виртуальные частные сети (Virtual Private Network — VPN) в значительной степени решают эту проблему, но не без некоторых издержек. Не менее важно в условиях аутсорсинга корпоративных приложений и географической разбросанности персонала компании и ее партнеров обеспечить безопасность передачи конфиденциальной информации по сетям общего пользования. Для отдельно взятого предприятия конкретное VPN-решение того или иного производителя обеспечит надежную защиту коммуникаций. Это касается как сотрудников, работающих на дому, так и персонала удаленных офисов. В большинстве случаев, однако, невозможно добиться того, чтобы все партнеры данного предприятия использовали одно и то же решение.

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

Новая рабочая группа, образованная в составе IETF и именуемая IPSRA (IPSec Remote Access), занимается вопросами безопасности удаленного доступа. Она готовит несколько проектов стандартов с упором на проблемы конфигурирования клиентского оборудования и аутентификации пользователей. Хотя эти стандарты протоколов (их можно найти на Web-узле IETF по адресу www.ietf.org/html.charters/ipseccharter. html) пока еще находятся на ранней стадии разработки, однако в части обеспечения интероперабельности определенные результаты уже имеются. Некоторые продукты, в том числе сетевая операционная система IOS фирмы Cisco Systems, линия продуктов SafeNet фирмы IRE и 130 Secure VPN Client фирмы Newbridge Networks (приобретена Alcatel — Прим. ред.), поддерживают вышеупомянутые протоколы, и в ближайшее время их список будет расширен. При этом IETF вовсе не является лидером в разработке данного направления: компания Microsoft в своей ОС Windows 2000 реализовала защищенную посредством IPSec технологию L2TP (Layer 2 Tunneling Protocol).

Несмотря на возможность использования в ПО IPSec цифровых сертификатов, применение последних ограничено рамками фирменных решений из-за проблем обеспечения их интероперабельности. Если же VPN-решение реализовано на базе продуктов нескольких производителей, то для взаимной аутентификации устройств IPSec необходима управляемая инфраструктура предварительно распределяемых ключей (Internet Key Exchange — IKE). Уровень безопасности и масштабируемости таких решений по сравнению с основанными на цифровых сертификатах невысок. Тем не менее инфраструктура IKE представляет собой вполне приемлемую альтернативу, особенно для небольших компаний.

В данной статье на примере маршрутизатора Cisco 4700 с IOS 12.0(2a)T1 фирмы Cisco Systems, шлюза Newbridge 234 Secure VPN Gateway фирмы Newbridge Networks, ПО SoftPK 2.1.0 (версия 15) фирмы IRE и VPN+ фирмы F-Secure мы рассмотрим вопросы интероперабельности решений, реализованных на основе семейства протоколов IPSec.

Установка правил

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

Инсталляция клиентской части VPN на базе IPSec во многом аналогична инсталляции VPN типа ЛВС—ЛВС. Для каждой из сторон необходимо обеспечить соответствие сетевых параметров и параметров безопасности. С помощью клиентов VPN+, SoftPK и Newbridge 130 Secure VPN Client мы создали простейшую сеть, подключив их к маршрутизатору Cisco 4700 и шлюзу Newbridge 234 Secure VPN Gateway (рис. 1). Наша политика безопасности была предельно проста: все соединения частной сети, проходящие через сеть общего пользования, должны быть защищены посредством протокола ESP (Encapsulating Security Payload) с использованием алгоритмов шифрования 3DES и аутентификации MD5.

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

Сконфигурировав VPN-шлюзы, мы приступили к инсталляции клиентских рабочих станций. Ручное конфигурирование ПО IPSec для специалистов не составляет труда, тем же, кто не знаком с “подводными камнями” этой технологии, наверняка потребуется помощь. Цель процесса состоит в достижении соответствия между сетевыми адресами и параметрами безопасности клиентского оборудования и шлюза VPN. Как правило, чтобы реализовать политику безопасности на клиентской стороне, последняя должна включать в себя все приемлемые конфигурации системы защиты. Например, одному удаленному пользователю для организации канала VPN между ним и корпоративной сетью может потребоваться алгоритм 3DES, а другому — просто DES. Когда клиентские машины “договариваются” об установлении сеанса связи с удаленным устройством VPN, ему будут направлены оба запроса. Обычно устройство выбирает предложение, поступившее первым, поэтому порядок их следования является важным. После того как профиль безопасности определен, наступает черед определения сети назначения и шлюза.

При конфигурировании сети могут возникнуть проблемы с IP-адресами. Они используются для идентификации ассоциации безопасности (Security Association — SA), которой принадлежит входящий IP-пакет. Адресом назначения (ID) может служить как хост, так и подсеть. Если между адресами, хранящимися в БД IPSec-устройств, и реальными IP-адресами обнаружится несоответствие, установить VPN-связь будет невозможно. По умолчанию в качестве идентификатора клиентского ПО IPSec используется IP-адрес рабочей станции, на которой оно установлено, но удаленный адрес назначения должен задаваться вручную. С синтаксисом управления идентификаторами поставщики привыкли обращаться вольно, поэтому следует быть очень внимательным. В некоторых VPN-шлюзах на основе IPSec обозначение 10.1.1.1/24 не является эквивалентным обозначению 10.1.1.1/255.255.255.0, несмотря на то что логически они идентичны — первое является сокращенной формой второго. В сетях VPN на основе IPSec лучше всего использовать идентичные пары IP-адрес/маска подсети.

Удаленное конфигурирование

Клиентское ПО VPN схоже с традиционными программами удаленного доступа, посредством которых удаленным пользователям назначаются IP-адреса и параметры маршрутизации, активизируются службы DNS и WINS, а также обеспечивается безопасность доступа в корпоративную сеть. Из-за отсутствия стандартных методов конфигурирования VPN-клиентов в гетерогенной среде автоматически задавать в ней IP-адреса и задействовать службы DNS и WINS не представляется возможным. В некоторых проектах стандартов рабочей группы IETF по протоколам IPSec (унаследованных группой IPSRA) сделана попытка решить проблему удаленного конфигурирования. Компании Altiga Networks, VPNet и некоторые другие справились с ней посредством фирменных методов, которые в гетерогенной среде становятся бесполезными.

В основном режиме (фаза 1) конфигурирования по методу ISAKMP выполняется транзакционный обмен информацией между клиентом и шлюзом VPN, в ходе которого клиенту сообщаются базовые данные адресации, после чего наступает черед фазы 2 — быстрого режима (см.: Сети и системы связи. 1998. № 7. С. 122). Исходя из информации, согласованной на фазе 1, в быстром режиме устанавливается VPN-соединение. Конфигурирование по методу ISAKMP может быть инициировано любой из сторон путем отправки сообщения типа запрос/ ответ. К примеру, если удаленный пользователь соединяется с VPN-шлюзом по протоколу IPSec, первым его шагом будет создание в основном режиме SA-соглашения, в соответствии с которым обеспечивается защита обмена данными IPSec на фазе 2.

Несмотря на простоту метода ISAKMP с точки зрения обмена сообщениями, его возможности конфигурировать VPN-клиентов ограниченны. Если последние нуждаются в дополнительной информации, они могут получить ее в рамках SA-соглашения, послав DHCPINFORM-запрос. Это обеспечивает дополнительную безопасность, поскольку механизмы IPSec используются главным образом для защиты трафика, а не для передачи широковещательных сообщений DHCP. Поскольку проект соответствующего стандарта явно не указывает на то, какая из сторон должна инициировать DHCPINFORM-запрос, это должен делать клиент.

Конфигурирование DHCP-клиента в туннельном режиме IPSec выполняется в начале фазы 2 путем установления отдельного кратковременного SA-соглашения. После согласования данных DHCP это соглашение ликвидируется, и наступает фаза 2. Последующие DHCP-сообщения передаются в рамках SA-соглашений с клиентом. Основное преимущество такого метода заключается в том, что протокол DHCP хорошо известен и поддерживается повсеместно, но вместе с тем он имеет и некоторые недостатки.

Технология IPSec разработана таким образом, чтобы обеспечивалась защита соединений между соответствующими адресами приемника и источника данных посредством их шифрования и аутентификации. Вполне разумно выбирать для различных соединений разные уровни криптостойкости алгоритмов шифрования. Сообщения DHCP, будучи широковещательными (рис. 2), таким образом, не могут быть защищены обычными методами IPSec. Для обеспечения безопасности DHCP-запросов предназначены краткосрочные общие SA-соглашения. По истечении их срока действия устанавливаются новые SA-соглашения для защиты всего последующего трафика. Хотя понятие “общий адрес назначения” технически вполне реализуемо, с точки зрения логики его не следует представлять как “адресуется всем”.

Несмотря на то что методы конфигурирования ISAKMP и DHCP являются относительно новыми, они тем не менее находят применение в фирменных решениях, поэтому проверьте, не использует ли ваш IPSec-клиент дополнительные возможности запроса сетевого адреса и аутентификации, помимо предусматриваемой IKE. Такие на первый взгляд безобидные вещи способны помешать установлению соединений из-за невозможности сторон завершить процесс переговоров. В ходе нашего тестирования мы по неосторожности сконфигурировали ПО Newbridge 130 Secure VPN Client для установления виртуального туннеля в соответствии с фирменной реализацией метода ISAKMP, чтобы получить IP-адреса из удаленной сети. Результатом стала ошибка протокола IKE на маршрутизаторе Cisco, который “не понимал” такого метода конфигурирования.

Аутентификация

Еще труднее было решать проблемы, возникающие при удаленной аутентификации пользователей. Для двусторонней аутентификации IPSec-устройств применяются либо сертификаты, либо предварительно распределяемые пароли. В процессе “переговоров” VPN-хосты проводят взаимную аутентификацию. В случае удаленного доступа возникает дилемма: вы должны использовать механизм PKI для выдачи сертификатов (весьма дорогое удовольствие) или же распределить пароли по всем конечным пользователям. На самом же деле всего-навсего нужно на основе имеющейся БД аутентифицировать пользователя, пытающегося установить соединение с частной сетью. Механизм IKE не поддерживает аутентификацию по имени и паролю, в то время как ISAKMP в этом отношении расширяем.

Протокол XAUTH (Extended Authentication Within ISAKMP/Oakley) позволяет вам аутентифицировать пользователя унаследованными методами по завершении фазы 1. XAUTH представляет собой односторонний метод аутентификации. По завершении XAUTH-переговоров осуществляется переход к фазе 2. Вместе с тем протокол XAUTH не решает проблему удаленной аутентификации пользователей полностью, поскольку IP-адреса последних должны быть известны заранее. Для IKE разработан метод Hybrid Authentication Mode, при котором используются два односторонних механизма аутентификации для взаимной идентификации хостов. Этот метод применяется тогда, когда клиентские IP-адреса неизвестны или у конечных пользователей отсутствуют цифровые сертификаты. Hybrid Authentication Mode реализуется на фазе 1 с целью аутентификации VPN-шлюза. По ее завершении шлюз инициирует транзакционный обмен по протоколу XAUTH и аутентифицирует конечного пользователя. В случае успеха заключается SA-соглашение и процесс переходит в фазу 2.

Термины IPSec

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

Identity. Данный термин имеет несколько толкований, но там, где речь идет о предварительно распределяемых секретах (паролях), он обозначает IP-адрес хоста или подсети.

Internet Key Exchange (IKE). Протокол защиты, предназначенный для обмена и управления ключами шифрования. Может использовать предварительно распределяемые секреты или сертификаты X.509.

Фаза 1 (основной режим). Относится к началу заключения соглашения SA (Security Association) между двумя конечными узлами IPSec. Соглашения фазы 1 устанавливают базовые параметры безопасности для обмена ключами в рамках данного и последующих SA-соглашений.

Фаза 2 (быстрый режим). Будучи защищенной в соответствии с соглашениями, достигнутыми на фазе 1, устанавливает параметры безопасности SA для IPSec-соединений.

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

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

Security Association (SA). Обеспечивает защиту трафика всех членов ассоциации, включая услуги шифрования, контроль целостности и управление ключами шифрования.





  
8 '2000
СОДЕРЖАНИЕ

колонка редактора

• Тупую сеть интеллектом не испортишь

локальные сети

• Элегантные кабельные розетки пополняют ряды Категории 6

• Повышение гибкости кабельной проводки, или Вторая жизнь кабелепроводов

• Служба RIS Windows 2000: снижаем затраты на ИТ

услуги сетей связи

• Интервью с руководителем департамента радио, телевидения и спутниковой связи Министерства РФ по связи и информатизации Василием Илларионовичем Павловым

• Беспроводные коммуникации: взгляд Hewlett-Packard

• IP-телефония - это не только дешевая связь

• Беспроводные мосты соединяют

• Оптимизация решений для беспроводной IP-телефонии

• IP-телефония: "cветлое будущее" или..?

новые продукты

• SURPASS открывает новые горизонты перед операторами

только на сервере

• Snap Server 1000 впечатляет

• Проблемы интероперабельности решений на основе IPSec

• Параллельные миры

корпоративные сети

• Почему ваша сеть стала работать медленно? Откройте ей "второе дыхание". Часть 1

• Подключение карманных компьютеров к корпоративной сети

• Unix BSD: жизнь продолжается

защита данных

• Защита информации на предприятии

• Информационная защита сервера Windows NT

электронная коммерция

• XML достигает "совершеннолетия"

бизнес

• Мушкетеры отечественной промышленности: АПОС, СППОСС и РОСС

• Lucent объявляет о начале эры "Фотонной Долины"

• Новая стратегия Novell

• Дистрибуция конвергированных решений

системы учрежденческой связи

• Корабль телефонии меняет курс


• КАЛЕЙДОСКОП



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх