Топалов

ним ключем потім використовується для шифрування останнього трафіка. Найбільш поширені алгоритми шифрування з відкритим ключем:

Діффі-Хеллмана – алгоритм, що дозволяє двом сторонам одержувати спільний секретний ключ, використовуючи незахищений від прослуховування, але захищений від підміни, канал зв'язку. Цей ключ може бути використаний для шифрування подальшого обміну за допомогою алгоритму симетричного шифрування. Алгоритм був уперше опублікований Уїтфілдом Діффі і Мартіном Хеллманом в 1976 році в статті «Нові напрями в криптографії». Недоліком системи Діффі-Хеллмана є те, що вона може бути вразлива для атаки посередником. Якщо той, хто атакує, зуміє розмістити свій комп'ютер між двома абонентами, підключити його до каналу зв'язку і здійснювати перехоплення всієї передаваної інформації, то він зможе виконувати обмін даними з іншими абонентами, видаючи себе за першого, і навпаки.

RSA (абревіатура від прізвищ Rivest, Shamir і Adleman). На відміну від алгоритму Діффі-Хеллмана RSA може використовуватися для шифрування і дешифрування. Також, на відміну від алгоритму Діффі-Хеллмана, безпека алгоритму RSA базується на факторизації великих чисел. Завдання факторизації великих чисел прийнято вважати дуже складним, якщо числа дуже великі (1024біт або більше).

Автентифікація – процедура встановлення відповідності параметрів, що характеризують користувача, процес або дані, заданим критеріям. Автентифікація, застосовується для перевірки права доступу користувача до тих або інших ресурсів, програм, даних.

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

Контроль доступу – запобігання несанкціонованому використанню ресурсу, у тому числі запобігання використанню ресурсу несанкціонованим чином. Здійснюється перевіркою повноважень об'єктів (програм і користувачів) з доступу до ресурсів інформаційної системи на основі їх ідентифікації та автентифікації.

31

Розділ 3 ТУНЕЛЬНІ ПРОТОКОЛИ

3.1.Протокол з’єднання типу “точка-точка” РРР

(Point-to-Point Protocol)

PPP (англ. Point-to-Point Protocol) – протокол з’єднання типу ―точкаточка‖ канального рівня (Data Link) мережної моделі OSI. Звичайно, використовується для встановлення прямого зв'язку між двома вузлами мережі, причому він може забезпечити автентифікацію з'єднання, шифрування й стиск даних. Використовується на багатьох типах фізичних мереж: нуль-модемний кабель, телефонна лінія, стільниковий зв'язок і т.д.

РРР розроблений для простих ліній зв'язку, які транспортують пакети між двома рівноправними вузлами. Ці з'єднання надають повнодуплексне двонапрамлене функціонування й беруть на себе послідовну доставку пакетів. Передбачається, що РРР надає загальне рішення для простого з'єднання територіально рознесених хостів, мостів і маршрутизаторів.

PPP становить собою ціле сімейство протоколів: протокол керування лінією зв'язку (LCP),протокол керування мережею (NCP),протоколи автентифікації (PAP, CHAP), багатоканальний протокол PPP (MLPPP).

PPP протокол був розроблений на основі HDLC і доповнений деякими можливостями.

Протокол РРР також містить у собі механізми для виконання наступних дій:

мультиплексування мережних протоколів;

конфігурування каналу;

перевірки якості каналу;

автентифікації;

стиснення заголовків;

виявлення помилок;

узгодження параметрів каналу.

Протокол РРР має три головних функціональних компоненти, які подані нижче.

Метод інкапсуляції дейтаграм для послідовних каналів, заснованих на протоколі HDLC стандарту ISO.

Протокол керування каналом (Link Control Protocol – LCP), що встановлює, конфігурує та перевіряє з'єднання канального рівня, а також виконує автентифікацію.

Протокол керування мережею (Network Control Protocols – NCP) уста-

новлює й конфігурує різні протоколи мережного рівня (такі, як IP, IPX і АрpleTalk). Наприклад, протокол керування міжмережним протоколом (Internet Protocol Control Protocol – IPCP) становить собою механізм керування мережею для стека IP.

32

Рівні еталонної моделі OSI

3Протоколи верхнього рівня

(такі, як IP, IPX, AppleTalk)

		Протокол керування мережею
		(NCP) (Окремий для кожного
		протоколу мережного рівня)
2
		Протокол керування каналом
		(LCP)
		Канальний протокол високого
		рівня (HDLC)
1		Фізичний рівень
		(EIA/TIA-232, V.24, V.35, ISDN)

Рисунок 3.1 – Протокол РРР і еталонна модель OSI

Link Control Protocol (LCP)забезпечує автоматичне настроювання інтерфейсів на кожному кінці (наприклад, установка розміру пакетів) і опціонально виконує автентифікацію. Протокол LCP працює поверх PPP, тобто початковий PPP зв'язок повинен бути до роботи LCP.

Для забезпечення достатньої універсальності й перенесення в широкому спектрі оточень, РРР надає протокол керування з'єднанням. LCP використовується для автоматичного встановлення опцій формату інкапсуляції, керування різними обмеженнями в розмірах пакетів, детектування петлею в з'єднанні й інших помилках конфігурування й термінування з'єднання. Інші додаткові можливості надаються для автентифікації й ідентифікації учасників з'єднання, визначення правильності функціонування з'єднання або його збоїв.

PPP дозволяє працювати декільком протоколам мережного рівня на одному каналі зв'язку. Інакше кажучи, усередині одного PPP-з'єднання можуть передаватися потоки даних різних мережних протоколів (IP, Novell IPXі т.д.), а також дані протоколів канального рівня локальної мережі. Для кожного мережного протоколу використовується Network Control Protocol (NCP)який його конфігурує (погоджує деякі параметри протоколу).

Тому що в PPP входить LCP протокол, то можна управляти наступними LCP параметрами:

Автентифікація. RFC 1994 описує Challenge Handshake Authentication

Protocol (CHAP),який є кращим для проведення автентифікації в PPP, хоча

Password Authentication Protocol (PAP)іноді ще використовується. Іншим варіа-

нтом для автентифікації є Extensible Authentication Protocol (EAP).

Стиск. Ефективно збільшує пропускну здатність PPP з'єднання, за рахунок стиску даних у кадрі. Найбільш відомими алгоритмами стиску PPP кад-

рів є Stacker і Predictor.

Виявлення помилок. Включає Quality-Protocol і допомагає виявити петлі зворотного зв'язку за допомогою Magic Numbers RFC 1661.

33

Багатоканальність. Multilink PPP (MLPPP, MPPP, MLP) надає методи для поширення трафіка через кілька фізичних каналів, маючи одне логічне з'єднання. Цей варіант дозволяє розширити пропускну здатність і забезпечує балансування навантаження.

Робота РРР з'єднання. Щоб установити повідомлення через з'єднання точ- ка-точка, кожний кінець РРР з'єднання повинен спочатку послати LCP пакети, щоб сконфігурувати і протестувати з'єднання. Після того як з'єднання встановлене, сторони можуть бути автентифіковані.

Після цього РРР повинен послати NCP пакети, щоб вибрати й сконфігурувати один або більше протоколів мережного рівня. Коли кожний з обраних протоколів мережного рівня сконфігурований, пакети від кожного протоколу мережного рівня можуть проходити через з'єднання.

З'єднання залишається сконфігурованим для передачі даних доти, поки кінцевий LCP або NCP пакет не закриє з'єднання, або поки не відбудеться яканебудь зовнішня подія (відпрацює таймер не активності або не втрутиться адміністратор).

У процесі конфігурації, утримання й завершення з'єднання РРР проходить через кілька певних фаз, які описує наступна спрощена діаграма станів подана на рис. 3.2 [(RFC 1661).

Початковий	Запуск	Установка	Відкриття	Автентифікація
стан			каналу
			Невдача
Невдача				Успіх
Завершення				Підключення
				до мережі
		Зачинення

Рисунок 3.2 – Фазна діаграма роботи протоколу РРР

На діаграмі роботи протоколу РРР зазначені не всі переходи.

Фаза Link Dead. З'єднання неминуче починається й закінчується цією фазою. Коли зовнішня подія (таке як детектування з'єднання на фізичному рівні або конфігурування мережним адміністратором) показує, що фізичний рівень готовий до використання, РРР перейде у фазу Link Establishment.

Протягом цієї фази, LCP автомат буде перебувати в станах Initial і Starting. Перехід у фазу Link Establishment буде сигналом Up для LCP автомата. Звичайно, з'єднання вертається в цю фазу після роз'єднання модему. У випадку фіксованого з'єднання (hardwired link) ця фаза може бути вкрай нетривалою - досить просто визначити присутність іншого пристрою.

Фаза Link Establishment. LCP використовується для встановлення з'єднання шляхом обміну пакетами Configure. Після того як цей обмін завершується, LCP переходить у стан Opened, обмінявшись пакетами Configure-Ack.

34

Всі конфігураційні опції отримують значення за замовчуванням, якщо вони не змінені під час конфігураційного обміну.

Важливо помітити, що LCP можуть бути настроєні тільки ті конфігураційні опції, які не залежать від специфіки протоколів мережного рівня. Конфігурування протоколів мережного рівня виконується окремими протоколами ке-

рування мережею (Network Control Protocols – NCPs) протягом фази NetworkLayer Protocol.

Будь-які не LCP пакети, отримані протягом цієї фази повинні бути відки-

нуті.

Одержання пакета LCP Configure-Request викликає повернення у фазу

Link Establishment з фаз Network-Layer Protocol і Authentication.

Фаза Authentication. У деяких випадках бажано запросити вилучену сторону автентифікувати себе, перед тим як дозволити протоколу мережного рівня почати обмін пакетами.

За замовчуванням, автентификація не обов'язкова. Якщо реалізація бажає, щоб вилучена сторона була автентифікована з використанням специфічного протоколу автентифікації, то вона повинна запросити використання цього протоколу автентифікації протягом фази Link Establishment.

Автентифікацію варто провести після встановлення з'єднання якнайшвидше, наскільки це можливо. Проте, визначення якості з'єднання може проходити одночасно. Реалізація може не дозволити обмін пакетами визначення якості з'єднання, щоб затримувати автентифікацію нескінченно. Якщо автентифікація невдала, варто перейти до фази Link Termination.

У даній фазі може відбуватися обмін пакетами LCP, протоколу автентифікації й пакетами моніторингу якості з'єднання. Всі пакети інших протоколів, отримані протягом цієї фази, повинні бути відкинуті.

Реалізації не слід вважати невдалою автентифікацію після закінчення таймаута або при відсутності відповіді. Автентифікації варто дозволяти кілька методів повторної передачі й виконувати фазу Link Termination тільки при перевищенні деякого числа спроб.

За початок фази Link Termination відповідальна та реалізація, яка відхилила автентифікацію вилученій стороні.

Фаза Network-Layer Protocol. Після того як РРР закінчив попередню фазу, кожний протокол мережного рівня (такий як IP, IPX, або AppleTalk) повинен бути окремо сконфігурований відповідним протоколом керування мережею

(Network Control Protocol - NCP).

Кожний NCP може бути у стані Opened або Closed. Тому що реалізація в початковій стадії може використовувати значну кількість часу на визначення якості з'єднання, реалізації варто уникати фіксованих таймаутів при очікуванні конфігурації сторонами NCPs.

Після того, як NCP досягне стану Opened, РРР буде переносити пакети відповідного протоколу мережного рівня. Будь-які пакети підтримуваних протоколів мережного рівня, отримані перш ніж відповідний NCP досягне стану Opened, повинні бути відкинуті.

35

Поки LCP у стані Opened, будь-який пакет непідтримуваний реалізацією протоколу повинен бути повернутий в Protocol-Reject. Тільки підтримувані протоколи повинні відкидатися.

Протягом цієї фази, трафік з'єднання складається з будь-якої можливої комбінації пакетів LCP, NCP, і протоколу мережного рівня.

Фаза Link Termination. РРР може завершити з'єднання в будь-який час. Це може відбутися тому, що загублено зв'язок, відбувся збій автентифікації, погіршилася якість з'єднання. Закінчення періоду бездіяльності або адміністративне закриття з'єднання.

LCP використовується для закриття з'єднання через обмін пакетами Terminate. Коли з'єднання закрите, РРР повідомляє протоколи мережного рівня, що вони можуть здійснити відповідну дію.

Після обміну пакетами Terminate, реалізації варто сигналізувати фізичному рівню про від'єднання, щоб змусити з'єднання завершитися, особливо у випадку зі збоєм автентифікації. Відправникові пакета Terminate-Request варто відключитися після одержання пакета Terminate-Ack або після закінчення лічильника Restart. Одержувачеві пакета Terminate-Request варто чекати відключення вилученої сторони й він не повинен відключатися, поки не пройде як мінімум один інтервал Restart після відправлення Terminate-Ack. РРР варто перейти у фазу Link Dead.

Всі не LCP-пакети, отримані протягом цієї фази повинні бути відкинуті. Закриття з'єднання за допомогою LCP є достатнім. NCP немає необхідності слати шквали пакетів Terminate. Навпроти, той факт, що NCP закритий, не є достатньою підставою для закриття РРР з'єднання, навіть якщо цей NCP у цей час єдиний у стані Opened.

Інкапсуляція HDLC є базисним форматом фрейма протоколу РРР. На рис.3.3 показані відмінності між цими двома форматами фреймів. У рекомендації RFC1662 докладно описується процес створення фреймів у протоколі

HDLC.

Прапор	Адреса	Керування	Корисне			FCS	Прапор
			навантаження
1 байт	1 байт	1 байт	1500 байт			2 байт	1 байт
HDLC ISO фрейм
Прапор	Адреса	Керування	Протокол			LCP	FCS	Прапор
1 байт	1 байт	1 байт	1 байт		1500 байт		2 байт	1 байт

Фрейм протоколу PPP

Рисунок 3.3 – Формат фреймів HDLC і РРР

Кожний фрейм PPP завжди починається й завершується прапором 0x7E. Потім йдуть байт адреси й байт керування, які теж завжди рівні 0xFF і 0x03 відповідно. У зв'язку з імовірністю збігу байтів усередині блока даних із зарезер-

36

вованими прапорами, існує система автоматичного коректування «проблемних» даних з наступним відновленням.

Поля «Прапор», «Адреса» і «Керування» можуть бути опущені й не передаватися, але це якщо PPP у процесі конфігурування (використовуючи LCP), домовиться про це.

Поле «Дані», PPP фрейма, у свою чергу розбиті ще на два поля: прапор протоколу (який визначає тип даних до кінця фрейма), і самі дані.

Прапори протоколу від 0x0XXX до 0x3XXX ідентифікують протоколи мережного рівня. Наприклад, популярному IP протоколу відповідає прапор

0x0021, а Novell IPX – 002B.

Прапори протоколу від 0x4XXX до 0x7XXX ідентифікують протоколи з низьким рівнем трафіка.

Прапори протоколу від 0x8XXX до 0xBXXX ідентифікують протокол керування мережею (NCP).

Прапори протоколу від 0xCXXX до 0xEXXX ідентифікують керуючі протоколи. Наприклад, 0xC021 позначає, що кадр містить дані протоколу керування з'єднанням LCP.

Автентифікація за допомогою протоколів PAP і CHAP

При використанні протоколу РРР перевірка прав доступу викликаючої сторони може бути виконана за допомогою механізмів PAP і CHAP. Можна також указати параметр, при якому ніякої перевірки не виконується. На рис. 11 показаний процес автентифікації в протоколі РРР.

Обмін повідомленнями, показаний на рис. 3.4, ілюструє наступні етапи автентифікації протоколу РРР:

			Перевірити локальну базу	Пройшло
			даних		вдало
		Локальній
		сервер
	Узгодження	Визначення методу	Не		Продовжувати
	вхідного			Від'єднати
		автентифікаціі	пройшло		узгодження РРР
	виклику РРР
		Сервер
		безпеки
		Зробити запит до бази даних		Пройшло
					вдало
		Автентифікація
		відсутня
	Рисунок 3.4 – Сеанс РРР для вхідного виклику: автентифікація

37

1.При введенні користувачем команди ррр система визначає тип сконфігурованого методу автентифікації. Якщо в конфігурації така перевірка доступу не задана, то процес РРР запускається негайно. У противному випадку система переходить до наступного етапу.

2.Система визначає використовуваний метод автентифікації; який варто використовувати, і виконує одне з наступних дій:

переглядає локальну базу даних (створену командами вказування імені користувача й пароля) для перевірки того, що пара ім’я користувача/пароль відповідає аналогічній парі в локальній базі даних (CHAP або PAP), або

надсилає запит на перевірку автентифікації на сервер безпеки

(TACACS+ або RADIUS).

З. Система аналізує відповідь на запит про перевірку прав доступу, отриманий від сервера безпеки або від локальної бази даних. Якщо ця відповідь позитивна, то сервер доступу запускає процес РРР. Якщо результат негативний, то сервер доступу негайно відкидає виклик користувача.

При обох типах перевірки автентифікації (PAP або CHAP) має місце двосторонній процес, у якому пара ідентифікатор/пароль постійно посилається пристрою автентифікації доти, поки не будуть визнані права на доступ викликаючої сторони або з'єднання не буде припинено. При використанні протоколу PAP, такий процес не забезпечує повної надійності. Якщо до каналу підключити аналізатор протоколу, то пароль буде видний у вигляді відкритого тексту.

При використанні протоколу PAP немає захисту від багаторазового зчитування запитів (якщо є програмний або апаратний перехоплювач трафіка, фізично підключений до каналу, і пакет перехоплюється, то його можна потім використовувати для підтвердження своєї автентифікації, шляхом направлення його безпосередньо в мережу й відтворення перехоплених пакетів).

Якщо потрібно більш надійний метод контролю доступу, то як метод автентифікації варто використовувати не протокол PAP, a CHAP: Протокол PAP варто використовувати тільки в тому випадку, якщо це єдиний метод автентифікації, який підтримує вилучена станція.

Віддалений	Сервер
користувач	доступу

Після запиту вводиться ім’я користувача та пароль

	Запустити РРР	Ім’я користувача
	Використовувати РАР	student
		Пароль student
	student
	student
	Прийняти або відкинути	База даних
		користувачів

Рисунок 3.5 – Одностороння автентифікація в протоколі PAP між вузлом і сервером доступу

38

Протокол PAP становить собою односторонню перевірку в тому випадку, коли вона здійснюється між вузлом і сервером доступу, як показано на рис. 3.5; якщо така перевірка відбувається між маршрутизаторами, те це двосторонній процес.

При використанні перевірки прав доступу протоколу CHAP сервер доступу після встановлення каналу РРР посилає повідомлення-запит на вилучений вузол, як показано на рис. 3.6. Вилучений вузол відповідає значенням, обчисленим з використанням односторонньої хеш-функції (звичайно за допомогою алгоритму MD5). Сервер доступу перевіряє отриману відповідь і порівнює її зі своїм, заздалегідь обчисленим, значенням цієї ж величини. Якщо величини збігаються, то автентифікація вважається підтвердженою. У противному випадку з'єднання негайно переривається.

	Віддалений		Сервер
	користувач		доступу
		Запустити РРР	Ім’я користувача
	Після запиту	Використовувати CHAP	student
	вводиться ім’я		Пароль student
	користувача	Виклик
	student та
	пароль student	Прийняти або відкинути	База даних
			користувачів

Рисунок 3.6 – Одностороння перевірка автентифікації протоколу CHAP між користувачем і сервером доступу

Метод CHAP забезпечує захист від спроби несанкціонованого доступу за допомогою використання змінного значення запиту (challenge), що є унікальним і непередбаченим. Використання повторних запитів кожні дві хвилини в сеансі CHAP призначене для того, щоб обмежити час можливості організації вторгнення при будь-якій спробі несанкціонованого доступу. Сервер доступу (або сервер перевірки автентифікації, такий, як TACACS+) управляє частотою й синхронізацією запитів. Головною перевагою постійно змінюваного рядка запиту на автентифікацію є те, що інформація каналу не може бути "прослухана" перехоплювачем пакетів і пізніше відтворена для одержання несанкціонованого доступу до мережі.

Стиск протоколу РРР.

Маршрутизатори також дозволяють збільшити продуктивність каналу за рахунок використання механізмів стиску даних, які підвищують пропускну здатність.

39

Стиск є налаштованим параметром лінії. Тому, якщо бажано використати стиск, а викликувана сторона для нього не сконфігурована, то стиску відбуватися не буде.

Нижче подані використовувані схеми стиску.

Predictor. Ця схема перевіряє чи не були дані вже стиснуті. Якщо були, то дані просто пересилаються, і час на перевірку можливості стиску вже стислих даних не затрачається.

Stacker. Даний механізм стиску, заснований на алгоритмі Lempel-Ziv (LZ), переглядає дані, і замість відправлення вихідного потоку відразу відправляє блоки даних з інформацією про те, де певна послідовність біт зустрічається

впотоці даних, а потім передає відповідні послідовності. Приймаюча сторона використовує одержувану в такий спосіб інформацію для повторного складання даних.

MPPCi Microsoft-Протокол стиску для каналів " точка-точка" (Microsoft Point-to-Point Compression Protocol, алгоритм, описаний у документі RFC 2118)

дозволяє маршрутизаторам Cisco обмінюватися стислими даними із клієнтами Microsoft. Механізм МРРС використовує алгоритм стиску, заснований на LZ.

Стиск заголовка TCP. Цей метод використовується для стиску заголовків протоколу TCP.

Найбільший ступінь стиску, звичайно, досягається для легко стисливих текстових файлів. Уже стислі дані, такі, як зображення у форматі JPEG, файли формату MPEG або файли, які були стиснуті за допомогою програмного забезпечення, такого, як архіватори PK2JP або Stufflt, стискуються у відношенні 1:1 або навіть меншому.

Якщо часто використовується передача вже стислих даних, таких, як зображення або відео, то варто розглянути питання про те, чи потрібно взагалі глобально встановлювати стиск. Спроба стиснути вже стислі дані може зайняти більше часу,ніж передача цих даних взагалі без стиску. В ідеальному випадку можна одержати стиск у відношенні 2:1 або 3:1 для інформації, що не була попередньо стисла. Для змішування стислих і не стислих даних варто очікувати середнього відношення при стискуванні 1,6:1.

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

Різні методи стиску мають свої особливості. Зокрема, метод Predictor більшою мірою завантажує пам'ять і в меншому ступені завантажує процесор. Методи Stacker і МРРС більшою мірою завантажують центральний процесор пристрою й меншою мірою завантажують оперативну пам'ять. Завантаження пам'яті означає, що виконання операції стиску даних вимагає виділення додаткової пам'яті.

При реалізації одного з методів стиску на конкретному маршрутизаторі необхідно розглянути питання про використання додаткової пам'яті.

40