В 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 Построение защищенных сетей на сеансовом уровне