99

Канальный уровень представлен протоколами PPTP (Point-to-Point Tunneling 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.

Рис. 5.3. Инкапсуляция в протоколе PPTP

К исходному отправляемому IP-пакету (обозначенному на рисунке серым цветом) последовательно добавляются PPP-, GRE- и IP-заголовки. В новом IP-пакете в качестве адресов указываются адреса туннелирующих узлов.

Протокол PPTP очень часто используется провайдерами Интернет при организации прямого кабельного подключения пользователей. В этом случае пользователям назначается IP-адрес из диапазона «домашних» сетей (например, 10.1.1.189 или 192.168.1.1). Сервер провайдера имеет два адреса — внутренний (для «домашней» сети) и внешний («настоящий»). Когда пользователь авторизуется на PPTP-сервере провайдера, ему динамически выделяется реальный IP-адрес.

Внутри локальной сети между пользователем и PPTP-сервером циркулируют IP-пакеты с внутренними IP-адресами, внутри которых инкапсулированы пакеты с внешними адресами.

100

Рис. 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 необходимо в настройках подключения указать пункт «Require 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-байтное значение, которое возвращается серверу как ответ.

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

AAAAAAAAAAAAAAАА BBBBBBBBBBBBBBBB CCCCCCCCCCCCCCCC

«Ответ»

Рис. 5.7. Схема формирования «ответа» в протоколе MSCHAP

Для шифрования передаваемых данных применяется поточный шифр RC4 с 40либо 128-разрядным ключом. Алгоритм предполагает существова-