У сучасному світірізні технології 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 повідомлення з різними параметрами і, відповідно, декодити і парсувати пакети у відповідь. Пробуємо промацати цільовий пристрій:

[email protected]:~# ike-scan -M -A 37.59.0.253 0 returned handshake; 0 returned notify

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

[email protected]:~# 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.

[email protected]:~# 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, логін і пароль другого чинника. Після цього саме підключення відбувається однією командою:

[email protected]:~# vpnc vpn

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

[email protected]:~# vpnc-disconnect

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

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

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

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

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

Наприкінці шістдесятих років американська агенція перспективних досліджень в обороні DARPA ухвалила рішення про створення експериментальної мережі під назвою ARPANet. У сімдесятих роках ARPANet стала вважатися діючою мережею США, і через цю мережу можна було отримати доступ до провідних університетських та наукових центрів США. На початку вісімдесятих років розпочалася стандартизація мов програмування, а потім і протоколів взаємодії мереж. Результатом цієї роботи стала розробка семирівневої моделі мережевої взаємодії ISO/OSI та сімейства протоколів TCP/IP, яка стала основою для побудови як локальних, так і глобальних мереж.

Базові механізми інформаційного обміну в мережах TCP/IP були загалом сформовані на початку вісімдесятих років, і були спрямовані насамперед забезпечення доставки пакетів даних між різними операційними системамиз використанням різноманітних каналів зв'язку. Незважаючи на те, що ідея створення мережі ARPANet (яка згодом перетворилася на сучасний Інтернет) належала урядовій оборонній організації, фактично мережа зародилася в дослідному світі, і успадкувала традиції відкритості академічної спільноти. Ще до комерціалізації Інтернету (яка відбулася в середині 90-х років) багато авторитетних дослідників відзначали проблеми, пов'язані з безпекою стека протоколів TCP/IP. Основні концепції протоколів TCP/IP в повному обсязі задовольняють (а часом і суперечать) сучасним уявленням про комп'ютерної безпеки.

Донедавна мережа Інтернет використовувалася в основному для обробки інформації щодо відносно простих протоколів: електронна пошта, передача файлів, віддалений доступ. Сьогодні завдяки широкому поширенню технологій WWW все активніше застосовуються засоби розподіленої обробки мультимедійної інформації. Водночас зростає обсяг даних, оброблюваних серед клієнт/сервер і призначених для одночасного колективного доступу великої кількості абонентів. Розроблено кілька протоколів прикладного рівня, що забезпечують інформаційну безпеку таких програм, як електронна пошта (PEM, PGP тощо), WWW (Secure HTTP, SSL тощо), мережеве управління (SNMPv2 тощо). Однак наявність засобів забезпечення безпеки у базових протоколах сімейства TCP/IP дозволить здійснювати інформаційний обмін між широким спектром різноманітних додатків та сервісних служб.

Коротка історична довідка появи протоколу

У 1994 році Рада з архітектури Інтернету (IAB) випустила звіт "Безпека архітектури Інтернету". У цьому документі описувалися основні сфери застосування додаткових коштівбезпеки в мережі Інтернет, а саме захист від несанкціонованого моніторингу, заміни пакетів та керування потоками даних. Серед першочергових та найважливіших захисних заходів вказувалася необхідність розробки концепції та основних механізмів забезпечення цілісності та конфіденційності потоків даних. Оскільки зміна базових протоколів сімейства TCP/IP викликала повну перебудову мережі Інтернет, було поставлено завдання забезпечення безпеки інформаційного обміну у відкритих телекомунікаційних мережах на базі існуючих протоколів. Отже, почала створюватися специфікація Secure IP, додаткова стосовно протоколів IPv4 і IPv6.

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

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

Специфікація IP Security (відома сьогодні як IPsec) розробляється Робочою групою IP Security Protocol IETF. Спочатку IPsec включав 3 алгоритмо-незалежні базові специфікації, опубліковані в якості RFC-документів "Архітектура безпеки IP", "Аутентифікуючий заголовок (AH)", "Інкапсуляція зашифрованих даних (ESP)" (RFC1825, 1826). Необхідно зауважити, що в листопаді 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 року.

Заголовок 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, принаймні одним загальним алгоритмом, не схильних до експортних обмежень.

Заголовок ESP

У разі використання інкапсуляції зашифрованих даних заголовок ESP є останнім у ряді опціональних заголовків, "видимих" у пакеті. Оскільки основною метою ESP є забезпечення конфіденційності даних, різні видиінформації можуть вимагати застосування суттєво різних алгоритмів шифрування. Отже, формат ESP може зазнавати значних змін залежно від криптографічних алгоритмів, що використовуються. Проте, можна виділити такі обов'язкові поля: SPI, що вказує на контекст безпеки та Sequence Number Field, що містить послідовний номер пакета. Поле "ESP Authentication Data" (контрольна сума) не є обов'язковим у заголовку ESP. Одержувач пакету ESP розшифровує ESP заголовок і використовує параметри та дані алгоритму шифрування, що застосовується для декодування інформації транспортного рівня.

Рис. 4 - Формат заголовка ESP.

Розрізняють два режими застосування ESP та AH (а також їх комбінації) – транспортний та тунельний.

Транспортний режим

Транспортний режим використовується для шифрування поля даних IP пакета, що містить протоколи транспортного рівня (TCP, UDP, ICMP), яке містить інформацію прикладних служб. Прикладом застосування транспортного режиму є передача електронної пошти. Усі проміжні вузли на маршруті пакета від відправника до одержувача використовують лише відкриту інформацію мережного рівня та, можливо, деякі опціональні заголовки пакета (в IPv6). Недоліком транспортного режиму є відсутність механізмів приховування конкретних відправників та одержувачів пакету, а також можливість проведення аналізу трафіку. Результатом такого аналізу може стати інформація про обсяги та напрямки передачі інформації, сферу інтересів абонентів, розташування керівників.

Тунельний режим

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

Security Associations

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

Політика безпеки

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

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

ISAKMP/Oakley

Протокол ISAKMP визначає загальну структурупротоколів, які використовуються для встановлення SA та для виконання інших функцій керування ключами. ISAKMP підтримує кілька Областей інтерпретації (DOI), однією з яких є IPSec-DOI. ISAKMP не визначає закінчений протокол, а надає "будівельні блоки" для різних DOI та протоколів обміну ключами.

Протокол Oakley - це протокол визначення ключа, який використовує алгоритм заміни ключа Діффі-Хеллмана. Протокол Oakley підтримує бездоганну пряму безпеку (Perfect Forward Secrecy — PFS). Наявність PFS означає неможливість розшифровування всього трафіку при компрометації будь-якого ключа у системі.

IKE

IKE — протокол обміну ключами за замовчуванням для ISAKMP, який є єдиним. IKE знаходиться на вершині ISAKMP і виконує власне встановлення як ISAKMP SA, так і IPSec SA. IKE підтримує набір різних примітивних функцій для використання у протоколах. Серед них можна виділити хеш-функцію та псевдовипадкову функцію (PRF).

Хеш-функція - це функція, стійка до колізій. Під стійкістю до колізій розуміється той факт, що неможливо знайти два різні повідомлення m 1і m 2, таких, що H(m 1)=H(m 2), де 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, і ця назва не має нічого спільного зі своїм вмістом.

Атаки на AH, ESP та IKE.

Всі види атак на компоненти IPSec можна розділити на наступні групи: атаки, що експлуатують кінцівку ресурсів системи (типовий приклад - атака "Відмова в обслуговуванні", Denial-of-service або DOS-атака), атаки, що використовують особливості та помилки конкретної реалізації IPSec та Нарешті атаки, засновані на слабкості самих протоколів. AH та ESP. Чисто криптографічні атаки можна не розглядати - обидва протоколи визначають поняття "трансформ", куди приховують усю криптографію. Якщо криптоалгоритм стійок, що використовується, а певний з ним трансформ не вносить додаткових слабкостей (це не завжди так, тому правильніше розглядати стійкість всієї системи - Протокол-Трансформ-Алгоритм), то з цього боку все нормально. Що лишається? Replay Attack - нівелюється за рахунок використання Sequence Number (в одному випадку це не працює - при використанні ESP без аутентифікації і без AH). Далі порядок виконання дій (спочатку шифрація, потім аутентифікація) гарантує швидке відбраковування "поганих" пакетів (більше того, згідно з останніми дослідженнями у світі криптографії, саме такий порядок дій найбільш безпечний, зворотний порядок в деяких, правда дуже окремих випадках, може призвести до потенційним дірам у безпеці, на щастя, ні SSL, ні IKE, ні інші поширені протоколи з порядком дій "спочатку аутентифікувати, потім зашифрувати", до цих окремих випадків не відносяться, і, отже, цих дірок не мають). Залишається Denial-Of-Service атака. Як відомо, це атака, від якої немає повного захисту. Тим не менш, швидке відбракування поганих пакетів і відсутність будь-якої зовнішньої реакції на них (згідно RFC) дозволяють більш-менш добре справлятися з цією атакою. У принципі, більшості (якщо не всім) відомим мережевим атакам (sniffing, spoofing, hijacking тощо) AH та ESP при правильному їх застосуванні успішно протистоять. З IKE дещо складніше. Протокол дуже складний, тяжкий для аналізу. Крім того, внаслідок друкарських помилок (у формулі обчислення HASH_R) при його написанні і не зовсім вдалих рішень (той же HASH_R і HASH_I) він містить кілька потенційних "дір" (зокрема, у першій фазі не всі Payload у повідомленні аутентифікуються), втім , вони не дуже серйозні і ведуть, максимум, до відмови у встановленні з'єднання. Від атак типу replay, spoofing, sniffing, hijacking IKE більш-менш успішно захищається. З криптографією дещо складніше, вона не винесена, як в AH і ESP, окремо, а реалізована в самому протоколі. Тим не менш, при використанні стійких алгоритмів та примітивів (PRF), проблем бути не повинно. Якоюсь мірою можна розглядати як слабкість IPsec те, що як єдиний обов'язковий до реалізації криптоалгоритм в нинішніх специфікаціях вказується DES (це справедливо і для ESP, і для IKE), 56 біт ключа якого вже не вважаються достатніми. Тим не менш, це суто формальна слабкість — самі специфікації є алгоритмо-незалежними, і практично всі відомі вендори давно реалізували 3DES (а деякі вже й AES). .

Оцінка протоколу

Протокол IPSec отримав неоднозначну оцінку фахівців. З одного боку, зазначається, що протокол IPSec є найкращим серед усіх інших протоколів захисту даних, що передаються по мережі, розроблених раніше (включаючи розроблений Microsoft PPTP). На думку іншої сторони, є надмірна складність і надмірність протоколу. Так, Niels Ferguson та Bruce Schneier у своїй роботі "A Cryptographic Evaluation of IPsec" відзначають, що вони виявили серйозні проблеми безпеки практично у всіх головних компонентах IPsec. Ці автори також зазначають, що набір протоколів потребує серйозного доопрацювання для того, щоб він забезпечував добрий рівень безпеки. У роботі наведено опис низки атак, що використовують як слабкість загальної схеми обробки даних, так і слабкість криптографічних алгоритмів.

Висновок

У цій статті ми розглянули деякі основні моменти, що стосуються протоколу мережної безпеки IPsec. До речі, протокол IPsec домінує в більшості реалізацій віртуальних приватних мереж. В даний час на ринку представлені як програмні реалізації (наприклад, протокол реалізований в операційній системі Windows2000 компанії Microsoft), так і програмно-апаратні реалізації IPsec - це рішення Cisco, Nokia. Незважаючи на велику кількість різних рішень, всі вони досить добре сумісні один з одним. На закінчення статті наводиться таблиця, в якій проводиться порівняння IPSec і широко поширеного SSL.

Посилання

• www.ietf.org/html.charters/ipsec-charter.html — Домашня сторінка робочої групи IETF. Там же знаходяться посилання на RFC та пропозиції щодо стандартів.
• www.microsoft.com/rus/windows2000/library/security/w2k_IPSecurity.asp – Інформація про реалізацію протоколу IPSec у Windows2000 Server.

Подяки

Вконтакте

Однокласники

Протоколи IPSec Організація захищеного каналу https://www.сайт/lan/protokoly-ipsec https://www.сайт/@@site-logo/logo.png

Протоколи IPSec

Організація захищеного каналу

Протоколи IPSec

Організація захищеного каналу за допомогою AH, ESP та IKE.

Internet Protocol Security (IPSec) називають у стандартах Internet системою. Дійсно, IPSec - це узгоджений набір відкритих стандартів, що має сьогодні цілком окреслене ядро, і в той же час він може бути досить доповнений новими протоколами, алгоритмами і функціями.

Основне призначення протоколів IPSec – забезпечення безпечної передачі даних по мережах IP. Застосування IPSec гарантує:

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

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

ЗАХИЩЕНІ КАНАЛИ НА РІЗНИХ РІВНЯХ

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

Захищений канал можна побудувати за допомогою системних засобів, реалізованих різних рівнях моделі OSI (див. малюнок 1). Якщо для захисту даних використовується протокол одного з верхніх рівнів (прикладного, презентаційного або сеансового), такий спосіб захисту не залежить від того, які мережі (IP або IPX, Ethernet або ATM) застосовуються для транспортування даних, що можна вважати безперечною гідністю. З іншого боку, додаток у своїй стає залежним від конкретного протоколу захисту, т. е. додатків такий протокол перестав бути прозорим.

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

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

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

Розглянемо, наприклад, протокол захищеного каналу Point-to-Point Tunneling Protocol (PPTP), що працює на канальному рівні. Він заснований на протоколі PPP, який широко використовується в з'єднаннях «точка-точка», наприклад, при роботі з виділеними лініями. Протокол PPTP не тільки забезпечує прозорість засобів захисту для додатків та служб прикладного рівня, але й не залежить від застосовуваного протоколу мережного рівня: зокрема, протокол PPTP може переносити пакети як у мережах IP, так і мережах, що працюють на основі протоколів IPX, DECnet або NetBEUI. Однак, оскільки протокол PPP використовується далеко не у всіх мережах (у більшості локальних мереж на канальному рівні працює протокол Ethernet, а в глобальних - протоколи ATM, frame relay), PPTP не можна вважати універсальним засобом.

протокол IPSec, що працює на мережевому рівні, є компромісним варіантом. З одного боку, він прозорий для додатків, з другого - може працювати практично переважають у всіх мережах, оскільки грунтується широко поширеному протоколі IP: нині у світі лише 1% комп'ютерів не підтримує IP взагалі, інші 99% використовують його чи як єдиний протокол, або як один з декількох протоколів.

РОЗПОДІЛ ФУНКЦІЙ МІЖ ПРОТОКОЛАМИ IPSEC

Ядро IPSec складають три протоколи: протокол аутентифікації (Authenti-cation Header, AH), протокол шифрування (Encapsulation Security Payload, ESP) та протокол обміну ключами (Internet Key Exchange, IKE). Функції підтримки захищеного каналу розподіляються між цими протоколами наступним чином:

• протокол AH гарантує цілісність та автентичність даних;
• протокол ESP шифрує передані дані, гарантуючи конфіденційність, але може також підтримувати аутентифікацію і цілісність даних;
• протокол IKE вирішує допоміжне завдання автоматичного надання кінцевим точкам каналу секретних ключів, необхідні роботи протоколів аутентифікації і шифрування даних.

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

Для шифрування даних IPSec може бути застосований будь-який симетричний алгоритм шифрування, що використовує секретні ключі. В основі забезпечення цілісності та аутентифікації даних також лежить один із прийомів шифрування - шифрування за допомогою односторонньої функції (one-way function), званої також хеш-функцією (hash function) або дайджест-функцією (digest function).

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

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

Розділення функцій захисту між двома протоколами AH і ESP викликане застосовуваною у багатьох країнах практикою обмеження експорту та/або імпорту коштів, які забезпечують конфіденційність даних шляхом шифрування. Кожен із цих двох протоколів може використовуватися як самостійно, так і одночасно з іншим, так що в тих випадках, коли шифрування через чинні обмеження застосовувати не можна, систему можна постачати тільки з протоколом AH. Природно, захист даних тільки за допомогою протоколу AH у багатьох випадках буде недостатнім, оскільки сторона, яка приймає, у цьому випадку буде впевнена тільки в тому, що дані були відправлені саме тим вузлом, від якого вони очікуються, і дійшли в тому вигляді, в якому були відправлені. Від несанкціонованого перегляду шляхом проходження даних протокол AH захистити не може, оскільки не шифрує їх. Для шифрування даних необхідно застосовувати протокол ESP, який може перевірити їх цілісність і автентичність.

БЕЗПЕЧНА АСОЦІАЦІЯ

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

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

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

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

Для забезпечення сумісності в стандартній версії IPsec визначено деякий обов'язковий «інструментальний» набір: зокрема, для аутентифікації даних завжди може бути використана одна з функцій односторонньої шифрації MD5 або SHA-1, а число алгоритмів шифрування неодмінно входить DES. При цьому виробники продуктів, що включають IPSec, вільні розширювати протокол за рахунок інших алгоритмів автентифікації та шифрування, що вони з успіхом роблять. Наприклад, багато реалізацій IPSec підтримують популярний алгоритм шифрування Triple DES, а також порівняно нові алгоритми - Blowfish, Cast, CDMF, Idea, RC5.

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

ТРАНСПОРТНИЙ І ТУНЕЛЬНИЙ РЕЖИМИ

Протоколи AH та ESP можуть захищати дані у двох режимах: транспортному та тунельному. У транспортному режимі передача IP-пакета через мережу виконується за допомогою оригінального заголовка цього пакета, а тунельному режимі вихідний пакет поміщається новий IP-пакет і передача даних у мережі виконується виходячи з заголовка нового IP-пакета. Застосування того чи іншого режиму залежить від вимог, що пред'являються захисту даних, а також від ролі, яку грає в мережі вузол, що завершує захищений канал. Так, вузол може бути хостом (кінцевим вузлом) чи шлюзом (проміжним вузлом). Відповідно, є три схеми застосування IPSec: «хост-хост», «шлюз-шлюз» та «хост-шлюз».

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

Відповідно до другої схеми, захищений канал встановлюється між двома проміжними вузлами, так званими шлюзами безпеки (Security Gateway, SG), на кожному з яких працює протокол IPSec. Захищений обмін даними може відбуватися між будь-якими двома кінцевими вузлами, підключеними до мереж, які розташовані за шлюзами безпеки. Від кінцевих вузлів підтримка протоколу IPSec не потрібна, вони передають свій трафік в незахищеному вигляді через заслуговують на довіру мережі Intranet підприємств. Трафік, що направляється в загальнодоступну мережу, проходить через шлюз безпеки, який забезпечує його захист за допомогою IPSec, діючи від свого імені. Шлюзи можуть використовувати лише тунельний режим роботи.

Схема хост-шлюз часто застосовується при віддаленому доступі. Тут захищений канал організується між віддаленим хостом, на якому працює IPSec, та шлюзом, що захищає трафік для всіх хостів, що входять до мережі Intranet підприємства. Віддалений хост може використовувати при відправленні пакетів шлюзу як транспортний, так і тунельний режим, а шлюз відправляє пакет хосту тільки в тунельному режимі. Цю схему можна ускладнити, створивши паралельно ще один захищений канал між віддаленим хостом і яким-небудь хостом, що належить внутрішньої мережі, що захищається шлюзом. Таке комбіноване використання двох SA дозволяє надійно захистити трафік у внутрішній мережі.

Наталія Оліфер

Операції із документом

Розглянемо архітектуру сімейства протоколів IPSec. Мета даного сімейства протоколів у тому, щоб забезпечити різні сервіси безпеки лише на рівні IP для протоколів IPv4 і IPv6. Розглянемо сервери безпеки, що надаються протоколами IPSec, та використання цих протоколів у мережах ТСР/IP.

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

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

IPSec може бути реалізований як в ОС, так і маршрутизаторі або міжмережевому екрані.

IPSec забезпечує конфіденційність, цілісність даних, управління доступомаутентифікацію джерела даних для IP-дейтаграм. Ці послуги надаються за допомогою підтримки стану між джерелом та одержувачем IP-дейтаграм. Даний стан визначає конкретні сервіси безпеки на рівні дейтаграми, використовувані криптографічні алгоритми для сервісів і ключі для цих алгоритмів.

Перелічимо основні завдання протоколів IPSec:

1. Забезпечення криптографічного захисту на рівні IP для протоколів IPv4 і IPv6, а саме забезпечення конфіденційності та цілісності даних і цілісності деякої послідовності дейтаграм.
2. Забезпечує прозорість для IP-трафіку, для якого не потрібне використання протоколів IPSec.
3. Забезпечення розширюваності, тобто. можливості додавати нові набори алгоритмів без зміни самого протоколу.

IPSec призначений для безпечної взаємодії з використанням криптографії для протоколів IPv4 та IPv6. Сервіси безпеки включають управління доступом, цілісність та конфіденційністьданих та захист від replay-атак, що забезпечується гарантуванням цілісності деякої послідовності дейтаграм. Ці послуги надаються лише на рівні IP , забезпечуючи захист для IP-протоколу і протоколів вищого рівня.

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

Розглянемо виконання протоколів IPSec, основні компоненти системи та їхню взаємодію для забезпечення сервісів безпеки.

IPSec виконується на хості ( Host – H) або шлюзі безпеки ( Security Gateway – SG), забезпечуючи захист IP-трафіку. Термін "шлюз безпеки" використовується для позначення маршрутизатора, який реалізує IPsec-протоколи.

Захист заснований на вимогах, визначених у базі даних політики безпеки ( Security Policy Database - SPD ), що встановлюється та підтримується адміністратором. У загальному випадку пакети обробляються одним із трьох способів, заснованих на інформації IP-заголовка та транспортного рівня відповідно до записів у SPD. Кожен пакет або відкидається або пропускається без обробки, або обробляється відповідно до запису SPD для цього пакета.

Можливі способи реалізації IPSec

Існує кілька способів реалізації IPSec на хості або спільно з маршрутизатором або міжмережевим екраном (для створення шлюзу безпеки).

1. інтеграція IPSec у конкретну реалізацію протоколу IP. Це вимагає доступу до коду IP і робиться як на хостах, так і на шлюзах безпеки.
2. "Bump-in-the-stack" (BITS) реалізації, коли IPSec реалізований "внизу" існуючої реалізації стека IP-протоколів, вбудовуючи свою реалізацію між стандартною реалізацією IP-протоколів та локальними мережними драйверами. Доступ до вихідного коду стека IP у цьому випадку не потрібний. Цей підхід зазвичай реалізується на хостах, коли IPSec реалізований у вигляді бібліотеки, що підключається.
3. Використання зовнішнього криптопроцесора. Зазвичай це називається "Bump-in-the-wire" (BITW) реалізацією. Такі реалізації можуть використовуватись як на хостах, так і на шлюзах. Зазвичай BITW-пристрої є IP-адресами.

Протоколи захисту трафіку та поняття безпечної асоціації

Надані IPSec сервіси захисту трафіку реалізуються за допомогою двох протоколів забезпечення безпечного трафіку: Authentication Header (AH) і Encapsulating Security Payload (ESP).

Для захисту трафіку в IPSec визначено такі протоколи:

1. Протокол Encapsulating Security Payload (ESP) забезпечує конфіденційність і цілісність протоколів, розміщених вище стеку протоколів і додатково може забезпечуватися анти-replay сервіс, тобто. цілісність деякої послідовності дейтаграм.
2. Протокол Authentication Header (AH) забезпечує цілісність протоколів, розміщених вище стеку протоколів і цілісність окремих полів IP-заголовка, які змінюються при пересиланні від відправника до одержувачу, додатково може забезпечуватися анти-replay сервіс, тобто. цілісність деякої послідовності дейтаграм. В IPSec v2 реалізація цього протоколу не є обов'язковою.
3. Параметри цих протоколів визначаються у протоколі розподілу ключів Internet Key Exchange (IKE).

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

SA є симплексним (односпрямованим) логічне з'єднання, що створюється між двома кінцевими точками, для забезпечення безпеки яких використовується один із протоколів IPSec. ESP і АН передають трафік SA. Весь трафік, що передається SA, обробляється відповідно до політики безпеки, заданої на кінцях з'єднання.

Опишемо різні аспекти управління SA, визначимо можливі способи управління політикою безпеки, способи обробки трафіку та управління SA.

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

Розглянемо SA тільки для одноадресних з'єднань.

Визначено два режими SA: режим транспорту та режим тунелювання. Транспортний режимвикористовується для створення VPN між двома хостами. IPv4 заголовок протоколу безпеки транспортного режиму з'являється відразу після IP-заголовка. У протоколі ESP транспортний режим SA забезпечує сервіси безпеки лише протоколів вищого рівня, але з IP -заголовка. У разі АН захист поширюється також і на окремі частини IP-заголовка.

Іншим режимом SA є режим тунелювання. Якщо одним із кінців з'єднання є шлюз безпеки, то за стандартами IPSec SA обов'язково має виконуватися в тунельному режимі, але багато виробників допускають у цьому випадку як тунельний, так і транспортний режими. Зауважимо, що коли трафік призначений для шлюзу безпеки, наприклад, у випадку ping- або SNMP-команд, шлюз безпеки розглядається як хост і зазвичай використовується транспортний режим. Два хости можуть за необхідності встановлювати тунельний режим.

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

Коротко підсумуємо:

1. Хостможе підтримувати обидва режими, як транспортний, і тунельний.
2. Шлюз безпекияк правило використовує тільки тунельний режим. Якщо він підтримує транспортний режим, то цей режим зазвичай використовується тільки тоді, коли безпечний шлюз є одержувачем трафіку, наприклад, для керування мережею.

Набір реалізованих

Подивилося: 8033

0 Давайте розглянемо деталі технологій, що становлять суть IPSec. Стандарти, що використовуються в рамках IPSec, досить складні для розуміння, тому в цьому розділі ми розглянемо кожну зі складових IPSec докладно. Для розуміння того, що таке IPSEC використовуйте документ "IPSEC як протокол захисту мережевого трафіку", опублікований раніше на цьому сайті. Ця стаття є продовженням вищезгаданого документа.

У IPSec використовуються такі технології:

• протокол АН;
• протокол ESP;
• стандарт шифрування DES;
• стандарт шифрування 3DES;
• протокол IKE;
• метод узгодження ключів за схемою Діффі-Хеллмана;
• хешовані коди автентичності повідомлень (НМАС);
• захист RSA;
• центри сертифікації.

Протокол АН

1. Виконується хешування IP-заголовка та корисного вантажу пакета.
2. Отриманий хеш-код використовується при побудові нового заголовка АН, який приєднується до вихідного пакета між заголовком та блоком корисного вантажу.
3. Новий пакет передається другій стороні IPSec.
4. Сторона-одержувач обчислює значення хеш-коду для заголовка IP та корисного вантажу, витягує передане значення хеш-коду із заголовка АН і порівнює ці два значення. Відповідні значення хеш-коду повинні точно збігатися. Якщо в дорозі зміниться хоча б один біт пакета, обчислений одержувачем хеш-код пакета не співпадатиме зі значенням, зазначеним у заголовку АН.

Протокол ESP

Протокол ESP забезпечує конфіденційність за допомогою шифрування на рівні пакетів IP. У цьому підтримується безліч алгоритмів симетричної схеми шифрування. Алгоритмом для IPSec є DES з 56-бітовим ключем. Цей шифр повинен бути присутнім для гарантії сумісності між усіма продуктами, що підтримують IPSec. Продукти Cisco також підтримують алгоритм 3DES, що забезпечує більш стійке шифрування. Конфіденційність може бути обрана незалежно від інших послуг.

Аутентифікація джерела даних та підтримка цілісності без встановлення з'єднань використовуються спільно та є опціями (тобто необов'язкові). Ці можливості також можна об'єднати з сервісом конфіденційності.
Сервіс захисту від відтворення можна вибрати лише в тому випадку, якщо вибрано аутентифікацію джерела даних, і вибір цього сервісу є виключною прерогативою одержувача. Хоча за замовчуванням від відправника і потрібно автоматично збільшувати порядковий номер, що використовується для захисту від відтворення, цей сервіс виявляється ефективним лише в тому випадку, якщо одержувач перевіряє цей порядковий номер. Конфіденційність трафіку вимагає вибору тунельного режиму. Найбільш ефективним це виявляється у шлюзі захисту, де маскування джерела-адресата може бути виконане відразу для всього трафіку. Тут слід зазначити, що хоч і конфіденційність, і аутентифікація є опціями, має бути обраний принаймні один із цих сервісів.
Набір сервісів, що забезпечуються протоколом ESP, залежить від параметрів, які вказуються в конфігурації IPSec та вибираються під час створення асоціації захисту IPSec. Однак вибір конфіденційності без цілісності/автентифікації (або в рамках ESP, або окремо за допомогою АН) залишає противнику можливість для проведення атак певного виду, що може обмежити користь сервісу конфіденційності, що застосовується таким чином.
Заголовок ESP вставляється в пакет після заголовка IP перед заголовком протоколу вищого рівня (у транспортному режимі) або перед заголовком інкапсульованого IP (в тунельному режимі). Повний опис протоколу ESP міститься у документі RFC 2406.

Шифрування ESP із застосуванням НМАС

В рамках протоколу ESP може також забезпечуватись аутентифікація пакетів за допомогою необов'язкового поля аутентифікації. У програмному забезпеченні Cisco IOS і брандмауерах PIX Firewall цей сервіс називається ESP НМАС. Значення автентифікації обчислюються після шифрування. Стандарт IPSec, що використовується сьогодні, описує алгоритми SHA1 і MD5 як обов'язкові для НМАС.
Головна відмінність між аутентифікацією ESP і аутентифікацією АН полягає у сфері їх охоплення. ESP не захищає жодних полів заголовка IP, якщо не передбачається інкапсуляція ESP (тунельний режим). На рис зазначено, які поля захищаються під час використання ESP НМАС.

Тунельний та транспортний режими IPSec

IPSec діє або в тунельному або транспортному режимі. На рис показано схему реалізації тунельного режиму. У цьому режимі вся вихідна дейтаграма IP шифрується і стає корисним вантажем у новому пакеті IP з новим заголовком IP та додатковим заголовком IPSec (на рис. заголовок позначений абревіатурою HDR). Тунельний режим дозволяє мережному пристрою (наприклад, брандмауер PIX Firewall) виступати в ролі шлюзу IPSec або проксі-сервера, що виконує шифрування для хостів, розміщених за брандмауером. Маршрутизатор джерела шифрує пакет і передає його тунелем IPSec. Брандмауер PIX Firewall адресата дешифрує отриманий пакет IPSec, отримує вихідну дейтаграму IP і передає її системі адресата. Головна перевага тунельного режиму полягає в тому, що не потрібно модифікувати кінцеві системи, щоб забезпечити можливість використання IPSec. Тунельний режим також дозволяє противнику аналізувати потік даних. При обміні в тунельному режимі противник має можливість визначити тільки кінцеві точки тунелю, але не справжніх джерела та адресата пакетів, що проходять через тунель, навіть якщо кінцеві точки тунелю знаходяться якраз у системах джерела та адресата.

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

Розглянемо кілька прикладів, що ілюструють правила вибору тунельного чи транспортного режиму. На рис нижче показані ситуації, у яких використовується тунельний режим. Цей режим найчастіше використовується для шифрування потоку даних між шлюзами захисту IPSec - наприклад між маршрутизатором Cisco і брандмау ером PIX Firewall. Шлюзи IPSec виконують функції IPSec для пристроїв, що знаходяться за такими шлюзами (на вказаному малюнку це персональний комп'ютер Аліси та сервери HR). У цьому прикладі Аліса отримує захищений доступ до серверів HR через тунель IPSec, встановлений між шлюзами.

Тунельний режим використовується для зв'язку кінцевих станцій, в яких виконується програмне забезпечення IPSec, наприклад для зв'язку клієнта CiscoSecure VPN і шлюзу IPSec.
У цьому прикладі тунельний режим використовується для створення тунелю IPSec між маршрутизатором Cisco та сервером, на якому виконується програмне забезпечення IPSec. Зверніть увагу на те, що у програмному забезпеченні Cisco IOS та брандмауера PIX Firewall тунельний режим для зв'язків IPSec є стандартним режимом.
Транспортний режим використовується між кінцевими станціями, що підтримують IPSec, або між кінцевою станцією та шлюзом, якщо шлюз інтерпретується як хост. На рис. Нижче показано приклад Г, що ілюструє застосування транспортного режиму для створення шифрованого тунелю IPSec від комп'ютера Аліси, на якому виконується програмне забезпечення клієнта Microsoft Windows 2000, до концентратора Cisco VPN 3000, що дозволяє Алісі використовувати L2ТР-тунель над IPSec.

Використання АН та ESP

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

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