Зміст
- Вступ...2
- Що таке безпека IPSecurity?...3
- Історична довідка появи протоколу...4
- Універсальний підхід...5
- Небезпека на кожнім кроці...7
- Діючі особи та елементи архітектури...9
- Архітектура IPSecurity...10
- Заголовок АН...14
- Заголовок ESP...14
- Транспортний режим...17
- Тунельний режим...18
- Шифрування...18
- Тунелювання...20
- Аутентифікація...20
- Security Association...21
- Політика безпеки...21
- Узгодження протоколів і керування ключами...21
- Генерація ключів...24
- Алгоритм Диффі-Хелмана...25
- Протоколи ISAKMP/Oakley…31
- Протокол IKE…31
- Атаки на АН, ESP, IKE...33
- Системи захисту інформації...34
- Системи для уважних і неледачих...36
- Прозорі системи захисту...37
- Віртуальні приватні мережі VPN...38
- VPN, що використовують протокол IPSec…41
- Коли VPN безсилий…42
- Системи для дуже зайнятих…42
- Переваги IPSec…45
- Конфігурація Win Route”s IPSec…46
- IP клієнт в локальній мережі…47
- ІР сервер в локальній мережі…49
- Оцінка потоколу...50
- Висновок...51
- Література...53
Вступ
Необхідність захисту даних
Наприкінці шестидесятих років американське агентство перспективних досліджень в обороні DARPA ухвалило рішення про створення експериментальної мережі під назвою ARPANet. У сімдесятих роках ARPANet стала вважатися діючою мережею США, і через цю мережу можна було дістати доступ до провідних університетських і наукових центрів США. На початку вісімдесятих років розпочалася стандартизація мов програмування, а потім і протоколів взаємодії мереж. Результатом цієї роботи стала розробка семирівневої моделі мережної взаємодії ISO/OSI і сімейства протоколів TCP/IP, яке стало основою для побудови як локальних, так і глобальних мереж.
Базові механізми інформаційного обміну в мережах TCP/IP були в загалом сформовані на початку вісімдесятих років, і були спрямовані перш за все на забезпечення доставки пакетів даних між різними операційними системами з використанням різнорідних каналів зв'язку. Не дивлячись на те, що ідея створення мережі ARPANet (згодом перетворилася на сучасний Інтернет) належала урядовій оборонній організації, фактично мережа зародилася в дослідницькому світі, і наслідувала традиції відвертості академічного співтовариства. Ще до комерціалізації Інтернету (яка відбулася у середині дев'яностих років) багато авторитетних дослідників відзначали проблеми, пов'язані з безпекою стека протоколів TCP/IP. Основні концепції протоколів TCP/IP не повністю задовольняють (а у ряді випадків і суперечать) сучасним уявленням про комп'ютерну безпеку.
До недавнього часу мережа Інтернет використовувалася в основному для обробки інформації по відносно простих протоколах: електронна пошта, передача файлів, віддалений доступ. Сьогодні, завдяки широкому поширенню технологій WWW, все активніше застосовуються засоби розподіленої обробки мультимедійної інформації. Одночасно з цим зростає об'єм даних, що обробляються в середовищах клієнт/сервер і призначених для одночасного колективного доступу великого числа абонентів. Розроблено декілька протоколів прикладного рівня, що забезпечують інформаційну безпеку таких додатків, як електронна пошта (PEM, PGP і т.п.), WWW (Secure HTTP, SSL і т.п.), мережне управління (SNMPv2 і т.п.). Проте наявність засобів забезпечення безпеки в базових протоколах сімейства TCP/IP дозволить здійснювати інформаційний обмін між широким спектром різних додатків і сервісних служб.
Безпека IP
Засоби безпеки протоколу IP дозволяють управляти захистом всього IP-трафіку від джерела інформації до її одержувача. Можливості управління безпекою IP (IP Security Management) в системі Windows 2000 дозволяють призначати і застосовувати політику безпеки IP, яка гарантує захищений обмін інформацією для всієї мережі. Механізм безпеки IP є реалізацією протоколу безпеки IP (IP Security, IPSec), прозорою для користувача, адміністрування безпеки централізоване і поєднує гарантії безпечного обміну інформацією із легкістю застосування.
Потреба в захисті мереж, заснованих на протоколі IP, вже досить велика і зростає з кожним роком. В даний час в тісно взаємозв'язаному діловому світі мереж Інтернет, интранет, экстранет (extranet — корпоративна мережа|, частини| якої зв'язані через відкриті мережі, наприклад, через Інтернет), філіалів і віддаленого доступу по мережах передається важлива інформація, конфіденційність якої не можна порушувати. Однією з основних вимог, що пред'являються до мережі|сіті| з боку мережевих|мережних| адміністраторів і інших професіоналів, що обслуговуючих і використовують мережі|сіті|, є|з'являється,являється| вимога гарантії, що цей трафік буде захищений:
|
Доступу суб'єктів, що не мають на це прав;
|
|
|
Перехоплення, перегляду|проглядання| або копіювання;
|
|
|
Модифікації даних під час шляху|колії,дороги| по мережі;|сіті|
|
|
|
|
|
Ці проблеми характеризуються такими показниками, як цілісність даних, конфіденційність і достовірність|справжність|. Крім того, зашита від повторного використання (replay protection) запобігає ухваленню|прийняттю,прийманню| повторно посланого|надісланого| пакету.
2.Історична довідка появи протоколу
У 1994 році Рада з архітектури Інтернет (IAB) випустив звіт "Безпека архітектури Інтернет". У цьому документі описувалися основні області застосування|вживання| додаткових засобів|коштів| безпеки в мережі|сіті| Інтернет, а саме захист від несанкціонованого моніторингу, підміни пакетів і управління потоками даних. У числі першочергових і наиболее| важливих|поважних| захисних заходів указувалася|вказувалася| необхідність розробки концепції і основних механізмів забезпечення цілісності і конфіденційності потоків даних. Оскільки зміна базових протоколів сімейства TCP/IP викликало|спричинило| б повну|цілковиту| перебудову мережі|сіті| Інтернет, було поставлене завдання|задача| забезпечення безпеки інформаційного обміну у відкритих|відчинених| телекомунікаційних мережах|сітях| на базі існуючих протоколів. Таким чином, почала|розпочала,зачала| створюватися специфікація Secure IP, додаткова по відношенню до протоколів IPv4 і IPv6.
Активне злиття компаній і утворення нових конгламератов і альянсів змушує задуматися про організації безпеки рыботы в загальних мережах. Як правило, з'являється необхідність в обміні комерційною або іншою важливою інформацією і далеко не факт, що компанії мають спеціальний виділений канал під ці задачі. В основному вся ця інформація йде по мережі загального користування.
Існує кілька способів убезпечити комунікації: купити маршрутизатор з убудованим брандмауером або виділений брандмауер. Вибір між цими варіантами робиться виходячи з задач компанії. Якщо потрібно якісна і швидка шифрация без затримок, то єдиним правильним рішенням буде поставити виділений брандмауер. Ми пропонуємо використовувати пристрою компанії Newbridge Networks, що можуть використовуватися в мережах будь-якого масштабу для шифрации інформації від ЛВС або вилучених користувачів на мережному рівні.
Загальна схема проключения устаткування може виглядати в такий спосіб.
На схемі показані варіанти проключения офісів і підключення вилучених користувачів. Апаратні брандмауери серії Newbridge 23x розрізняються кількістю підтримуваних сесій і продуктивністю. Вибір програмного брандмауера Newbridge 130 залежить тільки від платформи, на яку він установлюється. Шифрация здійснюється на мережному рівні з використанням протоколу IPsec.
Широке проникнення протоколу IP у мережі різного масштабу невипадково. Гнучкість, ефективність і здатність виступати в ролі комунікаційного «містка» між платформами різних типів забезпечили йому заслужену популярність. Однак повсюдне поширення цього протоколу оголило і його слабкі сторони. Створюючи своє дітище, архітектори IP не бачили причин особливо турбуватися про захист мереж, що будуються на його основі. Вони і не думали, що коли-небудь відсутність ефективних засобів захисту стане основним фактором, що стримує застосування IP.
Вада, що виявилася, спочатку передбачалася заповнити в шостій версії протоколу. У 1993 р. у складі консорціуму IETF була створена робоча група IP Security Working Group, що зайнялася розробкою архітектури і протоколів для шифрування даних, переданих по мережах IPv6. Однак у міру просування в цьому напрямку ставало усе очевидніше, що розробки, споконвічно орієнтовані на IP шостої версії, можуть придатися й у більш традиційному середовищі IPv4. У результаті на світло з'явився набір протоколів IPSec, заснованих на сучасних технологіях електронного цифрового підпису і шифрування даних.
2.1 Універсальний підхід
Проблема захисту даних, переданих по глобальних IP-мережах, виникла не вчора. Перші засоби захисту з'явилися практично відразу після того, як уразливість IP-мереж дала про себе знати на практиці. Характерними прикладами розробок у цій області можуть служити PGP/Web-of-Trust для шифрування повідомлень електронної пошти, Secure Sockets Layer (SSL) для захисту Web-трафика, Secure SHell (SSH) для захисту сеансів telnet і процедур передачі файлів.
Загальним недоліком подібних широко розповсюджених рішень є їх «прихильність» до визначеного типу додатків, а виходить, нездатність задовольнити тим різноманітним вимогам до систем мережного захисту, що пред'являють великі корпорації або Internet-провайдери. Самий радикальний спосіб перебороти зазначене обмеження зводиться до того, щоб будувати систему захисту не для окремих класів додатків (нехай і досить популярних), а для мережі в цілому. Стосовно до IP-мереж це означає, що системи захисту повинні діяти на мережному рівні моделі OSI.
Перевага такого вибору полягає в тім очевидному факті, що в IP-мережах саме даний рівень відрізняється найбільшої гомогенністью: незалежно від вышележащих протоколів, фізичного середовища передачі і технології канального рівня транспортування даних по мережі не може бути зроблена в обхід протоколу IP.
Тому реалізація захисту мережі на третьому рівні автоматично гарантує як мінімум такий же ступінь захисту всіх мережних додатків, причому без якої-небудь модифікації останніх. Для користувачів процедури захисти виявляться настільки ж прозорими, як і сам протокол IP. Раз архітектура IPSec сумісна з протоколом IPv4, її підтримку досить забезпечити на обох кінцях з'єднання; проміжні мережні вузли можуть узагалі нічого «не знати» про IPSec.
2.2 Небезпеки на кожнім кроці
На практиці IP-мережі уразливі для декількох способів несанкціонованого вторгнення в процес обміну даними. В міру розвитку комп'ютерних і мережних технологій (наприклад, з появою мобільних Java-додатків і елементів Active) список можливих типів мережних атак на IP-мережі постійно розширюється. На сьогоднішній день найбільш розповсюдженими є наступні варіанти:
- підміна IP-адреси відправника іншою адресою (IP spoofing);
- перехоплення сеансу (session hijacking), для чого по закінченні початкової процедури аутентификации встановлене з'єднання, скажемо, з поштовим сервером переключається на новий хост-компьютер, а вихідному серверові видається команда розірвати з'єднання. У результаті ваш «співрозмовник» виявляється непомітно підміненим;
- перехоплення пароля, переданого по мережі в незашифрованій формі, шляхом «прослуховування» каналу (password sniffing);
- посередництво в обміні незашифрованими ключами (man-in-the-middle). Якщо атаки трьох попередніх типів увінчалися успіхом, їхній автор може втрутитися в процес передачі ключів між сторонами і підсунути їм власний ключ для подальшого використання.
Неважко побачити, що перераховані мережні атаки можливі в силу ряду причин. По-перше, аутентификация відправника здійснюється винятково по його IP-адресі. По-друге, процедура аутентификации виконується тільки на стадії встановлення з'єднання, а надалі дійсність прийнятих пакетів не перевіряється. Нарешті, найважливіші дані, що мають відношення до системи захисту, передаються по мережі в незашифрованому виді.
Усунути ці слабкі місця і покликані процедури, регламентовані протоколами IPSec.
3. Діючі особи й елементи архітектури
Користувач сприймає мережу як надійно захищене середовище тільки в тому випадку, якщо він упевнений, що його «співрозмовник» — саме той, за кого він себе видає (аутентификация сторін), що передані пакети не проглядаються сторонніми особами (конфіденційність зв'язку) і що одержувані дані не піддалися зміні в процесі передачі (цілісність даних). Щоб досягти відповідності перерахованим критеріям, розроблювачі IPSec пропонують скористатися трьома інструментальними засобами захисту:
Протоколом аутентификации (Authentication Header, AH), що «прив'язує» дані в складі пакета до своєрідного підпису, що дозволяє упевнитися як у дійсності відправника, так і в цілісності прийнятих від нього даних;
Протоколом Encapsulated Security Payload (ESP), що відповідає за шифрування вмісту окремих пакетів (і навіть деяких IP-адрес, переданих у їхньому складі);
Протоколами обміну ключами (Internet Key Exchange, IKE), що призначені для узгодження використовуваних алгоритмів аутентификации і шифрування, ключів і тривалості їхньої дії, а також для захищеного обміну ключами.
Програмне забезпечення перерахованих протоколів (утиліти шифрування, цифрового підпису й ін.) може функціонувати на серверах або комп'ютерах кінцевих користувачів. Однак частіше його встановлюють на маршрутизаторах або спеціальних пристроях — брандмауерах, що в архітектурі IPSec іменуються шлюзами безпеки (security gateway). Відповідно до цього розрізняють два режими використання протоколів IPSec — транспортний і тунельний. У транспортному режимі зашифровані дані транспортуються безпосередньо між хост-компьютерами, але захист поширюється тільки на пакети четвертого і вышележащих рівнів.
У тунельному режимі ситуація виглядає трохи складніше. Основна роль тут приділяється шлюзам безпеки, оскільки передбачається, що клієнтські станції (або сервери) не підтримують IPSec і відправляють у мережу звичайний IP-трафик. Однак перед тим як досягти каналів глобальної мережі, кожен IP-пакет спочатку попадає в шлюз, що поміщає цей пакет цілком у «оболонку» IPSec, зашифровуючи його вміст разом з вихідним IP-заголовком. Щоб забезпечити можливість маршрутизації пакета, що вийшов, шлюз постачає його новим IP-заголовком і тільки після цього відправляє в мережу. Шлюз, що знаходиться на протилежному кінці з'єднання, дешифрує пакет і передає його на оконечное пристрій у первісному виді. Описана процедура і називається туннелированием. Вона дозволяє поширити дію засобів захисту на мережний рівень моделі OSI, зокрема сховати щирі IP-адреси джерела й одержувача для зменшення ризику атак, заснованих на детальному аналізі трафика. Менш очевидна задача туннелирования — транспортування через загальнодоступну мережу некоректних IP-адрес, що у явному виді не були б нею сприйняті.
4. Архітектура IPSec
IP Security - це комплект протоколів, що стосуються питань шифрування, аутентифікації і забезпечення захисту при транспортуванні IP-пакетів; у його склад зараз входять майже 20 пропозицій|речень| за стандартами і 18 RFC.
Специфікація IP Security (відома сьогодні як IPsec) розробляється Рабочою групою IP Security Protocol IETF. Спочатку IPsec включав 3 не-залежних базових специфікації, опубліковані як RFC-документи "Архітектура безпеки IP", "Аутентіфіцирующий заголовок (AH)", "Інкапсуляція зашифрованих даних (ESP)" (RFC1825, 1826 і 1827). Необхідно відмітити|помітити|, що в листопаді 1998 року Робоча група IP Security Protocol запропонувала нові версії цих специфікацій, що мають в даний час|нині| статус попередніх стандартів, це RFC2401 - RFC2412. Відзначимо, що RFC1825-27 впродовж|упродовж| вже декількох років вважаються|лічаться| застарілими і реально не використовуються. Окрім|крім| цього, існують декілька алгоритмо-залежних специфікацій, що використовують протоколи MD5, SHA, DES.
Мал. 1 – Архітектура IPSec.
Робоча група IP Security Protocol розробляє також і протоколи управління ключовою|джерельною| інформацією. У завдання|задачу| цієї групи входить розробка Internet Key Management Protocol (IKMP), протоколу управління ключами|джерелами| прикладного рівня, не залежного від використовуваних протоколів забезпечення безпеки. В даний час|нині| розглядаються|розглядуються| концепції управління ключами|джерелами| з використанням специфікації Internet Security Association and Key Management Protocol (ISAKMP) і протоколу Oakley Key Determination Protocol. Специфікація ISAKMP описує механізми узгодження атрибутів використовуваних протоколів, тоді як протокол Oakley дозволяє встановлювати сесійні ключі|джерела| на комп'ютери мережі|сіті| Інтернет. Раніше озглядалися розглядувалися також можливості|спроможності| використання механізмів управління ключами|джерелами| протоколу SKIP, проте|однак| зараз такі можливості|спроможності| реально практично ніде не використовуються. Створювані стандарти управління ключовою|джерельною| інформацією, можливо, підтримуватимуть Центри розподілу ключів|джерел|, аналогічні використовуваним в системі Kerberos. Протоколами ключового|джерельного| управління для IPSec на основі Kerberos зараз займається відносно нова робоча група KINK (Kerberized Internet Negotiation of Keys).
Гарантії цілісності і конфіденційності даних в специфікації IPsec забезпечуються за рахунок використання механізмів аутентифікації і шифрування відповідно. Останні, у свою чергу|своєю чергою|, засновані на попередньому узгодженні сторонами інформаційного обміну т.з. "контексту безпеки" – вживаних криптографічних алгоритмів, алгоритмів управління ключовою|джерельною| інформацією і їх параметрів. Специфікація IPsec передбачає можливість|спроможність| підтримки сторонами інформаційного обміну різних протоколів і параметрів аутентифікації і шифрування пакетів даних, а також різних схем розподілу ключів|джерел|. При цьому результатом узгодження контексту безпеки є|з'являється,являється| встановлення індексу параметрів безпеки (SPI), що є покажчиком на певний елемент внутрішньої структури сторони інформаційного обміну, безпеки, що описує можливі набори параметрів.
По суті, IPSec, який стане складовою частиною IPv6, працює на третьому рівні, тобто на мережевому|мережному| рівні. В результаті передавані IP-пакети будуть захищені прозорим для мережевих|мережних| додатків|застосувань| і інфраструктури чином|зображенням|. На відміну від SSL (Secure Socket Layer), який працює на четвертому (тобто транспортному) рівні і тісніше пов'язаний з вищими рівнями моделі OSI, IPSec покликаний забезпечити низькорівневий захист.
Мал. 2 – Модель OSI/ISO.
До IP-даних, готових до передачі по віртуальній приватній мережі|сіті|, IPSec додає|добавляє| заголовок для ідентифікації захищених пакетів. Перед передачею по Internet ці пакети інкапсулюються в інші IP-пакети. IPSec підтримує декілька типів шифрування, зокрема Data Encryption Standard (DES) і Message Digest 5 (MD5).
Щоб встановити захищене з'єднання|сполучення,сполуку|, обидва учасники сеансу повинні мати можливість|спроможність| швидко погоджувати|узгоджувати| параметри захисту, такі як алгоритми аутентифікації і ключі|джерела|. IPSec підтримує два типу схем управління ключами|джерелами|, за допомогою яких учасники можуть погоджувати|узгоджувати| параметри сеансу. Ця подвійна підтримка свого часу|у свій час| викликала|спричинила| певні тертя в IETF Working Group.
З|із| поточною версією IP IPv4, можуть бути використані або Internet Secure Association Key Management Protocol (ISAKMP), або Simple Key Management for Internet Protocol. З|із| новою версією IP IPv6, доведеться|припаде| використовувати ISAKMP, відомий зараз як IKE, хоча не виключається можливість|спроможність| використання SKIP. Проте|однак|, слід мати на увазі, що SKIP вже давно не розглядається|розглядується| як кандидат управління ключами|джерелами|, і був виключений із|із| списку можливих кандидатів ще в 1997 р.
5. Заголовок AH
Аутентичний заголовок (AH) є|з'являється,являється| звичайним|звичним| опціональним| заголовком і, як правило, розташовується між основним заголовком пакету IP і полем даних. Наявність AH ніяк не впливає на процес передачі інформації транспортного і вищого рівнів. Основним і єдиним призначенням AH є|з'являється,являється| забезпечення захисту від атак, пов'язаних з несанкціонованою зміною вмісту пакету, і зокрема від підміни початкової|вихідної| адреси мережевого|мережного| рівня. Протоколи вищого рівня повинні бути модифіковані в цілях здійснення перевірки автентичності|аутентичності| одержаних|отриманих| даних.
Формат AH достатньо|досить| простий і складається з 96-бітового заголовка і даних змінної довжини, що складаються з 32-бітових слів. Назви полів достатньо|досить| ясно відображають|відбивають| їх вміст: Next Header указує|вказує| на наступний|такий| заголовок, Payload Len представляє|уявляє| довжину пакету, SPI є|з'являється,являється| покажчиком на контекст безпеки і Sequence Number Field містить|утримує| послідовний номер пакету.
Мал. 3 – Формат заголовка AH.
Послідовний номер пакету був введений|запроваджений| в AH в 1997 році в ході процесу перегляду специфікації IPsec. Значення цього поля формується відправником і служить для захисту від атак, пов'язаних з повторним використанням даних процесу аутентифікації. Оскільки мережа|сіть| Інтернет не гарантує порядок|лад| доставки пакетів, одержувач повинен зберігати інформацію про максимальний послідовний номер пакету, що пройшов|минув,сплив| успішну аутентифікацію, і про отримання|здобуття| деякого числа пакетів, що містять|утримують| попередні послідовні номери (звичайно це число рівне 64).
На відміну від алгоритмів обчислення|підрахунку| контрольної суми, вживаних в протоколах передачі інформації по комутованих лініях зв'язку або по каналах локальних мереж|сітей| і орієнтованих на виправлення випадкових помилок середовища|середи| передачі, механізми забезпечення цілісності даних у відкритих|відчинених| телекомунікаційних мережах|сітях| повинні мати засоби|кошти| захисту від внесення цілеспрямованих змін. Одним з таких механізмів є|з'являється,являється| спеціальне застосування|вживання| алгоритму MD5: в процесі формування AH послідовно обчислюється|обчисляється,вичисляє| хэш-функція від об'єднання самого пакету і деякого заздалегідь узгодженого|погодженого| ключа|джерела|, а потім від об'єднання отриманого результату і перетвореного ключа|джерела|. Даний механізм застосовується за умовчанням в цілях забезпечення всіх реалізацій IPv6, принаймні, одним загальним|спільним| алгоритмом, не схильним|підвладним| експортним обмеженням.
Можливості AH у плані аутентификации відрізняються від таких для протоколу ESP насамперед тим, що останній не забезпечує захист зовнішнього IP-заголовка, що передує заголовкові ESP. Утім, і протокол AH захищає цей заголовок не цілком, оскільки частина його полів змінюється в процесі пересування пакета по мережі і такі зміни відправник не може пророчити заздалегідь.
Інформація, що додається в пакет протоколом AH, міститься після IP-заголовка, але перед заголовком ESP (якщо такий є присутнім) і заголовками протоколів вышележащих рівнів типу TCP. У пакетах IPv6 вона розташовується за додатковими заголовками (extension headers), що не були передбачені в четвертій версії IP і використовуються при маршрутизації і фрагментації пакетів.
Заголовок AH містить у собі п'ять полів (мал. 2):
наступний заголовок — поле, що вказує той протокол (наприклад, ESP або TCP), чий заголовок випливає за AH;
довжина заголовка — восьмиразрядное поле зі значенням, рівним довжині заголовка AH у четырехбайтных словах мінус два слова (для сумісності з більш ранньою специфікацією AH);
зарезервоване поле, встановлюване в нульове значення;
індекс параметра захисту (SPI). Це і наступне поле цілком аналогічні однойменним полям у заголовку ESP;
дані аутентификации — поле, що містить цифровий підпис ICV і, можливо, заповнювач для вирівнювання довжини заголовка до цілого значення, кратного 32 (IPv4) або 64 (IPv6) биткам.
Подібно ESP, протокол AH може застосовуватися для туннелирования пакетів.
З метою досягнення базової сумісності різних реалізацій процедур аутентификации стандартом IPSec передбачене використання в рамках AH тих же схем цифрового підпису і хеширования, що й у протоколі ESP.
6. Заголовок ESP
У разі|в разі| використання інкапсуляції зашифрованих даних заголовок ESP є|з'являється,являється| останнім у ряді|серед| опціональних| заголовків, "видимих" в пакеті. Оскільки основною метою|ціллю| ESP є|з'являється,являється| забезпечення конфіденційності даних, різні види інформації можуть вимагати застосування|вживання| істотно|суттєво| різних алгоритмів шифрування. Отже, формат ESP може зазнавати значні зміни залежно від використовуваних криптографічних алгоритмів. Проте|тим не менше|, можна виділити наступні|слідуючі| обов'язкові поля: SPI, вказуюче|показуюче| на контекст безпеки і Sequence Number Field, що містить|утримує| послідовний номер пакету. Поле "ESP Authentication Data" (контрольна сума), не є|з'являється,являється| обов'язковим в заголовку ESP. Одержувач пакету ESP розшифровує ESP заголовок і використовує параметри і дані вживаного алгоритму шифрування для декодування інформації транспортного рівня.
Мал. 4 – Формат заголовка ESP.
Розрізняють два режими застосування|вживання| ESP і AH (а також їх комбінації) - транспортний і тунельний.
6.1 Транспортний режим
Транспортний режим використовується для шифрування поля даних IP пакету, що містить|утримує| протоколи транспортного рівня (TCP, UDP, ICMP), яке, у свою чергу|своєю чергою|, містить|утримує| інформацію прикладних служб. Прикладом|зразком| застосування|вживання| транспортного режиму є|з'являється,являється| передача електронної пошти. Всі проміжні вузли на маршруті пакету від відправника до одержувача використовують тільки|лише| відкриту|відчинену| інформацію мережевого|мережного| рівня і, можливо, деякі опциональные| заголовки пакету (у IPv6). Недоліком|нестачею| транспортного режиму є|з'являється,являється| відсутність механізмів утаєння|приховання| конкретних відправника і одержувача пакету, а також можливість|спроможність| проведення аналізу трафіку. Результатом такого аналізу може стати інформація про об'єми|обсяги| і напрями|направлення| передачі інформації, області інтересів а бонентів, розташування керівників.
6.2 Тунельний режим
Тунельний режим припускає|передбачає| шифрування всього пакету, включаючи заголовок мережевого|мережного| рівня. Тунельний режим застосовується у разі потреби утаєння|приховання| інформаційного обміну організації із|із| зовнішнім світом. При цьому, адресні поля заголовка мережевого|мережного| рівня пакету, що використовує тунельний режим, заповнюються міжмережевим екраном організації і не містять|утримують| інформації про конкретного відправника пакету. При передачі інформації із|із| зовнішнього світу в локальну мережу|сіть| організації як адреса призначення використовується мережева|мережна| адреса міжмережевого екрану. Після|потім| розшифровки міжмережевим екраном початкового заголовка мережевого|мережного| рівня пакет прямує одержувачу.
7. Шифрування.
Протокол ESP допускає застосування практично будь-якого симетричного алгоритму для шифрування окремих пакетів. Більш того, в одному додатку можна використовувати різні методи шифрування в різних з'єднаннях. Разом з тим для спеціальних цілей, наприклад обміну ключами, призначеними для наступного шифрування переданих пакетів, служать асиметричні алгоритми. За замовчуванням як алгоритм шифрування стандартом передбачений симетричний метод DES-CBC (Cipher Block Chaining) з 56-розрядним ключем.
Заголовок ESP міститься в переданий пакет між заголовками протоколів четвертого (наприклад, TCP) і третього (IP) рівнів (мал. 1,а). Пакет рівня ESP включає шість полів (мал. 1,б), з яких зашифровуються тільки чотири останніх:
індекс параметра захисту (Security Parameter Index, SPI) — 32-розрядне число, що повідомляє одержувача про те, яку групу протоколів і алгоритмів захисту використовує відправник;
номер у послідовності — лічильник кількості відправлених пакетів з даним SPI; забезпечує захист від ретрансляційних атак (коли хакер посилає копію пакета з порушенням порядку проходження);
власне дані;
заповнювач — поле перемінного розміру (0—255 байт), що маскує щиру довжину переданих даних;
довжина попереднього поля;
новий заголовок — поле, аналогічне полю Next у заголовку IP-пакета й указывающее тип переданих даних і використовуваний протокол. У випадку застосування протоколу IPv6 у цьому місці можуть розташовуватися деякі додаткові поля заголовка.
Помітимо, що полючи протоколу ESP випливають після стандартного IP-заголовка, а це означає, що такий пакет може маршрутизироваться в мережі за допомогою звичайного устаткування, що підтримує IP.
7.1 Тунелювання.
Цей тип сервісу VPN також забезпечується засобами ESP. Туннелирование полягає в приміщенні первісного IP-пакета усередину пакета ESP і в наступному додаванні нового IP-заголовка, що містить адресу шлюзу.
7.2 Аутентификация.
Функціями шифрування і туннелирования призначення протоколу ESP не обмежується. Поле аутентификации, що може бути присутнім у його заголовку, містить параметр перевірки цілісності пакета (Integrity Check Value, ICV), що дозволяє реалізувати симетричну схему аутентификации. По суті, він являє собою цифровий підпис, що поміщається в поле аутентификации і позволяющую відправникові підписати результат попереднього хеширования змістовної частини пакета ESP (якщо відправник не хеширует її самостійно). Аналіз умісту цього полючи дає можливість одержувачеві ідентифікувати джерело даних і переконатися в тім, що вони не були змінені в процесі передачі.
У поточній версії стандарту IPSec у якості обов'язкової симетричної схеми використання цифрового підпису обрана HMAC і функції хеширования SHA-1 і MD5 із застосуванням ключів.
Якщо для протоколу ESP функції аутентификации є факультативними, то основна діюча особа в цій області — протокол AH. У IP-мережі він може використовуватися самостійно, разом з ESP або у виді «вкладеного» сервісу (за умови вибору режиму туннелирования).
8. Security Associations
Security Association (SA) – це з'єднання|сполучення,сполука|, яке надає служби забезпечення безпеки трафіку, який передається через нього. Два комп'ютери на кожній стороні SA зберігають режим, протокол, алгоритми і ключі|джерела|, використовувані в SA. Кожен SA використовується тільки|лише| в одному напрямі|направленні|. Для двонаправленого зв'язку потрібно два SA. Кожен SA реалізує один режим і протокол; таким чином, якщо для одного пакету необхідно використовувати два протоколи (як наприклад AH і ESP), то потрібно два SA.
9. Політика безпеки
Політика безпеки зберігається в SPD (База даних політики безпеки). SPD може вказати для пакету даних одна з трьох дій: відкинути пакет, не обробляти пакет за допомогою IPSec, обробити пакет за допомогою IPSec. У останньому випадку SPD також указує|вказує|, якої SA необхідно використовувати (якщо, звичайно, відповідний|придатний| SA вже був створений) або указує|вказує|, з|із| якими параметрами повинен бути створений новий SA.
SPD є|з'являється,являється| дуже гнучким механізмом управління, який допускає дуже хороше|добре| управління обробкою кожного пакету. Пакети класифікуються по великому числу полів, і SPD може перевіряти деякі або всі поля для того, щоб визначити відповідну дію. Це може привести до того, що весь трафік між двома машинами передаватиметься за допомогою одного SA, або окреміS використовуватимуться для кожного додатку застосування, або навіть для кожногоTCP з'єднання сполучення,сполуки.
10. Узгодження протоколів і керування ключами
Протоколи ESP і AH дозволяють зробити реальністю найважливіші атрибути захищеної передачі — конфіденційність зв'язку, аутентификацию сторін і цілісність даних. Тим часом очевидно, що їхньої функції утратять усяку цінність під час відсутності могутньої підтримуючої інфраструктури, що забезпечувала б розподіл ключів і узгодження протоколів між учасниками обміну.
Роль такої інфраструктури в IPSec виконує група протоколів Internet Key Exchange (IKE). Це назва в 1998 р. прийшло на зміну більш ранньому — ISAKMP/Oakley, що безпосередньо вказувало на походження засобів керування ключами в складі IPSec. Протокол Internet Security Association and Key Management Protocol (ISAKMP), описаний у документі RFC 2408, був розроблений у 1997 р. у Керуванні національної безпеки США. Він дозволяє погодити алгоритми і математичні структури (так називані мультиплікативні групи, визначені на кінцевому полі) для процедури обміну ключами Диффи — Хеллмана (див. нижче), а також процесів аутентификации. Протокол Oakley (RFC 2412) був запропонований у тому ж році співробітниками Університету штату Аризона і служить для безпосереднього обміну ключами.
Протоколи IKE вирішують три задачі: погоджують алгоритми шифрування і характеристики ключів, що будуть використовуватися в захищеному сеансі; забезпечують безпосередній обмін ключами (у тому числі можливість їхньої частої зміни); нарешті, контролюють виконання всіх досягнутих угод.
Історично розроблювачі IPSec почали свою діяльність з рішення останньої задачі. У результаті на світло з'явилася концепція виділених захищених віртуальних «каналів» (або «з'єднань») і відповідних їм структур даних, в англійській мові получивших назва, що не цілком адекватне, Security Association (SA). Саме в рамках SA визначаються алгоритм аутентификации протоколу AH і його ключі, алгоритм шифрування, використовуваний протоколом ESP, і його ключі, наявність або відсутність криптографічної синхронізації, способи аутентификации партнерів і захисти сеансу обміну, частота зміни ключів і ряд інших параметрів. Об'єднання настільки великої службової інформації в рамках SA надає користувачеві можливість сформувати різні класи захисту, призначені, наприклад, для електронного спілкування з різними «співрозмовниками». Іншими словами, застосування структур SA відкриває шлях до побудови безлічі віртуальних приватних мереж, що розрізняються своїми параметрами.
«Канал» SA цілком визначається трьома величинами: уже згадуваним 32-розрядним індексом SPI, IP-адресою вузла призначення й ідентифікатором протоколу захисту (AH або ESP). Вузол-одержувач вибирає значення індексу SPI з числа не використовуваних у даний момент (і бажано що не фігурували раніше) і повідомляє його відправникові. Якщо той погоджується на запропоноване значення індексу, даний SPI стає ідентифікатором «каналу» SA між двома сторонами і саме по ньому надалі будуть вибиратися службові дані, необхідні для захисту інформаційного обміну між учасниками сеансу.
З метою роботи з параметрами SA на кожній стороні створюється база даних таких «каналів» (Security Association Database). Кожному погодженому «каналові» у ній відповідає окремий запис.
Що стосується способів використання протоколів IPSec окремими додатками, то вони визначаються в записах бази даних, що містить набори правил, або стратегії, інформаційної безпеки (Security Policy Database). Така БД формується і підтримується на кожнім вузлі, де встановлене програмне забезпечення IPSec. Вибираючи той або інший запис з цієї БД, додаток визначає спосіб захисту генерируемых IP-пакетів, що потім реалізується в рамках погодженого «каналу» SA.
11. Генерація ключів.
Використання ключів спрямоване на зменшення ризику перехоплення переданих даних. Зрозуміло, що операція обміну зашифрованими ключами, що передує обмінові власне даними, також може стати об'єктом мережної атаки. Імовірність перехоплення і, головне, успішної розшифровки ключів, мабуть, падає з ростом їхньої довжини. У той же час надмірне збільшення розміру ключів здатно негативно позначитися на загальній продуктивності процедур обміну.
Компромісне рішення могло б складатися в частій зміні ключів, що мають помірну довжину. Однак тут виникає ще одна проблема. Необхідно, щоб знову сгенерированный ключ був сприйнятий іншою стороною, тоді як його генерація ніяк не повинна базуватися на попередніх ключах або на тих числових масивах, по яких вони генерувалися. Обійти ці труднощі допомагає комбінаційний алгоритм Диффи — Хеллмана (Diffie-Hellman), узятий на озброєння творцями IPSec.
Процедура обміну ключами виглядає в такий спосіб. Сторони направляють один одному запису cookies, що надалі дозволяють запобігти атаці типу перевантаження ресурсів (коли атакує намагається створити надлишкове навантаження на обчислювальні ресурси своєї жертви, наприклад ініціюючи відразу кілька сеансів обміну ключами по алгоритму Диффи — Хеллмана). Потім кожна зі сторін незалежно від іншої випадковим образом генерує пари значень, що є аналогами відкритого і секретного ключів. Сгенерированные відкриті ключі сторони передають один одному через мережу, після чого кожна сторона комбінує прийнятий відкритий ключ із власним секретним, використовуючи алгоритм Диффи — Хеллмана. Не вдаючись у математичні деталі, відзначимо, що основна ізюминка даного алгоритму полягає в тому, що в результаті зазначеної процедури обидві сторони одержать той самий комбінований ключ. Іншими словами, цей алгоритм дає можливість перейти від традиційних асиметричних процедур шифрування на основі пари ключів до симетричної схеми з застосуванням комбінованого ключа, що характеризується більшою продуктивністю. Комбінований ключ можна використовувати при наступних обмінах даними або для шифрування нових ключів, сгенерированных незалежно від попередніх.
11.1 Алгоритм Диффи — Хелмана, мабуть, має сенс застосовувати тільки в сполученні з процедурою аутентификации сторін з метою запобігти атаці типу посередництва при обміні незашифрованими ключами. Така аутентификация звичайно виробляється відразу після обміну відкритими ключами з використанням цифрових підписів.
Режими функціонування. Структура SA активно використовується протоколами IKE, що функціонують у два етапи. На першому обидва IKE-вузли (у їхній ролі виступають настільні комп'ютери, що підтримують IPSec або шлюзи безпеки) установлюють захищене «з'єднання» для процедури обміну (IKE SA). На другому етапі по цьому «каналі» здійснюється узгодження всіх параметрів, асоційованих із загальним «каналом» SA.
Перед тим як установити «канал» IKE SA, що ініціює сторона повинна запропонувати для узгодження шість пунктів: алгоритми шифрування, алгоритми хеширования, метод аутентификации, інформацію про групу вузлів, на которые буде поширюватися алгоритм Диффи — Хеллмана, псевдослучайную функцію, за допомогою якої має бути хешировать величини, використовувані при обміні ключами (утім, допускається безпосереднє використання алгоритму хеширования), і тип протоколу захисту (ESP або AH).
Схемою Oakley передбачені три режими обміну інформацією про алгоритми і параметри захисту і встановлення «каналу» SA. Два з них (основної й агресивний) відносяться до першої фази функціонування протоколів IKE і один (швидкий) — до другого.
Основний режим (Main mode) реалізує стандартний механізм установлення «каналу» IKE SA. Він містить у собі три процедури двунаправленного обміну (мал. 3,а). Спочатку сторони домовляються про базові алгоритми і використовувані методи хеширования. Потім здійснюється обмін відкритими ключами в рамках алгоритму Диффи — Хеллмана і випадковими числами (nonce), що підписуються приймаючими сторонами і відправляються назад для ідентифікації. Нарешті, у ході третього обміну по пришедшим назад підписаних значеннях nonce перевіряється дійсність сторін.
Відкритий ключ, отриманий за схемою Диффи — Хеллмана, кожної зі сторін хешируется тричі — для генерації першого комбінованого ключа, ключа аутентификации і ключа шифрування, використовуваного в IKE SA.
Агресивний режим (Aggressive mode) призначений для тій же цілей, що й основний, однак він простіше в реалізації й одночасно продуктивніше. Плата за ці переваги полягає в тім, що агресивний режим не забезпечує захист інформації, що служить для ідентифікації сторін, оскільки така інформація передається по мережі до узгодження параметрів захищеного «каналу» SA, тобто в незашифрованому виді.Даний режим вимагає тільки двох операцій обміну, а кількість переданих по мережі пакетів удається зменшити із шести до трьох (мал. 3,б). Ініціатор обміну намагається включити в перший же пакет максимум необхідної від нього інформації: пропонований ідентифікатор SA, відкритий ключ алгоритму Диффи — Хеллмана, значення nonce для підпису іншою стороною і навіть пакет із власним ідентифікатором, що дозволяє протилежній стороні «пізнати» свого співрозмовника. Одержувач у відповідь також відправляє всі ті параметри, що необхідні для завершення першої фази IKE і в основному режимі розбилися б по трьох пакетах. У результаті ініціаторові залишається тільки відправити повідомлення про те, що обмін успішно зроблений.
Швидкий режим (Quick mode) забезпечує узгодження параметрів основного «каналу» SA і генерацію нових ключів. Оскільки у швидкому режимі всі передачі здійснюються по захищеному тунельному з'єднанню, у реалізації він
|