А. Н. Андрончик, В. В. Богданов, Н. А. Домуховский, А. С. Коллеров, Н. И. Синадский, Д. А. Хорьков
 Скачать 9.2 Mb.
|
|
5.2. Туннелирование в VPN Как указывалось выше, основная задача, решаемая VPN, — скрыть пе- редаваемый трафик. При этом необходимо скрыть как передаваемые данные, так и адреса реальных отправителя и получателя пакетов. И кроме того, необ- ходимо обеспечить целостность и подлинность передаваемых данных. Для защиты передаваемых данных и реальных IP-адресов применяются крипто- графические алгоритмы. При отправке пакетов применяется туннелирование, т. е. в пакетах, которые идут в открытой сети, в качестве адресов фигурируют только адреса «черных ящиков». Кроме того, туннелирование предполагает, что внутри локальных сетей трафик передается в открытом виде, а его защита осуществляется только тогда, когда он попадает в «туннель». Итак, пусть у нас имеется пакет, содержащий данные и IP-заголовок, ко- торые подлежат защите (рис. 5.2). Для защиты применим криптографические методы и зашифруем и данные, и заголовок вместе. Так как необходимо обес- печить скорость обработки информации, то для зашифрования, естественно, будем использовать симметричный алгоритм. Известно, что применение симметричных алгоритмов шифрования тре- бует решения задачи распространения симметричных ключей. Поэтому по- ступим следующим образом: прикрепим симметричный ключ прямо к зашиф- рованным с его использованием данным. Назовем симметричный ключ пакет- ным ключом (его еще называют сеансовым ключом). Этот пакетный ключ бу- дем генерировать случайным образом при отправлении каждого нового пакета (тогда он действительно «пакетный» ключ). Либо будем его генерировать также случайно при каждом сеансе обмена. Тогда данные всех пакетов, пере- даваемых в данном сеансе связи, будут шифроваться одним и тем же ключом, и это уже «сеансовый» ключ. Конечно, нельзя отправлять пакетный ключ в открытом виде, прикреп- ляя его к зашифрованным им данным. Следует его зашифровать. Воспользу- емся тем, что ключ, в отличие от данных, — это лишь пара сотен бит (в зави- симости от реализации, например, 256 бит — длина ключа алгоритма ГОСТ 28147-89, 56 бит — длина ключа алгоритма DES). Таким образом, можем применить более медленные асимметричные алгоритмы и зашифровать с их помощью пакетный ключ. Вместе с тем, для шифрования пакетного ключа может быть применен и симметричный алгоритм. Ключ алгоритма шифрова- ния пакетного ключа назовем ключом связи. 97 Данные IP-заголовок Шифруются на пакетном ключе и подписываются ЭЦП Данные IP-заголовок Пакетный ключ ЭЦП пакета Пакетный ключ шифруется на ключе связи, формируется новый IP-пакет (IP-адреса устройств защиты) Данные IP-заголовок Пакетный ключ ЭЦП пакета IP-заголовок Аутентифицирующий заголовок Рис. 5.2. Преобразование отправляемого пакета Кроме того, для обеспечения целостности пакетов сгенерируем элек- тронно-цифровую подпись (ЭЦП) нашего пакета и прикрепим ее к формируе- мому пакету. Совокупность ЭЦП и зашифрованного пакетного ключа называют ау- тентифицирующим заголовком. Для того чтобы отправить сгенерированный нами пакет, необходимо добавить к нему IP-адреса источника и приемника. В случае туннеля этими адресами будут адреса пограничных VPN-узлов. Если же защищается трафик между двумя узлами без применения туннеля, то эти адреса совпадут с адре- сами в исходном пакете. Таким образом, исходный пакет защищен. Осталось выяснить ряд мо- ментов. Во-первых, каким образом будет осуществлен обмен ключом связи и, во-вторых, что будем понимать под шифруемыми данными: только лишь дан- ные прикладного уровня либо относящиеся к транспортному или сетевому уровню. Чтобы ответить на второй вопрос, рассмотрим уровни защищенных ка- налов. 5.3. Уровни защищенных каналов Итак, необходимо разобраться, данные какого уровня модели OSI под- лежат шифрованию в процессе организации VPN. Рассмотрим упрощенную модель OSI, реализованную в стеке протоко- лов TCP/IP. Эта модель предполагает наличие четырех уровней: прикладного, транспортного, сетевого и канального. Соответственно, для каждого уровня возможность шифрования передаваемой информации различна. Так, на при- 98 кладном уровне можно скрыть данные, например, электронного письма или получаемой web-страницы. Однако факт передачи письма, т. е. диалог по про- токолу SMTP скрыть невозможно. На транспортном уровне может быть вме- сте с данными скрыт и тип передаваемой информации, однако IP-адреса полу- чателя и приемника остаются открытыми. На сетевом уровне уже появляется возможность скрыть и IP-адреса. Эта же возможность имеется и на канальном уровне. Чем ниже уровень, тем легче сделать систему, функционирование кото- рой будет незаметно для приложений высокого уровня, и тем большую часть передаваемой информации можно скрыть. Для каждого уровня модели разработаны свои протоколы (табл. 5.1). Таблица 5.1 Уровни защищенных каналов и протоколы Уровень Протоколы Прикладной S/MIME / PGP / SHTTP Транспортный (TCP/UDP) SSL / TLS / SOCKS Сетевой (IP) IPSec / SKIP Канальный PPTP / L2F / L2TP Так, на прикладном уровне для защиты электронной почты применяется протокол S/MIME (Secure Multipurpose Internet Mail Extension) либо система PGP. Для защиты обмена по протоколу HTTP применяется протокол SHTTP (Secure HTTP). На данном уровне шифруется текст передаваемого почтового сообщения или содержимое HTML-документа. Недостатками организации VPN на базе протоколов прикладного уровня является узкая область действия, для каждой сетевой службы должна быть своя система, способная интегриро- ваться в соответствующие приложения. В пособии мы не будем подробно рас- сматривать системы этого уровня. На транспортном уровне чаще всего применяются протоколы SSL (Se- cure Socket Layer) и его более новая реализация — TSL (Transport Layer Secu- rity). Также применяется протокол SOCKS. Особенность протоколов транс- портного уровня — независимость от прикладного уровня, хотя чаще всего шифрование осуществляется для передачи по протоколу HTTP (режим HTTPS). Недостатком является невозможность шифрования IP-адресов и тун- нелирования IP-пакетов. На сетевом уровне используются два основных протокола: SKIP (Simple Key management for Internet Protocol – простое управление ключами для IP- протокола) и IPSec. На данном уровне возможно как шифрование всего тра- фика, так и туннелирование, включающее скрытие IP-адресов. На сетевом уровне строятся самые распространенные VPN системы. 99 Канальный уровень представлен протоколами PPTP (Point-to-Point Tun- neling Protocol), L2F (Layer-2 Forwarding) и L2TP (Layer-2 Tunneling Protocol). Достоинством данного уровня является прозрачность не только для приложе- ний прикладного уровня, но и для служб сетевого и транспортного уровня. В частности, достоинством является независимость от применяемых протоколов сетевого и транспортного уровня — это может быть не только IP-протокол, но и протоколы IPX (применяется в локальных сетях с серверами на основе ОС Novell Netware) и NetBEUI (применяется в локальных сетях Microsoft). Шиф- рованию подлежат как передаваемые данные, так и IP-адреса. В каждом из указанных протоколов по-разному реализованы алгоритмы аутентификации и обмена ключами шифрования. 5.4. Защита данных на канальном уровне На канальном уровне применяются упомянутые выше протоколы PPTP (разработчик Microsoft), L2F (разработчик Cisco Systems) и L2TP (совместная разработка Microsoft и Cisco Systems). Протоколы PPTP и L2TP основываются на протоколе Point-to-Point Protocol (PPP). PPP — протокол канального уровня, разработан для инкапсу- ляции данных и их доставки по соединениям типа точка-точка. В основе протокола PPTP лежит следующий алгоритм: сначала произ- водится инкапсуляция данных с помощью протокола PPP, затем протокол PPTP выполняет шифрование данных и инкапсуляцию. PPTP инкапсулирует PPP-кадр в пакет Generic Routing Encapsulation (протокол GRE). Схема инкап- суляции приведена на рис. 5.3. IP заголовок GRE заголовок PPP заголовок IP заголовок TCP, UDP Данные Рис. 5.3. Инкапсуляция в протоколе PPTP К исходному отправляемому IP-пакету (обозначенному на рисунке се- рым цветом) последовательно добавляются PPP-, GRE- и IP-заголовки. В но- вом IP-пакете в качестве адресов указываются адреса туннелирующих узлов. Протокол PPTP очень часто используется провайдерами Интернет при организации прямого кабельного подключения пользователей. В этом случае пользователям назначается IP-адрес из диапазона «домашних» сетей (напри- мер, 10.1.1.189 или 192.168.1.1). Сервер провайдера имеет два адреса — внут- ренний (для «домашней» сети) и внешний («настоящий»). Когда пользователь авторизуется на PPTP-сервере провайдера, ему динамически выделяется ре- альный IP-адрес. Внутри локальной сети между пользователем и PPTP-сервером цирку- лируют IP-пакеты с внутренними IP-адресами, внутри которых инкапсулиро- ваны пакеты с внешними адресами. 100 Source IP 195.12.90.175 Dest IP 194.226.237.16 Source Port 1134 Dest Port 110 Source IP 195.12.90.175 Dest IP 194.226.237.16 Source Port 1134 Dest Port 110 Рис. 5.4. Пакет протокола PPTP На рис. 5.4 приведен пример обмена по протоколу POP3 (порт приемни- ка 110), осуществляемого между удаленным POP3-сервером с адресом 194.226.237.16 и пользователем, которому назначен динамический адрес 195.12.90.175. В локальной сети видны пакеты протокола IP/GRE, проходящие между узлами 10.1.1.189 (внутренний адрес пользователя) и 10.1.0.2 (внутрен- ний адрес PPTP-сервера). Обычно провайдеры не включают возможность шифрования и сжатия инкапсулируемых пакетов, поэтому при анализе трафика в локальной сети со- держимое IP/GRE-пакетов легко распознать и увидеть адреса, протокол и пе- редаваемые данные. Для шифрования передаваемых данных с использованием клиентов с ОС Windows XP необходимо в настройках подключения указать пункт «Re- quire Data Encryption» («Требовать шифрование данных», рис. 5.5). В протоколе PPTP для аутентификации предусматриваются различные протоколы аутентификации: − Extensible Authentication Protocol (EAP), − Microsoft Challenge Handshake Authentication Protocol (MSCHAP), − Challenge Handshake Authentication Protocol (CHAP), − Shiva Password Authentication Protocol (SPAP) − Password Authentication Protocol (PAP) 101 Рис. 5.5. Настройка клиента протокола PPTP Наиболее стойким является протокол MSCHAP версии 2, требующий взаимную аутентификацию клиента и сервера. В протоколе MSCHAP могут быть использованы три различных варианта передачи пароля: − клиент передает серверу пароль в открытом текстовом виде; − клиент передает серверу хэш пароля; − аутентификация сервера и клиента с использованием вызова и ответа. Последний вариант наиболее защищенный, алгоритм его состоит в сле- дующем (рис. 5.6). − Клиент запрашивает вызов сетевого имени. − Сервер возвращает 8-байтовый случайный вызов (например, «01234567», рис. 5.7). − Клиент вычисляет хэш-функцию пароля алгоритмом «Lan Manager» (на- пример, «С2 34 1A 8A A1 E7 66 5F AA D3 B4 35 B5 14 04 EE»), добавляет пять нулей для создания 21-байтовой строки и делит строку на три 7-байтовых ключа. Каждый ключ используется для шифрования вызова с использованием алгоритма DES, что приводит к появлению 24-байтного шифрованного значе- ния (например, «AA AA AA AA AA AA AA AA BB BB BB BB BB BB BB BB CC CC CC CC CC CC CC CC»). Клиент выполняет то же самое с хэш- функцией пароля, получаемой алгоритмом хэширования, реализованном в ОС 102 семейства Windows NT. В результате формируется 48-байтное значение, кото- рое возвращается серверу как ответ. − Сервер ищет значение хэш-функции в своей базе данных, шифрует за- прос с помощью хэш-функции и сравнивает его с полученными шифрован- ными значениями. Если они совпадают, аутентификация заканчивается. Вызов Сервер, база паролей DES ? Хэш- пароль Ответ Ответ Ответ Вызов DES Клиент Хэш- пароль Рис. 5.6. Аутентификация в протоколе MSCHAP Клиент 8 байт «вызов» 0001020304050607 16 байт hash 5 нулей 21 байт + = C2341A8AA1E7665F AAD3B435B51404EE 0000000000 7 байт C2341A8AA1E766 5FAAD3B435B514 04EE0000000000 7 байт DES Key Шифруем «вызов» AAAAAAAAAAAAAAАА BBBBBBBBBBBBBBBB CCCCCCCCCCCCCCCC «Ответ» Сервер Клиент 8 байт «вызов» 0001020304050607 C2341A8AA1E7665F AAD3B435B51404EE «Ответ» Шифруем «вызов» Шифруем «вызов» 7 байт DES Key 7 байт DES Key 7 байт 7 байт Рис. 5.7. Схема формирования «ответа» в протоколе MSCHAP Для шифрования передаваемых данных применяется поточный шифр RC4 с 40- либо 128-разрядным ключом. Алгоритм предполагает существова- 103 ние секретного ключа, известного обоим участникам соединения. Данный ключ формируется из хэш-функции «Lan Manager» пароля пользователя, из- вестного и клиенту, и серверу. 5.5. Организация VPN средствами протокола PPTP 5.5.1. Постановка задачи Предлагается организовать соединение по протоколу PPTP между двумя сетевыми узлами. При этом имитируется соединение, которое пользователь Интернет устанавливает с сервером провайдера в том случае, когда использу- ется подключение по выделенному каналу на основе Ethernet. В результате подключения пользователю выделяется IP-адрес, который может быть извес- тен пользователю заранее либо выделяться динамически. Динамическое вы- деление адресов позволяет затруднить идентификацию узла пользователя из Интернет, сделав его в какой-то степени анонимным. Кроме того, это дает возможность провайдеру более эффективно использовать выделенное ему ад- ресное пространство. Для имитации предполагается использовать два рабочих места. Первое рабочее место (рис. 5.8) имитирует PPTP-сервер Интернет-провайдера, этим сервером является компьютер под управлением ОС Windows 2000/XP. На этом же рабочем месте имитируется пользовательский компьютер, который выполняется в виде виртуальной машины VMWare с установленной Windows 2000. Рис. 5.8. Схема имитируемой VPN-сети 104 Второе рабочее место (им может быть любой компьютер в локальной сети) имитирует удаленный web-сервер. Предполагается, что удаленный web-сервер имеет IP-адрес 192.168.1.1, основной компьютер имеет два интерфейса — внутренний с адресом 192.168.200.1 и внешний с адресом 192.168.1.128. Пользовательский компью- тер имеет внутренний адрес 192.168.200.2. Пройдя авторизацию на PPTP- сервере, пользовательский компьютер получит адрес внешней сети 192.168.1.129. В дальнейшем пользовательский компьютер будет обращаться к внешнему web-серверу по протоколу HTTP. Анализ трафика будет осуществляться в локальной сети между пользо- вательским компьютером и PPTP-сервером. 5.5.2. Установка и настройка VPN ВЫПОЛНИТЬ! 1. Настроить виртуальную сеть между основной ОС и виртуальной машиной Windows 2000. Для этого выполнить следующие действия. 2. В общих настройках виртуальной сети включить адаптер VMnet1 (опция «Enable adapter», рис. 5.9). Рис. 5.9. Активация адаптера VMnet1 105 3. В разделе «Host Virtual Network Mapping» настроить свойства адаптера VMnet1, указав подсеть 192.168.200.0 (рис. 5.10). Рис. 5.10. Настройка подсети адаптера VMnet1 4. В настройках загружаемой виртуальной машины указать подключение к адаптеру VMnet1 (рис. 5.11). 5. Установить IP-адрес виртуальной машины 192.168.200.2. 6. Установить IP-адрес адаптера VMnet1 основной ОС (VMware Network Adapter VMnet1) 192.168.200.1. 7. Подключение по локальной сети основной ОС настроить на IP-адрес 192.168.1.128. 8. Добавить в основной ОС входящее подключение VPN, для чего в свойст- вах «Сетевого окружения» запустить «Мастер новых подключений». С по- мощью мастера последовательно установить следующие параметры: «Ус- тановить прямое подключение к другому компьютеру»; «Принимать вхо- дящие подключения»; «Разрешить виртуальные частные подключения»; указать учетную запись, которая будет использована для подключения. 9. Настроить в основной ОС входящее подключение VPN в разделах: «Общие» ⇒ «Разрешить другим пользователям устанавливать частное подключение к моему компьютеру с помощью туннеля в Интернете или другой сети» (установлен). «Пользователи» ⇒ «Все пользователи должны держать в секрете свои па- роли и данные» (сброшен) 106 «Сеть» ⇒ «Протокол Интернета (TCP/IP)» ⇒ «Разрешить звонящим дос- туп к локальной сети» (установлен) «Сеть» ⇒ «Протокол Интернета (TCP/IP)» ⇒ «Указать IP-адреса явным образом» (192.168.1.128 — 192.168.1.254) «Сеть» ⇒ «Клиент для сетей Microsoft» (установлен) «Сеть» ⇒ «Служба доступа к файлам и принтерам сетей Microsoft» (уста- новлен) Остальные параметры оставить по умолчанию. Рис. 5.11. Настройка адаптера виртуальной машины на адаптер VMnet1 10. Добавить в ОС виртуальной машины подключение к виртуальной частной сети через Интернет со следующими параметрами: «IP-адрес компьютера, к которому осуществляется подключение» (IP-адрес назначения): 192.168.200.1 «Безопасность» ⇒ «Требуется шифрование данных» (сброшен) «Сеть» ⇒ «Тип вызываемого сервера VPN» ⇒ «Туннельный протокол точ- ка-точка (PPTP)» «Сеть» ⇒ «Тип вызываемого сервера VPN» ⇒ «Настройка» ⇒ «Программ- ное сжатие данных» (сброшен) «Сеть» ⇒ «Клиент для сетей Microsoft» (установлен) 107 «Сеть» ⇒ «Служба доступа к файлам и принтерам сетей Microsoft» (уста- новлен) 11. Чтобы предотвратить возможность сетевого доступа к файлам и каталогам основной ОС с виртуальной машины в обход туннеля VPN, необходимо дополнительно установить следующие параметры для соединения VMnet1 в основной ОС: «Общие» ⇒ «Протокол Интернета (TCP/IP)» ⇒ «Дополнительно» ⇒ «WINS» ⇒ «Отключить NetBIOS через TCP/IP» «Общие» ⇒ «Клиент для сетей Microsoft» (сброшен) «Общие» ⇒ «Служба доступа к файлам и принтерам сетей Microsoft» (сброшен) Аналогичные параметры должны быть установлены для подключения к локальной сети в ОС виртуальной машины (тоже, фактически, VMnet1): «Общие» ⇒ «Протокол Интернета (TCP/IP)» ⇒ «Дополнительно» ⇒ «WINS» ⇒ «Отключить NetBIOS через TCP/IP» «Общие» ⇒ «Клиент для сетей Microsoft» (сброшен) «Общие» ⇒ «Служба доступа к файлам и принтерам сетей Microsoft» (сброшен) 12. Установить виртуальное частное подключение. Выяснить адрес, выделен- ный клиенту, а также адрес сервера. При установленном параметре «Раз- решить звонящим доступ к локальной сети» подключившийся таким обра- зом клиент становится узлом локальной сети, но только на сетевом уровне модели OSI и выше. |