У світі різні VPN-технології використовуються повсюдно. Деякі (наприклад, PPTP) з часом визнаються небезпечними та поступово відмирають, інші (OpenVPN), навпаки, з кожним роком нарощують оберти. Але беззмінним лідером і найвідомішою технологією для створення та підтримки захищених приватних каналів, як і раніше, залишається IPsec VPN. Іноді при пентесті можна виявити серйозно захищену мережу з п'ятисотим UDP-портом, що стирчить назовні. Все інше може бути закрите, пропатчене та надійно фільтруватися. У такій ситуації може виникнути думка, що тут і робити особливо нічого. Але це завжди так. Крім того, поширена думка, що IPsec навіть у дефолтних конфігураціях неприступний і забезпечує належний рівень безпеки. Саме таку ситуацію сьогодні й подивимось на ділі. Але спочатку, щоб максимально ефективно боротися з IPsec, потрібно розібратися, що він є і як працює. Цим і займемося!

IPsec зсередини

Перед тим як переходити безпосередньо до самого IPsec, непогано згадати, які взагалі бувають типи VPN. Класифікацій VPN безліч, але ми не будемо глибоко занурюватися в мережеві технології і візьмемо найпростішу. Тому ділитимемо VPN на два основні типи - site-to-site VPN-підключення (їх ще можна назвати постійні) та remote access VPN (RA, вони ж тимчасові).
Перший тип служить для постійного зв'язку різних мережевих острівців, наприклад, центрального офісу з безліччю розкиданих філій. Ну а RA VPN є сценарієм, коли клієнт підключається на невеликий проміжок часу, отримує доступ до певних мережевих ресурсів і після завершення роботи благополучно відключається.

Нас буде цікавити саме другий варіант, тому що у разі успішної атаки вдається одразу отримати доступ до внутрішньої мережі підприємства, що для пентестера досить серйозне досягнення. IPsec, своєю чергою, дозволяє реалізовувати як site-to-site, і remote access VPN. Що ж це за технологія та з яких компонентів вона складається?

Варто зазначити, що IPsec – це не один, а цілий набір різних протоколів, які забезпечують прозорий та безпечний захист даних. Специфіка IPsec полягає в тому, що він реалізується на мережному рівні, доповнюючи його таким чином, щоб для наступних рівнів все відбувалося непомітно. Основна складність у тому, що у процесі встановлення з'єднання двом учасникам захищеного каналу необхідно узгодити досить багато різних параметрів. А саме - вони повинні аутентифікувати один одного, згенерувати та обмінятися ключами (причому через недовірене середовище), а також домовитися за допомогою яких протоколів шифрувати дані.

Саме з цієї причини IPsec і складається зі стеку протоколів, обов'язок яких полягає в тому, щоб забезпечити встановлення захищеного з'єднання, його роботу та управління ним. Весь процес встановлення з'єднання включає дві фази: перша фаза застосовується для забезпечення безпечного обміну ISAKMP-повідомлень вже в другій фазі. ISAKMP (Internet Security Association and Key Management Protocol) – це протокол, який слугує для узгодження та оновлення політик безпеки (SA) між учасниками VPN-з'єднання. У цих політиках і зазначено, за допомогою якого протоколу шифрувати (AES або 3DES) і за допомогою чого аутентифікувати (SHA або MD5).

Дві основні фази IPsec

Отже, ми з'ясували, що спочатку учасникам потрібно домовитися, за допомогою яких механізмів буде створено захищене з'єднання, тому тепер вступає у справу протокол IKE. IKE (Internet Key Exchange) використовується для формування IPsec SA (Security Association, самі політики безпеки), простіше кажучи - узгодження роботи учасників захищеного з'єднання. Через цей протокол учасники домовляються, який алгоритм шифрування буде застосований, за яким алгоритмом проводитиметься перевірка цілісності та як аутентифікувати один одного. Потрібно зауважити, що на сьогоднішній день існує дві версії протоколу: IKEv1 та IKEv2. Нас цікавитиме лише IKEv1: незважаючи на те, що IETF (The Internet Engineering Task Force) вперше представили його в 1998 році, він, як і раніше, ще дуже часто використовується, особливо для RA VPN (див. рис. 1).

Що стосується IKEv2, перші його начерки були зроблені в 2005 році, повністю описаний він був у RFC 5996 (2010 рік), і лише наприкінці минулого року він був оголошений на роль стандарту Інтернет (RFC 7296). Більш докладно про різницю між IKEv1 і IKEv2 можна прочитати у врізанні. Розібравшись із IKE, повертаємося до фаз IPsec. У процесі першої фази учасники аутентифікують один одного і домовляються про параметри встановлення спеціального з'єднання, призначеного тільки для обміну інформацією про бажані алгоритми шифрування та інші деталі майбутнього IPsec-тунелю. Параметри першого тунелю (який ще називається ISAKMP-тунель) визначаються політикою ISAKMP. Насамперед узгоджуються хеші та алгоритми шифрування, далі йде обмін ключами Діффі – Хеллмана (DH), і лише потім відбувається з'ясування, хто є хто. Тобто в останню чергу йде процес аутентифікації, або PSK-, або по RSA-ключу. І якщо сторони дійшли згоди, то встановлюється ISAKMP-тунель, яким вже проходить друга фаза IKE.

На другій фазі учасники, що вже довіряють один одному, домовляються про те, як будувати основний тунель для передачі безпосередньо даних. Вони пропонують один одному варіанти, зазначені в параметрі transform-set, і, якщо дійдуть згоди, піднімають основний тунель. Важливо підкреслити, що після встановлення допоміжний ISAKMP-тунель нікуди не подіється - він використовується для періодичного оновлення SA основного тунелю. У результаті IPsec певною мірою встановлює не один, а цілих два тунелі.

Як обробляти дані

Тепер кілька слів про transform-set. Адже треба якось шифрувати дані, що йдуть через тунель. Тому в типовій конфігурації transform-set є набором параметрів, в яких явно вказано, як потрібно обробляти пакет. Відповідно, існує два варіанти такої обробки даних – це протоколи ESP та AH. ESP (Encapsulating Security Payload) безпосередньо займається шифруванням даних, а також може забезпечувати перевірку цілісності даних. AH (Authentication Header), у свою чергу, відповідає лише за автентифікацію джерела та перевірку цілісності даних.

Наприклад, команда crypto ipsec transform-set SET10 esp-aes вкаже роутеру, що transform-set з ім'ям SET10 повинен працювати тільки за протоколом ESP і шифруванням за алгоритмом AES. Забігаючи вперед, скажу, що тут і далі ми будемо використовувати як мету маршрутизатори та файрволи компанії Cisco. Власне з ESP все більш-менш зрозуміло, його справа – шифрувати і цим забезпечувати конфіденційність, але навіщо тоді потрібен AH? AH забезпечує аутентифікацію даних, тобто підтверджує, що ці дані прийшли саме від того, з ким ми встановили зв'язок і не були змінені дорогою. Він забезпечує те, що іноді називається anti-replay захистом. У сучасних мережах AH практично не використовується, скрізь можна зустріти лише ESP.

Параметри (вони ж SA), які вибираються для шифрування інформації в IPsec-тунелі, мають час життя, після якого повинні бути замінені. За замовчуванням параметр lifetime IPsec SA становить 86400 с, або 24 год.
У результаті учасники отримали шифрований тунель з параметрами, які їх влаштовують, і направляють туди потоки даних, що підлягають шифруванню. Періодично, відповідно до lifetime, оновлюються ключі шифрування для основного тунелю: учасники знову зв'язуються ISAKMP-тунелем, проходять другу фазу і заново встановлюють SA.

Режими IKEv1

Ми розглянули у першому наближенні основну механіку роботи IPsec, але необхідно загострити увагу ще кількох речах. Перша фаза, окрім іншого, може працювати у двох режимах: main mode або aggressive mode. Перший варіант ми вже розглянули вище, але нас цікавить якраз aggressive mode. У цьому режимі використовується три повідомлення (замість шести у main-режимі). При цьому той, хто ініціює з'єднання, віддає всі свої дані одночасно - що він хоче і що вміє, а також свою частину обміну DH. Потім сторона у відповідь відразу завершує свою частину генерації DH. У результаті в цьому режимі, по суті, лише два етапи. Тобто перші два етапи з main mode (узгодження хешей та обмін DH) як би спресовуються в один. В результаті цей режим значно небезпечніший з тієї причини, що у відповідь надходить багато технічної інформації в plaintext'і. І найголовніше – VPN-шлюз може надіслати хеш пароля, який використовується для аутентифікації на першій фазі (цей пароль ще часто називається pre-shared key або PSK).

Ну а все наступне шифрування відбувається без змін, як завжди. Чому тоді цей режим як і раніше використовується? Справа в тому, що він набагато швидший, приблизно вдвічі. Окремий інтерес для пентестера представляє той факт, що aggressive-режим дуже часто використовується в RA IPsec VPN. Ще одна невелика особливість RA IPsec VPN при використанні агресивного режиму: коли клієнт звертається до сервера, він надсилає йому ідентифікатор (ім'я групи). Tunnel group name (див. рис. 2) - це ім'я запису, що містить у собі набір політик для даного IPsec-підключення. Це вже одна з фіч, специфічних обладнання Cisco.

Двох фаз виявилося недостатньо

Здавалося б, що виходить і так не дуже проста схема роботи, але насправді все ще трохи складніше. Згодом стало зрозуміло, що лише одного PSK недостатньо для забезпечення безпеки. Наприклад, у разі компрометації робочої станції співробітника атакуючий зміг би одразу отримати доступ до всієї внутрішньої мережі підприємства. Тому була розроблена фаза 1.5 прямо між першою та другою класичними фазами. До речі, ця фаза зазвичай не використовується у стандартному site-to-site VPN-з'єднанні, а застосовується при організації віддалених VPN-підключень (наш випадок). Ця фаза містить два нових розширення - Extended Authentication (XAUTH) і Mode-Configuration (MODECFG).

XAUTH – це додаткова автентифікація користувачів у межах IKE-протоколу. Цю аутентифікацію ще іноді називають другим фактором IPsec. Ну а MODECFG служить для передачі додаткової інформації клієнту, це може бути IP-адреса, маска, DNS-сервер та інше. Видно, що ця фаза просто доповнює розглянуті раніше, але корисність її безсумнівна.

IKEv2 vs IKEv1

Обидва протоколи працюють за UDP-портом з номером 500, але між собою несумісні, не допускається ситуація, щоб на одному кінці тунелю був IKEv1, а на іншому - IKEv2. Ось основні відмінності другої версії від першої:

У IKEv2 більше немає таких понять, як aggressive або main-режими.
В IKEv2 термін перша фаза замінений на IKE_SA_INIT (обмін двома повідомленнями, що забезпечує узгодження протоколів шифрування/хешування та генерацію ключів DH), а друга фаза - на IKE_AUTH (теж два повідомлення, що реалізують власне автентифікацію).
Mode Config (те, що у IKEv1 називалося фаза 1.5) тепер описаний у специфікації протоколу і його невід'ємною частиною.
IKEv2 додав додатковий механізм захисту від DoS-атак. Суть його в тому, що перш, ніж відповідати на кожен запит у встановленні захищеного з'єднання (IKE_SA_INIT) IKEv2, VPN-шлюз шле джерелу такого запиту якийсь cookie і чекає на відповідь. Якщо джерело відповіло – все гаразд, можна починати з ним генерацію DH. Якщо джерело не відповідає (у випадку з DoS-атакою так і відбувається, ця техніка нагадує TCP SYN flood), то VPN-шлюз просто забуває про нього. Без цього механізму при кожному запиті від будь-кого VPN-шлюз би намагався згенерувати DH-ключ (що досить ресурсомісткий процес) і незабаром зіткнувся б з проблемами. У результаті за рахунок того, що всі операції тепер вимагають підтвердження від іншої сторони з'єднання, на пристрої, що атакується, не можна створити велику кількість напіввідкритих сесій.

Виходимо на кордон

Нарешті, розібравшись з особливостями роботи IPsec та його компонентів, можна переходити до головного - до практичних атак. Топологія буде досить простою і водночас наближеною до реальності (див. рис. 3).

Насамперед потрібно визначити наявність IPsec VPN шлюзу. Зробити це можна, провівши сканування портів, але є невелика особливість. ISAKMP використовує протокол UDP, порт 500, а тим часом дефолтне сканування за допомогою Nmap зачіпає лише порти TCP. І в результаті буде повідомлення: All 1000 scanned ports on 37.59.0.253 are filtered .

Складається враження, що всі порти фільтруються і відкритих портів немає. Але виконавши команду

Nmap -sU --top-ports=20 37.59.0.253 Starting Nmap 6.47 (http://nmap.org) at 2015-03-21 12:29 GMT . PORT STATE SERVICE 500/udp open isakmp

переконуємось у тому, що це не так і перед нами справді VPN-пристрій.

Атакуємо першу фазу

Тепер нас цікавитиме перша фаза, aggressive-режим та автентифікація з використанням pre-shared key (PSK). У цьому сценарії, як ми пам'ятаємо, VPN-пристрій або сторона, що відповідає, відправляє хешований PSK ініціатору. Одна з найвідоміших утиліт для тестування протоколу IKE – це ike-scan, вона входить до складу дистрибутива Kali Linux. Ike-scan дозволяє відправляти IKE повідомлення з різними параметрами і, відповідно, декодити і парсувати пакети у відповідь. Пробуємо промацати цільовий пристрій:

Root@kali:~# ike-scan -M -A 37.59.0.253 0 returned handshake; 0 returned notify

Ключ A вказує на те, що потрібно використовувати aggressive-режим, а M говорить про те, що результати слід виводити рядково (multiline), для більш зручного читання. Видно, що жодного результату не було отримано. Причина полягає в тому, що необхідно вказати цей ідентифікатор, ім'я VPN-групи. Зрозуміло, утиліта ike-scan дозволяє задавати цей ідентифікатор як один зі своїх параметрів. Але оскільки він нам невідомий, візьмемо довільне значення, наприклад 0000.

Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 37.59.0.253 Aggressive Mode Handshake returned

На цей раз бачимо, що відповідь була отримана (див. рис. 5) і нам було надано досить багато корисної інформації. Досить важлива частина отриманої інформації – це transform-set. У нашому випадку там зазначено, що "Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK".

Всі ці параметри можна вказувати й утиліти ike-scan за допомогою ключа --trans . Наприклад --trans=5,2,1,2 буде говорити про те, що алгоритм шифрування 3DES, хешування HMAC-SHA, метод автентифікації PSK та другий тип групи DH (1024-bit MODP). Подивитися таблиці відповідності значень можна за цією адресою. Додамо ще один ключ (-P), щоб вивести безпосередньо пейлоад пакета, а точніше хеш PSK.

Root@kali:~# ike-scan -M -A --id=0000 37.59.0.253 -P

Подолаємо перші складнощі

Здавалося б, хеш отримано і можна пробувати його лаяти, але все не так просто. Колись дуже давно, у 2005 році, на деяких залізцях Сisco була вразливість: ці пристрої віддавали хеш, лише якщо атакуючий передавав коректне значення ID. Зараз, природно, зустріти таке обладнання практично неможливо і хешоване значення надсилається завжди незалежно від того, правильне значення ID відправив атакуючий чи ні. Очевидно, що брутувати неправильний хеш безглуздо. Тому перше завдання - визначити коректне значення ID, щоб отримати правильний хеш. І в цьому нам допоможе нещодавно виявлена вразливість. Справа в тому, що існує невелика різниця між відповідями під час початкового обміну повідомленнями. Якщо коротко, то при використанні правильного імені групи відбувається чотири спроби продовжити встановлення VPN-з'єднання плюс два зашифровані пакети другої фази. У той час як у разі неправильного ID у відповідь прилітає лише два пакети. Як бачимо, різниця досить суттєва, тому компанія SpiderLabs (автор не менш цікавого інструменту Responder) розробила спочатку PoC, а потім утиліту IKEForce для експлуатації цієї вразливості.

У чому сила IKE

Встановити IKEForce у довільний каталог можна, виконавши команду

Git clone https://github.com/SpiderLabs/ikeforce

Працює вона у двох основних режимах - режимі обчислення -e (enumeration) та режимі брутфорсу -b (bruteforce). До другого ми ще дійдемо, коли дивитимемося атаки на другий фактор, а ось першим зараз і займемося. Перед тим, як розпочати безпосередньо процес визначення ID, необхідно встановити точне значення transform-set. Ми його вже визначили раніше, тому вказуватимемо опцією -t 5 2 1 2 . У результаті виглядатиме процес знаходження ID буде наступним чином:

Python ikeforce.py 37.59.0.253 -e -w wordlists/group.txt -t 5 2 1 2

Внаслідок цього досить швидко вдалося отримати коректне значення ID (рис. 7). Перший крок пройдено, можна рухатися далі.

Отримуємо PSK

Тепер необхідно, використовуючи правильне ім'я групи, зберегти PSK-хеш у файл, зробити це можна за допомогою ike-scan:

Ike-scan -M -A --id=vpn 37.59.0.253 -Pkey.psk

І тепер, коли правильне значення ID було підібрано і вдалося отримати коректний хеш PSK, ми можемо почати офлайн-брутфорс. Варіантів такого брутфорсу досить багато - це і класична утиліта psk-crack, і John the Ripper (з jumbo-патчем), і навіть oclHashcat, який, як відомо, дозволяє використовувати потужність GPU. Для простоти будемо використовувати psk-crack, який підтримує як прямий брутфорс, так і атаку за словником:

Psk-crack -d /usr/share/ike-scan/psk-crack-dictionary key.psk

Але навіть успішно відновити PSK (див. рис. 8) – це лише половина справи. На цьому етапі слід згадати про те, що далі на нас чекає XAUTH і другий фактор IPsec VPN.

Розправляємось з другим фактором IPsec

Отже, нагадаю, що XAUTH - це додатковий захист, другий фактор аутентифікації, і він знаходиться на фазі 1.5. Варіантів XAUTH може бути кілька - це і перевірка протоколу RADIUS, і одноразові паролі (OTP), і звичайна локальна база користувачів. Ми зупинимося на стандартній ситуації, коли для перевірки другого фактора використовується локальна база користувачів. Донедавна не існувало інструменту у публічному доступі для брутфорсу XAUTH. Але з появою IKEForce це завдання отримало гідне рішення. Запускається брутфорс XAUTH досить просто:

python ikeforce.py 37.59.0.253 -b -i vpn -k cisco123 -u admin -w wordlists/passwd.txt -t 5 2 1 2 [+] passwords for user: admin [*]XAUTH Authentication Successful! Username: admin Password: cisco

При цьому вказуються всі знайдені значення: ID (ключ -i), відновлений PSK (ключ -k) і передбачуваний логін (ключ -u). IKEForce підтримує як грубий перебір логіну, так і перебір списку логінів, який може бути заданий параметром -U . У разі можливих блокувань підбору є опція -s , що дозволяє знизити швидкість брутфорсу. До речі, у комплекті з утилітою йдуть кілька непоганих словників, особливо корисних для встановлення значення ID.

Входимо у внутрішню мережу

Тепер, коли ми маємо всі дані, залишається останній крок - власне проникнення в локальну мережу. Для цього нам знадобиться якийсь VPN-клієнт, яких безліч. Але у випадку Kali можна без проблем скористатися вже встановленим - VPNC. Щоб він запрацював, потрібно підкоригувати один конфігураційний файл - /etc/vpnc/vpn.conf . Якщо його немає, то потрібно створити та заповнити ряд очевидних параметрів:

IPSec gateway 37.59.0.253 IPSec ID vpn IPSec secret cisco123 IKE Authmode psk Xauth Username admin Xauth password cisco

Тут бачимо, що було використано абсолютно всі знайдені попередніх кроках дані - значення ID, PSK, логін і пароль другого чинника. Після цього саме підключення відбувається однією командою:

Root@kali:~# vpnc vpn

Відключення теж досить просте:

Root@kali:~# vpnc-disconnect

Перевірити працездатність підключення можна за допомогою команди ifconfig tun0 .

Як побудувати надійний захист

Захист від розглянутих сьогодні атак має бути комплексним: потрібно вчасно встановлювати патчі, використовувати стійкі pre-shared ключі, які по можливості мають бути замінені на цифрові сертифікати. Парольна політика та інші очевидні елементи ІБ також відіграють важливу роль у справі забезпечення безпеки. Не можна не відзначити і той факт, що ситуація поступово змінюється, і згодом залишиться лише IKEv2.

Що в результаті

Ми розглянули процес аудиту RA IPsec VPN у всіх подробицях. Так, безумовно, це завдання далеко не тривіальне. Потрібно зробити чимало кроків, і на кожному з них можуть чекати труднощі, зате у разі успіху результат більш ніж вражаючий. Отримання доступу до внутрішніх ресурсів мережі відкриває найширший простір подальших дій. Тому тим, хто відповідає за захист мережевого периметра, необхідно не розраховувати на готові дефолтні шаблони, а ретельно продумувати кожен безпековий шар. Ну, а для тих, хто проводить пентести, виявлений п'ятисотий порт UDP - це привід провести глибокий аналіз захищеності IPsec VPN і, можливо, отримати непогані результати.

0 У цій статті пропонується огляд засобів IPSEC (IP Security – система захисту на рівні IP) та відповідних протоколів IPSec, доступних у продуктах Cisco та використовуваних для створення віртуальних приватних мереж (VPN). У цій статті ми визначимо, що таке IPSEC, а також які протоколи та алгоритми захисту лежать в основі IPSEC.

Вступ

IP Security - це комплект протоколів, що стосуються питань шифрування, автентифікації та забезпечення захисту під час транспортування IP-пакетів; до його складу зараз входять майже 20 пропозицій щодо стандартів та 18 RFC.

Продукти Cisco для підтримки VPN використовують набір протоколів IPSec, що на сьогодні є промисловим стандартом забезпечення широких можливостей VPN. IPSec пропонує механізм захищеної передачі в IP-мережах, забезпечуючи конфіденційність, цілісність і достовірність даних, переданих через незахищені мережі типу Internet. IPSec забезпечує такі можливості VPN у мережах Cisco:

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

IPSec є заснований на стандартах набір протоколів і алгоритмів захисту. Технологія IPSec та пов'язані з нею протоколи захисту відповідають відкритим стандартам, які підтримуються групою IETF (Internet Engineering Task Force – проблемна група проектування Internet) та описані у специфікаціях RFC та проектах IETF. IPSec діє на мережному рівні, забезпечуючи захист та автентифікацію пакетів IP, що пересилаються між пристроями (сторонами) IPSec - такими як маршрутизатори Cisco, брандмауери PIX Firewall, клієнти та концентратори Cisco VPN, а також багато інших продуктів, що підтримують IPSec. Засоби підтримки IPSec допускають масштабування від найменших до великих мереж.

Асоціації захисту (Security Association, SA)

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

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

Два комп'ютери на кожній стороні SA зберігають режим, протокол, алгоритми та ключі, що використовуються SA. Кожен SA використовується лише в одному напрямку. Для двонаправленого зв'язку потрібно два SA. Кожен SA реалізує один режим та протокол; таким чином, якщо для одного пакета необхідно використовувати два протоколи (наприклад AH і ESP), то потрібно два SA.

Протокол IKE (Internet Key Exchange – обмін Internet-ключами) є гібридним протоколом, який забезпечує спеціальний сервіс для IPSec, а саме автентифікацію сторін IPSec, узгодження параметрів асоціацій захисту IKE та IPSec, а також вибір ключів для алгоритмів шифрування, що використовуються в рамках IPSec. Протокол IKE спирається на протоколи ISAKMP (Internet Security Association and Key Management Protocol – протокол управління асоціаціями та ключами захисту в мережі Internet) та Oakley, які застосовуються для управління процесом створення та обробки ключів шифрування, що використовуються у перетвореннях IPSec. Протокол IKE застосовується також формування асоціацій захисту між потенційними сторонами IPSec.
Як IKE, так і IPSec використовують асоціації захисту, щоб вказати параметри зв'язку.
IKE підтримує набір різних примітивних функцій для використання у протоколах. Серед них можна виділити хеш-функцію та псевдовипадкову функцію (PRF).

Хеш-функція- Це функція, стійка до колізій. Під стійкістю до колізій розуміється той факт, що неможливо знайти два різні повідомлення m1 і m2, такі, що

H(m1)=H(m2), де H – хеш функція.

Що стосується псеводвипадкових функцій, то зараз замість спеціальних PRF використовується хеш функція в конструкції HMAC (HMAC - механізм автентифікації повідомлень з використанням хеш функцій). Для визначення HMAC нам знадобиться криптографічна хеш функція (позначимо її як H) та секретний ключ K. Ми припускаємо, що H є хеш функцією, де дані хешуються за допомогою процедури стиснення, що послідовно застосовується до послідовності блоків даних. Ми позначимо за B довжину таких блоків у байтах, а довжину блоків, отриманих у результаті хешування - як L (L
ipad = байт 0x36, повторений B разів;
opad = байт 0x5C, повторений B разів.

Для обчислення HMAC від даних "text" необхідно виконати таку операцію:

H(K XOR ipad, H(K XOR ipad, text))

З опису випливає, що IKE використовує для автентифікації сторін величини HASH. Зазначимо, що під HASH в даному випадку мається на увазі виключно назва Payload в ISAKMP, і ця назва не має нічого спільного зі своїм вмістом

Інфраструктура IPSec

Мережі VPN на основі IPSec можуть бути побудовані за допомогою різних пристроїв Cisco - маршрутизаторів Cisco, брандмауерів CiscoSecure PIX Firewall, програмного забезпечення клієнта CiscoSecure VPN і концентраторів Cisco VPN серій 3000 і 5000. Маршрутизатори Cisco мають вбудовану підтримку VPN з відповідними багатими IOS, що зменшує складність мережевих рішень та знижує загальну вартість VPN при можливості побудови багаторівневого захисту сервісів, що надаються. Брандмауер PIX Firewall є високопродуктивним мережевим пристроєм, який може обслуговувати кінцеві точки тунелів, забезпечуючи їм високу пропускну здатність та чудові функціональні можливості брандмауера. Програмне забезпечення клієнта CiscoSecure VPN підтримує найсуворіші вимоги VPN віддаленого доступу для операцій електронної комерції, а також додатків мобільного доступу, пропонуючи закінчену реалізацію стандартів IPSec та забезпечуючи надійну взаємодію маршрутизаторів Cisco та брандмауерів PIX Firewall.

Як працює IPSec

IPSec спирається на ряд технологічних рішень та методів шифрування, але дію IPSec загалом можна представити у вигляді наступних основних кроків:

Крок 1. Початок процесу IPSec.Трафік, який потребує шифрування відповідно до політики захисту IPSec, узгодженої сторонами IPSec, починає IКЕ-процес.
Крок 2. Перша фаза IKE. IKE процес виконує аутентифікацію сторін IPSec і веде переговори про параметри асоціацій захисту IKE, в результаті чого створюється захищений канал для ведення переговорів про параметри асоціацій захисту IPSec в ході другої фази IKE.
Крок 3. Друга фаза IKE. IKE-процес веде переговори про параметри асоціації захисту IPSec та встановлює відповідні асоціації захисту IPSec для пристроїв сполучених сторін.
Крок 4. Передача даних. Відбувається обмін даними між сторонами, що повідомляються IPSec, який базується на параметрах IPSec і ключах, що зберігаються в базі даних асоціацій захисту.
Крок 5. Завершення роботи тунелю IPSec. Асоціації захисту IPSec завершують свою роботу або в результаті їх видалення, або через перевищення граничного часу їх існування.

У наступних розділах ці кроки будуть описані докладніше.

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

Протокол працює на мережному рівні моделі OSI і, відповідно, він "прозорий" для програм. Іншими словами, на роботу додатків (таких як web-сервер, браузер, СУБД і т.д.) не впливає, використовується захист переданих даних за допомогою IPSec чи ні.

Операційні системи сімейства Windows 2000 та вище мають вбудовану підтримку протоколу IPSec. З точки зору багаторівневої моделі захисту цей протокол є засобом захисту рівня мережі.

Мал. 5.9.

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

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

IP-адреса одержувача;
вказівку на протоколи безпеки, які використовуються під час передачі даних;
ключі, необхідні для шифрування та формування імітівставки (якщо це потрібно);
вказівку на метод форматування, який визначає, яким чином створюються заголовки;
індекс параметрів захисту (від англ. Security Parameter Index, скор. SPI) - ідентифікатор, що дозволяє знайти потрібний SA.

Зазвичай контекст захисту є односпрямованим, а для передачі даних по тунелю в обидві сторони задіюються два SA . Кожен хост має власну базу SA , з якої вибирається необхідний елемент або з SPI , або з IP -адресу одержувача.

Два протоколи, що входять до складу IPSec:

протокол аутентифікуючого заголовка- AH (від англ. Authentication Header), що забезпечує перевірку цілісності та аутентифікацію переданих даних; остання версія протоколу описана RFC 4302 (попередні - RFC 1826, 2402);
протокол інкапсулюючого захисту даних – ESP (від англ. Encapsulating Security Payload) - забезпечує конфіденційність і, додатково, може забезпечувати перевірку цілісності та автентифікацію, описаний у RFC 4303 (попередні - RFC 1827, 2406).

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

Транспортний режиморієнтований на з'єднання хост-хост. При використанні ESP у транспортному режимі захищаються лише дані IP-пакета, заголовок не торкається. При використанні AH захист поширюється на дані та частину полів заголовка. Докладніше режими роботи наведено нижче.

Протокол AH

В IP ver .4 аутентифікуючий заголовок розташовується після заголовка IP. Уявімо вихідний IP-пакет як сукупність IP-заголовка, заголовка протоколу наступного рівня (як правило, це TCP або UDP, на рис. 5.10 він позначений як ULP - від англ. Upper-Level Protocol) і даних.

Мал. 5.10.

Розглянемо формат заголовка ESP (рис. 5.13). Він починається з двох 32-розрядних значень. SPIі SN. Роль їх така сама, як у протоколі AH - SPIідентифікує SA, що використовується для створення даного тунелю; SN- дозволяє захиститись від повторів пакетів. SNі SPIне шифруються.

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

Мал. 5.12.

Мал. 5.13.

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

Якщо ESP використовується і для аутентифікації даних, то пакет завершує змінну довжину, що містить ICV. На відміну від AH, ESP при розрахунку значення імітівставки , поля IP-заголовка (нового - для тунельного режиму, модифікованого старого - для транспортного) не враховуються.

При спільному використанні протоколів AH і ESP після IP заголовка йде AH, після нього - ESP . У цьому випадку ESP вирішує завдання забезпечення конфіденційності, AH - забезпечення цілісності та аутентифікації джерела з'єднання.

Розглянемо низку додаткових питань, пов'язаних із використанням IPSec. Почнемо з того, звідки береться інформація про параметри з'єднання SA. Створення бази SA може проводитись різними шляхами. Зокрема, вона може створюватися адміністратором безпекивручну, або формуватися з використанням спеціальних протоколів - SKIP, ISAKMP (Internet Security Association and Key Management Protocol) та IKE (Internet Key Exchange).

IPSec та NAT

При підключенні мереж організацій до Інтернету часто використовується механізм трансляції мережевих адрес - NAT (Network Address Translation). Це дозволяє зменшити кількість зареєстрованих IP-адрес, що використовуються в мережі. Всередині мережі використовуються незареєстровані адреси (зазвичай з діапазонів, спеціально виділених для цієї мети, наприклад, адреси виду 192.168.x.x для мереж класу C). Якщо пакет з такої мережі передається в Інтернет, то маршрутизатор, зовнішньому інтерфейсу якого призначено принаймні одну зареєстровану ip-адресу, модифікує ip-заголовки мережних пакетів, підставляючи замість приватних адрес зареєстровану адресу. Те, як робиться підстановка, фіксується у спеціальній таблиці. При отриманні відповіді, відповідно до таблиці, робиться зворотна заміна і пакет переправляється у внутрішню мережу.

Розглянемо приклад використання NAT рис. 5.14. У цьому випадку у внутрішній мережі використовуються приватні адреси 192.168.0.x. З комп'ютера, з адресою 192.168.0.2, звертаються до зовнішньої мережі до комп'ютера з адресою 195.242.2.2. Нехай це буде підключення до web-сервера (протокол HTTP, який використовує TCP порт 80).

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

Перед тим, як приступити до детального ознайомлення з протоколом IPsec та його налаштуванням, слід виявити його можливості та переваги перед іншими доступними протоколами захисту даних.

IPsec існує як розширення протоколу IPv4 і є невід'ємною частиною IPv6. Цей протокол забезпечує безпеку IP-рівня мережі (3 рівень у моделі ISO/OSI, рис. 1), що дозволяє забезпечити високий рівень захисту, прозорий для більшості додатків, служб і протоколів верхнього рівня, які використовують як транспорт протокол IP. IPSec не вимагає внесення змін до існуючих програм або операційних систем.

Мал. 1, модель ISO/OSI.

Впровадження безпеки на цьому рівні забезпечує захист для всіх протоколів сімейства TCP/IP, починаючи з рівня IP, таких як TCP, UDP, ICMP, а також безліч інших.

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

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

Однією з важливих переваг протоколу є дешевизна його використання. Він дозволяє убезпечити дані та забезпечити перевірку справжності користувачів та даних у раніше незахищеній мережі без додаткових витрат на мережеве обладнання, оскільки зберігається сумісність із усім раніше випущеним обладнанням.

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

Субпротоколи AH (Authentication Header) та ESP (Encapsulating Security Payload) можуть використовуватися як спільно для забезпечення максимального рівня безпеки, так і незалежно один від одного.

Робота протоколу можлива у двох режимах - транспортному та тунельному, що забезпечують різний рівень безпеки та застосовні у різних умовах.

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

У транспортному режимі протоколи AH та ESP мають такі функції та можливості:

протокол AHзабезпечує перевірку справжності і цілісність даних, і навіть відсутність повторів (як заголовка IP, і корисних даних), тобто захищає дані від цілеспрямованих змін. При цьому дані не шифруються і залишаються доступними для читання. AH підписує пакети використовуючи алгоритми хешування з ключами (MD5, а більш сучасних реалізаціях SHA1), у своїй заголовок AH міститься між заголовком IP і корисними даними (як показано малюнку 2). У заголовку AH підписується весь IP-пакет, за винятком полів, що підлягають зміні в процесі передачі через мережу (рисунок 3). Заголовок AH завжди розташований перед будь-якими іншими заголовками, які використовуються в Ipsec.

Мал. 2, Розміщення заголовка АН

Мал. 3, Охоплення AH (транспортний режим)

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

Мал. 4, Розміщення заголовка та трейлерів ESP

Мал. 5, Охоплення ESP (транспортний режим)

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

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

Мал. 6, Охоплення AH (тунельний режим)

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

Мал. 7, Охоплення ESP (тунельний режим)

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

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

Залежно від необхідного рівня безпеки можливі різні конфігурації роботи протоколу IPsec. Наприклад, якщо потрібно забезпечити лише автентифікацію користувачів та перевірку цілісності та справжності даних, то можна обмежиться використанням AH, що істотно не вплине на продуктивність мережі та окремих робочих станцій, навіть при застосуванні найбільш стійких алгоритмів хеш-функцій, як буде показано нижче. У випадку, якщо дані, що передаються, вимагають їх шифрування, то використовується протокол ESP, що, залежно від застосовуваних криптографічних алгоритмів і швидкості передачі даних, може значно позначитися на продуктивності робочих станцій, які виконують функції кінцевих точок тунелю або беруть участь у мережі, де застосовується транспортний режим IPsec.

Налаштування

Опис налаштування VPN-тунелів, як і розгляд їх властивостей та можливостей, виходить за межі цієї статті, тому обмежимося описом процесу налаштування транспортного режиму IPsec.

У Windows XP налаштування IPsec виконується за допомогою оснастки «Локальні параметри безпеки», запуск якої можливий з меню «Адміністрування», «Панелі керування» або через «Виконати» «secpol.msc». Можливе використання створених за умовчанням політик або створення нової.

Для створення політики безпеки IP необхідно виділити зі списку пункт "Політики безпеки IP" та в меню "Дія" вибрати "Створити політику безпеки IP".

Мал. 8, Створення політики безпеки IP

Відкриється Майстер політики IP-безпеки. Для продовження слід натиснути "Далі". У наступному вікні потрібно ввести ім'я нової політики та натиснути «Далі».

Мал. 9, Ім'я політики IP

У наступному вікні «Майстер» запропонує прийняти рішення, чи використовувати правило за умовчанням. Використання цього правила можна скасувати і після створення політики, якщо виникне така потреба.

Мал. 10, Правило за умовчанням

Після цього «Майстер» пропонує вибрати спосіб автентифікації користувача. IPsec підтримує такі способи: за допомогою протоколу Kerberos (стандартний протокол автентифікації в доменах Windows 2000 та Windows 2003), за допомогою сертифіката користувача, або на підставі рядка захисту («пароля»). Якщо у вашій мережі немає контролерів домену і користувачі мережі не мають дійсних сертифікатів, залишається тільки вибрати рядок складніше і тримати його в строгій таємниці. Рядок захисту насправді може складатися з кількох рядків.

Мал. 11, Вибір способу автентифікації

Створення політики практично закінчено. Змінити властивості можна негайно після завершення роботи майстра (вікно властивостей відкриється автоматично), або пізніше, виділивши потрібну політику і вибравши з контекстного пункт «Властивості».

Мал. 12, Завершення створення політики

Тепер настав час змінити властивості політики так, щоб вони задовольняли потребам, а отже належить створити правила безпеки IP, фільтр та правила фільтра.

Для створення правила безпеки необхідно відкрити властивості створеної політики безпеки IP та на вкладці «Правила» натиснути кнопку «Додати», попередньо знявши прапорець «Використовувати майстер», як показано на малюнку 13.

Рис.13, Створення правила безпеки IP

На закладці «Параметри тунелю» не слід змінювати щось, якщо Ви не налаштовуєте IPsec у тунельному режимі. На закладці «Тип підключення» можна вибрати для яких мережевих підключень буде застосовуватися створюване правило – для всіх підключень, тільки для локальних підключень або лише для віддалених. Таким чином передбачена можливість створення різних правил для мережних підключень з різною швидкістю передачі даних, що дозволяє більш повільних і, як правило, менш захищених віддалених підключень встановити інші параметри як аутентифікації, так і перевірки цілісності і шифрування.

Мал. 14, Тип підключення

На закладці «Методи автентифікації» є можливість додати кілька методів перевірки та змінити порядок їх переваги, що дозволяє гнучкіше налаштувати правило для зв'язку з різними вузлами, що підтримують різні способи автентифікації.

Мал. 15, Методи автентифікації

Після вибору типу підключень і методів автентифікації слід вибрати список фільтрів IP та дію фільтра, або створити нові. Для вибору або створення фільтрів IP слід перейти на закладку "Список фільтрів IP" (рисунок 16).

За замовчуванням створено такі фільтри:

Повний IP-трафік, який застосовується до всього IP-трафіку, незалежно від протоколу вищого рівня;

Повний ICMP-трафік, який застосовується відповідно до всього ICMP-трафіку.

Мал. 16, Список фільтрів IP.

Для створення нового фільтра слід натиснути кнопку «Додати», після чого відкриється вікно «Список фільтрів IP», де після введення імені списку фільтрів та зняття галочки «Використовувати майстер» слід натиснути кнопку «Додати» (рисунок 17).

Мал. 17, Створення списку фільтрів IP.

Відкриється вікно «Властивості: Фільтр» (рисунок 18), де слід вказати адреси джерела та одержувача пакетів, до яких застосовуватиметься фільтр, а також, за необхідності, протокол та порти джерела та одержувача.

Мал. 18, Параметри нового списку фільтрів IP

Після вибору або створення списків фільтрів необхідно визначити дію фільтра. Це можна зробити на закладці "Дія фільтра". Створені за умовчанням дії:

Дозволити, яке дозволяє проходження небезпечних пакетів (без використання IPsec),

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

Остання встановлена дія – Запит безпеки – передбачає вимогу від клієнтів безпечного зв'язку, але при невиконанні цих вимог небезпечний зв'язок перерваний не буде.

Мал. 19, Дії фільтра

Створити нову дію можна, натиснувши кнопку «Додати», попередньо знявши прапорець «Використовувати майстер» (рисунок 19). На вкладці «Методи безпеки» вікна «Властивості: створення дії фільтра», слід вказати, чи потрібно дозволити проходження даних, заблокувати їх або узгодити безпеку (рисунок 20).

Мал. 20, Пустий список можливих дій фільтра

Якщо вибрано пункт узгодити безпеку, можна додати методи безпеки та змінити порядок їх переваги. При додаванні методів безпеки слід вибрати, чи буде використовуватися AH, ESP, або налаштувати безпеку вручну, вибравши пункт «Безпека, що налаштовується». Тільки таким чином можна використовувати і AH і ESP. У параметрах безпеки, що настроюється, встановлюються необхідні протоколи (AH і ESP) (рисунок 21).

Мал. 21, Створення дії фільтра

Тут також надано можливість вручну вибрати алгоритми перевірки цілісності та шифрування, а також параметри зміни ключів сеансу. За замовчуванням ключі змінюються щогодини чи через кожні 100Mb переданої інформації (рисунок 22).

Мал. 22, Параметри особливого методу безпеки

Після вибору дій фільтрів налаштування політики безпеки IP можна вважати завершеним. Якщо налаштування здійснювалося в Windows XP, як у цьому прикладі, для транспортного режиму IPsec, то таку саму операцію слід зробити кожному комп'ютері. Засоби автоматизації Windows Server дозволяють централізовано розгорнути політику IP на всіх робочих станціях домену. Поза доменом автоматизація можлива лише частково за допомогою сценаріїв командного рядка (за допомогою програми ipseccmd).

Тестування

Тестування продуктивності протоколу IPsec має на меті виявити рівень навантаження на центральний процесор під час передачі даних з мережі з допомогою різних криптографічних алгоритмів.

Тестування проводилося на комп'ютерах наступної конфігурації:

	Комп'ютер 1	Комп'ютер 2
Процесор	AMD Athlon 64 3000+ Socket 754	AMD Athlon XP 1700+ Socket А
Материнська плата
	2*512 Mb Samsung PC 3200	256 Mb Samsung PC 2700
Жорсткий диск	Seagate ST3160023A	Seagate ST380011A
Мережевий адаптер

Між двома комп'ютерами передавався файл об'ємом 701 Мб, з різними налаштуваннями IPsec, а також без використання протоколу, що розглядається.

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

Без використання IPsec файл був переданий за 86 с. При цьому завантаженість процесорів на обох комп'ютерах була не висока, як показано на рисунках 23 та 24, а середня швидкість передачі досягла 65,21 Мбіт/с.

Після цього IPsec був налаштований описаним вище чином для забезпечення цілісності даних (субпротокол AH з використанням SHA-1).

Час передачі даних зріс трохи, до 91 с, а швидкість трохи впала, до 61,63 Мбіт/с. При цьому завантаження процесорів зросла небагато і зображена на малюнках 25 і 26.

Наступний тестовий варіант налаштування IPsec був таким: ESP без використання AH, із шифруванням за допомогою DES та хешуванням MD5. Значних змін у продуктивності цієї конфігурації проти попередніми помічено був.

Файл передано за 93 с, швидкість передачі становила 60,3 Мбіт/с. Завантаження процесорів показано відповідно на малюнках 27 і 28. Слід зауважити, що DES є застарілим алгоритмом і не рекомендується до використання там, де дані, що захищаються, дійсно маю велику цінність. У той же час стійкість цього алгоритму може бути значно покращена завдяки частішій зміні ключа.

При використанні стійкішого 3DES замість DES в тій же конфігурації (MD5), швидкість передачі впала більш ніж в два рази, і склала 29,99 Мбіт/с, а час відповідно 187 с. Графіки завантаженості процесорів мало змінилися (рисунки 29 і 30).

При використанні ESP з 3DES та SHA1 час передачі зріс на 1с (до 188), а швидкість впала до 29,83 Мбіт/с. Наводити графіки завантаженості процесора немає сенсу – вони такі самі як на малюнках 29 і 30.

Використовуючи спільно з ESP протокол AH у найбільш безпечній, а отже, і найбільш ресурсомісткій конфігурації, доступній у Windows XP, отримані наступні результати: час передачі збільшився до 212 с, швидкість впала до 26,45 Мбіт/с.

Діаграма 1, Час передачі файлу та швидкість залежно від використовуваних криптографічних алгоритмів

Як видно з результатів тестування (діаграма 1), ресурсомісткість IPsec невисока при використанні тільки AH і при застосуванні ESP з DES. У випадку використання 3DES продуктивність різко падає, але при низьких швидкостях передачі даних продуктивності навіть застарілих процесорів буде достатньо. Там, де потрібна висока швидкість передачі даних, може виявитися достатнім використання DES із частою зміною ключа. Характерно, що завантаження двох процесорів різного класу не надто відрізнялося.

(The Internet Key Exchange (IKE)) - Обмін ключами.

RFC 2410 (Null Encryption Algorithm and Its Use With IPsec) - Нульовий алгоритм шифрування та його використання.

RFC 2411 (IP Security Document Roadmap) - Подальший розвиток стандарту.

RFC 2412 (The OAKLEY Key Determination Protocol) - Перевірка відповідності ключа.

Архітектура IPsec

Протоколи IPsec, на відміну інших добре відомих протоколів SSL і TLS , працюють на мережному рівні (рівень 3 моделі OSI). Це робить IPsec більш гнучким, тому він може використовуватися для захисту будь-яких протоколів, що базуються на TCP і UDP . IPsec може використовуватися для забезпечення безпеки між двома IP-вузлами, між двома шлюзами безпеки або між IP-вузлом та шлюзом безпеки. Протокол є надбудовою над IP-протоколом, і обробляє сформовані IP-пакети описаним нижче способом. IPsec може забезпечувати цілісність та/або конфіденційність даних, що передаються по мережі.

IPsec використовує такі протоколи для виконання різних функцій:

Authentication Header (АН) забезпечує цілісність віртуального з'єднання (переданих даних), аутентифікацію джерела інформації та додаткову функцію щодо запобігання повторній передачі пакетів
Encapsulating Security Payload (ESP) може забезпечити конфіденційність (шифрування) інформації, що передається, обмеження потоку конфіденційного трафіку. Крім цього, він може забезпечити цілісність віртуального з'єднання (переданих даних), автентифікацію джерела інформації та додаткову функцію щодо запобігання повторній передачі пакетів (Кожного разу, коли застосовується ESP, в обов'язковому порядку повинен використовуватися той чи інший набір даних послуг із забезпечення безпеки)
Security Association (SA) забезпечують зв'язок алгоритмів та даних, які надають параметри, необхідні для роботи AH та/або ESP. Internet Security Association and Key Management Protocol (ISAKMP) забезпечує основу для аутентифікації та обміну ключами, автентифікації ключів.

Security Association

Концепція "Захищеного віртуального з'єднання" (SA, "Security Association") є фундаментальною в архітектурі IPsec. SA являє собою симплексне з'єднання, яке формується для транспортування по ньому відповідного трафіку. При реалізації послуг безпеки формується SA з урахуванням використання протоколів AH чи ESP (або обох одночасно). SA визначено відповідно до концепції міжтермінального з'єднання (point-to-point) та може функціонувати у двох режимах: транспортний режим (РТР) та режим тунелювання (РТУ). Транспортний режим реалізується за умови SA між двома IP-вузлами. У режимі тунелювання SA формує IP-тунель.

Усі SA зберігаються у базі даних SADB (Security Associations Database) IPsec-модуля. Кожне SA має унікальний маркер, що складається із трьох елементів:

індексу параметра безпеки (SPI)
IP-адреси призначення
ідентифікатора протоколу безпеки (ESP або AH)

IPsec-модуль, маючи ці три параметри, може знайти в SADB запис про конкретний SA. До списку компонентів SA входять:

Послідовний номер 32-бітове значення, яке використовується для формування поля Sequence Numberу заголовках АН та ESP. Переповнення лічильника порядкового номераПрапор, який сигналізує про переповнення лічильника номера послідовного. Вікно для придушення атак відтворенняВикористовується для визначення повторної передачі пакетів. Якщо значення у полі Sequence Numberне потрапляє в заданий діапазон, пакет знищується. Інформація AHвикористовується алгоритм аутентифікації, необхідні ключі, час життя ключів та інші параметри. Інформація ESPалгоритми шифрування та аутентифікації, необхідні ключі, параметри ініціалізації (наприклад, IV), час життя ключів та інші параметри Режим роботи IPsecтунельний або транспортний MTUМаксимальний розмір пакета, який можна передати віртуальним каналом без фрагментації.

Оскільки захищені віртуальні сполуки (SA) є симплексними , то організації дуплексного каналу, як мінімум, потрібні два SA. Крім цього, кожен протокол (ESP/AH) повинен мати свою власну SA для кожного напряму, тобто зв'язування AH+ESP вимагає наявності чотирьох SA. Всі ці дані розміщуються в SADB.

AH: алгоритм аутентифікації.
AH: секретний ключ для автентифікації
ESP: алгоритм шифрування.
ESP: таємний ключ шифрування.
ESP: використання аутентифікації (так/ні).
Параметри для обміну ключами
Обмеження маршрутизації
IP політика фільтрації

Крім бази даних SADB, реалізації IPsec підтримують базу даних SPD (Security Policy Database-База даних політик безпеки). Запис SPD складається з набору значень полів IP-заголовка і полів заголовка протоколу верхнього рівня. Ці поля називаються селекторами. Селектори використовуються для фільтрації вихідних пакетів, з метою поставити кожен пакет у відповідність до певного SA. Коли формується пакет, порівнюються значення відповідних полів у пакеті (селекторні поля) з тими, що містять SPD. Знаходяться відповідні SA. Потім визначається SA (у разі, якщо воно є) для пакета і пов'язаний з нею індекс параметрів безпеки (SPI). Після цього виконуються операції IPsec (операції протоколу AH чи ESP).

Приклади селекторів, які містяться у SPD:

IP-адреса призначення
IP-адреса відправника
Протокол IPsec (AH, ESP або AH+ESP)
Порти відправника та одержувача

Authentication Header

Authentication Header format

Offsets	Octet 16	0								1								2								3
Octet 16	Bit 10	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Next Header								Payload Len								Reserved
4	32
8	64	Sequence Number
C	96	Integrity Check Value (ICV) …
…	…	Integrity Check Value (ICV) …

Next Header(8 bits) Тип заголовка протоколу, що йде після заголовка AH. За цим полем приймальний IP-sec модуль дізнається про протокол, що захищається верхнього рівня. Значення цього поля для різних протоколів можна переглянути в RFC 1700 . Payload Len(8 bits) Це поле визначає загальний розмір АН-заголовка в 32-бітових словах мінус 2. Незважаючи на це, при використанні IPv6 довжина заголовка повинна бути кратна 8 байтам. Reserved(16 bits) Зарезервовано. Заповнюється нулями. Security Parameters Index(32 bits) Індекс параметрів безпеки. Значення цього поля разом з IP-адресою одержувача та протоколом безпеки (АН-протокол) однозначно визначає захищене віртуальне з'єднання (SA) для цього пакета. Діапазон значень SPI 1…255 зарезервований IANA. Sequence Number(32 bits) Послідовний номер. Для захисту від повторної передачі. Поле містить монотонно зростаюче значення параметра. Незважаючи на те, що одержувач може відмовитися від послуги захисту від повторної передачі пакетів, воно є обов'язковим і завжди присутній в AH-заголовку. IPsec-модуль, що передає, завжди використовує це поле, але одержувач може його і не обробляти. Integrity Check Value

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

Обробка вихідних IP-пакетів

Якщо передавальний IPsec-модуль визначає, що пакет пов'язаний з SA, яке передбачає AH-обробку, він починає обробку. Залежно від режиму (транспортний або тунелювання) він по-різному вставляє AH-заголовок в IP-пакет. У транспортному режимі AH-заголовок розташовується після заголовка протоколу IP та перед заголовками протоколів верхнього рівня (Зазвичай, TCP або UDP). У режимі тунелювання весь вихідний IP-пакет обрамляється спочатку заголовком AH, потім заголовком IP-протоколу. Такий заголовок називається зовнішнім, а заголовок вихідного IP-пакета-внутрішнім. Після цього передавальний IPsec-модуль повинен згенерувати послідовний номер і записати його в полі Sequence Number. При встановленні SA послідовний номер встановлюється в 0 і перед відправкою кожного IPsec-пакета збільшується на одиницю. Крім того, відбувається перевірка - чи не зациклився лічильник. Якщо він досяг свого максимального значення, то він знову встановлюється в 0. Якщо використовується послуга запобігання повторній передачі, то при досягненні лічильника свого максимального значення, передає IPsec-модуль перевстановлює SA. Таким чином забезпечується захист від повторної посилки пакета - приймальний IPsec-модуль перевірятиме поле Sequence Number, і ігнорувати повторно приходять пакети. Далі відбувається обчислення контрольної суми ICV. Потрібно зауважити, що тут контрольна сума обчислюється із застосуванням секретного ключа, без якого зловмисник зможе заново обчислити хеш, але не знаючи ключа, не зможе сформувати правильну контрольну суму. Конкретні алгоритми, що використовуються для обчислення ICV, можна дізнатися із RFC 4305 . В даний час можуть застосовуватись, наприклад, алгоритми HMAC-SHA1-96 або AES-XCBC-MAC-96. Протокол АН обчислює контрольну суму (ICV) за наступними полями IPsec-пакету:

поля IP-заголовка, які не були схильні до змін у процесі транслювання, або визначені як найважливіші
АН-заголовок (Поля: "Next Header", "Payload Len, "Reserved", "SPI", "Sequence Number", "Integrity Check Value". Поле "Integrity Check Value" встановлюється в 0 при обчисленні ICV
дані протоколу верхнього рівня

Якщо поле може змінюватися в процесі транспортування, його значення встановлюється в 0 перед обчисленням ICV. Винятки становлять поля, які можуть бути змінені, але значення яких можна передбачити при прийомі. При обчисленні ICV вони заповнюються нулями. Прикладом поля, що змінюється, може бути поле контрольної суми, прикладом зміненого, але зумовленого може бути IP-адреса одержувача. Більш детальний опис того, які поля, як враховуються при обчисленні ICV, можна знайти в стандарті RFC 2402 .

Обробка вхідних IP-пакетів

Після отримання пакета, що містить повідомлення АН-протоколу, приймальний IPsec-модуль шукає відповідне захищене віртуальне з'єднання (SA) SADB (Security Associations Database), використовуючи IP-адресу одержувача, протокол безпеки (АН) та індекс SPI. Якщо відповідний SA не знайдено, пакет знищується. Знайдене захищене віртуальне з'єднання (SA) вказує на те, чи використовується послуга запобігання повторній передачі пакетів, тобто. на необхідність перевірки поля Sequence Number. Якщо послуга використовується, поле перевіряється. Для цього використовується метод ковзного вікна. Приймальний IPsec-модуль формує вікно із шириною W. Лівий край вікна відповідає мінімальному послідовному номеру( Sequence Number) N правильно прийнятого пакета. Пакет із полем Sequence Number, В якому міститься значення, починаючи від N+1 і закінчуючи N+W, приймається коректно. Якщо отриманий пакет виявляється по ліву межу вікна, він знищується. Потім приймальний IPsec-модуль обчислює ICV по відповідним полям прийнятого пакета, використовуючи алгоритм аутентифікації, який він дізнається із запису про SA, і порівнює отриманий результат значення ICV, розташованим в полі "Integrity Check Value". Якщо обчислене значення ICV збіглося з прийнятим, то пакет вважається дійсним і приймається для подальшої IP-обробки. Якщо перевірка дала негативний результат, приймальний пакет знищується.

Encapsulating Security Payload format

Offsets	Octet 16	0								1								2								3
Octet 16	Bit 10	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Security Parameters Index (SPI)
4	32	Sequence Number
8	64	Payload data
…	…	Payload data
…	…
…	…									Padding (0-255 octets)
…	…																	Pad Length								Next Header
…	…	Integrity Check Value (ICV) …
…	…	Integrity Check Value (ICV) …

Security Parameters Index(32 bits) Індекс параметрів безпеки. Значення цього поля разом з IP-адресою одержувача та протоколом безпеки (АН-протокол) однозначно визначає захищене віртуальне з'єднання (SA) для цього пакета. Діапазон значень SPI 1...255 зарезервований IANA для подальшого використання. Sequence Number(32 bits) Послідовний номер. Для захисту від повторної передачі. Поле містить монотонно зростаюче значення параметра. Незважаючи на те, що одержувач може і відмовитися від послуги захисту від повторної передачі пакетів, воно завжди присутнє в AH-заголовку. Відправник (передавальний IPsec-модуль) повинен завжди використовувати це поле, але одержувач може і не потребувати його обробки. Payload data(variable) Це поле містить дані відповідно до поля "Next Header". Це поле обов'язкове і складається з цілого числа байтів. Якщо алгоритм, який використовується для шифрування цього поля, вимагає даних для синхронізації криптопроцесів (наприклад, вектор ініціалізації - "Initialization Vector"), це поле може містити ці дані в явному вигляді. Padding(0-255 octets) Доповнення. Необхідно, наприклад, для алгоритмів, які вимагають, щоб відкритий текст був крадений деякому числу байтів), наприклад, розмір блоку для блокового шифру. Pad Length(8 bits) Розмір доповнення (в байтах). Next Header(8 bits) Це поле визначає тип даних, які у полі " Payload data " . Integrity Check ValueКонтрольна сума. Повинна бути кратна 8-байтам для IPv6, і 4-байтам для IPv4.

Обробка вихідних IPsec-пакетів

Якщо передавальний IPsec-модуль визначає, що пакет пов'язаний з SA, яке передбачає ESP-обробку, він починає обробку. Залежно від режиму (транспортний або тунелювання) вихідний IP-пакет обробляється по-різному. У транспортному режимі передавальний IPsec-модуль здійснює процедуру обрамлення (інкапсуляції) протоколу верхнього рівня (наприклад, TCP або UDP), використовуючи для цього ESP-заголовок і ESP-кінцевик, не торкаючись при цьому заголовка вихідного IP-пакета. У режимі тунелювання IP-пакет обрамляється ESP-заголовком та ESP-кінцем, після чого обрамляється зовнішнім IP-заголовком. Далі проводиться шифрування - у транспортному режимі шифрується тільки повідомлення протоколу вище лежачого рівня (тобто все, що знаходилося після IP-заголовка у вихідному пакеті), в режимі тунелювання - весь вихідний IP-пакет. Передавальний IPsec-модуль із запису про SA визначає алгоритм шифрування та секретний ключ. Стандарти IPsec дозволяють використовувати алгоритми шифрування triple-DES, AES і Blowfish. Так як розмір відкритого тексту повинен бути кратний певному числу байт, наприклад, розмір блоку для блокових алгоритмів, перед шифруванням проводиться ще і необхідне доповнення повідомлення, що шифрується. Защифроване повідомлення розміщується в полі Payload Data. В полі Pad Lengthміститься довжина доповнення. Потім, як і в AH, обчислюється Sequence Number. Після цього вважається контрольна сума (ICV). Контрольна сума, на відміну від протоколу AH, де при її обчисленні враховуються також і деякі поля IP-заголовка, ESP обчислюється тільки по полях ESP-пакету за вирахуванням поля ICV. Перед обчисленням контрольної суми воно заповнюється нулями. Алгоритм обчислення ICV, як і в протоколі AH, передавальний IPsec-модуль дізнається із запису про SA, з яким пов'язаний пакет, що обробляється.

Обробка вхідних IPsec-пакетів

Після отримання пакета, що містить повідомлення ESP-протоколу, приймальний IPsec-модуль шукає відповідне захищене віртуальне з'єднання (SA) в SADB (Security Associations Database), використовуючи IP-адресу одержувача, протокол безпеки (ESP) та індекс SPI. Якщо відповідний SA не знайдено, пакет знищується. Знайдене захищене віртуальне з'єднання (SA) вказує на те, чи використовується послуга запобігання повторній передачі пакетів, тобто. на необхідність перевірки поля Sequence Number. Якщо послуга використовується, поле перевіряється. Для цього, як і в AH, використовується метод ковзного вікна. Приймальний IPsec-модуль формує вікно із шириною W. Лівий край вікна відповідає мінімальному послідовному номеру (Sequence Number) N правильно прийнятого пакета. Пакет із полем Sequence Number, у якому міститься значення, починаючи від N+1 і закінчуючи N+W, приймається коректно. Якщо отриманий пакет виявляється по ліву межу вікна, він знищується. Потім, якщо використовується послуга аутентифікації, приймальний IPsec-модуль обчислює ICV по відповідним полям прийнятого пакета, використовуючи алгоритм аутентифікації, який він дізнається із запису SA, і порівнює отриманий результат зі значенням ICV, розташованим у полі "Integrity Check Value". Якщо обчислене значення ICV збіглося з прийнятим, то пакет, що прийшов, вважається дійсним. Якщо перевірка дала негативний результат, приймальний пакет знищується. Далі проводиться розшифрування пакета. Приймальний IPsec-модуль дізнається із запису про SA, який алгоритм шифрування використовується та секретний ключ. Слід зазначити, що перевірка контрольної суми та процедура розшифрування можуть проводитися не тільки послідовно, а й паралельно. В останньому випадку процедура перевірки контрольної суми повинна закінчитися раніше за процедуру розшифрування, і якщо перевірка ICV провалилася, процедура розшифрування також повинна припинитися. Це дозволяє швидше виявляти зіпсовані пакети, що, своєю чергою, підвищує рівень захисту від атак типу " відмова у обслуговуванні " (DOS-атаки). Далі розшифроване повідомлення відповідно до поля Next Headerпередається для подальшої обробки.

Використання

Протокол IPsec використовується в основному для організації VPN-тунелів. У цьому випадку протоколи ESP та AH працюють у режимі тунелювання. Крім того, налаштування політики безпеки певним чином протокол можна використовувати для створення міжмережевого екрану. Сенс міжмережевого екрану полягає в тому, що він контролює і фільтрує пакети, що проходять через нього, відповідно до заданих правил. Встановлюється набір правил, і екран переглядає всі пакети, що проходять через нього. Якщо пакети, що передаються, потрапляють під дію цих правил, міжмережевий екран обробляє їх відповідним чином. Наприклад, він може відхиляти певні пакети, тим самим припиняючи небезпечні з'єднання. Налаштувавши політику безпеки відповідно, можна, наприклад, заборонити інтернет-трафік. Для цього достатньо заборонити відсилання пакетів, в які вкладаються повідомлення HTTP і HTTPS. IPsec можна використовувати і захисту серверів - для цього відкидаються всі пакети, крім пакетів, необхідні коректного виконання функцій сервера. Наприклад, для Web-сервера можна блокувати весь трафік, за винятком з'єднань через 80-й порт протоколу TCP або через порт TCP 443 у випадках, коли застосовується HTTPS .

Див. також

Посилання

Опис конфігурування IPSec (cisco.com) (англ.)

Віртуальні приватні мережі (VPN)
Програмне забезпечення	Chaply Check Point VPN-1 Cisco Systems VPN Client CloudVPN CryptoLink Gbridge Hamachi Jabpunch Microsoft Forefront Unified Access Gateway n2n NetworkManager OpenVPN Openswan pLan OpenVPN Edition (ZeroGC Gaming Client) rp-pppoe Social VPN strongSwan Tinc tcpcrypt Vyatta Wippien
Механізми
Керовані постачальником

Механізми безпеки в

IPad