И целостности данных с использованием VPN.

Виртуальная частная сеть VPN — это технология сетевого доступа, позволя­ющая на основе телекоммуникационной инфраструктуры общего пользования, например, Интернетом, сформировать защищенные каналы обмена информаци­ей между отдельными сетями и/или пользователями. Поскольку беспроводные сети IEEE 802.11 легко доступны для случайного или злонамеренного прослуши­вания, то именно в них развертывание и обслуживание VPN приобретает особую важность, если необходимо обеспечить высокий уровень защиты информации. Стандарт IEEE 802.11i снизил необходимость развертывания VPN, но она пол­ностью не отпадает в сетях, где безопасность информации играет решающую роль. Кроме того, в реализациях стандарта IEEE 802.11i обнаружилось немало проблем с безопасностью. Можно утверждать, что с течением времени будут разработаны новые атаки против этого стандарта. Да и для обеспечения безо­пасности особо секретных данных нельзя полагаться на какой-то один механизм или на защиту лишь одного уровня сети. В случае двухточечных каналов про­ще и экономичнее развернуть VPN, покрывающую две сети, чем реализовывать защиту на базе стандарта IEEE 802.11i, включающую RADIUS-сервер и базу данных о пользователях.

В названии VPN слово «виртуальный» подразумевает мирное сосуществова­ние в одном сегменте сети двух различных сетей, не создающих помех друг другу, будь то сети IP, IPX и DDP в одной локальной сети или трафик IP, IPSec и L2TP в Интернете. Слово «частная» означает признание того факта, что весь обмен данными и вообще наличие какой-то сети понятны лишь концевым точ­кам канала и никому больше. Это равным образом относится к секретности и аутентичности передаваемых данных.

VPN строится на двух механизмах — туннелировании и шифровании.

Суть туннелирования — исходные передаваемые пакеты вставляются (инкапсулиру­ются) в пакеты транспортной сети, через которую реализуется передача. При этом форматы исходных пакетов не имеют никакого значения, что допускает передачу через, например, IP-сеть любой не-IP информации. Разумеется, воз­можен и вариант передачи IP-B-IP. В этом случае каждая дейтаграмма «как есть» вставляется в другую дейтаграмму в начале туннеля и передается по сети. В узле-получаетеле (конец туннеля), определяемом заголовком внешней дейта­граммы, происходит выделение (декапсуляция) внутренней дейтаграммы и ее обработка в соответствии с ее заголовком. Дополнительно, инкапсулируемый пакет может шифроваться любым способом, причем не только поле данных, но и служебные заголовки. Возможно использование методов аутентификации (т. е. получатель должен удостовериться в легитимности источника пакета перед его обработкой). Для каждого из этих механизмов существуют свои протоколы, широко используемые в современных сетях. Но для отправителя исходных па­кетов и их конечного получателя все эти механизмы скрыты, а среда передачи выглядит абсолютно прозрачной, как будто они находятся в одной локальной сети.

Распространено представление о том, что VPN обязательно должна шифро­вать все проходящие через нее данные, но в общем случае это не так.

VPN отве­чает трем условиям:

ü конфиденциальность,

ü целостность

ü доступность.

Следует отметить, что никакая VPN не является устойчивой к DoS- или DDoS-атакам (Отказ в обслуживании или Распределенный отказ в обслуживании). Также VPN не защищает от несанкционированного доступа на физическом уровне просто в силу своей виртуальной природы и зависимости от нижележащих протоколов.

Основное достоинство связи через VPN — это сокращение расходов на по­строение каналов связи между удаленными точками. На данный момент аль­тернативой VPN служат выделенные линии или внедрение сервера удаленного доступа. Выделенные линии обычно организуются для критически важных при­ложений, которым требуется гарантированная пропускная способность, тогда как передача данных по сетям общего пользования представляется ненадеж­ной, а их доступность в любой момент времени не может быть гарантирована. Создание беспроводного двухточечного канала — это еще одна недорогая аль­тернатива, но в свете атак, рассмотренных выше, такое решение нельзя считать достаточно безопасным. Традиционные для сетей IEEE 802.Ha/b/g механизмы аутентификации и шифрования сами по себе не в состоянии обеспечить не­обходимый уровень защиты от опытного взломщика. Но если развертывание протокола IEEE 802.IX и RADIUS-сервера слишком дорого для двухточечных беспроводных мостов, то большинство имеющихся на рынке сетевых устройств могут поддержать VPN, обеспечивающую примерно такой же уровень защиты.

Топология VPN может быть самой разной, но основные — это «сеть-сеть» и «хост-сеть» . Топология «сеть-сеть», очевидно, связывает две удаленные ло­кальные сети (рис. 3.1).

Рис.3.1. VPN между разнесенными сетями.

Топология хост-сеть Топология «хост-сеть» означает, что сначала клиент устанавливает соедине­ние с сетью общего пользования (с Интернетом), а через нее — с VPN-шлюзом нужной его сети (например, сети своей организации) (рис. 3.2). После успешной аутентификации создается туннель поверх сети общего пользования.

Рис.3.2 Топология VPN “хост-сеть”

Топология типа «звезда» — самая распространенная для VPN. Централь­ный VPN-концентратор организует туннели со всеми удаленными клиентами (рис.3.3). Масштабируемость и общая производительность такой сети ограни­чена пропускной способностью и вычислительной мощностью VPN-концентра­тора. Последнее особенно актуально, поскольку сначала нужно расшифровать принятые данные, а затем снова зашифровать перед отправкой. Но в сети «звезда» проще выполнять конфигурирование, обслуживание, контроль досту­па и учет. Но при выходе концентратора из строя перестанет работать вся сеть. Звездная топология применима в сетях с каналами «точка-многоточка», но она менее безопасна, чем топология «хост-сеть» поскольку позволяет беспроводным хостам взаимодействовать между собой (через концентратор).

Полносвязная топология предполагает, что каждый узел напрямую соеди­нен туннелем с любым другим узлом сети. При этом образуется «переплетение» соединений (рис. 3.4). Хотя недостатки топологии «звезда» и устраняются, но существенно увеличиваются временные затраты на обслуживание сети и ста­новится трудно добавлять новые узлы. Заметим еще, что оконечные клиенты должны быть достаточно мощными компьютерами, поскольку им приходится поддерживать более одного туннеля.

Рис.3.3 Топология “Звезда”

Рис.3.4 Полносвязная топология.

 

Распространенные туннельные протоколы и VPN.

Протокол IPsec.

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

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

Протокол РРТР.

Двухточечный туннельный протокол (Point-to-Point Tunneling Protocol — РРТР) — это технология компании Microsoft. Он в основном используется для создания безопасных каналов в Интернете для машин под упроавлением ОС Windows. РРТР обеспечивает аутентификацию пользователей с помощью таких протоко­лов, как MS-CHAP, CHAP, SPAP и РАР. Этот протокол недостаточно гибок и мало приспособлен для совместной работы с другими протоколами VPN, но прост и широко распространен во всем мире. Протокол определяет следующие типы коммуникаций:

o РРТР-соединение, по которому клиент организует РРР-канал с провайде­ром;

o управляющее РРТР-соединение, которое клиент организует с VPN-серве­ром и по которому согласует характеристики туннеля;

o РРТР-туннель, по которому клиент и сервер обмениваются зашифрован­ными данными.

Этот протокол имеет известные уязвимости и использует относительно сла­бые шифры MD4 и DES.

Протокол GRE

Протокол Generic Routing Encapsulation (GRE) разработан компанией Cisco и применяется для туннелирования трафика между различными частными се­тями, включая не-IP трафик, который нельзя пропустить по сети в неизменном виде. Несмотря на то, что протокол не осуществляет шифрования, он позволя­ет эффективно организовать туннель с низкими накладными расходами. GRE часто применяется в сочетании с протоколами шифрования на сетевом уровне, в результате чего решаются две задачи: инкапсуляция не-IP трафика, реализу­емая GRE, и шифрование, выполняемое другим протоколом, например, IPSec.

 

Протокол L2TP.

Этот протокол (RFC 2661), совместно разработанный компаниями Cisco, Mi­crosoft и 3Com, обещает заменить РРТР в качестве основного туннельного протокола. По существу, L2TP представляет собой комбинацию РРТР и создан­ного Cisco протокола Layer Two Forwarding (L2F). Протокол L2TP применяется для туннелирования РРР-трафика поверх IP-сети. Для установления соединения по коммутируемой линии в нем используется РРР с аутентификацией по прото­колу РАР или CHAP. Но в отличие от РРТР, L2TP определяет свой собственный туннельный протокол. Поскольку L2TP работает на уровне 2, то через туннель можно пропускать и не-IP трафик. L2TP совместим с любым канальным прото­колом, например ATM, Frame Relay или IEEE 802.11. Сам по себе протокол не содержит средств шифрования, но может быть использован в сочетании с дру­гими протоколами или механизмами шифрования на прикладном уровне.

Помимо стандартных протоколов VPN существуют и специализированные варианты. Рассмотрим некоторые из них.

Протокол cIPe.

Разработчики утверждают, что cIPe обеспечивает почти такой же уровень безопасности, как IPSec. Протокол работает на уровне IP и позволяет туннелировать протоколы более высоких уровней (например, ICMP, TCP, UDP). Принцип работы напоминает РРР, но cIPe инкапсулирует передаваемые IP-па­кеты в UDP-дейтаграммы. При разработке cIPe была поставлена цель создать облегченный протокол, в котором для шифрования данных применяются доста­точно стойкие криптографические алгоритмы Blowfish и IDEA, но при этом простой для установки и обслуживания и в то же время несколько более про­изводительный, чем IPSec. В cIPe используется единственный UDP-порт для организации туннеля, трафик без труда проходит через механизм преобразо­вания сетевых адресов NAT (network address translation) и межсетевой экран с запоминанием состояния. Существуют бесплатные реализации cIPe как для UNIX, так и для Windows. К сожалению, были выявлены многочисленные не­достатки, допущенные при проектировании cIPe, которые, вероятно, не будут исправлены до выхода следующей версии протокола.

 

Пакет OpenVPN.

Open VPN — это еще одно открытое решение, по своей функциональности ана­логичное cIPe. Пакет легко инсталлируется и конфигурируется. Он работает на большинстве UNIX-подобных систем, в которых есть драйверы виртуальной се­ти TUN/TAP. OpenVPN имеет модульную структуру. Все криптографические функции реализованы посредством библиотеки OpenSSL, в том числе и самые современные шифры, к примеру, AES с 256-битным ключом. Следовательно, про­токол в полной мере поддерживает реализованные в OpenSSL механизм PKI для аутентификации сеансов, протокол TLS для обмена ключами, не зависящий от шифра интерфейс EVP для шифрования данных и коды НМАС для аутенти­фикации данных. Как и в случае cIPe, использование единственного UDP-порта для инкапсуляции туннеля позволяет без труда пропускать трафик через NAT и межсетевые экраны с запоминанием состояния.

Пакет VTun.

VTun — это решение, которое использует драйвер виртуальной сети TUN/TAP для туннелирования IP-трафика. Протокол поддерживает все распространенные протоколы уровня 3, в том числе IPX и AppleTalk, протоколы для работы по последовательным линиям связи РРР и SLIP, а также все программы, работа­ющие с конвейерами UNIX. Встроенный механизм контроля трафика позволяет ограничивать входную и выходную скорость работы туннеля, что отличает это решение от всех остальных. С точки зрения конфиденциальности, VTun не пре­тендует на звание самого безопасного протокола, основные усилия при разработ­ке были направлены на быстродействие, стабильность и удобство эксплуатации. Тем не менее, используется алгоритм шифрования Blowfish с 128-битным клю­чом для шифрования данных и MD5 для генерирования 128-разрядных сверток. Версии для Windows не существует, применение ограничено UNIX-подобными ОС, которые поддерживают драйвер TUN/TAP.

Протокол IPSec.

Протокол IPSec — это набор открытых стандартов, разрабатываемых под эги­дой IETF. Набор протоколов IPSec состоит из трех основных частей, которые определяют два режима его работы (АН и ESP):

1. АН (Authentication Header — заголовок аутентификации) обеспечивает аутентификацию источника данных, целостность и защиту от воспроиз­ведения;

2. ESP (Encapsulating Security Payload — инкапсуляция зашифрованных дан­ных, обеспечивает аутентификацию источника данных, целостность, за­щиту от воспроизведения, конфиденциальность данных и до некоторой степени скрытность управления потоком;

3. IKE (Internet Key Exchange — схема обмена ключами через Интернет) предоставляет средства согласования криптографического алгоритма и от­вечает за распределение ключей, используемых в АН и ESP.

В режиме аутентификации к стандартной дейтаграмме IP добавляется спе­циальный заголовок аутентификации АН (рис. 3.5) . Поле «следующий заго­ловок» определяет тип данных после НА. Параметр безопасности SCI определяет тип профиля безопасности для данного пакета. Порядковый номер пакета слу­жит для предотвращения атак повторением. В поле данных аутентификации содержится информация в соответствии с выбранной схемой обеспечения бе­зопасности. Для проверки аутентичности вычисляется свертка в соответствии с механизмом НМАС (с MD5 или SHA-1).

Режим инкапсуляции зашифрованных данных ESP намного сложнее ре­жима НА. Этот механизм обеспечивает не только аутентификацию, но и целостность и конфиденциальность передаваемых пакетов. Помимо собственно шифрования данных, к исходной дейтаграмме добавляются поля «Заголовок ESP» и «Трейлер ESP» (рис. 3.6).

Рис.3.5 Формат пакета с заголовком аутентификации НА, протокол IPSec.

 

Оба режима — АН и ESP — полагаются на механизм согласования сторонами параметров безопасного соединения (профиля безопасности — security associa­tion, SA) по алгоритму IKE. В SA хранятся параметры, о которых договорились оба участника обмена по сети VPN. К ним относятся криптографические ключи и время их жизни, используемые криптографические алгоритмы и режим рабо­ты IPSec.

Рис.3.6 Формат пакета с инкапсулированными данными ESP,протокол IPSec

Для каждого режима работы нужно два SA: для входящего и исходящего трафиков. Эти два набора параметров, описывающих данные, отправляемые и получаемые хостом, называются парой SA (SA bundle). В каждом SA явно ука­зывается протокол АН или ESP, IP-адрес получателя для исходящего соединения или IP-адрес отправителя для входящего соединения и 32-разрядный уникальный идентификатор SPI. Еще одна важная характеристика SA — время жизни. Этот параметр определяет интервал времени, по истечении которого следует прове­сти повторное согласование или считать SA недействительным. Время жизни задается либо как число обработанных байтов, либо как временной интервал; по достижении любого из этих порогов начинается повторное согласование SA. Существует два значения порога времени жизни SA: жесткий и мягкий. В слу­чае если достигнут мягкий порог, то SA согласуется заново, по достижении же жесткого порога SA удаляется из памяти хоста.

Каждый хост-участник хранит SA в базе данных параметров безопасности (SA Database — SAD). Для работы IPSec необходима база данных политик безопасности (Security Policy Database — SPD), в которой хранятся сведения о политиках, применяемых к трафику. SPD содержит набор правил, которые, в свою очередь, состоят из селекторов, несущих информацию о типах выпол­няемых действий. Когда приходит пакет, по базе данных SPD определяется дальнейшее действие над ним: отбросить, пропустить дальше или передать для обработки протоколу IPSec. В отличие от SPD, база данных SAD хранит только необходимые параметры соединения.

 

Чтобы определить необходимые действия над пакетом, из его заголовка из­влекаются три поля, которые сопоставляются с информацией, хранящейся в SAD (протокол IPSec, IP-адрес и SPI). Если соответствие найдено, то далее параме­тры сравниваются с полями АН или ESP. Если соответствие не найдено, пакет отбрасывается.

Традиционно в IPSec использовался шифр DES или 3DES. Шифр DES счита­ется слабым и может быть вскрыт за несколько дней или даже часов, поэтому его использование не рекомендуется. Шифр 3DES гораздо более стоек, но требует большого объема вычислений и медленно работает на маломощных устройствах, таких как точки доступа и карманные компьютеры. Возможны и другие шифры, например Rijndael.

Добавление новых заголовков к IP-пакету после инкапсуляции ведет к уве­личению размера пакета, т. е. к накладным расходам на организацию туннеля. В случае протокола ESP пакет может вырасти на 300 байт, что негативно сказывается на производительности. В протоколе IPSec предпринята попыт­ка решения этой проблемы посредством встроенного протокола сжатия IP-па­кетов (IPComp), в котором обычно применяются алгоритмы DEFLATE или LZS.DEFLATE. Сжатие выполняется до модификации в соответствии с IPSec и до фрагментации. Обычно сжатие случайных или уже сжатых данных неэф­фективно, более того, иногда применение избыточного сжатия приводит даже к увеличению размера IP-пакета. Применение протокола IPComp должно быть согласовано обеими сторонами с помощью механизма IKE. Следует отметить, что IPComp достаточно гибок, он позволяет выборочно применять сжатие толь­ко к конкретному протоколу транспортного уровня или лишь на одном конце соединения.

Протокол обмена и управления ключами в IPSec (IPSec Key Exchange and Management Protocol — ISAKMP)  входит в набор протоколов IPSec и опре­деляет процедуры согласования, создания, модификации и удаления SA, а также форматы соответствующих пакетов. Он спроектирован так, чтобы не зави­сеть ни от какого конкретного метода обмена ключами или генерации ключей, криптографического алгоритма или механизма аутентификации. ISAKMP опи­сывает лишь общий каркас в довольно абстрактных терминах.

Internet Key Exchange (IKE) — это протокол общего назначения для обмена информацией, относящейся к безопасности. Он предоставляет вспомогательный сервис для аутентификации узлов в протоколе IPSec, согласования параметров безопасности (SA) и ключей алгоритмов шифрования.

В IPSec есть внутренний механизм, который позволяет посылать по прото­колу IKE сообщение с извещением об удалении, когда одна из сторон уничтожа­ет SA. К сожалению, хост обычно не посылает такое извещение, например, из-за неожиданной остановки по причине сбоя электропитания или в беспроводных сетях — из-за выхода из зоны покрытия. Для решения этой проблемы преду­смотрен механизм обнаружения неработающего хоста (Dead Peer Discovery — DPD). Идея в том, что сообщение с извещением посылается раньше данных, ес­ли период неактивности продлился дольше заранее установленного порогового значения. Работающий хост на поступившее извещение должен ответить своим собственным.

Отметим, что в беспроводных сетях вероятна ситуация, когда клиент соеди­няется по беспроводному каналу и получает новый IP-адрес от DHCP-сервера, который изменяется время от времени. Поскольку один из IP-адресов дина­мический, его нельзя использовать для идентификации данной стороны. Для аутентификации таких хостов необходимо применять другие методы, например сертификаты Х.509.