Построение защищенных виртуальных сетей
3.1. Введение в защищенные виртуальные сети
Безопасность информационного взаимодействия локальных сетей и отдельных компьютеров через открытые сети, например, через сеть Internet, требует качественного решения двух базовых задач (рис. 3.1):
● защиты подключенных к публичным каналам связи локальных сетей и отдельных компьютеров от несанкционированных действий со стороны внешней среды;
● защиты информации в процессе передачи по открытым каналам связь.
Решение первой задачи основано на использовании рассмотренных выше межсетевых экранов (брандмауэров), поддерживающих безопасность информационного взаимодействия путем фильтрации двустороннего потока сообщений, а также выполнения функций посредничества при обмене информацией. Для защиты локальных сетей брандмауэр располагают на стыке между локальной и открытой сетью. Для защиты отдельного удаленного компьютера, подключенного к открытой сети, программное обеспечение межсетевого экрана устанавливается на этом же компьютере, а сам межсетевой экран в этом случае называют персональным.
Зашита информации в процессе передачи по открытым каналам связи основана на выполнении следующих функций:
● аутентификации взаимодействующих сторон;
● криптографическом закрытии передаваемых данных;
● подтверждении подлинности и целостности доставленной информации;
● защите от повтора, задержки и удаления сообщений;
● защите от отрицания фактов отправления и приема сообщений.
Перечисленные функции во многом связаны друг с другом, и их реализация основана на криптографической защите передаваемых данных. Высокая эффективность такой защиты обеспечивается за счет совместного использования симметричных и асимметричных криптографических систем.
Объединение локальных сетей и отдельных компьютеров через открытую внешнюю среду передачи информации в единую виртуальную сеть, обеспечивающую безопасность циркулирующих данных, называют защищенной виртуальной сетью (Virtual Private Network — VPN). Виртуальная сеть формируется на основе каналов связи открытой сети. Сам термин "виртуальная" подчеркивает, что каналы связи виртуальной сети моделируются с помощью каналов связи реальной. Открытая сеть может служить основой для одновременного сосуществования множества виртуальных сетей, количество которых определяется пропускной способностью открытых каналов связи.
Открытую внешнюю среду передачи информации можно разделить на среду
скоростной передачи данных, в качестве которой может использоваться сеть Internet, а также более медленные общедоступные каналы связи, в качестве которых чаще всего применяются каналы телефонной сети. Наиболее эффективным способом объединения локальных сетей и удаленных компьютеров является объединение на основе глобальной сети Internet (рис. 3.2). В случае отсутствия непосредственного подключения доступ к Internet может осуществляться и через телефонную сеть. Организация виртуальных сетей на основе Internet обладает рядом преимуществ:
• гарантирует высокое качество информационного обмена, так как магистральные каналы и маршрутизаторы Internet имеют большую пропускную способность, и характеризуются надежностью передачи информации;
• обеспечивает масштабируемую поддержку удаленного доступа к ресурсам локальной сети, позволяя мобильным пользователям связываться по местным телефонным линиям с поставщиками услуг Internet и через них входить в свою корпоративную сеть;
• для организации удаленного доступа пользователей к локальной сети исключается необходимость в наличии модемных пулов, а трафиком дистанционного доступа можно управлять точно так же, как любым другим трафиком Internet;
• сокращаются расходы на информационный обмен через открытую внешнюю среду:
• использование Internet для объединения локальных сетей значительно дешевле аренды каналов связи телефонных и других глобальных сетей, например, сетей frame relay, не говоря уже о стоимости самостоятельного построения коммуникаций;
• при удаленном доступе вместо того, чтобы устанавливать дорогостоящие
непосредственные соединения с локальной сетью по междугородной или международной телефонной связи, удаленные пользователи могут подключаться к Internet и, далее, связываться с сетью своей организации через эту глобальную сеть.
Виртуальную сеть, использующую в качестве внешней среды передачи информации глобальную сеть Internet, часто называют еще сетью Extranet.
Эффективность использования виртуальных сетей во многом определяешься степенью защищенности информации, циркулирующей по открытым каналам связи. Безопасность информационного обмена необходимо обеспечить как в случае объединения локальных сетей, так и в случае доступа к локальным сетям удаленных пользователей (рис. 3.2). Защита информации в процессе ее передачи по открытым каналам основана на построении защищенных виртуальных каналов связи, называемых криптозащищенными туннелями или туннелями VPN. Каждый такой туннель представляет собой соединение, проведенное через открытую сеть, по которому передаются криптографический защищенные пакеты сообщений виртуальной сети.
Для защиты от повтора, удаления и задержек пакетов сообщений, передаваемых по туннелю VPN, используются встроенные возможности стека протоколов ТСР/IP. Для защиты от повтора, удаления и задержек на уровне отдельных сообщений в состав каждого сообщения подсистемой защиты прикладного уровня должна добавляться дополнительная информация. В "качестве такой дополнительной информации могут использоваться номера, :случайные числа, а также отметки времени.
С целью защиты от отказа получения сообщений подсистема защиты прикладного уровня должна предусматривать при приеме каждого сообщения передачу отправителю уведомления о получении сообщения. Такое уведомление должно криптографический подписываться получателем сообщения.. Защита от отказа отправления сообщения, т. е. защита от непризнания цифровой подписи может быть обеспечена только правовыми и организационными мерами по приданию цифровой подписи юридической силы. Чтобы предотвратить отказы от открытых ключей, а соответственно и отказы от цифровой подписи обмен открытыми ключами должен подкрепляться юридической процедурой.
3.1.2. Способы создания защищенных виртуальных каналов
Любой из двух узлов виртуальной сети, между которыми формируется защищенный туннель, может принадлежать конечной или промежуточной точке защищаемого потока сообщений. Соответственно возможны различные способы образования защищенного виртуального канала (рис. 3.3).
Вариант, когда конечные точки защищенного туннеля совпадают с конечными точками защищаемого потока сообщений, является с точки зрения безопасности лучшим. В этом случае обеспечивается полная защищенность канала вдоль всего пути следования пакетов сообщений. Однако такой вариант ведет к децентрализации управления и избыточности ресурсных затрат. Требуется установка средств создания защищенных туннелей на каждый клиентский компьютер локальной сети, что усложняет централизованное управление доступом к компьютерным ресурсам и экономически не всегда оправдано. В большой сети отдельное администрирование каждого клиентского компьютера с целью конфигурирования в нем средств защиты является достаточно трудоемкой процедурой.
Поэтому, если отсутствует необходимость защиты трафика внутри локальной сети, входящей в виртуальную сеть, то в качестве конечной точки защищенного туннеля целесообразно выбрать брандмауэр или пограничный маршрутизатор этой локальной сети. В случае же, когда внутри локальной сети поток сообщений также должен быть защищен, то в качестве конечной точки туннеля в этой сети должен выступать компьютер, представляющий одну из сторон защищенного взаимодействия. При доступе к локальной сети удаленного пользователя компьютер этого пользователя также должен быть конечной точкой защищенного виртуального канала.
Распространен также вариант, характеризующийся более низкой безопасностью, но более высоким удобством применения. Согласно данному варианту рабочие станции и серверы локальной сети, а также удаленные компьютеры не участвуют в создании защищенного туннеля, который прокладывается только внутри публичной сети с коммутацией пакетов, например, внутри Internet. В качестве конечных точек такого туннеля чаще всего выступают провайдеры Internet и/или пограничные маршрутизаторы (брандмауэры) локальной сети. При удаленном доступе к локальной сети туннель создается между сервером удаленного доступа провайдера Internet, а также пограничным провайдером Internet или маршрутизатором (брандмауэром) локальной | сети. При объединении локальных сетей туннель формироваться только между пограничными провайдерами Internet и/или маршрутизаторами (брандмауэрами) локальной сети.
Аргументацией в пользу описанного варианта создания виртуальных сетей выступает тот факт, что уязвимыми для злоумышленников в большей степени являются сети с коммутацией пакетов, такие, как Internet, а не каналы телефонной сети или выделенные каналы связи. Виртуальные сети, построенные по данному варианту, обладают хорошей масштабируемостью и управляемостью. Для клиентских компьютеров и серверов локальной сети, входящей в виртуальную сеть, защищенные туннели полностью прозрачны и программное обеспечение этих узлов остается без изменений. Однако по причине того, что часть защищаемого трафика проходит в незащищенном виде по публичным каналам связи, данный вариант существенно снижает безопасность информационного взаимодействия. Кроме того, большая часть работы по созданию защищенных туннелей ложится на провайдеров, которым необходимо доверять и платить.
Создание защищенного туннеля выполняют компоненты виртуальной сети, функционирующие на узлах, между которыми формируется туннель. Эти компоненты принято называть инициатором и терминатором туннеля. Инициатор туннеля инкапсулирует (встраивает) пакеты в новый пакет, сoдержащий наряду с исходными данными новый заголовок с информацией об отправителе и получателе. Хотя все передаваемые по туннелю пакеты являются пакетами IP, инкапсулируемые пакеты могут принадлежать к протоколу любого типа, включая пакеты немаршрутизируемых протоколов, таких как NetBEUI. Маршрут между инициатором и терминатором туннеля определяет обычная маршрутизируемая сеть IP, которая может быть и ceтью, отличной от Internet. Терминатор туннеля выполняет процесс, обратный инкапсуляции — он удаляет новые заголовки и направляет каждый исходный пакет в локальный стек протоколов или адресату в локальной сети.
Сама по себе инкапсуляция никак не влияет на защищенность пакетов сообщений, передаваемых по туннелю VPN. Но благодаря инкапсуляции появляется возможность полной криптографической защиты инкапсулируемых пакетов. Конфиденциальность инкапсулируемых пакетов обеспечивается путем их криптографического закрытия, т. е. зашифровывания, а целостность и подлинность — путем формирования цифровой подписи. Поскольку существует большое множество методов криптозащиты данных, очень важно, чтобы инициатор и терминатор туннеля использовали одни и те же методы и могли согласовывать друг с другом эту информацию. Кроме того, для возможности расшифровывания данных и проверки цифровой подписи при приеме инициатор и терминатор туннеля должны поддерживать функции безопасного обмена ключами. Чтобы туннели VPN создавались только между уполномоченными пользователями, конечные стороны взаимодействия требуется аутентифицировать.
Технически реализация защищенных виртуальных сетей стала возможной уже достаточно давно. Инкапсуляция использовалась раньше и применяется сейчас для передачи немаршрутизируемого трафика через маршрутизируемые сети, а также для ограничения многопротокольного трафика одним протоколом. Технологии шифрования также появились задолго до широкого внедрения глобальных сетевых технологий. Однако общепринятые протоколы для создания защищенных виртуальных сетей разработаны недавно и сейчас продолжается работа над их совершенствованием и расширением. Они являются открытыми, т. е. свободными для распространения и реализации. Для независимости от прикладных протоколов и приложений защищенные виртуальные сети формируются на одном из более низких уровней модели OSI — канальном, сетевом или сеансовом. Канальному (второму) уровню соответствуют такие протоколы реализации VPN, как PPTP, L2F и L2TP, сетевому (третьему) уровню — IPSec, SKIP, а сеансовому (пятому) уровню — SSL/TLS и SOCKS. Чем ниже уровень эталонной модели, на котором реализуется защита, тем она прозрачнее для приложений и незаметнее для пользователей. Однако при снижении этого уровня уменьшается набор услуг безопасности и становится сложнее организация управления. Чем выше защитный уровень в соответствии с моделью OSI, тем шире набор услуг безопасности, надежнее контроль доступа и проще конфигурирование системы защиты. Однако в этом случае усиливается зависимость от используемых протоколов обмена и приложений. В виртуальной сети криптозащита может одновременно выполняться на не- .скольких уровнях эталонной модели. При этом увеличивается криптостойкость, но по причине снижения общей скорости криптографических преобразований уменьшается пропускная способность виртуальной сети. Поэтому на практике защищенные виртуальные сети формируются на одном уровне модели OSI (канальном, сетевом, транспортном или сеансовом).
Для стандартного формирования криптозащищенных туннелей на канальном уровне модели OSI компанией Microsoft при поддержке компаний Ascend Communications, 3Com/Primary Access, ECI-Telematics и US Robotics был разработан протокол туннелирования PPTP (Point-to-Point Tunneling Protocol), представляющий собой расширение протокола PPP (Point-to-Point Protocol). В протоколе PPTP не специфицируются конкретные методы аутентификации и шифрования. Клиенты удаленного доступа в Windows NT 4.0 и Windows 98 с Dial-Up Networking поставляются с версией шифрования DES компании RSA Data Security, получившей название "шифрование двух- точечной связи Microsoft" (Microsoft Point-to-Point Encryption — MPPE).
Канальному уровню модели OSI соответствует также протокол туннелирования L2F (Layer-2 Forwarding), разработанный компанией Cisco Systems при поддержке компаний Shiva и Northern Telecom. В данном протоколе также не специфицируются конкретные методы аутентификации и шифрования. В отличие от протокола PPTP протокол L2F позволяет использовать для удаленного доступа к провайдеру Internet не только протокол PPP, но и другие протоколы, например, SLIP. При формировании защищенных каналов по глобальной сети провайдерам Internet не нужно осуществлять конфигурацию адресов и выполнять аутентификацию. Кроме того, для переноса данных через защищенный туннель могут использоваться различные протоколы сетевого уровня, а не только IP, как в протоколе PPTP. Протокол L2F стал компонентом операционной системы IOS (Internetwork Operating System) компании Cisco и поддерживается во всех выпускаемых ею устройствах межсетевого взаимодействия и удаленного доступа.
Протоколы PPTP и L2F были представлены в организацию Internet Engineering Task Force (IETF) и в 1996 году соответствующие комитеты ре- шили их объединить. Получившийся в результате протокол, включивший . все лучшее из PPTP и L2F, был назван протоколом туннелирования второго, уровня (Layer-2 Tunneling Protocol — L2TP). Его поддерживают компании Cisco, Microsoft, 3Com, Ascend и многие другие производители. Как и пред- 4 шествующие протоколы канального уровня, спецификация L2TP не . описывает методы аутентификации и шифрования. Протокол L2TP является
расширением PPP на канальном уровне и может поддерживать любые высокоуровневые протоколы.
Протоколы формирования защищенного туннеля на канальном уровне независимы от протоколов сетевого уровня модели OSI, по которым функционируют локальные сети, входящие в состав виртуальных сетей. Они позволяет создавать защищенные каналы для обмена данными между удаленными компьютерами и локальными сетями, функционирующими по различным протоколам сетевого уровня — IP, IPX или NetBEUI. Пакеты; этих протоколов криптографический защищаются и инкапсулируются в IP- Д' пакеты сети Internet, которые и переносятся к месту назначения, образуя защищенные виртуальные каналы. Многопротокольность — основное преимущество инкапсулирующих протоколов канального уровня.
Вместе с тем формирование криптозащищенных туннелей между объединяемыми локальными сетями на основе протоколов канального уровня приводит к сложности конфигурирования и поддержки виртуальных каналов связи. Туннели на основе PPP требуют, чтобы конечные точки поддерживали информацию о состоянии каждого канала (например, такую, как тайм-ауты), и, следовательно, не обладают хорошей масштабируемостью при необходимости иметь несколько туннелей с общими конечными точками. Кроме того, протоколы формирования защищенных туннелей на канальном уровне не специфицируют конкретные методы шифрования, аутентификации, проверки целостности каждого передаваемого пакета, а также средств управления ключами.
Исходя из вышесказанного, можно сделать вывод, что протоколы создания защищенных виртуальных каналов на канальном уровне лучше всего подходят для защиты информационного взаимодействия при удаленном доступе к локальной сети. Учитывая, что в состав операционных систем Windows 98/ХТ включена реализация протокола PPTP, этот протокол для организации защищенного удаленного доступа получил наиболее широкое распространение. В ближайшее время ожидается переориентация средств удален- ного доступа на более совершенный протокол L2TP.
Спецификацией, где описаны стандартные методы для всех компонентов и функций защищенных виртуальных сетей, является протокол Internet Protocol Security (IPSec), соответствующий сетевому уровню модели 0SI и входящий в состав новой версии протокола IP — IPv6. Протокол IPSec иногда еще называют протоколом туннелирования третьего уровня (Layers Tunneling) . IPSec предусматривает стандартные методы аутентификации пользователей или компьютеров при инициации туннеля, стандартные способы шифрования конечными точками туннеля, формирования и проверки цифровой подписи, а также стандартные методы обмена и управления криптографическими ключами между конечными точками. Этот гибкий стандарт предлагает несколько способов для выполнения каждой задачи. Выбранные методы для одной задачи обычно не зависят от методов реализации других задач. Для функций аутентификации IPSec поддерживает цифровые сертификаты популярного стандарта Х.509.
Туннель IPSec между двумя локальными сетями может поддерживать множество индивидуальных каналов передачи данных, в результате чего приложения данного типа получают преимущества с точки зрения масштабирования по сравнению с технологией второго уровня. Протокол IPSec может использоваться совместно с протоколом L2TP. Совместно эти два протокола обеспечивают наиболее высокий уровень гибкости при защите виртуальных каналов. Дело в том, что спецификация IPSec ориентирована на протокол IP и, таким образом, бесполезна для трафика любых других протоколов сетевого уровня. Протокол L2TP отличается независимостью от транспортного уровня, что может быть полезно в гетерогенных сетях, состоящих из IP-, IPX- и AppleTalk-сегментов. IPSec стремительно завоевывает популярность и станет, вероятно, доминирующим стандартом по созданию и поддержке защищенных виртуальных сетей.
Для управления криптографическими ключами на сетевом уровне модели OSI наиболее широкое распространение получили такие протоколы, как SKIP (Simple Кеу management for Internet Protocols) и ISAKMP (Internet Security Association and Key Management Protocol). SKIP проще в реализации, но он не поддерживает переговоров по поводу алгоритмов шифрования. Если получатель, использующий SKIP, не в состоянии расшифровать пакет, он уже не сможет согласовать метод шифрования с противоположной стороной. Протокол ISAKMP поддерживает такие переговоры и выбран в качестве обязательного протокола для управления ключами в IPSec для IPv6. Другими словами протокол ISAKMP является составной частью протокола IPSec. В текущей четвертой версии протокола IP (в протоколе IPv4) может применяться как протокол ISAKMP, так и протокол SKIP.
Защищенные виртуальные каналы могут быть сформированы и на сеансовом уровне модели OSI. Для этого применяются так называемые "посредники каналов" (circuit proxy). Посредник функционирует над транспортным уровнем, шифрует и ретранслирует трафик из защищенной сети в общедоступную сеть Internet для каждого сокета в отдельности. При приеме выполняется обратная процедура. Сокет IP идентифицируется комбинацией TCP- соединения и конкретного порта или заданным портом UDP.
Для шифрования информации на сеансовом уровне наибольшую популярность получил протокол SSL/TLS (Secure Sockets Layer Transport Layer Security), разработанный компанией Netscape Communications. Этот протокол, создает защищенный туннель между конечными точками виртуальной сети, обеспечивая взаимную аутентификацию абонентов, а также конфиденциальность, подлинность и целостность циркулирующих по туннелю данных. Ядром протокола SSL/TLS является технология комплексного использования асимметричных и симметричных криптосистем компании RSA Data Security.- Для аутентификации взаимодействующих сторон и криптозащиты ключа симметричного шифрования используются цифровые сертификаты открытых ключей пользователей (клиента и сервера), заверенные цифровыми подписями специальных Сертификационных Центров. Поддерживаются цифровые сертификаты, соответствующие общепринятому стандарту Х.509. С целью стандартизации процедуры взаимодействия клиент-серверных приложений ТСР/IP через сервер-посредник (брандмауэр) комитет IETF утвердил протокол под названием SOCKS, и в настоящее время пятая версия: данного протокола (SOCKS 5) применяется для стандартизованной реализации посредников каналов. SOCKS поддерживает приложения, требующие контроля над направлениями информационных потоков и настройки условий доступа в зависимости от атрибутов пользователя и/или информации.
В соответствии с SOCKS 5 клиентский компьютер устанавливает аутентифицированный сеанс с сервером, исполняющим роль посредника (proxy). Использование этого посредника является единственным способом связи через брандмауэр. Посредник, в свою очередь, проводит любые операции, запрашиваемые клиентом. Поскольку посреднику известно о трафике на уровне сеанса (сокета), он может осуществлять тщательный контроль, например, блокировать конкретные приложения пользователей, если они не имеют необходимых полномочий.
В отличие от виртуальных сетей, защищенных на сеансовом уровне модели OSI, виртуальные сети, защищенные на канальном или сетевом уровне, обычно просто открывают или закрывают канал для всего трафика по аутентифицированному туннелю. Это может представлять проблему, если локальная сеть на другом конце туннеля является неблагонадежной. Кроме того, созданные туннели канального и сетевого уровня функционируют одинаково в обоих направлениях, а виртуальные сети, защищенные на сеансовом уровне, допускают независимое управление передачей в каждом направлении.
Виртуальные сети с посредником канала типа IPSec ориентированы на протокол IP. Если IPSec, по существу, разграничивает защищенные виртуальные каналы между разными парами взаимодействующих сторон, то протокол SOCKS 5 обеспечивает создание защищенных туннелей для каждого приложения и сеанса в отдельности. Аналогично протоколу IPSec и протоколам туннелирования канального уровня, виртуальные сети сеансового уровня можно использовать с другими типами виртуальных частных сетей, поскольку данные технологии не являются взаимоисключающими.
Следует отметить, что имеются протоколы для реализации защищенного взаимодействия и на прикладном уровне модели OSI. Эти протоколы, как правило, являются дополнениями к различным протоколам прикладного уровня. Например, протокол Secure НТТР (SHTTP) является дополнением : по функциям защиты к протоколу передачи гипертекста НТТР, а протокол Secure MIME (S/MIME) — дополнением по защитным функциям к протоколу электронной почты MIME. Прикладные протоколы защиты информационного взаимодействия не относят к протоколам построения защищенных виртуальных сетей, так как они полностью зависят от используемых сервисов и приложений. Протоколы формирования защищенных виртуальных каналов прозрачны для прикладных протоколов защиты. Соответственно применение предложений, реализующих, например, SHTTP или S/MIME, наряду с криптографической защитой на более низком уровне, нисколько не уменьшает, а только увеличивает уровень безопасности.
3.2. Туннелирование на канальном уровне
Протокол PPTP (Point-to-Point-Tunneling Protocol), разработанный Microsoft . При поддержке других компаний, представляет собой расширение протокола . PPP (Point-to-Point Protocol) для создания защищенных виртуальных каналов при доступе удаленных пользователей к локальным сетям через Internet. Он предусматривает создание криптозащищенного туннеля на канальном уровне модели OSI как в случае прямого соединения удаленного компьютера с публичной сетью, так и в случае подсоединения его к публичной сети по телефонной линии через провайдера.
Данный протокол был представлен в организацию Internet Engineering Task Force (IETF) в качестве претендента на стандартный протокол создания защищенного канала при доступе удаленных пользователей к локальным ceтям через публичные сети (в первую очередь через Internet). PPTP получил статус проекта стандарта Internet, однако, несмотря на широкое распространение, в качестве стандарта так и не был утвержден. Сейчас рабочая группа IETF рассматривает возможность принятия в качестве стандарта протокол L2TP (Layer 2 Tunneling Protocol), который объединяет лучшие стороны протокола PPTP и подобного протокола L2F (Layer 2 Forwarding), предложенного компанией Cisco Systems.
Для удаленного пользователя, подключенного через публичную IP-сеть к серверу удаленного доступа (Remote Access Service — RAS) локальной сети, PPTP имитирует нахождение компьютера этого пользователя во внутренней сети посредством туннелирования пакетов сообщений. Данные через туннель переносятся с помощью стандартного протокола удаленного доступа PPP, который в протоколе PPTP используется не только для связи компьютера удаленного пользователя с RAS провайдера Internet, но и для взаимо действия с RAS локальной сети через туннель. Для передачи данных применяются Ip-пакеты, содержащие инкапсулированные PPP-пакеты. Инкапсулированные PPP-пакеты в свою очередь включают зашифрованные инкапсулированные исходные пакеты (IP, IPX или NetBEUI), предназначенные для взаимодействия между компьютером удаленного пользователя и локальной сетью. Пакеты, циркулирующие в рамках сессии PPTP, имеют следующую структуру:
• заголовок канального уровня, используемый внутри Internet, например, заголовок кадра Ethernet;
• заголовок IP;
• заголовок (ЖЕ (Generic Routing Encapsulation — общий метод инкапсуляции для маршрутизации);
• исходный пакет PPP, включающий пакет IP, IPX или NetBEUI.
Для указания сведений о том, что внутри пакета IP находится инкапсулированный пакет PPP, используется стандартный для Internet заголовок протокола GRE ч.2, используемый при инкапсуляции различного типа.
Описанный способ инкапсуляции обеспечивает независимость от протоколов сетевого уровня модели OSI и позволяет осуществлять защищенный удаленный доступ через публичные IP-сети к любым локальным сетям (IP, IPX или NetBEUI).
Технология создания защищенного виртуального канала по протоколу PPTP предусматривает как аутентификацию удаленного пользователя, так и зашифрованную передачу данных.
Для аутентификации могут использоваться различные протоколы. В реализации PPTP, включенной в Windows 98/NT, поддерживаются протоколы аутентификации PAP (Password Authentication Protocol — протокол распознавания пароля) и CHAP (Challenge-Handshaking Authentication Protocol— протокол распознавания при рукопожатии). При использовании протокола PAP идентификаторы и пароли передаются по линии связи в незашифрованном виде. При использовании же протокола CHAP каждый пароль для передачи по линии связи шифруется на основе случайного числа, получен- ного от сервера. Такая технология обеспечивает также защиту от повторного использования злоумышленником перехваченных пакетов с зашифрованным паролем.
Программное обеспечение удаленного доступа, реализующее PPTP, может использовать любой стандарт криптографического закрытия передаваемых данных. Например, сервер удаленного доступа Windows NT использует стандарт RC4 и в зависимости от версии 40 или 128-разрядные сеансовые ключи, которые генерируются на основе пароля пользователя.
В протоколе PPTP определено три схемы его применения: одна схема для случая прямого соединения компьютера удаленного пользователя с Internet и две для случая подсоединения удаленного компьютера к Internet по телефонной линии через провайдера.
При прямом соединении компьютера удаленного пользователя с сетью Internet (рис. 3.4), например, при доступе из локальной сети, напрямую подключенной к Internet, пользователь устанавливает удаленное соединение с помощью клиентской части сервиса удаленного доступа. Он обращается к серверу удаленного доступа локальной сети, указывая его IP-адрес, и устанавливает с ним связь по протоколу PPTP. Функции сервера удаленного доступа может выполнять и пограничный маршрутизатор локальной сети. Протокол PPTP определяет некоторое количество служебных сообщений, которыми обмениваются взаимодействующие стороны. Служебные сообщения передаются по протоколу TCP. После успешной аутентификации начинается процесс защищенного информационного обмена.
В этом варианте на компьютере удаленного пользователя должны быть установлены клиент RAS и драйвер PPTP, которые входят в состав Windows 98/NT, а на сервере удаленного доступа локальной сети — сервер RAS и драйвер PPTP, входящие в состав Windows NT Server. Внутренние серверы локальной сети не должны поддерживать протокол PPTP, так как пограничный маршрутизатор извлекает кадры PPP из пакетов IP и посылает их по сети в необходимом формате — IP, IPX или NetBIOS.
Для случая подсоединения удаленного компьютера к Internet по телефонной линии через провайдера предусмотрено две схемы (рис. 3.5).
Первая схема рассчитана на поддержание защищенного канала между сервером удаленного доступа провайдера Internet и пограничным маршрутизатором локальной сети (рис. 3.5). В этом варианте компьютер удаленного пользователя не должен поддерживать протокол PPTP. Он связывается с сервером удаленного доступа провайдера с помощью стандартного протокола PPP и проходит аутентификацию у провайдера. Сервер удаленного доступа (RAS) провайдера должен поддерживать протокол PPTP. По имени пользователя RAS провайдера находит в базе учетных данных пользователей IP-адрес маршрутизатора, являющегося пограничным маршрутизатором и сервером удаленного доступа локальной сети данного пользователя. С этим маршрутизатором RAS ISP устанавливает сессию по протоколу PPTP.
RAS провайдера передает серверу удаленного доступа локальной сети идентификатор пользователя и другие данные, на основе которых этот сервер, снова аутентифицирует пользователя по протоколу CHAP. Если пользователь прошел эту аутентификацию, которая для него является прозрачной, то RAS провайдера посылает ему сообщение об этом по протоколу PPP и далее формируется защищенный виртуальный канал между серверами удаленного,. доступа провайдера и локальной сети. Компьютер удаленного пользователя посыпает пакеты взаимодействия с локальной сетью (IP, IPX или NetBIOS) к серверу удаленного доступа (RAS) провайдера, упаковывая их в кадры PPP. RAS провайдера осуществляет инкапсуляцию кадров PPP в пакеты IP, указывая в качестве адреса назначения адрес пограничного маршрутизатора локальной сети, а в качестве адреса источника — свой собственный IP- адрес. Пакеты PPP для следования между серверами удаленного доступа провайдера и локальной сети шифруются с помощью секретного ключа, в качестве которого используется значение хзш-функции от пароля пользователя, который хранится в базе учетных данных RAS провайдера для аутентификации по протоколу СТАР.
Описанная схема не находит широкого применения, так протокол PPTg реализован в основном в продуктах компании Microsoft — в клиентской и серверной частях RAS Windows NT 4.0, а также в клиентской части RAS Windows 98. В качестве сервера удаленного доступа провайдеры чаще всего используют более мощные средства, чем RAS Windows NT. Кроме того,
данная схема не обеспечивает высокой степени безопасности, так как между , компьютером удаленного пользователя и провайдером Internet данные передаются в незащищенном виде. Для случая подсоединения удаленного компьютера к Internet по телефонной линии через провайдера более широкое применение получила вторая схема (см. рис. 3.5), когда криптозащищенный туннель образуется между конечными точками взаимодействия.
Пользователь дважды устанавливает удаленное соединение с помощью клиентской части сервиса удаленного доступа, например, утилиты Dial-Up Networking из Windows 98/NT. В первый раз он звонит по модему на сервер удаленного доступа провайдера и устанавливает с ним связь по протоколу PPP, проходя аутентификацию одним из способов, поддерживаемых провайдером, по протоколам PAP, CТAP или с помощью терминального диалога.
После успешной аутентификации у провайдера, пользователь устанавливает соединение с сервером удаленного доступа локальной сети, указывая его IP- адрес. Далее устанавливается сессия по протоколу PPTP между удаленным компьютером и RAS локальной сети. Сервер удаленного доступа локальной сети проверяет подлинность пользователя на основе своей базы учетных данных. В случае успешной аутентификации начинается процесс защищенного информационного обмена. Для сокращения ручного труда Microsoft предлагает пользоваться возможностями языка написания сценариев (языка скриптов) в RAS Windows 98/NT.
Для взаимодействия между пограничными устройствами криптозащищенного туннеля в протоколе PPTP предусмотрены управляющие сообщения, предназначенные для установки, поддержки и разрыва туннеля. Обмен управляющими сообщениями выполняется по TCP-соединению, устанавливаемому между клиентом и сервером PPTP. Пакеты, передаваемые через это соединение, помимо заголовка канального уровня, содержат заголовок протокола IP, заголовок протокола TCP и управляющее сообщение PPTP в области данных пакета. Если компьютер удаленного пользователя не имеет поддержки PPTP, что характерно для схемы создания защищенного канала между сервером удаленного доступа провайдера Internet и пограничным маршрутизатором локальной сети, то в процессе обмена управляющими со- общениями этот компьютер не участвует. Функции клиента PPTP в данном случае возложены на сервер удаленного доступа провайдера Internet.
При обмене управляющими сообщениями PPTP используется логический . порт протокола TCP с номером 1723, а при передаче инкапсулированных пакетов PPP в заголовке IP устанавливается идентификатор протокола, равный 47. Эти соглашения позволяют использовать технологию PPTP совместно с межсетевыми экранами. Для повышения безопасности следует с помощью межсетевого экрана локальной сети блокировать любой трафик, отличный от трафика PPTP.
Протокол L2F (Layer-2 Forwarding) разработан компанией Cisco Systems при поддержке компаний Shiva и Northern Telecom в качестве альтернативы протоколу PPTP для создания защищенных виртуальных сетей на канальном уровне модели OSI. В отличие от PPTP, данный протокол характеризуется более высоким удобством в использовании для провайдеров Internet, a также поддержкой разных сетевых протоколов. В соответствии с протоколом L2F для связи компьютера удаленного пользователя с сервером провайдера могут применяться различные протоколы удаленного доступа — PPP, SLIP и другие. Публичная сеть, используемая для переноса данных через туннель, может функционировать не только по протоколу IP, но и на основе других протоколов, например, протокола Х.25. Первая реализация протокола L2F выполнена для сетей.
Помимо ориентации на различные протоколы информационного обмена, при разработке протокола L2F также преследовались следующие цели:
• гибкость аутентификации, предусматривающая отсутствие жесткой при- вязки к конкретным протоколам подтверждения подлинности;
• прозрачность для конечных систем — ни удаленная система, ни рабочие станции локальной сети не должны иметь специальное программное обеспечение, чтобы использовать защитный сервис;
• прозрачность для посредников: авторизация должна выполняться так, как в случае непосредственного подключения пользователей к серверу удаленного доступа локальной сети;
• адрес сервера удаленного доступа должен назначаться не сервером провайдера, а сервером локальной сети;
• полнота аудита, предусматривающая регистрацию событий по доступу к серверу локальной сети не только сервером удаленного доступа этой сети, но и сервером провайдера.
Можно выделить три типа протоколов, участвующих в образовании защищенного туннеля:
• исходный инкапсулируемый протокол — это протокол, по которому функционирует локальная сеть и который используется для непосредственного взаимодействия с этой локальной сетью, например, протокол IP, IPX или NetBEUI;
• протокол-пассажир, в который инкапсулируется исходный протокол и который в свою очередь требуется инкапсулировать при удаленном доступе через публичную сеть (в качестве данного протокола рекомендован протокол РРР);
• инкапсулирующий протокол — это управляющий протокол, который
используется для создания, поддержания и разрыва туннеля (в данном случае в качестве такого протокола выступает протокол L2F);
• протокол провайдера, который используется для переноса инкапсулируемых протоколов (исходного протокола и протокола-пассажира); наиболее гибким и популярным протоколом провайдера является протокол IP.
Формирование виртуального канала по протоколу L2F выполняется в соответствии со следующими этапами (рис. 3.6).
Этап 1. Удаленный пользователь устанавливает соединение с сервером RAS (Remote Access Service) провайдера по протоколу PPP. Далее RAS провайдера начинает процесс аутентификации на основе используемого протокола (CТAP, PAP или другого). В соответствии с протоколом CТAP после установления соединения сервер RAS провайдера запрашивает у пользователя пароль пакетом "Вызов" (Challenge), включающим псевдослучайное число.
Проверяемая сторона отвечает пакетом "Отклик" (Response), содержащим идентификатор пользователя, а также число, сгенерированное с помощью односторонней хэш-функции на основе псевдослучайного числа и пароля пользователя.
Этап 2. В процессе аутентификации RAS провайдера интерпретирует только идентификатор пользователя, чтобы определить необходимость создания виртуального канала, а в случае необходимости найти адрес пограничного маршрутизатора требуемой локальной сети. Идентификатор пользователя, а также другие данные, полученные на этой стадии аутентификации, сохраняются для передачи серверу удаленного доступа локальной сети, который и будет осуществлять окончательную проверку подлинности пользователя. В качестве таких данных для протокола СНАР выступают значение хэш-функции от пароля и псевдослучайного числа, а также само это до случайное число.
Необходимость создания виртуального канала определяется на основе базы данных, которая ведется провайдером на своем сервере безопасности.
Для возможности быстрого определения адреса пограничного маршрутизатора требуемой локальной сети предполагается, что идентификаторы пользователей будут составными, например, левой части от символа указывается зарегистрированное в локальной сети имя пользователя, а в правой части доменный адрес пограничного маршрутизатора ] локальной сети, являющегося и сервером удаленного доступа. Если же процедура определения адресов по составным идентификаторам не используется, то провайдер на своем сервере безопасности должен вести базу данных, в которой идентификаторы пользователей отображаются на IP-адреса по граничных маршрутизаторов локальных сетей.
Этап 3. Если сервис виртуального канала необходим, то после определения адреса пограничного маршрутизатора локальной сети проверяется существование туннеля к этому пограничному маршрутизатору. Если туннель отсутствует, то он создается. Спецификации протокола L2F требуют, чтобы туннель обеспечивал соединение "точка-точка". В первой реализации L2F для формирования такого соединения выбран протокол UDP.
После создания туннеля сервер RAS провайдера назначает неиспользуемый идентификатор мультиплексируемого канала (Multiplex ID — MID) новому виртуальному соединению, генерирует для него псевдослучайный ключ и отправляет серверу удаленного доступа локальной сети сообщение об установлении новой dial-up сессии, включающее также информацию для аутентификации. Сгенерированный псевдослучайный ключ используется для защиты пакетов сообщений от подмены.
Этап 4. На основе информации, полученной от сервера RAS провайдера, сервер удаленного доступа локальной сети выполняет окончательную проверку подлинности пользователя и в зависимости от полученных результатов принимает или отвергает новую сессию. Проверка подлинности осуществляется на основе взаимодействия с сервером безопасности локальной сети.
Так, если для аутентификации пользователя применяется протокол CHAP, то в сообщении об установлении новой dial-up сессии, помимо других служебных данных, серверу RAS локальной сети передается идентификатор пользователя, значение хэш-функции от пароля и псевдослучайного числа- вызова, а также само это псевдослучайное число. Сервер RAS локальной сети по полученному идентификатору пользователя извлекает из базы данных своего сервера безопасности зашифрованное эталонное значение пароля и на основе этого значения, а также полученного псевдослучайного числа-вызова определяет эталонное значение хэш-функции. В случае, если эталонное значение хэш-функции совпадает с полученным, то аутентификация считается успешной. В противном случае пользователь не допускается в локальную сеть и новая сессия отвергается.
Этапы 5 и 6. Если сервер RAS локальной сети принимает новую сессию, то
он создает для нее виртуальный канал по протоколу PPP (этап 5), подобно тому, как это происходит при непосредственном звонке на сервер удаленного доступа. Сервер удаленного доступа провайдера может выполнять регистрацию событий по созданию и разрыву виртуального канала (этап 6).
Этап 7. После создания виртуального канала кадры протокола PPP переда- ются в обоих направлениях. На сервере RAS провайдера и локальной сети кадры PPP для передачи по Internet очищаются от стартовых и стоповых флагов, инкапсулируются по протоколу L2F в пакеты IP и отправляются. При приеме пакетов IP с инкапсулированными кадрами PPP в пограничных точках Internet серверы RAS провайдера и локальной сети выполняют обратную процедуру. Так функционирует эмулируемое PPP-соединение "точка-точка", где конечными точками являются сетевая программа удаленного пользователя и программа, поддерживающая PPP на сервере RAS локальной сети.
Для криптографического закрытия трафика между конечными точками созданного виртуального канала предполагается использовать протокол IP Sec.
Описанные этапы формирования виртуального канала по протоколу L2F, а также схемы использования протокола PPTP позволяют выделить важные отличия данной технологии от использования традиционной службы уда- ленного доступа через Internet.
В случае традиционной службы удаленного доступа аутентификация пользователей осуществляется самим сервером провайдера. При использовании технологии L2F сервер удаленного доступа провайдера использует аутентификацию только для того, чтобы определить необходимость создания виртуального канала и найти адрес сервера удаленного доступа требуемой локальной сети. Как в протоколе L2F, так и в протоколе PPTP окончательно проверка подлинности выполняется сервером RAS локальной сети после того, как сервер провайдера с ним связывается.
Сервер удаленного доступа локальной сети проводит аутентификацию с помощью стандартных протоколов аутентификации удаленного доступа на основании информации, полученной от сервера провайдера. Так как аутентификацию проводит сервер локальной сети, то и политику доступа диктует служба безопасности этой сети, а не провайдер Internet. Такой подход обеспечивает более высокий уровень безопасности, так как функции защиты в данном случае возложены на того, кто в этом заинтересован. Провайдер Internet может быть неблагонадежным или халатно относиться к своим обязанностям. Кроме того, технология L2F является более гибкой, так как в случае ее полной реализации не требует привязки учетных данных об удаленных пользователях к провайдерам Internet.
К недостатку протокола L2F можно отнести то, что для текущей (четвертой) версии протокола IP не предусматривается создание криптозащищенного туннеля между конечными точками информационного
взаимодействия. Виртуальный защищенный канал может быть создан только между сервером удаленного доступа провайдера и пограничным маршрутизатором локальной сети, а участок между компьютером удаленного пользователя и сервером провайдера остается открытым.
3.2.3. Особенности протокола L2TP
Протокол L2TP (Layer-2 Tunneling Protocol — Ь2ТР) разработан в организации Internet Engineering Task Force (IETF) при поддержке компаний Microsoft и Cisco Systems как протокол защищенного туннелирования РРР- трафика через сети общего назначения с произвольной средой. Работа над данным протоколом велась на основе протоколов РРТР и L2F, и он вобрал в себя лучшие возможности обоих проектов. L2TP, в отличие от РРТР, не привязан к протоколу IP, а потому может быть использован в сетях с ком- мутацией пакетов, например, в сетях АТМ. Кроме того, L2TP предусматривает управление потоками данных, отсутствующее в L2F. Главное же, по мнению разработчиков, то, что новый протокол должен стать общепринятым стандартом, признаваемым всеми производителями.
Чтобы понять суть концепции L2TP, нужно представлять цели, которые преследовали компании Microsoft и Cisco при разработке РРТР и L2F.
В соответствии с целями, которые преследовались при разработке РРТР и L2F, различные организации должны были получить возможность делегировать функции безопасного удаленного доступа провайдерам Internet. Это, в свою очередь, позволило бы снизить затраты на администрирование и при- обретение аппаратных средств, так как локальные сети этих организаций смогли бы обойтись без множества модемов и дополнительных телефонных каналов. В обоих протоколах поставленная цель была достигнута. И L2F, и РРТР позволяют провайдерам Internet проводить удаленные сеансы по протоколу РРР, используя для аутентификации запросы к серверам безопасности локальных сетей.
Различия между L2F и РРТР объясняются специализацией их разработчиков. Cisco производит аппаратные маршрутизаторы для сетевой инфра- структуры, тогда как Microsoft выпускает операционные системы. Для работы провайдеров с L2F нужно, чтобы их маршрутизаторы и серверы удаленного доступа поддерживали этот протокол. Что касается протокола РРТР, то провайдеры не обязательно должны иметь средства организации туннелей, так как туннели могут формироваться специальным программным обеспечением конечных точек взаимодействия — компьютеров удаленных пользователей и серверов удаленного доступа локальных сетей. Тем не менее, L2F по сравнению с РРТР имеет несколько преимуществ. Так, РРТР требует применения маршрутизации на базе IP, тогда как L2F не привязан к конкретным протоколам сетевого уровня, используемым для транспортировки РРР- кадров.
В гибридном протоколе L2TP не только объединены лучшие черты протоколов РРТР и L2TP, но и добавлены новые функции.
Как и РРТР, новая спецификация не нуждается во встроенной аппаратной поддержке, хотя оборудование, специально предназначенное для нее, повысит производительность и защищенность системы. В Ь2ТР есть ряд отсутствующих в спецификации РРТР функций защиты, включая возможность работы с протоколом IPsec.
Наследственные черты L2F видны в том, что протокол не привязан к среде IP и с таким же успехом способен работать в любых сетях с коммутацией пакетов, например, в сетях АТМ или в сетях с ретрансляцией кадров (fmme relay).
В Ь2ТР добавлена важная функция управления потоками данных, которая не
допускает в систему больше информации, чем та способна обработать. Кроме того, в отличие от своих предшественников, L2TP позволяет открывать между: конечными абонентами сразу несколько туннелей, каждый из которых администратор может выделить для того или иного приложения. Эти особенности обеспечивают безопасность и гибкость туннелирования, а также существенно повышают качество обслуживания виртуальных каналов связи.
По существу протокол Ь2ТР представляет собой расширение РРР-протокола . функциями аутентификации удаленных пользователей, установки защищенного виртуального соединения, а также управлением потоками данных. В соответствии с протоколом L2TP (рис. 3,7) в качестве сервера удаленного доступа провайдера должен выступать концентратор доступа (Access Concentrator), который реализует клиентскую часть протокола L2TP и обеспечивает пользователю сетевой доступ к его локальной сети через Internet. Роль сервера удаленного доступа локальной сети должен выполнять сетевой сервер L2TP (Ь2ТР Network Server), функционирующий на любых платформах, совместимых с протоколом РРР.
Подобно протоколам PPTP и L2F, протокол L2TP предусматривает 3 этапа формирования защищенного виртуального канала:
• установление соединения с сервером удаленного доступа локальной сети;
• аутентификация пользователя;
• конфигурирование криптозащищенного туннеля.
Для установления соединения с сервером удаленного доступа локальной
сети, в качестве которого выступает сетевой сервер L2TP, удаленный пользователь связывается по протоколу PPP с концентратором доступа L2TP, функционирующим на сервере провайдера Internet или другой публичной сети. На данном этапе концентратор доступа Ь2ТР может выполнить аутентификацию пользователя от имени провайдера. Далее по имени пользователя концентратор доступа провайдера определяет IP-адрес сетевого сервера L2TP, принадлежащего требуемой локальной сети. Между концентратором доступа провайдера и сервером L2TP локальной сети устанавливается сессия по протоколу L2TP, называемая сессией L2TP. После установки сессии L2TP происходит процесс аутентификации пользователя на сервере L2TP локальной сети. Для этого может использоваться любой из стандартных алгоритмов аутентификации, например, алгоритм l CHAP. Как и в протоколах PPTP и L2F, в спецификации L2TP отсутствуют ! описания методов аутентификации. В случае успешной аутентификации пользователя между концентратором доступа провайдера и сервером L2TP локальной сети создается криптозащищенный туннель. С помощью управляющих сообщений осуществляется настройка различных параметров туннеля. В одном туннеле могут мультиплексироваться несколько сессий L2TP. Сам протокол L2TP не специфицирует конкретные методы криптозащиты и предусматривает возможность использования различных стандартов шифрования. Однако если туннель формируется в IP-сетях, то криптозащита должна выполняться в соответствии с протоколом IPSec. В этом случае пакеты L2TP инкапсулируются в UDP-пакеты, которые передаются между концентратором доступа провайдера и сервером L2TP локальной сети через IPSec-туннель. Для этого задействуется UDP-порт 1701.
Несмотря на свои достоинства, протокол L2TP не устраняет всех недостатков туннельной передачи данных на канальном уровне. В частности, необходима поддержка L2TP провайдерами. Протокол L2TP ограничивает весь трафик рамками выбранного туннеля и лишает пользователей доступа к другим частям Internet. Для текущей (четвертой) версии протокола IP не предусматривается создание криптозащищенного туннеля между конечными точками информационного взаимодействия. Кроме того, предложенная спецификация обеспечивает стандартное шифрование только в IP-сетях при использовании протокола IPSec, который пока не получил достаточно широкого распространения. А это может привести к проблемам совместимости, так как каждый производитель будет использовать в продуктах пол L2TP собственные технологии криптозащиты.
3.3. Защита виртуальных каналов на сетевом уровне
3.3.1. Архитектура средств безопасности IPSec
Формирование защищенных туннелей на канальном уровне модели OSI обеспечивает независимость от протоколов сетевого уровня, но приводит к; сложности конфигурирования и поддержки виртуальных каналов связи, Кроме того, при защите информационного обмена на канальном уровне уменьшается набор реализуемых функций безопасности, а также усложняет- се управление криптографическими ключами. Оптимальное соотношению междупрозрачностью и качеством защиты достигается при формировании защищенных виртуальных каналов на сетевом уровне модели OSI. Размещение средств защиты на этом уровне делает их прозрачными для приложений, так как между сетевым уровнем и приложением всегда будет функционировать реализация протокола транспортного уровня. Переписывать приложения при этом не придется. Вместе с тем на сетевом уровне появляется возможность достаточно полной реализации функций защиты трафика и управления ключами, так как именно на сетевом уровне выполняется маршрутизация пакетов сообщений.
Стандартные способы защиты информационного обмена на сетевом уровне модели OSI для IP-сети, являющейся основным видом публичных сетей, определяются протоколом IPSec (Internet Protocol Security). Данный протокол входит в состав новой версии протокола IP (IPv6) и применим также к его текущей версии (IPv4). Для протокола IPv4 поддержка IPsec является желательной, а для IPv6 — обязательной. IPsec обеспечивает аутентификацию источника данных, криптографическое закрытие передаваемых пакетов сообщений, проверку их целостности и подлинности после приема, защиту от навязывания повторных сообщений, а также частичную защиту от анализа трафика. Стандартизованными функциями IPSec-защиты могут и должны пользоваться протоколы более высоких уровней, в частности, управляющие протоколы, протоколы конфигурирования, а также протоколы маршрутизации.
В соответствии с протоколом IPSec архитектура средств безопасности информационного обмена разделяется на три уровня (рис. 3.8).
На верхнем уровне расположены следующие протоколы:
• протокол согласования параметров виртуального канала и управления ключами (Internet Security Association Key Management Protocol- ISAKMP), обеспечивающий общее управление защищенным виртуальным соединением, включая согласование используемых алгоритмов криптозащиты, а также генерацию и распределение ключевой информации;
• протокол аутентифицирующего заголовка (Authentication Header — АН), предусматривающий аутентификацию источника данных, проверку их целостности и подлинности после приема, а также защиту от навязывания повторных сообщений;
• протокол инкапсулирующей защиты содержимого (Encapsulating Security Payload — ESP), обеспечивающий криптографическое закрытие передаваемых пакетов сообщений и предусматривающий также выполнение всех функций протокола аутентифицирующего заголовка (АН).
Использование в IPSec двух различных протоколов защиты виртуального канала (AH и ESP) обусловлено практикой, применяемой во многих странах на ограничение экспорта и/или импорта криптосредств. Каждый из этих протоколов может использоваться как самостоятельно, так и одновременно с другим. Протоколы ESP и АН зарегистрированы организацией IANA (Internet Address Naming Authority) и занесены в реестр протоколов под порядковыми номерами 50 и 51 соответственно.
Алгоритмы аутентификации и шифрования, используемые в протоколах аутентифицирующего заголовка (АН) и инкапсулирующей защиты содержимого (ESP), образуют средний уровень архитектуры IPSec. К этому уровню 1 относятся также алгоритмы согласования параметров и управления ключами, применяемые в протоколе ISAKMP. Протоколы защиты виртуального. канала верхнего уровня архитектуры IPSec (АН и ESP) не зависят от конкретных криптографических алгоритмов. Могут использоваться любые методы аутентификации, типы ключей (симметричные или несимметричные), алгоритмы шифрования и распределения ключей. Например, в каждой стране могут применяться свои алгоритмы, соответствующие национальным стандартам.
Алгоритмическая независимость протоколов АН и ESP требует предварительного согласования набора применяемых алгоритмов и их параметров, поддерживаемых взаимодействующими сторонами. Эту функцию и предусматривает протокол ISAKMP, в соответствии с которым при формировании защищенного виртуального канала взаимодействующие стороны должны вы работать общий контекст безопасности (Security Association — ЗА) и только затем использовать элементы этого контекста, такие как алгоритмы и ключи. Роль фундамента в архитектуре IPSec выполняет так называемый домен интерпретации (Domain of Interpretation, DOI), являющийся по сути базой: данных, хранящей сведения об используемых в IPSec протоколах и алгоритмах, их параметрах, протокольных идентификаторах и т. д. Архитектура IPSec является полностью открытой. В IPSec могут использоваться протоколы и алгоритмы, которые изначально не разрабатывались для этой архитектуры. Поэтому возникла необходимость в так называемом домене интерпретации (DOI), который обеспечивал бы совместную работу всех включаемых протоколов и алгоритмов. Для того чтобы в качестве алгоритмов аутентификации и шифрования в протоколах аутентифицирующего заголовка (АН) и инкапсулирующей защиты содержимого (ESP) можно было использовать алгоритмы, соответствующие национальным стандартам, необходимо, как минимум, зарегистрировать эти алгоритмы в домене интерпретации.
В настоящий момент для протоколов АН и ESP зарегистрировано два aлгoритма аутентификации — НМАС-MD5 (Hashed Message Authentication Code — Message Digest version 5) и НМАС-SHA1 (Hashed Message Authentication Code — Secure Hash Algorithm version 1). Данные алгоритмы являются алгоритмами аутентификации с секретным ключом. Если секретный ключ известен только передающей и принимающей сторонам, это обеспечит аутентификацию источника данных, а также целостность пакетов, пересылаемых между двумя сторонами. Для обеспечения совместимой работы оборудования и программного обеспечения на начальной стадии реализации протокола IPSec один из зарегистрированных алгоритмов аутентификации принято использовать по умолчанию. В качестве такого алгоритма определен алгоритм НМАС-MD5.
Для протокола ESP зарегистрировано семь алгоритмов шифрования. Алгоритм шифрования DES (Data Encryption Standard), как и алгоритм HMAC- MD5, принят по умолчанию и необходим для обеспечения IPSec- совместимости. В качестве альтернативы DES определены алгоритмы Triple DES, CAST-128, RC5, IDEA, Blowfish и ARCFour.
Протоколы аутентифицирующего заголовка (АН) и инкапсулирующей защиты содержимого (ESP) поддерживают работу в двух режимах:
• туннельном, при котором IP-пакеты защищаются целиком, включая их заголовки;
• транспортном, обеспечивающим полную защиту только содержимого
IP-пакетов. Основным режимом является туннельный. При работе в этом режиме каждый обычный IP-пакет помещается целиком в криптозащищенном виде в конверт IPSec, а тот, в свою очередь инкапсулируется в другой IP-пакет. Туннельный режим обычно реализуют на специально выделенных защитных шлюзах, в роли которых могут выступать маршрутизаторы или межсетевые экраны. Между такими шлюзами и формируются защищенные туннели IPSec. Перед передачей по такому туннелю исходные IP-пакеты передающей локальной сети инкапсулируются по протоколу IPSec в защищенные IP-пакеты. После передачи на другую сторону туннеля защищенные IP-пакеты "распаковываются" и полученные исходные IP-пакеты и передаются компьютерам приемной локальной сети по стандартным правилам. Туннелирование IP-пакетов полностью прозрачно для обычных компьютеров в локальных сетях, являющихся держателями туннелей. На оконечных системах туннельный режим может использоваться для поддержки удаленных и мобильных пользователей. В этом случае на компьютерах этих пользователей должно быть установлено программное обеспечение, реализующее туннельный режим IPSec.
В транспортном режиме в конверт IPSec в криптозащищенном виде помещается только содержимое исходного IP-пакета и к полученному конверту добавляется исходный IP-заголовок. Соответственно в транспортном режиме заголовок IPSec размещается между сетевым (IP) и транспортным (TCP или UDP) заголовками обычного IP-пакета. Транспортный режим быстрее туннельного и разработан для применения на оконечных системах. Данный режим может использоваться для поддержки удаленных и мобильных пользователей, а также защиты информационных по токов внутри локальных сетей. Кроме того, транспортный режим может применяться на шлюзах для защиты внутренних связей между одноранговыми шлюзами. Это обеспечивает эффективную защиту процесса удаленного управления маршрутизаторами, коммутаторами АТМ, межсетевыми экранами и другими ключевыми компонентами инфраструктуры сети. Работа в транспортном режиме отражается на всех входящих в группу защищенного взаимодействия системах и в большинстве случаев требуется перепрограммирование сетевых приложений.
3.3.2. Протокол аутентифицирующего заголовка
Протокол аутентифицирующего заголовка (Authentication Header — АН) обеспечивает целостность IP-пакетов и аутентификацию источника данных, а также защиту от воспроизведения ранее посланных IP-пакетов. Этот протокол полностью защищает от подлога и случайного искажения содержимое IP-пакетов, включая данные протоколов более высоких уровней. Полнота защиты полей IP-заголовков зависит от используемого режима работы— туннельного или транспортного.
В туннельном режиме защищаются все поля IP-заголовков (рис. 3.9). При защите каждый обычный IP-пакет помещается целиком в конверт IPSec, а тот, в свою очередь инкапсулируется в другой IP-пакет. В защищенном IP- пакете внутренний (первоначальный) IP-заголовок содержит целевой адрес пакета, а внешний IP-заголовок содержит адрес конца туннеля.
При использовании протокола АН в транспортном режиме защита не накладывается лишь на те поля IP-заголовков, которые меняются на маршруте ) доставки непредсказуемым образом. К таким полям для протокола IPv4 от носится поле Типе to Live, задающее время жизни IP-пакета, а также поле Туре of Service, определяющее тип его обслуживания. Для IPv6 защита не накладывается на поля Prio. и Flow Label, подобные полю Туре of Service в IPv4, а также на поле Нор Limit, задающее максимальное число промежуточных систем на пути следования пакета и уменьшаемое при передаче па- кета каждым маршрутизатором на единицу. В транспортном режиме в конверт IPSec помещается только содержимое защищаемого IP-пакета и к полученному конверту добавляется исходный IP-заголовок (рис. 3.10).
Формат заголовка AH представлен на рис. 3.11. Поясним смысл полей этого заголовка.
• Next Header — однобайтовое поле, содержащее код типа следующего заголовка, вложенного в IPSec пакет. Например, если в IPSec пакете содержится TCP-пакет, то данное поле будет содержать число 6 — код протокола TCP.
• Payload Len — длина заголовка АН в 32-битных словах минус 2. ,
• SPI — 32-битный индекс параметров безопасности, определяющий структуру SA (Security Association), содержащую все параметры туннеля IPSec, включая типы криптографических алгоритмов и ключи шифрования.
• Sequence Number — без знаковое 32-битное целое, увеличиваемое на единицу после передачи каждого защищенного по протоколу AH IP- пакета. Данное поле обеспечивает защиту от воспроизведения ранее по сланных IP-пакетов. Отправитель обязан поддерживать этот счетчик. При формировании каждого защищенного сеанса информационного обмена в рамках туннеля IPSec обе взаимодействующие стороны делают свои счетчики нулевыми, а потом согласованным образом увеличивают их.
• Authentication Data — поле переменной длины, содержащее информацию, используемую для аутентификации пакета и называемую МАС- кодом (Message Authentication Code). Это поле называют также цифровой подписью, имитовставкой, хэш-значением или криптографической контрольной суммой (Integrity Check Value — ICV) пакета. Способ вычисления этого поля определяется алгоритмом аутентификации.
Для вычисления содержимого поля Authentication Data могут применяться; различные алгоритмы. В настоящее время предписывается обязательная, поддержка алгоритмов НМАС-MD5 и НМАС-SHA1, основанных на применении односторонних хэш-функций с секретными ключами. Секретные ключи генерируются в соответствии с протоколом ISAKMP.
Таким образом, независимо от режима работы, протокол АН предоставляет меры защиты от атак, ориентированных на нарушение целостности и подлинности пакетов сообщений. С помощью этого протокола аутентифицируется каждый пакет, что делает программы, пытающиеся перехватить управление сеансом, неэффективными. Несмотря на нахождение IP-заголовков за пределами защищенного IPSec конверта, протокол АН обеспечивает аутентификацию не только содержимого, но и заголовков IP-пакетов. Но следует иметь в виду, что аутентификация по протоколу АН не допускает манипулирование основными полями IP-заголовка во время прохождения пакета.. По этой причине данный протокол нельзя применять в среде, где используется механизм трансляции сетевых адресов (Network Address Translation- NAT), так как манипулирование IP-заголовками необходимо для его работы.
3.3.3. Протокол инкапсулирующей защиты содержимого
Протокол инкапсулирующей защиты содержимого (Encapsulating Security Payload — ESP) обеспечивает выполнение следующих функций по защите информационного обмена:
• криптографическое закрытие содержимого IP-пакетов;
• частичная защита от анализа трафика путем применения туннельного режима;
• формирование и проверка цифровой подписи IP-пакетов для их защиты от нарушений подлинности и целостности;
• защита от воспроизведения Ip-пакетов.
Представленный перечень функций по защите информационного обмена показывает, что функциональность протокола ESP шире, чем у протокола AH. Протокол ESP обеспечивает конфиденциальность данных, а также поддерживает все функции протокола АН по защите зашифрованных потоков данных от подлога, воспроизведения и случайного искажения.
Обобщенно все функции защиты, поддерживаемые протоколом ESP можно свести к аутентификации, которую обеспечивает также протокол АН, и криптографическому закрытию передаваемых IP-пакетов. Спецификация IPSec допускает использование протокола ESP для криптографического закрытия IP-пакетов без использования функций аутентификации. Кроме того, допускается использование фиктивного шифрования при выполнении функций протокола АН. Таким образом, в протоколе ESP функции аутентификации и криптографического закрытия могут быть задействованы либо вместе, либо отдельно друг от друга. При выполнении шифрования без аутентификации появляется возможность использования механизма трансляции сетевых адресов (Network Address Translation — NAT), поскольку в этом случае адреса в заголовках IP-пакетов можно модифицировать.
Независимо от режима использования протокола ESP его заголовок формируется как инкапсулирующая оболочка для зашифрованного содержимого (рис. 3.12).
Поля SPI, Sequence Number, Next Header и Authentication Data имеют тот же смысл, что и для АН. Поле Authentication Data помещается в заголовок ESP только при включенной аутентификации. В поле Payload Data, имеющее переменную длину, включается инкапсулируемый пакет, который шифруется вместе с полями Padding, Pad Length и Next Header. Поле Padding представляет собой байты, добавляемые для обеспечения кратности длины инкапсулируемого пакета и размера блока алгоритма шифрования. Поле Pad Length содержит длину области Padding. В туннельном режиме использования протокола ESP в качестве инкапсулируемого пакета выступает весь исходный IP-пакет (рис. 3.13), а в транспортном — только его содержимое, т. е. исходный TCP- или UDP-пакет. Алгоритм применения протокола ESP к исходящим IP-пакетам включает следующие шаги:
• инкапсулируемый пакет копируется в буфер;
• далее к этому пакету в буфере приписываются дополняющие байты (поле Padding), их число (поле Pad Length) и тип первого заголовка инкапсулируемого пакета (поле Next Header); поле Padding выбирается таким, чтобы поле Next Header было прижато к границе 32-битного слова, а размер буфера удовлетворял требованиям алгоритма шифрования;
• текущее содержимое буфера зашифровывается;
• в начало буфера приписываются поля SPI и Sequence Number с соответствующими значениями;
• пополненное содержимое буфера обрабатывается по используемому алгоритму аутентификации, и после окончания этой процедуры в конец, буфера помещается поле Authentication Раса;
• формируется результирующий IP-пакет путем приписывания соответствующего IP-заголовка в начало буфера.
Таким образом, если в соответствии с протоколом ESP предусматриваются и криптографическое закрытие, и аутентификация, то аутентифицируется зашифрованный пакет. Для входящих пакетов действия выполняются в обратном порядке, то есть сначала производится аутентификация. Это позволяет не тратить ресурсы на расшифровку поддельных пакетов, что в какой то степени защищает от атак, ориентированных на отказ в обслуживании.
При использовании протокола ESP в туннельном режиме (рис. 3.13) каждый исходный IP-пакет в криптозащищенном виде помещается целиком в конверт IPSec, а тот, в свою очередь инкапсулируется в другой IP-пакет. В защищенном IP-пакете внутренний (исходный) IP-заголовок, располагаемый в зашифрованной части, содержит целевой адрес пакета, а внешний IP-заголовок содержит адрес конца туннеля. Когда ESP используется в транспортном режиме (рис. 3.13), в конверт IPSec в криптозащищенном виде помещается только содержимое исходного IP-пакета и к полученному конверту добавляется исходный IP-заголовок.
В настоящее время спецификация IPSec для криптографического закрытия IP-пакетов по протоколу ESP предписывает обязательную поддержку алгоритма шифрования DES-СВС (Data Encryption Standard in Cipher Block Chaining mode). Данный алгоритм шифрования применятся в протоколе ESP по умолчанию. Он необходим для обеспечения IPSec-совместимости. В качестве альтернативы DES определены алгоритмы Triple DES, САЯТ-128, RC5, IDEA, Blowfish и ARCFour.
Алгоритм CAST (стандарт RFC 2144) считается таким же стойким, как алгоритм Triple DES со 128-битовым ключом. Кроме того, CAST быстрее чем : DES. Алгоритм RC5 (стандарт И..С 2040) является алгоритмом шифрования потока данных, использующим ключ переменной длины. По мнению болваншинства, стойкость RC5 зависит от длины ключа, которая может достигать 256 бит. Алгоритм IDEA (International Data Encryption Algorithm) рассматривают как "быстрый" эквивалент Triple DES. Еще одним алгоритмом, использующим ключ переменной длины, является Blowfish, который также считается достаточно стойким. Алгоритм ARCFour является общедоступной версией алгоритма RC4.
Выбор алгоритма, за исключением алгоритма DES, который является обязательным, целиком зависит от разработчика. Возможность выбора алгоритма шифрования предоставляет дополнительное преимущество: ведь злоумышленник должен не только вскрыть шифр, но и определить, какой именно шифр ему надо вскрывать. Вместе с необходимостью подбора ключей это существенно снижает вероятность своевременного обхода криптозащиты. Протоколы АН и ESP могут комбинироваться разными способами. Если используется транспортный режим, то аналогично тому, как в рамках ESP аутентификация идет следом за шифрованием, протокол АН должен применяться после. протокола ESP. В туннельном режиме протоколы АН и ESP применяются к разным вложенным пакетам и, кроме того, в данном режиме допускается многократная вложенность туннелей с различными начальными и/или конечными точками. Поэтому в случае туннельного режима число возможных комбинаций по совместному использованию протоколов AH и ESP существенно больше.
3.3.4. Управление защищенным туннелем
Создание и поддержка защищенного виртуального канала невозможны без реализации функций управления. В спецификации IPSec такие функции разделяются на две группы:
• общие функции управления, основанные на использовании базы данных политики безопасности (Security Policy Database — SPD);
• функции управления, ориентированные на согласование параметров туннеля и формирование контекста безопасности (Security Association — SA), который описывает общие параметры защищенного виртуального канала.
В соответствии с общими функциями управления все входящие и исходящие IP-пакеты должны сопоставляться с упорядоченным набором правил политики безопасности, которая задается для следующих объектов:
• для каждого сетевого интерфейса с задействованными средствами IPSec;
• для каждого исходящего и входящего потока данных.
Cогласно спецификациям IPsec политика должна быть рассчитана на независимую обработку IP-пакетов на сетевом уровне модели OSI по современной технологии фильтрации. Соответственно должны существовать средства администрирования базы данных политики безопасности, подобные средствам администрирования базы правил межсетевых экранов. База данных политики безопасности (SPD) представляет собой упорядоченный набор правил, каждое из которых включает совокупность селекторов и допустимых контекстов безопасности. Селекторы служат для отбора пакетов, а контексты задают требуемую обработку.
При сопоставлении с упорядоченным набором правил в первую очередь обрабатываются селекторы, в которых указывается совокупность анализируемых полей сетевого и более высоких протокольных уровней. В реализациях, IPSec должна поддерживаться фильтрация IP-пакетов на основе анализа следующих элементов:
• исходного и целевого IP-адреса; при этом адреса могут быть индивидуальными и групповыми (допускается также применение в правилах диапазонов адресов и метасимволов "любой");
• имени пользователя или узла (в формате DNS или Х.500);
• номеров используемого транспортного протокола;
• номеров исходного и целевого портов (здесь также могут применяться диапазоны и метасимволы).
Первое подходящее правило из базы данных политики безопасности (SPD) определяет дальнейшую судьбу пакета:
• пакет ликвидируется;
• пакет обрабатывается без использования средств IPSec;
• пакет обрабатывается средствами IPsec с учетом набора контекстов безопасности, ассоциированных с правилом.
В случае принятия решения об обработке пакета средствами IPSec анализируются контексты безопасности выбранного правила. Каждый контекст безопасности (SA) описывает параметры допустимого IPSec-соединения, включающие типы криптографических алгоритмов, ключи шифрования, а также другую служебную информацию для защиты информационного обмена. Если правило ссылается на несуществующий контекст, то для формирования защищенного IPSec-туннеля данный контекст должен быть создан. В этом случае должно поддерживаться автоматическое управление контекстами и ключами.
При создании контекста безопасности (SA) взаимодействующие стороны должны аутентифицировать друг друга и согласовать между собой параметры туннеля, включающие, помимо различной служебной информации, типы криптографических алгоритмов и ключи шифрования. Для решения этих задач в IPSec используется протокол согласования параметров виртуального канала и управления ключами (Internet Security Association Key Management Protocol — ISAKMP), обеспечивающий общее управление защищенным виртуальным соединением. Протокол ISAKMP описывает базовую технологию аутентификации, обмена ключами и согласования всех остальных параметров IPSec-туннеля при создании контекстов безопасности (SA). Однако ISAKMP не содержит конкретные алгоритмы обмена криптографическими ключами. Поэтому для обмена ключами могут использоваться другие протоколы. В настоящий момент в качестве такого протокола, используемого при формировании IPSec-туннеля, выбран протокол Oakley, основанный на алгоритме Диффи-Хеллмана. Объединение протоколов ISAKMP и Oakley обозначают как ISAKMP/Oakley.
Согласно протоколу ISAKMP согласование параметров защищенного взаимодействия необходимо как при формировании IPSec-туннеля, так и при формировании в его рамках каждого защищенного однонаправленного соединения. Глобальные параметры туннеля образуют управляющий контекст и согласуются по протоколу ISAKMP/Oakley. Параметры каждого защищенного однонаправленного соединения согласуются на основе созданного управляющего контекста и как раз образуют упоминаемый выше контекст безопасности (Security Association — SA), называемый еще протокольным контекстом. Для идентификации каждого из контекстов безопасности предназначен индекс параметров безопасности (Security Parameters Index — SPI). Этот индекс включается в заголовки защищенных IPSec-пакетов, чтобы принимающая сторона смогла правильно их расшифровать или аутентифицировать, воспользовавшись указанным контекстом безопасности (SA).
Криптографические ключи для каждого защищенного однонаправленного соединения (входящие в контекст безопасности этого соединения) генерируются на основе ключей, выработанных в рамках управляющего контекста. При этом учитываются алгоритмы аутентификации и шифрования, используемые в протоколах аутентифицирующего заголовка (АН) и инкапсулирующей защиты (ESP).
В соответствии со спецификацией IPSec обработка исходящего и входящего трафика не является симметричной. Для исходящих пакетов просматривается база данных политики безопасности (SPD), находится подходящее правило, извлекаются ассоциированные с ним контексты безопасности (SA) и применяются соответствующие функции защиты. Во входящих пакетах для каждого защитного протокола уже проставлено значение индекса параметров безопасности (SPI), однозначно определяющее контекст (SA). В этом случае просмотр базы данных политики безопасности не требуется, так как политика безопасности учитывалась при формировании соответствующего контекста (SA).
Гибкость политики безопасности при использовании протокола IPSec определяется селекторами и контекстами безопасности, употребленными в правилах. Например, в случае, когда в селекторах фигурируют только IP- адреса, пара взаимодействующих компьютеров может применять один набор контекстов безопасности. Если же анализируются номера TCP- и UDP- портов, то набор контекстов может быть своим для каждого приложения. Соответственно, с одной стороны, два защитных шлюза могут организовать единый туннель для всех обслуживаемых компьютеров, а с другой — могут разграничить туннель путем организации разных контекстов по парам компьютеров или даже приложений.
3.4. Построение защищенных виртуальных сетей на сеансовом уровне
3.4.1. Особенности туннелирования
Сеансовый уровень является максимально высоким уровнем модели OSI, на котором возможно формирование защищенных виртуальных каналов. При построении защищенных виртуальных сетей на данном уровне достигаются наилучшие показатели по функциональной полноте защиты информационного обмена, надежности контроля доступа, а также простоте конфигурирования системы безопасности. Протоколы формирования защищенных виртуальных каналов на сеансовом уровне прозрачны для прикладных протоколов защиты, а также высокоуровневых протоколов предоставления различных сервисов (протоколов HTTP, FTP, POPИ, SMTP, NNTP и др.). Однако на сеансовом уровне начинается непосредственная зависимость от приложений, реализующих высокоуровневые протоколы. Поэтому реализация протоколов защиты информационного обмена, соответствующих этому уровню, в большинстве случаев требует внесения изменений в высокоуровневые сетевые приложения.
Так как сеансовый уровень модели OSI отвечает за установку логических соединений и управление этими соединениями, то на данном уровне появляется возможность использования программ-посредников, проверяющих допустимость запрошенных соединений и обеспечивающих выполнение других функций защиты межсетевого взаимодействия. В общем случае программы посредники, которые традиционно используются в межсетевых экранах, могут выполнять следующие функции:
• идентификация и аутентификация пользователей;
• криптозащита передаваемых данных;
• разграничение доступа к ресурсам внутренней сети;
• разграничение доступа к ресурсам внешней сети;
• фильтрация и преобразование потока сообщений, например, динамический поиск вирусов и прозрачное шифрование информации;
• трансляция внутренних сетевых адресов для исходящих пакетов сообщений;
• регистрация событий и реагирование на задаваемые события;
• кэширование данных, запрашиваемых из внешней сети.
Таким образом, при построении защищенных виртуальных сетей на сеансовом уровне появляется возможность не только криптографической защиты информационного обмена, включая аутентификацию, но и возможность реализации ряда функций посредничества между взаимодействующими сторонами.
Для криптографической защиты информационного обмена на сеансовом , уровне наибольшую популярность получил протокол SSL/TLS (Secure Sockets Layer/ Transport Layer Security), разработанный компанией Netscape Communications. Далее этот протокол будем называть просто протоколом SSL. Для выполнения на сеансовом уровне функций посредничества между взаимодействующими сторонами организацией IETF (Internet Engineering Task Force) в качестве стандарта принят протокол SOCKS.
Протокол Secure Sockets Layer (SSL), изначально ориентированный на за- щиту информационного обмена между клиентом и сервером компьютерной сети, является промышленным протоколом сеансового уровня модели OSI, использующим для обеспечения безопасности информационного обмена криптографические методы защиты информации. Конфиденциальность передаваемых данных обеспечивается за счет их криптографического закрытия, а аутентификация взаимодействующих сторон, а также подлинность и целостность циркулирующей информации — за счет формирования и проверки цифровой подписи.
Ядром протокола SSL является технология комплексного использования асимметричных и симметричных криптосистем. В качестве алгоритмов асимметричного шифрования используются такие алгоритмы, как RSA (раз- работки RSA Data Security Inc.), а также алгоритм Диффи-Хеллмана. Для вычисления хэш-функций могут применяться стандарты MD5 и SHA-1. Допустимыми алгоритмами симметричного шифрования являются RC2, RC4, DES, а также тройной DES. В протоколе SSL третьей версии набор крипто графических алгоритмов является расширяемым. Для аутентификации взаимодействующих сторон и криптозащиты ключа симметричного шифрования применяются цифровые сертификаты открытых ключей пользователей (клиента и сервера), заверенные цифровой подписью специальных Сертификационных Центров. Поддерживаются цифровые сертификаты,
соответствующие общепринятому стандарту Х.509. Протокол SSL разработан корпорацией Netscape, а затем поддержан рядом ведущих производителей программного обеспечения. Из-за своих положительных качеств SSL практически вытеснил конкурирующие высококровные протоколы по защите информационного обмена, например, такие как j SHTTP (Secure НТТР), и стал общепризнанным неофициальным стандартом защиты в Internet и Intranet сетях. Спецификации SSL были в свое время предложены в качестве официальных стандартов Internet, но не получили этого статуса по формальным обстоятельствам. Не исключено, что SSL все же начнет продвигаться по ступеням формального принятия IETF в качестве стандарта, так как он уже стал промышленным протоколом, развиваемым и продвигаемым вне иерархии технических координирующих институтов Internet. Последней версией SSL является версия 3.0, о которой и будет идти речь.
Клиентская часть SSL реализована во всех популярных Web-навигаторах, к которым относятся Netscape Navigator компании Netscape и Internet Explorer от Microsoft, а серверная в большинстве как коммерческих, так и распространяемых на некоммерческих условиях WWW-серверов, например, в серверных приложениях компаний IBM, Netscape, Microsoft, Spyglass, Open Market.
В соответствии с протоколом SSL криптозащищенные туннели создаются между конечными точками виртуальной сети (рис. 3.14). Инициаторами каждого защищенного туннеля являются клиент и сервер, функционирующие на компьютерах в конечных точках туннеля. Протокол SSL предусматривает два этапа взаимодействия клиента и сервера при формировании и поддержке защищаемого соединения:
• установление SSL-сессии;
• защищенное взаимодействие.
Процедура установления SSL-сессии, называемая также процедурой "рукопожатия", отрабатывается перед непосредственной защитой информационного обмена и выполняется по протоколу начального приветствия (Handshake Protocol), входящему в состав протокола SSL. В процессе становления SSL-сессии решаются следующие задачи:
• аутентификация сторон;
• согласование криптографических алгоритмов и алгоритмов сжатия, которые будут использоваться при защищенном информационном обмене;
• формирование общего секретного мастер-ключа;
• генерация на основе сформированного мастер-ключа общих секретных сеансовых ключей для криптозащиты информационного обмена.
В реализациях протокола SSL для аутентификации взаимодействующих сторон и формирования общих секретных ключей чаще всего используют алгоритм RSA разработки RSA Data Security Inc.
Однозначное и достоверное соответствие между открытыми ключами и их владельцами устанавливается с помощью цифровых сертификатов, выдаваемых специальными Центрами Сертификации. Сертификат представляет собой блок данных, содержащий следующую информацию:
• имя центра сертификации;
• имя владельца сертификата;
• открытый ключ владельца сертификата;
• период действия сертификата;
• идентификатор и параметры криптоалгоритма, который должен использоваться при обработке сертификата;
• цифровую подпись центра сертификации, заверяющую все данные в составе сертификата.
Цифровая подпись центра сертификации в составе сертификата обеспечивает достоверность и однозначность соответствия открытого ключа и его владельца. Центр сертификации исполняет роль нотариуса, заверяющего подлинность открытых ключей, что позволяет их владельцам пользоваться услугами защищенного взаимодействия без предварительной личной встречи. Необходимость безусловного доверия к центру сертификации со стороны всех участников защищенного обмена предъявляет к нему достаточно высокие требования по проверке подлинности заверяемых открытых ключей. Одним из таких центров в Internet является компания VeriSign, учрежденная RSA Data Security Inc при участии компаний Visa, IBM, Netscape, Microsoft и Oracle.
Третья версия протокола SSL поддерживает три режима аутентификации:
• взаимная аутентификация сторон;
• односторонняя аутентификация сервера без аутентификации клиента;
• полная анонимность.
При использовании последнего варианта взаимодействующие стороны незащищены от атак, связанных с подменой участников взаимодействия. В данном режиме обеспечивается защита информационного обмена без каких либо гарантий относительно подлинности взаимодействующих сторон.
В режиме односторонней аутентификации сервера без аутентификации клиента процедура установления SSL-сессии между клиентом и сервером включает следующие шаги.
1. Клиент посылает серверу запрос на установление защищенного соединения, в котором передает некоторые формальные параметры этого соединения:
• текущее время и дату;
• случайную последовательность (RAND CL); набор поддерживаемых клиентом алгоритмов симметричного шифрования и алгоритмов вычисления хэш-функции;
набор поддерживаемых алгоритмов сжатия и др.
2. Сервер обрабатывает запрос от клиента и передает ему согласованный набор параметров:
идентификатор SSL-сессии;
конкретные криптографические алгоритмы из числа предложенных клиентом (если по какой-либо причине предложенные алгоритмы или их параметры не удовлетворяют требованиям сервера, сессия закрывается); сертификат сервера, заверенный цифровой подписью центра сертификации;
• случайную последовательность (RAND SERV).
3. Клиент проверяет полученный сертификат сервера с помощью открытого ключа центра сертификации, который ему известен. При отрицательном результате проверки сессия закрывается, а при положительном — клиент выполняет следующие действия:
• генерирует случайную 48-байтную последовательность Pre MasterSecret, предназначенную для генерации общего секретного мастер-ключа;
шифрует Pre MasterSecret по открытому ключу сервера, полученному в сертификате сервера, и посылает серверу;
• с помощью согласованных хэш-алгоритмов формирует общий секретный мастер-ключ (MasterSecret), используя в качестве параметров последовательность Pre MasterSecret, посланную серверу случайную последовательность RAND СЬ и полученную от него случайную последовательность RAND SERV;
• используя MasterSecret, вычисляет криптографические параметры SSL- сессии: формирует общие с сервером сеансовые секретные ключи для симметричного шифрования и вычисления хэш-функций;
• переходит в режим защищенного взаимодействия.
4. Сервер расшифровывает полученную последовательность Pre MasterSecret по своему закрытому ключу и выполняет на ее основе те же операции, что и клиент:
• с помощью согласованных хэш-алгоритмов формирует общий секретный мастер-ключ (MasterSecret), используя в качестве параметров Pre MasterSecret, а также посланную клиенту случайную последовательность RAND SERV и полученную от него случайную последовательность RAND CL;
• используя MasterSecret, вычисляет криптографические параметры SSL- сессии: формирует общие с клиентом сеансовые секретные ключи для симметричного шифрования и вычисления хэш-функций;
• переходит в режим защищенного взаимодействия.
Так как при формировании параметров SSL-сессии и клиент, и сервер
пользовались одними и теми же исходными данными (согласованными алгоритмами, общей секретной последовательность Pre MasterSecret и случайными последовательностями RAND CL и RAND SERV), то очевидно, что в результате описанных выше действий они выработали одинаковые сеансовые секретные ключи. Для проверки идентичности параметров SSL- сессии клиент и сервер посылают друг другу тестовые сообщения, содержание которых известно каждой из сторон:
• клиент формирует сообщение из собственных посылок в адрес сервера на шаге 1 и посылок, полученных от сервера на шаге 2, внося элемент случайности в виде последовательности MasterSecret, уникальной для данной сессии; формирует код для проверки целостности сообщения (МАС), шифрует сообщение по общему сеансовому секретному ключу и отправляет серверу;
• сервер, в свою очередь, формирует сообщение из собственных посылок в адрес клиента на шаге 2, посылок, полученных от клиента на шаге и последовательности MasterSecret; формирует код для проверки сообщения (МАС), шифрует сообщение на общем сеансовом секретном ключе и отправляет клиенту;
• в случае успешной расшифровки и проверки целостности каждой из сторон полученных тестовых сообщений, сессия считается установленной и стороны переходят в штатный режим защищенного взаимодействия.
В процессе защищенного взаимодействия с установленными криптографическими параметрами SSL-сессии выполняются следующие действия:
• каждая сторона при передаче сообщения формирует МАС-код для последующей проверки целостности сообщения и затем зашифровывает исходное сообщение вместе с МАС-кодом по сеансовому секретному ключу;
• каждая сторона при приеме сообщения расшифровывает его и проверяет
на целостность (вычисляется текущий МАС-код и сверяется с МАС-кодом проверки целостности, полученным вместе с сообщением); в случае обнаружения нарушения целостности сообщения, сессия закрывается.
Несмотря на то, что протокол SSL поддерживается программным обеспечением серверов и клиентов, выпускаемых ведущими западными компаниями, в нашей стране имеются обстоятельства, препятствующие распространению данного протокола и принятию его в качестве базового для реализации приложений, требующих защищенного информационного взаимодействия участвующих сторон. Практически все существующие продукты, поддерживающие протокол SSL, реализованы в США и из-за экспортных ограничений доступны только в усеченном варианте (с длиной сеансового ключа 40 бит для алгоритмов симметричного шифрования и 512 бит для алгоритма RSA, используемого на этапе установления SSL-сессии), что на сегодняшний день явно недостаточно. Также возникают трудности создания и использования национальных центров сертификации.
Ограничения на длину допустимых ключей шифрования относятся и к криптографическим модулям популярных Web-навигаторов — Netscape Navigator и Netscape Communicator компании Netscape, а также Internet Explorer от Microsoft. Следует уточнить, что последние "экспортные" релизы. этих продуктов все же поддерживают ряд алгоритмов с достаточной длиной ключа, но — с особыми ограничениями. Так, "экспортная" версия Netscape Communicator 4.0 содержит исполняемый код алгоритмов RC4 (128 бит) и тройного DES (168 бит). Однако он задействуется только при особых условиях. "Экспортный" Netscape установит соединение, защищенное стойкой криптографией, только с серверами, входящими в определенный список, поддерживаемый сертификатором VeriSign, Inc. За пределами США VeriSign предоставляет такие права только серверам лицензированных банков. Подобные ограничения содержит и "экспортный" Internet Explorer.
Для решения описанной проблемы целесообразно использовать программные продукты, дополняющие программное обеспечение клиентов и серверов ведущих мировых производителей с целью поддержки протокола SSL без экспортных ограничений на длину ключа и реализации возможностей использования национальных криптографических стандартов и центров сертификации. К программным продуктам такого класса относятся, например, программные системы Inter-PRO и Net-PRO, разработанные российский компанией "Сигнал-KOM". Если необходима только поддержка протокола SSL без экспортных ограничений на длину ключа шифрования, то можно воспользоваться зарубежными программными системами, дополняющими популярные Web-навигаторы. Например к такой системе относится программа Fortify, разработанная австралийцем Фаррелом МакКейем (Farrell МсКау) и распространяемая бесплатно (http:/ www.fortify.net).
Протокол SOCKS разработан в 1990 г. Дэвидом Кобласом для организации посредничества при взаимодействии между клиент-серверными приложениям
и на сеансовом уровне модели OSI. Изначально данный протокол разрабатывался только для перенаправления запросов к серверам со стороны клиентских приложений, а также возврата этим приложениям полученных ответов. Однако даже лишь перенаправление запросов и ответов между клиент- серверными приложениями уже позволяет реализовать функцию трансляции сетевых IP-адресов (Network Address Translation — NAT). При замене для исходящих пакетов внутренних IP-адресов отправителей одним IP-адресом шлюза топология внутренней сети скрыта от внешних пользователей, что усложняет задачу несанкционированного доступа. Трансляция сетевых адресов, помимо повышения безопасности позволяет расширить внутреннее адресное пространство сети за счет возможности поддержки собственной системы адресации, не согласованной с адресацией во внешней сети.
На основе протокола SOCKS могут быть реализованы и любые другие функции посредничества по защите сетевого взаимодействия. Например, SOCKS может применяться для контроля над направлениями информационных потоков и разграничения доступа в зависимости от атрибутов пользователей или информации. Эффективность использования данного протокола для выполнения функций посредничества обеспечивается его ориентацией на сеансовый уровень модели OSI. По сравнению с посредниками прикладного уровня на сеансовом уровне достигаются более высокое быстродействие и независимость от высокоуровневых протоколов (HTTP, FTP, POPИ, SMTP, NNTP и др.). Кроме того, протокол SOCKS не привязан к протоколу IP, а также не зависит от операционных систем. Например, для обмена информацией между клиентским приложением и посредником может использоваться протокол IPX.
Виртуальные частные сети и брандмауэры благодаря протоколу SOCKS могут организовать безопасное взаимодействие и обмен информацией между разными сетями. Кроме того, SOCKS позволяет реализовать безопасное управление этими системами на основе унифицированной стратегии. Следует отметить, что если на основе протоколов канального и сетевого уровня защищенные виртуальные каналы формируются между разными парами взаимодействующих сторон, то на основе протокола SOCKS могут создаваться защищенные туннели для каждого приложения и сеанса в отдельности.
В соответствии с протоколом SOCKS различают SOCKS-сервер, который целесообразно устанавливать на шлюз (брандмауэр) сети, а также SOCKS- клиент, который устанавливается на каждый пользовательский компьютер. SOCKS-сервер обеспечивает взаимодействие с любым прикладным сервером от имени соответствующего этому серверу прикладного клиента. Для перехвата всех запросов к прикладному серверу со стороны клиента и передачи их SOCKS-серверу предназначен SOCKS-клиент. Поскольку SOCKS- серверу известно о трафике на уровне сеанса (сокета), он может осуществлять тщательный контроль, например, блокировать работу конкретных приложений пользователей, если они не имеют необходимых полномочий на информационный обмен.
С момента разработки широкое распространение получили 4 и 5 версии (ч4 и v5) этого протокола. SOCKS ч5 в настоящее время одобрен организацией IETF (Internet Engineering Task Force) в качестве стандарта Internet и включен в RFC 1928 (Request for Comments — серия документов, в совершенствовании которых принимает участие все сообщество Internet).
Обобщенная схема взаимодействия по протоколу SOCKS ч4 сводится к следующему:
1. Запрос прикладного клиента, желающего установить соединение с каким-либо прикладным сервером в сети, перехватывает SOCKS-клиент, установленный на этом же компьютере.
2. SOCKS-клиент соединяется с SOCKS-сервером и передает ему запрос прикладного клиента.
3. SOCKS-сервер соединяется с запрошенным прикладным сервером.
4. Прикладной клиент и прикладной сервер взаимодействуют друг с другом по цепочке соединений, в которой SOCKS-сервер просто ретранслирует данные.
В реализации SOCKS-сервера ч4, кроме трансляции IP-адресов, могут быть предусмотрены другие функции посредничества по защите сетевого взаимодействия. Однако в протоколе SOCKS ч4 такие функции не специфицируются.
Протокол SOCKS ч5 является значительным развитием четвертой версии, реализуя следующие дополнительные возможности.
1. SOCKS-клиент может передавать SOCKS-серверу не только IP-адрес, компьютера, с которым необходимо установить соединение, но и его DNS-имя. SOCKS-сервер сам получит IP-адрес по DNS-имени. Таким образом, в локальных сетях, использующих SOCKS v5, можно обойтись без локального DNS-сервера, наличия которого требовал протокол SOCKS v4.
2. В SOCKS ч5 поддерживается не только протокол TCP, но и UDP. Вместе эти протоколы покрывают почти все множество используемых протоколов. Из широко используемых программ только диагностические утилиты PING и TRACERT пользуются протоколом ICMP и не могут работать через TCP и UDP.
3. Предусмотрена аутентификация пользователей, от имени которых обращаются SOCKS-клиенты. SOCKS-сервер может согласовывать с SOCKS- клиентом способ аутентификации. Аутентификация делает возможным разграничение доступа к компьютерным ресурсам. Допускается также двухсторонняя аутентификация, т. е. пользователь может, в свою очередь, убедиться, что соединился с нужным SOCKS-сервером.
4. SOCKS ч5 допускает использование не только текущих схем адресации в соответствии с протоколом IPv4, но и будущих, предусмотренных в IPv6.
Обобщенная схема установления соединения по протоколу SOCKS ч5 выглядит следующим образом:
1. Запрос прикладного клиента, желающего установить соединение с каким-либо прикладным сервером в сети, перехватывает установленный на этом же компьютере SOCKS-клиент.
2. SOCKS-клиент соединяется с SOCKS-сервером и сообщает ему идентификаторы всех методов аутентификации, которые он поддерживает.
3. SOCKS-сервер решает, каким методом аутентификации воспользоваться; если же SOCKS-сервер не поддерживает ни один из методов аутентификации, предложенных пользователем, соединение разрывается.
4. При поддержке каких-либо предложенных методов аутентификации SOCKS-сервер в соответствии с выбранным методом аутентифицирует пользователя, от имени которого выступает SOCKS-клиент; в случае без- успешной аутентификации SOCKS-сервер разрывает соединение.
5. После успешной аутентификации SOCKS-клиент передает SOCKS-
серверу DNS-имя или IP-адрес запрашиваемого прикладного сервера в сети и далее SOCKS-сервер на основе имеющихся правил разграничения доступа принимает решение об установлении соединения с этим прикладным сервером.
6. В случае установления соединения прикладной клиент и прикладной сервер взаимодействуют друг с другом по цепочке соединений, в которой SOCKS-сервер ретранслирует данные, а также может выполнять функции посредничества по защите сетевого взаимодействия; например, если в ходе аутентификации SOCKS-клиент и SOCKS-сервер обменялись сеансовым ключом, то весь трафик между ними может шифроваться.
Аутентификация пользователя, выполняемая SOCKS-сервером, может основываться на цифровых сертификатах в формате Х.509 или паролях. Для шифрования трафика между SOCKS-клиентом и SOCKS-сервером могут использоваться любые протоколы, ориентированные на сеансовый и более низкие уровни модели OSI. Максимальную функциональность по крипто- защите обеспечит протокол SSL. Помимо аутентификации пользователей, трансляции IP-адресов и криптозащиты трафика SOCKS-сервер может выполнять также такие функции, как:
• разграничение доступа к ресурсам внутренней сети;
• разграничение доступа к ресурсам внешней сети;
• фильтрация потока сообщений, например, динамический поиск вирусов;
• регистрация событий и реагирование на задаваемые события;
• кэширование данных, запрашиваемых из внешней сети.
SOCKS-клиенты, выполняющие перехват запросов клиентских приложений и взаимодействие с SOCKS-сервером, могут быть изначально встроены в универсальные клиентские программы. К приложениям, имеющим встроенную поддержку протокола SOCKS, относятся популярные Web-навигаторы Netscape Navigator (Communicator) и Microsoft Internet Explorer. Существуют также специальные программы, называемые "соксификаторами" дополняющие клиентские приложения поддержкой протокола SOCKS. Например, к таким программам относятся NEC SocksCap, а также Hummingbird SOCKS Client. При установке "соксификатор" внедряется между пользовательскими приложениями и стеком коммуникационных протоколов. Далее в процессе работы он перехватывает коммуникационные вызовы, формируемые приложениями, и перенаправляет их в случае надобности на SOCKS-сервер. Если нет нарушений установленных правил безопасности, то работа SOCKS-клиента совершенно прозрачна для клиентских приложений и пользователей.
Таким образом, для формирования защищенных виртуальных сетей по протоколу SOCKS в точке сопряжения каждой локальной сети с Internet на компьютере-шлюзе устанавливается SOCKS-сервер, а на рабочих станциях в локальных сетях и на компьютерах удаленных пользователей устанавливаются SOCKS-клиенты (рис. 3.15). SOCKS-сервер является ни чем иным, как межсетевым экраном, поддерживающим протокол SOCKS.
Удаленные пользователи могут подключаться к Internet любым способом по коммутируемой или выделенной линии. При попытке пользователя защищенной виртуальной сети установить соединение с каким-либо прикладным сервером SOCKS-клиент начинает взаимодействовать с SOCKS- сервером. По завершении первого этапа взаимодействия пользователь будет аутентифицирован, а проверка правил доступа покажет, имеет ли он право соединяться с конкретным серверным приложением, функционирующим на компьютере с указанным адресом. Дальнейшее взаимодействие может происходить по криптографический защищенному каналу.
Помимо защиты локальной сети от несанкционированного доступа, SOCKS-сервер может возлагаться контроль доступа пользователей этой локальной сети к открытым ресурсам Internet (Telnet, WWW, SMTP, РО- и: др.). Доступ является полностью авторизованным так как идентифицируются и аутентифицируются конкретные пользователи, а не компьютеры, с. которых они выходят в сеть. Правила доступа могут запрещать или разрешать соединения с конкретными ресурсами Internet в зависимости от полномочий конкретного сотрудника. Действие правил доступа может зависеть и от других параметров, например, от метода аутентификации или времени суток. В дополнение к функциям разграничения доступа может выполняться регистрация событий и реагирование на задаваемые события. В Для достижения наиболее высокой степени безопасности сетевого взаимодействия серверы локальной сети, к которым разрешен доступ со стороны Internet, должны быть выделены в отдельный подсоединяемый к SOCKS- серверу сегмент, образующий защищаемую открытую подсеть (см. локальную сеть слева на рис. 3.15). За счет трансляции сетевых адресов серверы и рабочие станции локальной сети, подсоединенной к Internet через SOCKS- сервер, могут не иметь зарегистрированных сетевых адресов и доменных имен. Разрешение адресов и имен производится SOCKS-сервером. При такой конфигурации пользователи защищенной виртуальной сети получают доступ ко всем серверам локальных сетей, входящим в состав виртуальной сети, так, как если бы эти серверы находились в одной локальной сети.
3.5. Распределение криптографических ключей и согласование параметров защищенных туннелей
При построении защищенных виртуальных сетей одними из важнейших функций являются функции распределения криптографических ключей и согласования параметров защищенных туннелей. Данные функции выполняются при формировании каждого криптозащищенного канала.
В защищенных виртуальных сетях по длительности использования различают следующие типы криптографических ключей:
• основные ключи, которые применяются в течение относительно долгого периода времени, например, недели, месяца или нескольких месяцев;
• временные ключи, каждый из которых генерируется для криптозащиты информации в рамках одного защищенного канала.
Основные ключи закрепляются за пользователями и серверами компьютерной сети и обеспечивают аутентификацию сторон, а также криптозащиту распределяемых временных ключей. После аутентификации сторон и безопасного распределения временных ключей, а также согласования параметров защищенного туннеля криптозащита трафика в рамках этого туннеля осуществляется на основе распределенных временных ключей.
Основные ключи шифрования, применяемые в течение относительно долгого периода времени, должны распределяться заблаговременно до непосредственного формирования защищенных виртуальных соединений. При этом способ распределения этих ключей зависит от вида криптосистемы, которой они соответствуют.
Симметричные криптосистемы характеризуются дороговизной, Сложностью и ненадежностью распределения основных ключей шифрования. Для пользователя аналогами основных ключей симметричного шифрования являются пароли, которые, как и эти ключи, необходимо хранить в секрете. Соответственно при обмене ключами симметричного шифрования должна быть: обеспечена не только их подлинность и целостность, но и конфиденциальность. Это требует первичного распределения основных ключей симметричного шифрования из рук в руки или по закрытым каналам связи, что для большой компьютерной сети связано с существенными экономическими затратами. В случае децентрализованного распределения основных ключей симметричного шифрования резко возрастает их количество, а соответственно — сложность распределения. При централизованном распределении, этих ключей в центре распределения известно кому и какие ключи что не гарантирует их конфиденциальности. Кроме того, при использовании в качестве основных — ключей симметричного шифрования невозможно реализовать протоколы защищенного взаимодействия не доверяющих друг другу сторон, так как общий секретный ключ любая из обладающих им сторон может разгласить.
Наиболее высокая эффективность распределения основных криптографических ключей достигается при использовании асимметричных криптосистем, когда распределению подлежат только открытые ключи. В этом случае закрытые ключи должны находиться у того, кто их сгенерировал. При должном обеспечении конфиденциальности закрытого ключа никто кроме его владельца не сможет с помощью этого ключа сформировать цифровую подпись, а также расшифровать информацию, зашифрованную соответствующим открытым ключом. Поэтому при использовании в качестве основных — ключей асимметричного шифрования обеспечивается реализация протоколов защищенного взаимодействия сторон, которые не доверяют друг другу.
Распределение открытых ключей, в отличие от закрытых ключей симметричного шифрования, не требует поддержания их конфиденциальности. Необходимо обеспечить лишь подлинность и целостность распределяемых открытых ключей, что успешно достигается при использовании цифровых сертификатов. Такой сертификат включает имя центра сертификации, описание владельца сертификата, его открытый ключ, период действия сертификата, а также дополнительные параметры. Цифровая подпись центра сертификации, сформированная под содержимым каждого сертификата обеспечивает подлинность и целостность указанной в нем информации, включая описание владельца и его открытый ключ. Наиболее популярным и общепринятым стандартом, специфицирующим содержимое и формат цифровых сертификатов, является стандарт Х.509.
Временные или, как их еще называют, сеансовые ключи, действующие в рамках одного криптозащищенного туннеля, распределяются по сети с помощью основных ключей. В связи с тем, что для криптографического закрытия передаваемых данных используются в основном симметричные криптосистемы, временные ключи, как правило, являются симметричными ключами шифрования. Для исключения возможности прогнозирования злоумышленником значения временного ключа его генерация должна выполняться на основе строго случайных параметров.
Безопасное распределение каждого временного ключа может выполняться двумя способами:
• его зашифровыванием по соответствующему основному ключу и передачей по сети принимающей стороне;
• самостоятельным формированием противоположными сторонами сеансового ключа на основе ранее распределенных (назначенных) основных ключей симметричного шифрования (паролей);
• самостоятельным формированием противоположными сторонами сеансового ключа на основе ранее распределенных или передаваемых друг другу открытых ключей.
Если для криптографического закрытия распределяемых временных ключей: используется асимметричная криптосистема, то кроме зашифровывания, передаваемые временные ключи должны еще и подписываться. Наличие подписи к полученному ключу позволяет принимающей стороне убедиться в том, что временный ключ зашифрован именно той стороной, которая указана в сообщении с зашифрованным ключом.
В случае самостоятельного формирования противоположными сторонами сеансового ключа на базе ранее распределенных основных ключей симметричного шифрования или ранее назначенных паролей каждая из сторон генерирует временный ключ на основе одних и тех же параметров, в состав которых для повышения безопасности помимо основного ключа или пароля должно входить согласованное случайное число. В качестве такого числа; целесообразно использовать текущую отметку времени, включающую год, дату и время.
При самостоятельном формировании противоположными сторонами сеансового ключа, если вычисление этого ключа осуществляется не на основе ранее распределенных, а на основе передаваемых друг другу открытых ключей, то либо эти ключи должны быть заверены центром сертификации, либо перед процедурой непосредственного формирования временного ключа необходимо выполнить аутентификацию сторон. Здесь также для повышения безопасности защищенного туннеля временный ключ целесообразно генерировать не только на основе открытых ключей, но и в зависимости от согласованного случайного числа. Одним из наиболее популярных алгоритмов формирования сеансового ключа на основе распределенных или передаваемых друг другу открытых ключей является алгоритм Диффи- Хеллмана.
В протоколах формирования защищенных туннелей на канальном уровне модели OSI (РРТР, L2F, Ь2ТР) временные ключи чаще всего генерируются на основе паролей пользователей. Генерация выполняется каждой стороной информационного взаимодействия после взаимной аутентификации. Совпадение двух временных ключей, генерируемых противоположными сторонами для одного защищенного туннеля, обеспечивается за счет их вычисления на основе одних и тех же параметров, в состав которых входит согласованное случайное число или временная метка, а также хэш-функция от пароля. Учитывая, что пароли являются аналогами основных ключей симметричного шифрования, более эффективным способом распределения временных ключей на канальном уровне является их централизованное распределение, например, на основе протокола Kerberos.
На сетевом и сеансовом уровне модели OSI в протоколах распределения временных ключей (SKIP, ISAKMP, SSL Handshake Protocol) в подавляющем большинстве применяются асимметричные криптосистемы. При использовании этих криптосистем временные ключи распределяются с помощью основных открытых ключей. Распределение временных ключей на сетевом уровне чаще всего выполняется по алгоритму Диффи-Хеллмана. На сеансовом уровне временные ключи, как правило, распределяются с помощью таких асимметричных систем, как RSA и Эль-Гамаля.
В зависимости от простоты реализации и достигаемой степени безопасности возможны следующие способы построения защищенного канала между двумя узлами компьютерной сети:
• формирование защищенного канала для каждого соединения, устанавливаемого от имени какого-либо программного приложения;
• формирование общего защищенного канала между сетевыми узлами и создание в рамках этого канала отдельных защищенных соединений, устанавливаемых от имени программных приложений.
Формирование защищенного виртуального канала для каждого соединения предполагает выполнение следующих этапов:
• выдачу запроса одной из сторон и достижение соглашения на создание защищенного туннеля;
• аутентификацию сторон, которая выполняется с помощью ранее распределенных основных ключей шифрования или назначенных паролей;
• распределение временных ключей и согласование параметров защищенного туннеля.
Вторая и третья фазы чаще всего пересекаются друг с другом, и аутентификация выполняется совместно с распределением временных ключей. Исключением является только случай, когда проверка подлинности сторон осуществляется на основе парольных методов.
При формировании защищенного туннеля для каждого соединения временные ключи всегда распределяются с помощью основных, в качестве которых могут также использоваться ранее назначенные пароли. Соответственно при частых защищенных соединениях между программными приложениями взаимодействующих сторон так же часто используются закрытые основные ключи, что увеличивает вероятность их хищения.
В случае формирования между двумя сетевыми узлами общего защищенного канала, в контексте которого создаются отдельные защищенные соединения, перечисленные этапы выполняются не только при установлении защищенного туннеля. Они реализуются и при создании каждого защищенного соединения, устанавливаемого от имени программных приложений взаимодействующих сторон.
В начале формирования общего защищенного канала распределяется главный сеансовый ключ симметричного шифрования. Это распределение осуществляется с помощью основных ключей взаимодействующих сторон. Распределение же временных ключей для каждого создаваемого защищенного соединения выполняется на основе главного сеансового ключа. Независимо от числа защищенных соединений, создаваемых в рамках одного защищен- ного туннеля, основные ключи используются только один раз при распределении главного сеансового ключа. Соответственно увеличивается безопасность информационного взаимодействия, так как снижается вероятность хищения закрытых основных ключей.
Таким образом, способ формирования защищенного канала для каждого соединения, устанавливаемого от имени какого-либо программного приложения, является достаточно простым в реализации. Но при этом снижается безопасность взаимодействия за счет частого использования закрытых основных ключей. Кроме того, частое распределение и генерация временных ключей на базе основных приводит к ресурсным издержкам.
Формирование между двумя сетевыми узлами общего защищенного канала и создание на его базе отдельных защищенных соединений характеризуется более высокой сложностью реализации. Однако в этом случае снижается уязвимость закрытых основных ключей, служащих для распределения главного сеансового ключа, и может быть обеспечено более эффективное расходование компьютерных ресурсов, затрачиваемых на генерацию временных ключей. Снижение ресурсных издержек на генерацию временных ключей достигается за счет переноса основной части вычислений на стадию распре- деления и генерации главного сеансового ключа.
Яркими представителями рассмотренных способов построения защищенных каналов на сетевом уровне являются популярные протоколы SKIP, а также ISAKMP.
Протокол SKIP ориентирован на формирование защищенного туннеля для каждого соединения. Этот протокол проще в реализации, но при самостоятельном использовании не поддерживает согласования параметров по поводу алгоритмов шифрования. Согласование всех параметров, необходимых для формирования универсального защищенного туннеля, обеспечивают дополнительные спецификации, которые могут быть выдержаны при реализации протокола SKIP.
Протокол ISAKMP ориентирован на формирование общего защищенного канала и создание в его контексте отдельных защищенных соединений. Данный протокол более совершенен и выбран в качестве обязательного стандарта для управления ключами в спецификации IPSec протокола IP перспективной шестой версии (чб). В текущей четвертой версии протокола IP чаще применяется протокол SKIP.
Протокол SKIP (Simple Кеу management for Internet Protocol — простой протокол управления ключами для Internet) разработан компанией Sun Micro- systems в 1994 году и предложен в качестве стандарта Internet. Хотя данный протокол пока не принят в качестве официального стандарта, он уже стал открытым индустриальным протоколом, поддерживаемым рядом компаний.
Протокол SKIP, являясь IP-совместимым протоколом, обеспечивает не только управление ключами шифрования, но и прозрачную для приложений криптозащиту IP-пакетов на сетевом уровне модели OSI. Реализация SKIP, устанавливаемая непосредственно над IP-драйвером, обрабатывает весь трафик, не накладывая никаких ограничений ни на вышележащее программное обеспечение, ни на физические каналы, используемые для передачи информации.
SKIP предусматривает самостоятельное формирование противоположными сторонами временного ключа на основе ранее распределенных или передаваемых друг другу открытых ключей. Технология распределения ключей основана на асимметричной криптосистеме Диффи-Хеллмана. В соответствии с данной криптосистемой для всей защищенной виртуальной сети выбираются большое простое число р, а также число а, такое, что а<р. Для обеспечения криптостойкости на число р накладывается следующее условие: разложение числа p — 1 на множители должно содержать по крайней мере один большой простой множитель, а размер числа р должен быть не менее 512 бит.
Каждый абонент защищенной виртуальной сети генерирует закрытый ключ х, являющийся большим случайным числом, и вырабатывает открытый ключ у, соответствующий закрытому ключу, в соответствии с формулой:
Все абоненты размещают свои открытые ключи в общедоступном справочнике. Данный справочник должен быть заверен, чтобы исключить возможные нападения путем подмены открытых ключей.
Если две стороны А и В хотят установить защищенный туннель, то сторона А берет из справочника открытый ключ абонента В и, используя свой закрытые ключ, вычисляет общий секретный ключ:
где у — открытый ключ абонента В, а х в и х, — закрытые ключи абонентов. В и А. Общий секретный ключ К, в нет необходимости передавать по каналам связи, поскольку абонент В по известному из справочника открытому ключу абонента А аналогичным способом вычисляет значение
где для у — открытый ключ абонента А, а х и х — закрытые ключи абонентов А и В. Для ускорения обмена общие секретные ключи, разделяемые с другими абонентами, на каждом из узлов защищенной виртуальной сети могут рассчитываться заранее и храниться вместе с асимметричными закрытыми ключами в зашифрованном виде.
Общий секретный ключ К не используется непосредственно для шифрования трафика между узлами А и В. Вместо него для шифрования конкретного пакета или их небольшой группы передающая сторона вырабатывает случайный временный ключ К называемый в спецификации SKIP пакетным ключом. Далее выполняется следующие действия (рис. 3.16):
• исходный IP-пакет зашифровывается по пакетному ключу и инкапсулируется в SKIP-пакет;
• пакетный ключ зашифровывается по общему секретному ключу и
помещается в SKIP-заголовок; при этом в SKIP-заголовке резервируется поле под эталонную характеристику результирующего IP-пакета;
• полученный SKIP-пакет инкапсулируется в результирующий IP-пакет; 5
• для результирующего IP-пакета с помощью хэш-функции рассчитывается по пакетному ключу Кр эталонная характеристика и полученное значение помещается как имитовставки в зарезервированное поле SKIP-заголовка.
Таким образом, протокол SKIP помимо эффективного распределения ключей обеспечивает аутентификацию и криптографическое закрытие IP- пакетов. Поскольку пакетный ключ К зашифрован по общему секретному ключу Кв. расшифровать этот пакетный ключ смогут только стороны А и В. Тем самым исключается возможность подмены имитовставки и расшифровывания исходного IP-пакета.
Сформированный в результате перечисленных операций результирующий IP-пакет отправляется получателю, который производит его обработку в обратном порядке:
• вычисляет общий секретный ключ Кя,
• расшифровывает пакетный ключ K,
• для полученного IP-пакета с помощью хэш-функции рассчитывает по пакетному ключу Кр текущую характеристику и сравнивает ее с ставкой;
• при совпадении, которое подтверждает целостность и подлинность полученного IP-пакета, получатель расшифровывает и извлекает из SKIP- пакета исходный IP-пакет.
В качестве как отправителя, так и получателя выступают приложения, функционирующие на компьютерах взаимодействующих сторон.
Применение для криптозащиты трафика не общего секретного ключа Кр, а случайного пакетного ключа Кр, повышает безопасность защищенного туннеля. Это связано с тем, что долговременный секретный ключ Кр не сможет быть скомпрометирован, так как вероятный противник не будет иметь достаточного материала для проведения быстрого криптоанализа с целью раскрытия этого ключа. Кроме того, защищенность обмена повышает также частая смена пакетных ключей шифрования. Если пакетный ключ и будет скомпрометирован, то ущерб затронет лишь небольшую группу пакетов, зашифрованных по этому временному ключу.
Протокол SKIP постоянно совершенствуется. В последних спецификациях этого протокола приняты дополнительные меры для защиты общего секретного ключа. Повышение криптостойкости протокола при атаках на общий секретный ключ достигнуто за счет шифрования пакетного ключа К, не по общему секретному ключу ХА, а по сеансовому ключу, генерируемому на основе ключа КА и нового параметра — числа N. Для возможности вычисления сеансового ключа принимающей стороной число N включается в SKIP-заголовок вместе с зашифрованным ключом КР. Правила для работы с числом N отнесены на усмотрение разработчика, однако для обеспечения совместимости версий предлагается считать, что N — это время в часах, от считанное от 00 час. 00 мин. 01.01.95. Проблема синхронизации часов на защищаемых системах решается достаточно просто — если параметр У отличается более, чем на 1, что составляет разбежку по времени свыше одного часа, то пакет не принимается, поскольку может быть сформированным злоумышленником.
Существенным нововведением является также приведение протокола SKIP к единообразному виду с точки зрения архитектуры протоколов семейства IP. Это выразилось, в первую очередь, в некотором упорядочении инкапсуляции протоколов, выполненной в соответствии со стандартом RFC 1827. В заголовке SKIP-пакета появилось поле NEXT HEADER, которое указывает протокол, содержащийся внутри данного SKIP-пакета. За счет этого достигается унификация последовательной инкапсуляции пакетов один в другой. Кроме того, внесены изменения для достижения совместимости с протоколом инкапсулирующей защиты содержимого (ESP), используемым в спецификации IPSec. При совместном использовании протоколов SKIP и ESP протокол SKIP отвечает только за передачу сеансового ключа и номеров алгоритмов криптозащиты, применяемых в ESP.
Для протокола SKIP разработан и ряд дополнительных спецификаций. С целью безопасного распределения открытых ключей, исключающего нарушение их целостности и подлинности, предлагается использовать цифровые сертификаты, соответствующие стандарту Х.509. Имеются также дополнительные спецификации, описывающие процедуру обмена информацией о поддерживаемых алгоритмах шифрования. Важность стандартизации этой процедуры обусловлена потенциальной возможностью использования различных алгоритмов шифрования на разных узлах защищенной виртуальной сети. Без согласования используемых алгоритмов шифрования криптозащищенные туннели не смогут быть сформированы. Предлагаемый протокол согласования базируется на расширении известного протокола ICMP (Internet Control Message Protocol, RFC 792) и предусматривает аутентификацию согласовываемых параметров. Для защиты от приема ложной информации в заголовок каждого SKIP-пакета, содержащего передаваемый ICMP-пакет, помещается имитовставка. В случае несоответствия текущей характеристики полученного пакета имитовставке, параметры согласования в ICMP-пакете игнорируются.
Для согласования параметров и управления ключами при формировании общего защищенного канала и создании в его рамках отдельных защищен- ных соединений наибольшее распространение получил протокол ISAKMP (Internet Security Association Key Management Protocol — протокол управления ключами и контекстами безопасности в Internet). Данный протокол разработан организацией Internet Engineering Task Force (IETF) и определен в качестве обязательного стандарта по управлению ключами в спецификам IPSec протокола IPv6. В сравнении с протоколом SKIP протокол lSAKMP более сложен в реализации, но обеспечивает повышенную безопасность информационного взаимодействия. При использовании ISAKMP снижается уязвимость закрытых основных ключей, служащих для распределения временных ключей шифрования.
Протокол ISAKMP описывает базовые процедуры аутентификации сторон, обмена ключами и согласования всех остальных параметров защищенного IPSec-туннеля. Однако он не содержит конкретные алгоритмы обмена криптографическими ключами. Поэтому для обмена ключами могут использоваться другие протоколы. В спецификации IPSec в качестве такого протокола, используемого при формировании общего защищенного туннеля, выбран протокол Oakley, основанный на алгоритме Диффи-Хеллмана. Объединение протоколов ISAKMP и Oakley обозначают как ISAKMP/Oakley. Следует отметить, что протоколы ISAKMP и Oakley разработаны таким образом, что они не зависят от спецификации IPSec. Например, для повышения безопасности процесса установления сеансов протокол Oakley вполне можно использовать вместе с протоколом SSL (Secure Sockets Layer).
В соответствии с протоколом ISAKMP согласование параметров защищенного взаимодействия необходимо как при формировании IPSec-канала, так и при создании в его рамках каждого защищенного однонаправленного соединения. Глобальные параметры защищенного канала образуют управляющий контекст и при их согласовании помимо протокола ISAKMP используется протокол распределения ключей Oakley. Параметры каждого защищенного соединения согласуются на основе созданного управляющего контекста и образуют контекст безопасности (Security Association — SA). Криптографические ключи для каждого защищенного соединения, входящие в его контекст безопасности, генерируются на основе ключей, выработанных в рамках управляющего контекста. При этом учитываются также алгоритмы аутентификации и шифрования, которые будут использоваться в защищенном соединении.
Согласование глобальных параметров защищенного канала
Согласование глобальных параметров выполняется при формировании общего защищенного канала между сетевыми узлами. Эти параметры служат для создания в рамках сформированного туннеля отдельных защищенных соединений. В терминологии ISAKMP согласованные глобальные параметры защищенного туннеля называют управляющим контекстом.
Возможные способы согласования глобальных параметров защищенного канала различаются по методу распределения общего секретного ключа, а также степени защиты идентификаторов конечных взаимодействующих сторон.
В простейшем случае общий сеансовый ключ для защищенного канал формируется на базе ранее распределенных основных ключей симметричного шифрования. Для небольших сетей такой подход может быть приемлемым, но он не масштабируемый. Последнее свойство обеспечивается при использовании асимметричных криптосистем. В протоколе IPSec для спецификации ISAKMP в качестве протокола распределения общего сеансового ключа выбран протокол Oakley, основанный на алгоритме Диффи- Хеллмана. Данный протокол называют также протоколом IKE (The Internet Кеу Exchange — протокол для обмена ключами в Internet).
При согласовании глобальных параметров защищенного канала идентификаторы конечных взаимодействующих сторон, например, их IP-адреса, могут передаваться в открытом виде или шифроваться. Сокрытие этих идентификаторов путем шифрования возможно в том случае, если защищенный формируется между промежуточными точками взаимодействия, например, между шлюзами локальных сетей, формирующих защищенный туннель от имени конечных узлов. Поскольку ISAKMP предусматривает работу в режим клиент/сервер, то ISAKMP-сервер, функционирующий на шлюзе, может выполнять криптозащиту идентификаторов ISAKMP-клиентов, функционирующих на рабочих станциях. Сокрытие идентификаторов конечных взаимодействующих сторон повышает защищенность от пассивного прослушивания открытой сети.
Протокол ISAKMP предусматривает следующую последовательность действий по формированию управляющего контекста, образующего согласованные глобальные параметры защищенного туннеля (рис. 3.17).
При необходимости защищенного взаимодействия инициатор направляет противоположной стороне (партнеру) запрос на формирование защищенного канала, включающий предложения по набору защитных алгоритмов и их параметров (см. шаг 1). В запросе инициатора предложения по набору защитных алгоритмов и их параметров упорядочены по степени предпочтительности. В ответном сообщении (см. шаг 2) партнер информирует о тех алгоритмах защиты и параметрах, которые его устраивают. Для каждой защитной функции (генерация и распределение ключей, аутентификация, шифрование) выбирается один алгоритм и его параметры.
На третьем и четвертом шагах взаимодействия инициатор и партнер отправляют друг другу свои открытые ключи, необходимые для выработки общего секретного ключа. В соответствии протоколом Oakley для взаимодействующих сторон А и В этими открытыми ключами являются— заданные для защищенной виртуальной сети большие простые числа, а х и х в — закрытые ключи абонентов А и В, сгенерированные как большие случайные числа. Общий секретный ключ вычисляется в соответствии со следующим выражением: Открытые ключи направляются друг другу вместе со случайными одноразовыми номерами, служащими для защиты от воспроизведения сообщений. Для обеспечения подлинности направляемых друг другу открытых ключей предполагается использование технологии цифровых сертификатов в соответствии со стандартом Х.509. Но способы воплощения этой технологии совместно с ISAKMP в спецификации IPSec пока не определены из за отсутствия устраивающей всех реализации службы каталогов.
На основе общего секретного ключа вырабатываются три вида ключей: О SKEYID d — ключевой материал, используемый для генерации временных (протокольных) ключей для защищенных соединений.
• SKEYID a — сеансовые ключи, используемые для аутентификации сторон и согласовываемых параметров.
• SKEYID e — сеансовые ключи, используемые для шифрования согласовываемых параметров.
Пятый и шестой шаги формирования управляющего контекста служат для обмена идентификационной информацией, зашифрованной и подписанной по ключам SKEYID e и SKEYID a.
Формирование управляющего контекста защищенного канала на основе протокола ISAKMP/Oakley требует больших ресурсных затрат на вычисление общего секретного ключа, а также генерацию сеансовых ключей. Но за счет этого снижаются затраты на генерацию временных ключей для защищенных соединений. Учитывая, что для многих защищенных соединений общий защищенный канал формируется только один раз, то такой подход в итоге эффективнее формирования защищенного канала для каждого соединения. В зависимости от условий использования протокола ISAKMP/Oakley возможен компромисс между криптостойкостью и необходимым объемом вычислений. При формировании управляющего контекста на основе более коротких открытых ключей снижается объем вычислений, но по причине уменьшения криптостойкости также снижается и безопасность коммуникаций.
Протокол ISAKMP предусматривает не только защиту от нарушений конфиденциальности и подлинности согласовываемых глобальных параметров, но и защиту от повтора, задержек и удаления защищенных сообщений. Для защиты от перечисленных атак применяются так называемые идентифицирующие цепочки. Эти цепочки формируются инициатором и его партнером, с использованием текущего времени и присутствуют во всех ISAKMP-
сообщениях (рис. 3.18). Исключением является первый запрос на формирование защищенного канала, в который включена только одна из идентифицирующих цепочек — цепочка инициатора.
Как инициатор, так и партнер для каждого отправляемого сообщения генерирует на основе текущего времени свою идентифицирующую цепочку и вставляет ее в это сообщение. В каждое ответное сообщение помимо идентифицирующей цепочки отправителя вставляется также цепочка противоположной стороны, полученная в сообщении, для которого формируется этот ответ. При получении ответного сообщения получатель проверяет наличие посланной им идентифицирующей цепочки. При задании максимального времени следования ожидаемого сообщения использование идентифицирующих цепочек позволяет обнаружить повторные, задержанные и удаленные сообщения.
Важным видом атак являются атаки, реализуемые путем маскировки под санкционированного участника взаимодействия. Таким способом можно не только получить несанкционированный доступ к конфиденциальной информации, но и выполнить любые другие противоречащие политике безопасности действия. Например, можно вызвать нарушение работоспособности любого узла защищенной виртуальной сети путем навязывания интенсивных вычислений, присущих криптографии с открытым ключом. Для защиты от маскировки под санкционированного участника взаимодействия на третьем и четвертом шагах согласования глобальных параметров (см. рис. 3.17) совместно с обменом открытых ключей должны выполняться функции проверки подлинности взаимодействующих сторон. Такая проверка эффективно реализуется при использовании цифровых сертификатов. Для доказательства любым из участников взаимодействия, что именно он является владельцем представленного открытого ключа, ему достаточно сформировать цифровую подпись под отправляемым сообщением, включающим его цифровой сертификат, а также отметку времени для защиты этого сообщения от повтора. Получатель такого сообщения выполняет следующие действия:
1. Извлекает из цифрового сертификата открытый ключ отправителя и проверяет по этому ключу истинность его цифровой подписи.
2. Проверяет по имеющемуся открытому ключу центра сертификации его цифровую подпись в сертификате.
3. В случае истинности проверяемых цифровых подписей и действительности по времени пришедшего сообщения получатель делает вывод, что отправитель сообщения является именно тем, за кого себя выдает.
Сформированный защищенный туннель с согласованными глобальными параметрами является двунаправленным в том смысле, что любая из общающихся сторон имеет возможность инициировать с помощью этих параметров отдельное защищенное соединение. Для передачи ISAKMP- сообщений может использоваться любой протокол, однако в спецификации IPSec в качестве такого протокола определен протокол UDP с номером порта 500.
Согласование параметров каждого защищенного соединения
После создания общего защищенного канала параметры каждого защищенного соединения согласуются на основе сформированных глобальных параметров канала и образуют контекст безопасности (Security Association- SA), называемый еще протокольным контактом. Каждое защищенное соединение, создаваемое в рамках общего защищенного канала, является однонаправленным соединением, т. е. соединением от отправителя пакета со- общения к его получателю. При этом в одном защищенном IPSec- соединении может быть использован только один из двух протоколов криптозащиты пакетов сообщений:
• протокол аутентифицирующего заголовка (Authentication Header — АН), предусматривающий аутентификацию источника данных, проверку их целостности и подлинности после приема, а также защиту от навязывания повторных сообщений;
•протокол инкапсулирующей защиты содержимого (Encapsulating Security Payload — ESP), обеспечивающий криптографическое закрытие передаваемых пакетов сообщений и предусматривающий также выполнение всех функций протокола аутентифицирующего заголовка (АН).
На базе общего защищенного канала, сформированного по протоколу ISAKMP, могут быть также созданы защищенные соединения, не соответствующие спецификации IPSec. Однако и в этом случае при создании защищенного соединения необходимо формирование контекста безопасности и в одном соединении может быть использован только один протокол крипто защиты.
При симметричном взаимодействии партнерам придется сформировать как минимум два защищенных соединения, а соответственно два контекста безопасности (SA) — по одному в каждом направлении. Если протоколы криптозащиты АН и ESP используются вместе, то потребуется сформировать четыре контекста безопасности.
В состав согласовываемых параметров каждого защищенного соединения, образующих контекст безопасности, входят следующие элементы:
• номер используемого протокола криптозащиты (АН, ESP или протокол криптозащиты, не входящий в спецификацию IPSec);
• номера алгоритмов криптозащиты и их параметры;
• режим криптозащиты (транспортный или туннельный);
• временные ключи шифрования, действительные только для текущего
защищенного соединения;
• срок существования защищенного соединения;
• максимальный размер пакетов;
• дополнительные параметры (счетчик, окно, флаги) для защиты от повтора, задержки и удаления пакетов сообщений. Из данного перечня следует, что при формировании контекста безопасности согласуется также срок существования защищенного соединения, который зависит от требуемой криптостойкости. Согласно этому сроку определяется, как скоро, в зависимости от времени или объема переданных данных, потребуется закрытие текущего защищенного соединения и, возможно, открытие нового. Важно отметить, что время жизни задается не только для каждого защищенного соединения, но и для каждого защищенного канала. Этот параметр может быть задан максимальным интервалом времени или максимальным объемом переданных данных. Например, срок существования защищенного соединения может быть определен как 15 минут или 10 Мбайт, а срок существования защищенного канала — как 60 минут или 40 Мбайт. При увеличении длины используемых ключей и криптостойкости применяемых алгоритмов криптозащиты также увеличивается допустимый срок существования защищенного канала и защищенного соединения. Такой подход позволяет сбалансировать криптографическую стойкость сервисов и стоимость накладных расходов на передачу ISAKMP-пакетов.
Пользователями защищенных соединений, как правило, являются прикладные процессы и между двумя узлами сети может существовать произвольное число таких соединений, сформированных в рамках одного защищенного канала (рис. 3.19). Следует отметить, что пара сетевых узлов может одновременно поддерживать несколько защищенных каналов, если имеются приложения с совершенно разными криптографическими требованиями. Например, допустима выработка части временных ключей на основе предварительно распределенных основных ключей симметричного шифрования, в то время как другая часть порождается по алгоритму Диффи-Хеллмана.
Защищенное соединение, соответствующее спецификации IPSec, идентифицируется целевым IP-адресом, используемым протоколом криптозащиты (АН или ESP), а также дополнительной величиной — индексом параметров безопасности (Security Parameter Index — SPI). Индекс параметров безопасности необходим для идентификации каждого из контекстов безопасности (SA), так как может существовать несколько защищенных соединений с одинаковыми IP-адресами и протоколами криптозащиты. Этот индекс включается в заголовки защищенных IPSec-пакетов, чтобы принимающая сторона смогла правильно расшифровать и аутентифицировать эти пакеты, воспользовавшись указанным контекстом безопасности (SA).
Процедура формирования защищенного соединения существенно проще процедуры формирования защищенного канала. Согласование параметров для двух симметричных однонаправленных соединений осуществляется на основе сформированного управляющего контекста с помощью трех шагов (рис. 3.20). Для криптозащиты сообщений по согласованию параметров создаваемых соединений, а также распределения временных ключей, действующих только в рамках своих соединения, предназначены следующие сеансовые ключи, выработанные при формировании защищенного канала:
• SKEYID а — сеансовые ключи, используемые для аутентификации сторон и согласовываемых параметров.
• SKEYID e — сеансовые ключи, используемые для шифрования согласовываемых параметров.
• SKEYID d — ключевой материал, используемый для генерации временных (протокольных) ключей для защищенных соединений.
По ключам SKEYID e и SKEYID a шифруются и аутентифицируются все три сообщения, представленные на рис. 3.20. Для аутентификации используется имитовставка, вычисляемая с помощью хэш-функции, в качестве аргументов которой выступают аутентифицируемое сообщение и сеансовый ключ SKEYID а. Временные ключи для защищенного соединения генерируются путем применения хэш-функции к ключу SKEYID d с дополни- тельными параметрами, в число которых входят одноразовые номера инициатора и партнера. Сообщения (1) и (2) могут нести дополнительную нагрузку, например, данные для выработки новых ключей по алгоритму , Биффи-Хелмана или идентификаторы клиентов, от имени которых [ ISAKMP-серверы формируют защищенные соединения. За один информационный обмен по согласованию параметров, состоящий из трех шагов ) (рис. 3.20), формируется два однонаправленных соединения — по одному в каждом направлении.
Принимающая сторона соединения задает для него индекс параметров безопасности (SPI), с помощью которого она будет находить контекст безопасности (SA) для обработки получаемых криптозащищенных пакетов.
Согласование параметров защищенного соединения, включая генерацию и распределение временных ключей, не требует большого объема вычислений, так как здесь используется набор простых математических операций. Так же, как задаются сроки существования защищенных каналов и защищенных соединений, могут быть заданы ограничения на допустимое число защищенных соединений в рамках одного защищенного канала. Превышение этого числа ведет к тому, что ключи, сгенерированные при формировании управляющего контекста, а соответственно и все временные ключи, окажутся под угрозой вскрытия. В настоящее время нет жесткого правила, определяющего число защищенных соединений для одного защищенного туннеля, и разработчики средств защиты действуют, руководствуясь общими соображениями и учитывая условия использования создаваемых продуктов.