После того как кадр PPP был инкапсулирован в кадр с заголовком GRE, выполняется инкапсуляция в кадр с IP-заголовком. IP-заголовок содержит адреса отправителя и получателя пакета. В заключение PPTP добавляет PPP заголовок и окончание.

Система-отправитель посылает данные через туннель. Система-получатель удаляет все служебные заголовки, оставляя только данные PPP.

Поскольку вся идея дистанционного доступа состоит в разрешении машине клиента подключаться по сети к машине сервера, соединение PPTP инициируется клиентом, который использует служебное средство Windows NT -- Remote Access Service (RAS) -- для установления PPP-соединения с поставщиком услуг Интернет. Затем при активизированном соединении PPP с помощью сервера, подключенного к Интернет и действующего как сервер RAS, клиент применяет RAS для выполнения второго соединения. На этот раз в поле номера телефона указывается IP-адрес (или доменное имя), и клиент, для того чтобы осуществить соединение, вместо COM-порта использует VPN-порт (VPN-порты конфигурируются на машинах клиента и сервера в процессе инсталляции PPTP).

Ввод IP-адреса инициирует передачу запроса серверу на начало сеанса. Клиент ожидает от сервера подтверждения имени пользователя и пароля и ответа сообщением, что соединение установлено. В этот момент начинает свою работу канал PPTP, и клиент может приступить к туннелированию пакетов серверу. Поскольку они могут быть пакетами IPX и NetBEUI, сервер может выполнять с ними свои обычные процедуры обеспечения защиты.

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

В протоколе PPTP определено две схемы его применения.

Первая схема рассчитана на поддержание защищенного канала между сервером удаленного доступа ISP и пограничным маршрутизатором корпоративной сети представлена на рисунке 2.2.



Рисунок 2.2 - Защищенный канал "провайдер-маршрутизатор корпоративной сети" на основе протокола PPTP

В этом варианте компьютер удаленного пользователя не должен поддерживать протокол PPTP. Он связывается с сервером удаленного доступа RAS, установленного у ISP, с помощью стандартного протокола PPP и проходит первую аутентификацию у провайдера. RAS ISP должен поддерживать протокол PPTP. По имени пользователя RAS ISP должен найти в базе учетных данных пользователей IP-адрес маршрутизатора, являющегося пограничным маршрутизатором корпоративной сети данного пользователя. С этим маршрутизатором RAS ISP устанавливает сессию по протоколу PPTP. Протокол PPTP определяет некоторое количество служебных сообщений, которыми обмениваются взаимодействующие стороны, служебные сообщения передаются по протоколу TCP. RAS ISP передает маршрутизатору корпоративной сети идентификатор пользователя, по которому маршрутизатор снова аутентифицирует пользователя по протоколу CHAP. Если пользователь прошел вторичную аутентификацию (она для него прозрачна), то RAS ISP посылает ему сообщение об этом по протоколу РРР и пользователь начинает посылать свои данные в RAS ISP по протоколу IP, IPX или NetBIOS, упаковывая их в кадры РРР. RAS ISP осуществляет инкапсуляцию кадров РРР в пакеты IP, указывая в качестве адреса назначения адрес пограничного маршрутизатора, а в качестве адреса источника -- свой собственный IP-адрес. Пакеты РРР шифруются с помощью секретного ключа, в качестве которого используется дайджест от пароля пользователя, который хранится в базе учетных данных RAS ISP для аутентификации по протоколу CHAP.

Внутренние серверы корпоративной сети также не должны поддерживать протокол PPTP, так как пограничный маршрутизатор извлекает кадры РРР из пакетов IP и посылает их по сети в необходимом формате -- IP, IPX или NetBIOS.

Microsoft предложила также и другую схему использования протокола PPTP, с помощью которой образуется защищенный канал между компьютером удаленного пользователя и пограничным маршрутизатором корпоративной сети, в качестве которого должен использоваться RAS Windows NT/2000. Данная схема приведена на рисунке 2.3

Рисунок 2.3 - Защищенный канал "клиент - маршрутизатор" корпоративной сети на основе протокола PPTP

Сначала клиент звонит на сервер RAS ISP и устанавливает с ним связь по протоколу PPP, проходя аутентификацию одним из способов, поддерживаемых провайдером -- по протоколам PAP, CHAP или с помощью терминального диалога.

После аутентификации у провайдера, пользователь вторично "звонит", на этот раз в сервер удаленного доступа корпоративной сети. Этот "звонок" отличается от обычного тем, что вместо телефонного номера указывается IP-адрес RAS Windows NT, подключенного к Интернет со стороны корпоративной сети. При этом устанавливается сессия по протоколу PPTP между клиентским компьютером и RAS корпоративной сети. Клиент еще раз аутентифицируется, теперь на сервере RAS его сети, а затем начинается передача данных, как и в первом варианте.

2.2.2 Протокол L2TP

Протокол L2TP (Layer-2 Tunneling Protocol -- L2TP) разработан в организации Internet Engineering Task Force (IETF) при поддержке компаний Microsoft и Cisco Systems как протокол защищенного туннелирования РРР-трафика через сети общего назначения с произвольной средой. Работа над данным протоколом велась на основе протоколов РРТР и L2F, и он вобрал в себя лучшие возможности обоих проектов. L2TP, в отличие от РРТР, не привязан к протоколу IP, а потому может быть использован в сетях с коммутацией пакетов, например, в сетях ATM. Кроме того, L2TP предусматривает управление потоками данных, отсутствующее в L2F. Главное же, по мнению разработчиков, то, что новый протокол должен стать общепринятым стандартом, признаваемым всеми производителями.

Чтобы понять суть концепции L2TP, нужно представлять цели, которые преследовали компании Microsoft и Cisco при разработке РРТР и L2F. В соответствии с целями, которые преследовались при разработке РРТР и L2F, различные организации должны были получить возможность делегировать функции безопасного удаленного доступа провайдерам Internet. Это, в свою очередь, позволило бы снизить затраты на администрирование и приобретение аппаратных средств, так как локальные сети этих организаций смогли бы обойтись без множества модемов и дополнительных телефонных каналов. В обоих протоколах поставленная цель была достигнута. И L2F, и РРТР позволяют провайдерам Internet проводить удаленные сеансы по протоколу РРР, используя для аутентификации запросы к серверам безопасности локальных сетей [7].

Различия между L2F и РРТР объясняются специализацией их разработчиков. Cisco производит аппаратные маршрутизаторы для сетевой инфраструктуры, тогда как Microsoft выпускает операционные системы. Для работы провайдеров с L2F нужно, чтобы их маршрутизаторы и серверы Удаленного доступа поддерживали этот протокол. Что касается протокола РРТР, то провайдеры не обязательно должны иметь средства организации туннелей, так как туннели могут формироваться специальным программным обеспечением конечных точек взаимодействия -- компьютеров удаленных пользователей и серверов удаленного доступа локальных сетей. Тем не менее, L2F по сравнению с РРТР имеет несколько преимуществ. Так, РРТР требует применения маршрутизации на базе IP, тогда как L2F не привязан к конкретным протоколам сетевого уровня, используемым для транспортировки РРР-кадров.

В гибридном протоколе L2TP не только объединены лучшие черты протоколов РРТР и L2TP, но и добавлены новые функции.

Как и РРТР, новая спецификация не нуждается во встроенной аппаратной поддержке, хотя оборудование, специально предназначенное для нее, повысит производительность и защищенность системы. В L2TP есть ряд отсутствующих в спецификации РРТР функций защиты, включая возможность работы с протоколом IPsec.

Наследственные черты L2F видны в том, что протокол не привязан к среде IP и с таким же успехом способен работать в любых сетях с коммутацией пакетов например, в сетях ATM или в сетях с ретрансляцией кадров (frame relay).

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

По существу протокол L2TP представляет собой расширение РРР-протокола функциями аутентификации удаленных пользователей, установки защищенного виртуального соединения, а также управлением потоками данных. В соответствии с протоколом L2TP в качестве сервера удаленного доступа провайдера должен выступать концентратор доступа (Access Concentrator), который реализует клиентскую часть протокола L2TP и обеспечивает пользователю сетевой доступ к его локальной сети через Internet. Роль сервера удаленного доступа локальной сети должен выполнять сетевой сервер L2TP (L2TP Network Server), функционирующий на любых платформах, совместимых с протоколом РРР.

Подобно протоколам РРТР и L2F, протокол L2TP предусматривает 3 этапа формирования защищенного виртуального канала (рисунок 2.4):

- установление соединения с сервером удаленного доступа локальной сети;

- аутентификация пользователя;

- конфигурирование криптозащищенного туннеля.

Рисунок 2.4 - Схема взаимодействия по протоколу L2TP

Для установления соединения с сервером удаленного доступа локальной сети, в качестве которого выступает сетевой сервер L2TP, удаленный пользователь связывается по протоколу РРР с концентратором доступа L2TP, функционирующим на сервере провайдера Internet или другой публичной сети. На данном этапе концентратор доступа L2TP может выполнить аутентификацию пользователя от имени провайдера. Далее по имени пользователя концентратор доступа провайдера определяет IP-адрес сетевого сервера L2TP, принадлежащего требуемой локальной сети. Между концентратором доступа провайдера и сервером L2TP локальной сети устанавливается сессия по протоколу L2TP, называемая сессией L2TP.

После установки сессии L2TP происходит процесс аутентификации пользователя на сервере L2TP локальной сети. Для этого может использоваться любой из стандартных алгоритмов аутентификации, например, алгоритм CHAP. Как и в протоколах РРТР и L2F, в спецификации L2TP отсутствуют описания методов аутентификации.

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

Несмотря на свои достоинства, протокол L2TP не устраняет всех недостатков туннельной передачи данных на канальном уровне. В частности, необходима поддержка L2TP провайдерами. Протокол L2TP ограничивает весь трафик рамками выбранного туннеля и лишает пользователей доступа к Другим частям Internet. Для текущей (четвертой) версии протокола IP не предусматривается создание криптозащищенного туннеля между конечными точками информационного взаимодействия. Кроме того, предложенная спецификация обеспечивает стандартное шифрование только в IP-сетях при использовании протокола IPSec.

2.3 Сетевой уровень

Спецификацией, где описаны стандартные методы для всех компонентов и функций защищенных виртуальных сетей, является протокол Internet Protocol Security (IPSec), соответствующий сетевому уровню модели OSI и входящий в состав новой версии протокола IP -- IPv6. Протокол IPSec иногда еще называют протоколом туннелирования третьего уровня (Layer-3 Tunneling) . IPSec предусматривает стандартные методы аутентификации пользователей или компьютеров при инициации туннеля, стандартные способы шифрования конечными точками туннеля, формирования и проверки Цифровой подписи, а также стандартные методы обмена и управления криптографическими ключами между конечными точками. Этот гибкий стандарт предлагает несколько способов для выполнения каждой задачи. Выбранные методы для одной задачи обычно не зависят от методов реализации других задач. Для функций аутентификации IPSec поддерживает цифровые сертификаты популярного стандарта Х.509.

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

Для управления криптографическими ключами на сетевом уровне модели OSI наиболее широкое распространение получили такие протоколы, как SKIP (Simple Key management for Internet Protocols) и ISAKMP (Internet Security Association and Key Management Protocol). SKIP проще в реализации, но он не поддерживает переговоров по поводу алгоритмов шифрования. Если получатель, использующий SKIP, не в состоянии расшифровать пакет, он уже не сможет согласовать метод шифрования с противоположной стороной. Протокол ISAKMP поддерживает такие переговоры и выбран в качестве обязательного протокола для управления ключами в IPSec для IPv6. Другими словами протокол ISAKMP является составной частью протокола IPSec. В текущей четвертой версии протокола IP (в протоколе IPv4) может применяться как протокол ISAKMP, так и протокол SKIP.

Протокол IPsec.

IPSec - набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP, позволяет осуществлять подтверждение подлинности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена ключами в сети Интернет.

Существует два режима работы IPsec: транспортный режим и туннельный режим. В транспортном режиме шифруется (или подписывается) только информативная часть IP-пакета. Маршрутизация не затрагивается, так как заголовок IP пакета не изменяется (не шифруется). Транспортный режим как правило используется для установления соединения между хостами. Он может также использоваться между шлюзами, для защиты туннелей, организованных каким-нибудь другим способом (IP tunnel, GRE и др.). В туннельном режиме IP-пакет шифруется целиком. Для того, чтобы его можно было передать по сети, он помещается в другой IP-пакет. По существу, это защищённый IP-туннель. Туннельный режим может использоваться для подключения удалённых компьютеров к виртуальной частной сети или для организации безопасной передачи данных через открытые каналы связи (например, Интернет) между шлюзами для объединения разных частей виртуальной частной сети. Режимы IPsec не являются взаимоисключающими. На одном и том же узле некоторые SA могут использовать транспортный режим, а другие -- туннельный.

В IPsec используются две базы данных: SPD (Security Policy Database, куда записываются правила обеспечения безопасности) и SADB (Security Association Database, где хранятся данные об активных ассоциациях безопасности).

Система IPsec предлагает многовариантный механизм реализации безопасности для обоих концов соединения. Эта техника пригодна для отдельного пользователя, особенно если он работает на выезде, и для виртуальных субсетей организаций, работающих с данными, которые требуют секретности.

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

IPsec предусматривает процедуры аутентификации и шифрования. Формирование и удаления заголовка IPsec может осуществляться в машине клиента или в сетевом шлюзе (маршрутизаторе).

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

Заголовок аутентификации (AH) и Encapsulating Security Payload (ESP) являются двумя протоколами нижнего уровня, применяемыми IPsec, именно они осуществляют аутентификацию и шифрование+аутентификацию данных, передаваемых через соединение. Эти механизмы обычно используются независимо, хотя возможно (но не типично) их совместное применение.

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

Установление IPsec-соединения подразумевает любые варианты крипто-алгоритмов, но ситуация существенно упрощается благодаря тому, что обычно допустимо применение двух, максимум трех вариантов.

На фазе аутентификации вычисляется контрольная сумма ICV (Integrity Check Value) пакета с привлечением алгоритмов MD5 или SHA-1. При этом предполагается, что оба партнера знают секретный ключ, который позволяет получателю вычислить ICV и сравнить с результатом, присланным отправителем. Если сравнение ICV прошло успешно, считается, что отправитель пакета аутентифицирован. Протокол AH всегда осуществляет аутентификацию, а ESP выполняет ее опционно.

Шифрование использует секретный ключ для кодирования данных перед их транспортировкой, что исключает доступ к содержимому со стороны злоумышленников. В системе IPsec могут применяться следующие алгоритмы: DES, 3DES, Blowfish, CAST, IDEA, RC5 и AES. Но, в принципе, разрешены и другие алгоритмы [8].

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

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

Протокол AH используется для аутентификации, но не для шифрования IP трафика, и служит для подтверждения того, что мы связаны именно с тем, с кем предполагаем, что полученные данные не искажены и не подменены при транспортировке.

Аутентификация выполняется путем вычисления зашифрованного аутентификационного хэш-кода сообщения. Хэширование охватывает практически все поля IP пакета (исключая только те, которые могут модифицироваться при транспортировке, например, TTL или контрольная сумма заголовка). Этот код записывается в AH заголовке и пересылается получателю.

AH заголовок содержит пять важных полей которые показаны на рисунке 2.6.



Рисунок 2.6 - Формат заголовка протокола AH

- AH len Определяет длину заголовка пакета, измеренную в 32-битовых словах, за вычетом двух слов (это диктуется RFC 1883 для IPv6).

- Зарезервировано. Поле зарезервировано на будущее и должно содержать нули.

- Индекс параметров безопасности (SPI)

- 32-битовый идентификатор, который помогает получателю выбрать, к какому из входных обменов относится этот пакет. Каждый обмен, защищенный AH, использует хэш-алгоритм (MD5, SHA-1 и т.д..), какие-то секретные и возможно некоторые иные данные. SPI может рассматриваться как индекс таблицы наборов таких параметров, чтобы облегчить выбор нужного набора.

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

- Аутентификационные данные. Это контрольная сумма ICV (Integrity Check Value), вычисленная для всего пакета, включая большинство полей заголовка. Получатель повторно вычисляет тот же хэш. Если значения кодов не совпадут, пакет был поврежден в пути или не соответствует секретному ключу. Такие пакеты отбрасываются. ICV часто называется также МАС (Message Authentication Code). Для вычисления МАС используются следующие поля:

- поля IP-заголовка, которые не меняются при транспортировке.

- заголовок АН, кроме поля данных аутентификации

- поле данных протокола верхнего уровня, которые остаются неизменными при транспортировке.

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

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

Перестановка кодов протокола необходима для восстановления исходного вида IP пакетов конечным получателем: после выполнения проверки получателем корректности IPsec заголовка, этот заголовок удаляется, а в поле код протокола IP заносится прежнее значение (TCP, UDP и т.д.). Когда к адресату приходит пакет, успешно прошедший процедуру аутентификации, заголовок AH удаляется, а содержимое поля протокол (=AH) в IP заголовке заменяется запомненным значением поля следующий заголовок. Таким образом, восстанавливается первоначальный вид IP дейтограммы, и пакет может быть передан ожидающему процессу.

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

Большинство реализаций рассматривает оконечную точку туннеля в качестве сетевого интерфейса. Реконструированный пакет может быть доставлен локальной машине или маршрутизован куда-либо еще (согласно IP-адресу места назначения в инкапсулированном пакете). Дальнейшая его транспортировка уже не обеспечивается средствами безопасности IPsec.

В то время как транспортный режим используется исключительно для обеспечения безопасной связи между двумя компьютерами, туннельный режим обычно применяется между шлюзами (маршрутизаторами, сетевыми экранами, или отдельными VPN устройствами) для построения VPN (Virtual Private Network).

Следует заметить, что в пакете IPsec нет специального поля "режим": которое бы позволяло разделить транспортный режим от туннельного, эту функцию выполняет поле следующий заголовок пакета AH.

Когда поле следующий заголовок соответствует IP, это означает, что пакет инкапсулирует всю IP-дейтограмму (туннельный режим), включая независимые адреса отправителя и получателя, которые позволяют реализовать маршрутизацию после туннеля. Любое другое значение поля (TCP, UDP, ICMP и т.д.) означает транспортный режим (безопасная транспортировка по схеме точка-точка). IP дейтограмма верхнего уровня имеет ту же структуру вне зависимости от режима, и промежуточные маршрутизаторы обрабатывают трафик, не анализируя внутреннее содержание IPsec/AH. Заметим, что ЭВМ, в отличие от сетевого шлюза, должна поддерживать как транспортный, так и туннельный режим, но при формировании соединения машина-машина формирование туннеля представляется избыточным. Кроме того, для сетевого шлюза (маршрутизатора, сетевого экрана и т.д.) необходимо поддерживать туннельный режим, в то же время поддержка транспортного режима представляется полезной лишь для случая, когда шлюз сам является конечным адресатом (например, в случае реализации процедур удаленного управления сетью). AH содержит ICV (Integrity Check Value) в аутентификационной части заголовка, и эта контрольная сумма формируется обычно (но не всегда) с помощью стандартного криптографического хэш алгоритма, например, MD5 или SHA-1. Здесь используется не традиционная контрольная сумма, которая не может предотвратить намеренное искажение содержимого, а алгоритм HMAC (Hashed Message Authentication Code), который при вычислении ICV применяет секретный ключ. Несмотря на то, что хакер может заново вычислить хэш, без секретного ключа он не сможет корректно сформировать ICV. Алгоритм HMAC описан в документе RFC 2104. Заметим, что IPsec/AH не определяет, какой должна быть аутентификационная функция, вместо этого предоставляются рамки, в которых можно реализовать любую функцию, согласованную отправителем и получателем. Можно использовать для аутентификации цифровую подпись или криптографическую функцию, если оба участника их поддерживают. Именно потому, что AH обеспечивает хорошую защиту содержимого пакета, так как этот протокол покрывает все, что только нужно защитить, эта защита приводит к несовместимости с NAT (Network Address Translation).

Протокол NAT используется для установления соответствия между частными IP-адресами (например, 19.125.1.X) и легальными IP. При этом IP заголовок модифицируется устройством NAT путем замены IP-адресов отправителя и получателя. Когда изменяются IP-адреса, нужно заново вычислить контрольную сумму заголовка. Это нужно сделать в любом случае. Так как устройство NAT обычно размещается в одном шаге между отправителем и получателем это требует, кроме того декрементации значения TTL (Time To Live). Так как поля TTL и контрольная сумма заголовка всегда модифицируются на пролете, AH знает, что эти поля следует исключить из зоны защиты, но это не касается IP адресов. Адреса включены в область вычисления ICV, и любая модификация вызовет сбой при проверке ICV получателем. Так как вычисление ICV требует знания секретного ключа, который неизвестен промежуточным узлам, маршрутизатор NAT не сможет заново вычислить ICV.

Аналогичная проблема возникает при использовании протокола PAT (Port Address Translation), который устанавливает соответствие нескольких частных IP адресов одному внешнему IP. В этом случае изменяются не только IP-адреса. Но и коды портов в UDP и TCP пакетах (а иногда и в поле данных). Это требует много большей адаптивности со стороны устройства NAT, и более серьезных модификаций всей IP дейтограммы. По этой причине, протокол AH в туннельном или транспортном режиме полностью несовместим с NAT. Заметим, что эта трудность не относится к ESP, так как аутентификация и шифрование в этом варианте не охватывает IP заголовок, модифицируемый NAT. Несмотря на это, NAT создает определенные проблемы и для ESP. Протокол NAT транслирует IP адреса “на пролете” -- но он должен отслеживать то, с каким соединением происходит работа, чтобы корректно связывать отклики с источником пакетов. При использовании TCP или UDP, это обычно делается с привлечением номеров порта, но IPsec не оставляет такой возможности. На первый взгляд можно предположить, что для решения проблемы можно использовать идентификатор SPI, но так как SPI отличаются для разных направлений обмена, для устройства NAT нет способа связать возвращаемый пакет с конкретным соединением. Протокол ESP является протоколом защиты, обеспечивающим конфиденциальность (т.е. шифрование), аутентификацию источника и целостность данных, а также (в качестве опции) сервис защиты от воспроизведения и ограниченную конфиденциальность трафика путем противодействия попыткам анализа потока данных.

Протокол ESP обеспечивает конфиденциальность с помощью шифрования на уровне пакетов IP. При этом поддерживается множество алгоритмов симметричной схемы шифрования, например DES, triple-DES, AES и Blowfish для шифрования поля данных. Алгоритм, используемый для конкретного соединения, специфицируется ассоциацией безопасности SA, SA включает в себя не только алгоритм, но и используемый ключ.

В отличие от протокола AH, который вводит небольшой заголовок перед полем данных, ESP “окружает” защищаемое поле данных. Поля индекс параметров безопасности (Security Parameters Index) и номер по порядку служат для тех же целей, что и в случае AH, но в ESP имеются также поля заполнителя, следующего заголовка, и опционно аутентификационных данных в конце, в хвостовике ESP. Формат ESP-пакета рассмотрен на рисунке 2.7

Рисунок 2.7 - Формат ESP-пакета без аутентификации

Возможно использование ESP без какого-либо шифрования (чтобы применить NULL алгоритм). Этот режим не обеспечивает конфиденциальности, и его имеет смысл использовать в сочетании с аутентификацией ESP. Неэффективно использовать ESP без шифрования или аутентификации (если только это не делается для тестирования протокола).

Помимо шифрования, ESP может опционально предоставлять возможность аутентификации, с привлечение алгоритма HMAC. В отличие от AH, однако, эта аутентификация производится только для ESP заголовка и зашифрованного поля данных. При этом не перекрывается весь IP пакет. Это не существенно ослабляет безопасность аутентификации, но дает некоторые важные преимущества.

Когда посторонний рассматривает IP пакет, содержащий данные ESP, принципиально невозможно определить IP адреса отправителя и получателя, нарушитель, конечно, узнает, что это ESP данные (это видно из заголовка пакета), но тип поля данных и сами данные зашифрованы.

Глядя на сам пакет, невозможно даже определить, присутствуют или нет аутентифицированные данные (это можно сделать лишь, используя индекс параметров безопасности).

Как и в случае AH, транспортный режим предполагает инкапсуляцию поля данных дейтограмм, и протокол ориентирован на обмен машина-машина. Исходный IP заголовок оставлен на месте (за исключением замененного поля протокол), и это означает, что адреса отправителя и получателя также остаются неизмененными [9].

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

Реализация шифрованного соединения в туннельном режиме очень близка к традиционным VPN.

В отличие от AH, где наблюдатель может легко сказать, происходил обмен в туннельном или транспортном режиме, здесь эта информация недоступна. Это происходит из-за того, что указание на то, что следующий заголовок является IP, находится в зашифрованном поле данных и, поэтому не виден для участника, неспособного дешифровать пакет [10].

IPSec опирается на ряд технологических решений и методов шифрования которое можно представить в виде следующих главных шагов:

Шаг 1. Начало процесса IPSec. Трафик, которому требуется шифрование в соответствии с политикой защиты IPSec, согласованной сторонами IPSec, начинает IКЕ-процесс.

Шаг 2. Первая фаза IKE. IKE-процесс выполняет аутентификацию сторон IPSec и ведет переговоры о параметрах ассоциаций защиты IKE, в результате чего создается защищенный канал для ведения переговоров о параметрах ассоциаций защиты IPSec в ходе второй фазы IKE.

Шаг 3. Вторая фаза IKE. IKE-процесс ведет переговоры о параметрах ассоциации защиты IPSec и устанавливает соответствующие ассоциации защиты IPSec для устройств сообщающихся сторон.

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

Шаг 5. Завершение работы туннеля IPSec. Ассоциации защиты IPSec завершают свою работу либо в результате их удаления, либо по причине превышения предельного времени их существования.

2.4 Построение защищенных сетей на сеансовом уровне

Сеансовый уровень является максимально высоким уровнем модели OSI, на котором возможно формирование защищенных виртуальных каналов. При построении защищенных виртуальных сетей на данном уровне достигаются наилучшие показатели по функциональной полноте защиты информационного обмена, надежности контроля доступа, а также простоте конфигурирования системы безопасности. Протоколы формирования защищенных виртуальных каналов на сеансовом уровне прозрачны для прикладных протоколов защиты, а также высокоуровневых протоколов предоставления различных сервисов (протоколов HTTP, FTP, POP3, SMTP, NNTP и др.). Однако на сеансовом уровне начинается непосредственная зависимость от приложений, реализующих высокоуровневые протоколы. Поэтому реализация протоколов защиты информационного обмена, соответствующих этому уровню, в большинстве случаев требует внесения изменений в высокоуровневые сетевые приложения.

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

- идентификация и аутентификация пользователей;

- криптозащита передаваемых данных;

- разграничение доступа к ресурсам внутренней сети; - разграничение доступа к ресурсам внешней сети;

- фильтрация и преобразование потока сообщений, например, динамический поиск вирусов и прозрачное шифрование информации;

- трансляция внутренних сетевых адресов для исходящих пакетов сообщений;

- регистрация событий и реагирование на задаваемые события;

- кэширование данных, запрашиваемых из внешней сети.

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

Для криптографической защиты информационного обмена на сеансовом Уровне наибольшую популярность получил протокол SSL/TLS (Secure Sockets Layer/ Transport Layer Security), разработанный компанией Netscape Communications.

Протокол SSL.

Протокол Secure Sockets Layer (SSL), изначально ориентированный на защиту информационного обмена между клиентом и сервером компьютерной сети, является промышленным протоколом сеансового уровня модели OSI использующим для обеспечения безопасности информационного обмена криптографические методы защиты информации. Конфиденциальность передаваемых данных обеспечивается за счет их криптографического закрытия, а аутентификация взаимодействующих сторон, а также подлинность и целостность циркулирующей информации -- за счет формирования и проверки цифровой подписи.

Ядром протокола SSL является технология комплексного использования асимметричных и симметричных криптосистем. В качестве алгоритмов асимметричного шифрования используются такие алгоритмы, как RSA (разработки RSA Data Security Inc.), а также алгоритм Диффи-Хеллмана. Для вычисления хэш-функций могут применяться стандарты MD5 и SHA-1. Допустимыми алгоритмами симметричного шифрования являются RC2, RC4, DES, а также тройной DES. В протоколе SSL третьей версии набор криптографических алгоритмов является расширяемым. Для аутентификации взаимодействующих сторон и криптозащиты ключа симметричного шифрования применяются цифровые сертификаты открытых ключей пользователей (клиента и сервера), заверенные цифровой подписью специальных Сертификационных Центров. Поддерживаются цифровые сертификаты, соответствующие общепринятому стандарту Х.509 [11].

Протокол SSL разработан корпорацией Netscape, а затем поддержан рядом ведущих производителей программного обеспечения. Из-за своих положительных качеств SSL практически вытеснил конкурирующие высокоуровневые протоколы по защите информационного обмена, например, такие как SHTTP (Secure HTTP), и стал общепризнанным неофициальным стандартом защиты в 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 криптозащищенные туннели создаются между конечными точками виртуальной сети (рисунок 2.8). Инициаторами какого защищенного туннеля являются клиент и сервер, функционирующие на компьютерах в конечных точках туннеля. Протокол SSL предусматривает два этапа взаимодействия клиента и сервера при формировании и поддержке защищаемого соединения:

- установление SSL-сессии;

- защищенное взаимодействие.

Рисунок 2.8 Криптозащищенный туннель на базе протокола 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_CL и полученную от него случайную последовательность 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, уникальной для данной сессии; формирует код для проверки целостности сообщения (MAC), шифрует сообщение по общему сеансовому секретному ключу и отправляет серверу;

- сервер, в свою очередь, формирует сообщение из собственных посылок в адрес клиента на шаге 2, посылок, полученных от клиента на шаге 1, и последовательности MasterSecret; формирует код для проверки целостности сообщения (MAC), шифрует сообщение на общем сеансовом секретном ключе и отправляет клиенту;

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

В процессе защищенного взаимодействия с установленными криптографическими параметрами SSL-сессии выполняются следующие действия:

- каждая сторона при передаче сообщения формирует МАС-код для последующей проверки целостности сообщения и затем зашифровывает исходное сообщение вместе с МАС-кодом по сеансовому секретному ключу;

- каждая сторона при приеме сообщения расшифровывает его и проверяет на целостность (вычисляется текущий МАС-код и сверяется с МАС-кодом проверки целостности, полученным вместе с сообщением); в случае обнаружения нарушения целостности сообщения, SSL-сессия закрывается.

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

Практически все существующие продукты, поддерживающие протокол SSL, реализованы в США и из-за экспортных ограничений доступны только в усеченном варианте (с длиной сеансового ключа 40 бит для алгоритмов симметричного шифрования и 512 бит для алгоритма RSA, используемого на этапе установления SSL-сессии), что на сегодняшний день явно недостаточно.

3. Построение VPN на основе Windows Server 2003

3.1 Настройка сервера VPN под Windows 2003 Server

Проанализировав все возможные варианты построения VPN сети мы сделав выводы пришли к тому что на сегодняшний день самый дешевый вариант для построения и настройки VPN сервера является операционная система Windows 2003 Server. Данная реализация удобна в конфигурации и настройке. Топология VPN сети изображена на рисунке 3.1.

Рисунок 3.1 - Предложенная топология сети VPN

После успешной установки Windows 2003 Server на компьютер нам нужно запустить службу Маршрутизация и удаленный доступ. Он настраивается как сервер удаленного доступа (RAS-сервер) в службе RRAS (Маршрутизация и удаленный доступ) которая показана на рисунке 3.2



Рисунок 3.2 - Настройка службы "Маршрутизация и удаленный доступ"

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

.

Рисунок 3.3 - Выбор конфигурации сервера

Далее выбираем пункт Удаленный доступ (VPN или модем) и нажимаем далее. В следующем окне ставим галочку напротив Доступ к виртуальной частной сети (VPN) тем самым разрешаем удалённые подключения к нашему серверу через интернет.

При выборе сервер VPN мастер запросит, какой протокол следует использовать для работы удаленных клиентов на этом сервере, мы выбираем TCP/IP. Мастер попросит нас указать устройство, через которое мы подключены к Интернету. Через это устройство к нашей частной виртуальной сети VPN, будут подключатся пользователи, следует отметить, что у этого устройства должен быть постоянный IP адрес.

Указав устройство, через которое мы подключены к Интернету, мастер попросит нас указать диапазон IP адресов, из этого диапазона IP адресов, которого мы укажем, будут раздаваться IP адреса входящим VPN соединениям, мы укажем такие IP адреса начальный 192.168.0.1 и конечный 192.168.0.40. Теперь, когда мы указали IP адреса можно нажать кнопку Далее. Настройка сервера VPN практически завершена, осталось только создать учетную запись пользователя, под которой пользователи будут заходить в сеть, что мы сейчас с вами и сделаем.

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

Чтобы создать нового пользователя, нужно щелкнуть правой кнопкой мыши; затем в раскрывшемся контекстном меню выбрать элемент Новый пользователь. В появившемся окне достаточно ввести имя пользователя и пароль, еще нужно поставить галочку запретить смену пароля пользователем, чтобы пользователи не смогли поменять пароль. У пользователя будет имя Dovbnya, а пароль будет testdasdsa111.

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

Один и тот же пользователь может быть членом любого количества групп пользователей. На закладке Входящие звонки нужно настроить параметры удаленного доступа для нашей учетной записи. В пункте Разрешение на удалённый доступ(VPN или модем)) нужно выбрать Разрешить доступ.

На этом настройка сервера VPN завершена, и любой, кто знает наш IP адрес, логин и пароль сможет зайти в нашу сеть из любого конца мира через Интернет.

Рисунок 4.4 - Добавление нового пользователя.

3.2 Настройка клиентской части VPN под Windows 2003 Server

Настройка клиентской части VPN таким следующим образом. Для того чтобы приступить к настройке нам нужно зайти в систему с учётной записью Администратора. Нажимаем Пуск, далее выполнить и вводим Ncpa.cpl, тем самым вызвав окно сетевых подключений.