Защита данных на канальном уровне

На канальном уровне применяются упомянутые выше протоколы 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). Схема инкапсуляции приведена на рис. 1.3.

 

IP заголовок

GRE заголовок

PPP заголовок

IP заголовок

TCP, UDP

Данные

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

 

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

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

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

 

Рис. 1.4. Пакет протокола PPTP

 

На рис. 1.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» («Требовать шифрование данных», рис. 1.5).

 

Рис. 1.5. Настройка клиента протокола PPTP

 

В протоколе 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)

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

− клиент передает серверу пароль в открытом текстовом виде;

− клиент передает серверу хэш пароля;

− аутентификация сервера и клиента с использованием вызова и ответа.

Последний вариант наиболее защищенный, алгоритм его состоит в следующем (рис. 1.6).

− Клиент запрашивает вызов сетевого имени.

− Сервер возвращает 8-байтовый случайный вызов (например, «01234567», рис. 1.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»). Клиент выполняет то же самое с хэш-функцией пароля, получаемой алгоритмом хэширования, реализованном в ОС семейства Windows NT. В результате формируется 48-байтное значение, которое возвращается серверу как ответ.

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

 

 

Рис. 1.6. Аутентификация в протоколе MSCHAP

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

 

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