Протоколи: SSL, socks, ipsec, PPTP, L2F, l2tf

На транспортному рівні найчастіше застосовуються протоколи SSL (Secure Socket Layer) і його більш нова реалізація - TSL (Transport Layer Security). Також застосовується протокол SOCKS. Особливість протоколів транспортного рівня - незалежність від прикладного рівня, хоча найчастіше шифрування здійснюється для передачі по протоколу HTTP (режим HTTPS). недостатком є неможливість шифрування IP-адрес і тунелювання IP- пакетів.

Розглянемо функціонування протоколу SSL. Протокол часто застосовується для установки захищеного з'єднання, коли користувач, який звернувся до web-серверу, передає або одержує конфіденційні відомості, наприклад про обсяг і вартості покупки в Інтернет-магазині, або отримує статистику своїх з'єднань у Інтернет-провайдера. У цьому випадку web-клієнт, наприклад Internet Explorer, автоматично переходить в захищений режим, про що свідчить піктограма «замок» у правій нижній частині вікна.

Рис. 4.39. Мережевий пакет з сертифікатом відкритого ключа сервера

Протокол SSL передбачає функції аутентифікації, шифрування даних і забезпечення цілісності даних. Аутентифікація здійснюється шляхом обміну цифровими сертифікатами при встановленні з'єднання (сесії). Так як web-сервер зазвичай приймає запити від довільних клієнтів, то найчастіше аутентифікується тільки сервер. Для шифрування даннях застосовується стандартний для VPN-з'єднань підхід: для шифрування даних застосовується симетричний сеансовий ключ. Обмін симетричними сеансовими ключами відбувається при встановленні з'єднання, при передачі сеансові ключі шифруються за допомогою відкритих ключів. Для забезпечення цілісності до повідомлення додається його хеш-код.

SOCKS — мережевий протокол, який дозволяє кліент-серверним додаткам прозоро використовувати сервіси за міжмережевими екранами (фаєрволами). SOCKS — це скорочення від «SOCKet Secure».

Кліенти за міжмережевим екраном, що потребують доступ до зовнішніх серверів, замість цього можуть з'єднуватися з SOCKS проксі-сервером. Такий проксі-сервер контролює права клієнта для доступу до зовнішніх ресурсів і передає запит до сервера. SOCKS може використовуватися і протилежним способом, дозволяючи зовнішнім клієнтам з'єднуватися з серверами за міжмережевим екраном (брандмауером).

На відміну від HTTP проксі-серверів, SOCKS передає всі дані від кліента, нічого не додаючи від себе, тобто з точки зору кінцевого сервера, SOCKS проксі є звичайним клієнтом. SOCKS більш універсальний - не залежить від конкретних протоколів рівня додатків (7-го рівня моделі OSI) і базується на стандарті TCP/IP - протоколі 4-го рівня. Зате HTTP проксі кешує дані і може більш ретельно фільтрувати вміст переданих даних.

Цей протокол був розроблений Девідом Кобласом (David Koblas), системним адміністратором MIPS Computer Systems. Після того, як в 1992 році MIPS увійшла до складу Silicon Graphics (SGI), Коблас зробив доповідь про SOCKS на Симпозіумі з Безпеки Usenix (Usenix Security Symposium), і SOCKS став публічно доступним. Протокол був розширений до четвертої версії Ін-Да Лі (Ying-Da Lee) з NEC Systems Laboratory

На мережному рівні використовуються два основні протоколи: SKIP (Simple Key management for Internet Protocol - просте управління ключами для IP-протоколу) і IPSec. На даному рівні можливо як шифрування всього трафіка, так і тунелювання, яке включає приховування IP-адрес. На мережевому рівні будуються найпоширеніші VPN системи.

Розглянемо протокол IPSec. Він дозволяє здійснювати дві найважливіші функції мережевої захисту - здійснювати криптографічний захист трафіку і виконувати фільтрацію вхідних/вихідних пакетів. Протокол реалізований в ОС Windows 2000/XP. Протокол забезпечує аутентифікацію учасників мережевої обміну (протокол IKE - Internet Key Exchange), захист цілісності (Заголовок аутентифікації AH - Authentication Header) і шифрування (ESP - Encapsulating Security Payload)

Заголовок, що аутентифікуз (AH) виконує захист від атак, пов'язаний з несанкціонованою зміною вмісту пакету. Для цього особливим чином застосовується алгоритм MD5: в процесі формування AH послдовно обчислюється хеш-функція від об'єднання самого пакету і деякого попередньо погодженого ключа, потім від об'єднання отриманого результату і перетвореного ключа. Заголовок ESP служить для забезпечення конфіденційності даних, припускає можливість використання будь-якого симетричного алгоритму шифрування. Протокол обміну ключами IKE відповідає за первинний етап установлення з'єднання, спосіб ініціалізації захищеного каналу, процедури обміну секретними ключами, вибір методу шифрування. Передбачає три різних способи автентифікації: технологію «виклик-відповідь» з використанням хеш-функції із загальним секретним ключем, застосування сертифікатів відкритих ключів і використання протоколу Керберос.

Канальний рівень представлений протоколами PPTP (Point-to-Point Tunneling Protocol), L2F (Layer-2 Forwarding) і L2TP (Layer-2 Tunneling Protocol). Перевагою даного рівня є прозорість не тільки для додатків прикладного рівня, але і для служб мережевого і транспортного рівня. Зокрема, перевагою є незалежність від протоколів мережевого і транспортного рівня, що застосовуються - це може бути не тільки IP-протокол, але і протоколи IPX (застосовується в локальних мережах з серверами на основі ОС Novell Netware) і NetBEUI (застосовується в локальних мережах Microsoft). шифрування підлягають як передані дані, так і IP-адреси. У кожному із зазначених протоколів по-різному реалізовані алгоритми аутентифікації і обміну ключами шифрування.

В основі протоколу PPTP лежить наступний алгоритм: спочатку проводиться інкапсуляція даних за допомогою протоколу PPP, потім протокол PPTP виконує шифрування даних і інкапсуляцію. PPTP інкапсулює PPP- кадр в пакет Generic Routing Encapsulation (протокол GRE). Схема інкапсуляції наведена на рис. 4.3. (Слайд 7)

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

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

Протокол PPTP дуже часто використовується провайдерами Інтернет при організації прямого кабельного підключення користувачів. У цьому випадку користувачам призначається IP-адресу з діапазону «домашніх» мереж (наприклад, 10.1.1.189 або 192.168.1.1). Сервер провайдера має дві адреси - внутрішню (для «домашньої» мережі) і зовнішню («справжній»). Коли користувач авторизується на PPTP-сервері провайдера, йому динамічно виділяється реальний IP-адресу.

Всередині локальної мережі між користувачем і PPTP-сервером циркулюють IP-пакети з внутрішніми IP-адресами, всередині яких інкапсульовані пакети із зовнішніми адресами. (Слайд 8)

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

На рис. 4.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-пакетів легко розпізнати і побачити адреси, протокол і передані дані.

У протоколі PPTP для аутентифікації передбачаються різні протоколи аутентифікації:

- Extensible Authentication Protocol (EAP),

- Microsoft Challenge Handshake Authentication Protocol (MSCHAP),

- Challenge Handshake Authentication Protocol (CHAP),

- Shiva Password Authentication Protocol (ПУНП)

- Password Authentication Protocol (PAP)

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

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

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

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

Протокол розсилки канального рівня L2F (Layer 2 Forwarding Protocol) дозволяє організувати тунелювання канального рівня протоколами вищих рівнів. Використання таких тунелів дозволяє позбутися зв'язку місцеположення початкового сервера комутованого з місцем завершення комутованого з'єднання та забезпечення доступу в мережу.

Дата добавления: 2014-01-04