Захист даних на канальному рівні

На канальному рівні застосовуються згадані вище протоколи 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) Схема ИНКАП-

суляціі наведена на рис 53

IP

заголовок

GRE

заголовок

PPP

заголовок

IP

заголовок

TCP, UDP

Дані

Рис 53 Інкапсуляція в протоколі PPTP

До вихідного який скеровується IP-пакету (позначеному на малюнку се-рим кольором) послідовно додаються PPP-, GRE-і IP-заголовки У но-вом IP-пакеті як адрес вказуються адреси туннелирующих вузлів

Протокол PPTP дуже часто використовується провайдерами Інтернет при організації прямого кабельного підключення користувачів У цьому випадку

користувачам призначається IP-адреса з діапазону «домашніх» мереж (наприклад, 1011189 або 19216811) Сервер провайдера має дві адреси – внут-ренній (для «домашньої» мережі) і зовнішній («справжній») Коли користувач

авторизується на PPTP-сервері провайдера, йому динамічно виділяється ре-

альний IP-адресу

Усередині локальної мережі між користувачем і PPTP-сервером цирку-

лируют IP-пакети з внутрішніми IP-адресами, усередині яких Інкапсулює-

вани пакети із зовнішніми адресами

Source IP

1951290175

Dest IP

19422623716

Source Port

1134

Dest Port

110

Рис 54 Пакет протоколу PPTP

На рис 54 наведено приклад обміну по протоколу POP3 (порт приймачів

ка 110), здійснюваного між віддаленим POP3-сервером з адресою

19422623716 і користувачем, якому призначений динамічний адресу

1951290175 У локальній мережі видно пакети протоколу IP / GRE, що проходять між вузлами 1011189 (внутрішній адресу користувача) і 10102 (внутріш-

ний адресу PPTP-сервера)

Зазвичай провайдери не включають можливість шифрування і стиснення інкапсуліруемих пакетів, тому при аналізі трафіку в локальній мережі со-

держимое IP / GRE-пакетів легко розпізнати і побачити адреси, протокол і пе-

редавать дані

Для шифрування переданих даних з використанням клієнтів з

ОС Windows XP необхідно в налаштуваннях підключення вказати пункт «Re-quire Data Encryption» («Вимагати шифрування даних», рис 55)

У протоколі 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)

Рис 55 Налаштування клієнта протоколу PPTP

Найбільш стійким є протокол MSCHAP версії 2, що вимагає взаємну аутентифікацію клієнта і сервера У протоколі MSCHAP можуть бути використані три різні варіанти передачі пароля:

– Клієнт передає серверу пароль у відкритому текстовому вигляді

– Клієнт передає серверу хеш пароля

– Аутентифікація сервера і клієнта з використанням виклику і відповіді

Останній варіант найбільш захищений, алгоритм його полягає в на-

дующем (рис 56)

– Клієнт запитує виклик мережевого імені

– Сервер повертає 8-байтовий випадковий виклик (наприклад, «01234567»,

рис 57)

– Клієнт обчислює хеш-функцію пароля алгоритмом «Lan Manager» (на-

приклад, «С2 34 1A 8A A1 E7 66 5F AA D3 B4 35 B5 14 квітня 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-байтное значення, кото-

рої повертається серверу як відповідь

– Сервер шукає значення хеш-функції в своїй базі даних, шифрує за-прос за допомогою хеш-функції і порівнює його з отриманими шифрувати-ними значеннями Якщо вони збігаються, аутентифікація закінчується

Клієнт

Сервер, база паролів

Виклик

Виклик

Хеш-

пароль

DES

DES

Хеш-

пароль

Відповідь

?

Відповідь Відповідь

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

Клієнт 8 байт «виклик» 0001020304050607

Сервер

16 байт hash +

5 нулів =

21 байт

C2341A8AA1E7665F

AAD3B435B51404EE

C2341A8AA1E7665F

AAD3B435B51404EE

0000000000

7 байт

7 байт 7 байт

C2341A8AA1E766        5FAAD3B435B514          04EE0000000000

7 байт DES Key

7 байт DES Key 7 байт DES Key

Шифруємо

«Виклик»

Шифруємо

«Виклик»

Шифруємо

«Виклик»

AAAAAAAAAAAAAAАА BBBBBBBBBBBBBBBB CCCCCCCCCCCCCCCC

«Відповідь»

Рис 57 Схема формування «відповіді» в протоколі MSCHAP

Для шифрування переданих даних застосовується потоковий шифр

RC4 з 40 – або 128-розрядним ключем Алгоритм передбачає существова-

ня секретного ключа, відомого обом учасникам зєднання Даний ключ формується з хеш-функції «Lan Manager» пароля користувача, з-Вестн і клієнту, і серверу

Джерело: Андрончик А Н, Богданов В В, Домуховскій Н А, Коллеров А С, Синадський Н І, Хорьков Д А, Щербаков М Ю, Захист інформації в компютерних мережах Практичний курс

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*