Технології, що використовуються в IPSEC. IPsec VPN. Основи Esp шифрування

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

Отже, назва IPSec походить від IP Security.
IPSec – це сукупність протоколів та адлгоритмів, які використовуються для захисту IP пакетів на рівні Layer3.

IPSec дозволяє гарантувати:
- Confidentiality – за допомогою шифрування
- Data integrity - через Hashing та HMAC\
- Authentication – через використання Digital Signatures або Pre-shared key (PSK).

Перерахуємо основні протоколи IPsec:
■ ESP і AH: Два основні протоколи, що використовуються в IPsec
Encapsulating Security Payload (ESP), може робити все, що потрібно для IPsec, а
Authentication Header (AH)може робити все, крім шифрування, encryption of the data, - тому найчастіше використовують ESP.
■ Обробка algoritms для confidentiality: DES, 3DES, AES.
■Hashing algorithms for integrity: MD5, SHA.
■ Authentication algorithms: Pre-shared keys (PSK), RSA digital signatures.
■ Key management: An example would be Diffie-Hellman (DH), які можуть бути використані
dynamically generate symmetrical keys to be used by symmetrical algorithms; PKI,
which supports the function of digital certificates issued by trusted CAs; and Internet
Key Exchange (IKE), які є безліч з них і менеджменту
IPsec to operate.

Навіщо потрібний IPSec

Розглянемо наступну просту топологію з'єднання двох офісів.

Нам необхідно забезпечити з'єднання двох офісів та виконати такі цілі:

  • Confidentiality- Забезпечується через шифрування даних.
  • Data integrity- забезпечується через hashing, або через Hashed Message Authentication Code (HMAC), - методи, що дозволяють гарантувати, що дані не були змінені.
  • Authentication- забезпечується з використанням pre-shared keys (PSK), або digital signatures. А при використанні HMAC автентифікація відбувається постійно.
  • Antireplay protection- всі пакети VPN нумеруються, що є захистом від їхнього повторення.

Протоколи та порти IPSec

IKEv1 Phase 1 UDP port 500 IKEv1 Phase 1 використовує UDP:500 для його negociation.
NAT-T (NAT
Traversal) 		UDP port 4500 NAT Traversal використовується пристроями для подолання NAT. Якщо обидва пристрої підключаються один до одного через NAT: they want to put a fake UDP port 4500
header on each IPsec packet (before the ESP header) to
survive a NAT device that otherwise may have a problem
tracking an ESP session (Layer 4 protocol 50)
ESP Layer 4 Protocol
50 		Усі пакети IPSec являють собою Layer 4 protocol of ESP (IP Protocol # 50), в нього інкапсулюються всі дані. Зазвичай використовується саме ESP (а не AH). У разі використання NAT-T ESP header закривається другим UDP header.
AH Layer 4 protocol
51 		AH packets є Layer 4 protocol of AH (IP Protocol #51). AH не підтримує шифрування корисних даних, і тому він використовується рідко.

Робота IPSec

Для підняття безпечного з'єднання VPN, IPSec використовує протокол Internet Key Exchange (IKE).
IKE - це framework, що забезпечується Internet Security Association, а також Key Management Protocol (ISAKMP)

Отже у нашої конфігурації обидва роутери виступатимуть як VPN gatewayабо IPsec peers.

Припустимо користувач мережі 10.0.0.0 відправляє пакет у мережу 172.16.0.0.
Оскільки тунель ще не створений R1, почне initiate negotiations з другим роутером R2.

Step 1: Negotiate the IKEv1 Phase 1 Tunnel

Першим кроком між роутерами піднімається Internet Key Exchange (IKE) Phase 1 tunnel.
Такий тунель не призначений для передачі даних, але використовується в службових цілях, для захисту management traffic.

Підняття IKE Phase 1 tunnel може бути виконане у двох режимах:
- main mode
- Aggressive mode
Main mode вимагає обміну великою кількістюАле пакетів і вважається більш безпечним.

Для підняття IKE Phase 1 tunnel повинні бути куповані наступні елементи:

  • Hash algoritm: Це може бути message digest 5 algorithm (MD5)або Secure Hash
    Algorithm (SHA)    .
  • Encryption algorithm: Digital Encryption Standard (DES)(слабкий, не рекомендується), Triple DES (3DES)(трохи краще) or Advanced Encryption Standard (AES)(рекомендується) AES може використовувати ключі різної довжини: чим довше, тим безпечніше.
  • Diffie-Hellman (DH) group to use: The DH “group” refers to the modulus size
    key) to use for the DH key exchange. Group 1 uses 768 bits, group 2 uses 1024, and
    group 5 uses 1536. More secure DH groups є part of the next-generation encryption
    (NGE):
    - Group 14 or 24: Provides 2048-bit DH
    - Groups 15 and 16: Support 3072-bit and 4096-bit DH
    - Group 19 or 20: Supports the 256-bit and 384-bit ECDH groups, respectively

    Завдання DH - згенерувати keying material (symmetric keys). Ці ключі будуть використовуватись для передачі даних.
    Сам DH є asymmetrical , але ключі він генерує symmetrical.

  • Authentication метод: може бути у вигляді pre-shared key (PSK)або RSA signatures
  • Lifetime: брешемо життя IKE Phase 1 tunnel. Єдиний параметр, який може збігатися. Чим коротше Lifetime, тим частіше мінятимуть ключі, і тим це безпечніше.

Step 2: Run the DH Key Exchange

Після того, як роутери домовилися про IKE Phase 1 policy, вони можуть розпочати процес DH key exchange. DH дозволяє двом пристроям, між якими поки що немає secure connection, безпечно обмінятися симетричними ключами, які будуть використовуватися симетричними алгоритмами, наприклад AES.

Step 3: Authenticate the Peer

Останнє, що буде зроблено в IKE Phase 1 - це взаємна автентифікація хостів, яка може бути зроблена двома методами (PSK або RSA digital signatures)
Якщо аутентифікація пройшла успішно, IKE Phase 1 tunnel вважається піднятим. Тунель є двонаправленим.

Step 4: IKE Phase 2

Після того, як піднявся IKE Phase 1 tunnel, роутери починають піднімати IKE Phase 1 tunnel.
Як уже згадувалося, IKE Phase 1 tunnel є чисто службовим, management tunnel і через нього проходить весь трафік negotiation для підняття тунелю IKE Phase 2.
IKE Phase 2 tunnel також використовує алгоритми hashing та encryption.
Підняття IKE Phase 2 tunnel може бути виконане в одному режимі:
- Quick mode

IKE Phase 2 tunnel насправді і двох односпрямованих тунелів, тобто. можна сказати що створюються:
Один тунель IKE Phase 1 tunnel, який є bidirectional, що використовується для службових функцій.
І два тунелі IKE Phase 2, які є unidirectional, і які використовуються для шифрування корисного трафіку.
Всі ці тунелі також називаються як security agreements between the 2 VPN peersабо security associations (SA).
Кожен SA має власний унікальний номер.

Тепер, після того як було піднято IKE Phase 2 tunnel, всі пакети, що виходять із зовнішніх інтерфейсів, будуть зашифровані.

Приклад налаштування


Розглянемо приклад налаштування IPsec з прикладу даної схеми.

  1. Configure Interesting Traffic
    Для початку ми повинні визначити трафік, який ми шифруватимемо.
    Router R1
    ip access-list extended VPN-ACL permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

    Router R2

    ip access-list extended VPN-ACL permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
  2. Configure Phase 1 (ISAKMP)
    Phase 1 піднімає тунель, що використовується для службових цілей: обмін shared secret keys, authenticate, negotiate IKE security policies і т.д.
    Може бути створено кілька isakmp policies з різними пріоритетами.

    Router R1

    crypto isakmp key secretkey address 200.200.200.1

    Router R2

    crypto isakmp policy 1 encryption 3des hash md5 authentication pre-share group 2
    crypto isakmp key secretkey address 100.100.100.1

    Тут key є PSK(Preshared Key), що використовується роутерами для аутентифікації IKE Phase 1.

  3. Configure Phase 2 (IPSEc)
    Мета IKE Phase 2 Tunnel – передача корисного трафіку між хостами двох офісів.
    Параметри тунелю Phase 2 Tunnel групуються в sets, які називаються transform sets.
    Router R1
    crypto ipsec transform-set TRSET esp-3des esp-md5-hmac! crypto map VPNMAP 10 ipsec-isakmp set peer 200.200.200.1 set transform-set TRSET match address VPN-ACL ! interface FastEthernet0/0 crypto map VPNMAP

    Router R2

    crypto ipsec transform-set TRSET esp-3des esp-md5-hmac! crypto map VPNMAP 10 ipsec-isakmp set peer 100.100.100.1 set transform-set TRSET match address VPN-ACL ! interface FastEthernet0/0 crypto map VPNMAP

    На обох хостах використовувалася crypto ipsec transform-set TRSET esp-3des esp-md5-hmac.
    Це означає, що 3des буде використано для шифрування, а md5-hmac для автентифікації.

    crypto map еплаїться на інтерфейс. Криптокарта відстежує трафік, що відповідає заданим умовам. Наша криптокарта буде працювати з роутером з адресою 100.100.100.1, заданим ACL внутрішнім трафіком і застосовуватиме цей трафік transform-set TRSET.

Перевірка IPSec

Загалом список корисних команд наступний:
show crypto isakmp policy
show crypto map
show crypto isakmp sa detail
show crypto ipsec sa
show crypto engine connections active

На практиці найбільш корисним є наступне:


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

Режими роботи ipSec

Існує два режими роботи IPSec: транспортний та тунельний.

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

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

Узгодження перетворень IPSec

У ході роботи протоколу IKE ведуться переговори про перетворення IPSec (алгоритми захисту IPSec). Перетворення IPSec та пов'язані з ними алгоритми шифрування є такими:

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

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

    Стандарт DES (Data Encription Standard – стандарт шифрування даних).Алгоритм шифрування та дешифрування даних пакетів. Алгоритм DES використовується як у межах IPSec, і IKE. Для алгоритму DES використовується 56-бітовий ключ, що означає не тільки більш високе споживання обчислювальних ресурсів, а й надійніше шифрування. Алгоритм DES є симетричним алгоритмом шифрування, для якого потрібні ідентичні секретні ключі шифрування в пристроях кожної зі сторін IPSec. Для створення симетричних ключів застосовується алгоритм Діффі-Хеллмана. IKE та IPSec використовують алгоритм DES для шифрування повідомлень.

    "Потрійний" DES (3DES).Варіант DES заснований на використанні трьох ітерацій стандартного DES з трьома різними ключами, що практично потроює стійкість DES. Алгоритм 3DES використовується в рамках IPSec для шифрування та дешифрування потоку даних. Цей алгоритм використовує 168-бітовий ключ, що гарантує високу надійність шифрування. IKE та IPSec використовують алгоритм 3DES для шифрування повідомлень.

    AES(advanced encryption standard). Протокол AES використовує алгоритм шифрування Rine Dale4, який забезпечує значно надійніше шифрування. Багато криптографів вважають, що AES взагалі неможливо зламати. Наразі AES є федеральним стандартом обробки інформації. Він визначений як алгоритм шифрування використання урядовими організаціями США для захисту важливих, але несекретних відомостей. Проблема, пов'язана з AES, у тому, що його реалізації потрібна велика обчислювальна потужність проти аналогічними протоколами.

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

    Алгоритм MD5 (Message Digest 5).Алгоритм хешування, який застосовується для аутентифікації пакетів даних. У продуктах Cisco використовується обчислюваний за допомогою MD5 код НМАС (Hashed Message Authentication Code - хешований код автентичності повідомлення) - варіант коду автентичності повідомлення, якому забезпечується додатковий захистза допомогою хешування. Хешування являє собою процес одностороннього (тобто незворотного) шифрування, в результаті якого для вступу на вхід повідомлення довільної довжини виходить висновок фіксованої довжини. IKE, АН та ESP використовують MD5 для аутентифікації даних.

    Алгоритм SHA-1 (Secure Hash Algorithm-1 - захищений алгоритм хешування 1).Алгоритм хешування, який використовується для аутентифікації пакетів даних. У продуктах Cisco застосовується варіант коду НМАС, що обчислюється за допомогою SHA-1. IKЕ, АН та ESP використовують SHA-1 для автентифікації даних.

У рамках протоколу IKE симетричні ключі створюються за допомогою алгоритму Діффі-Хеллмана, що використовує DES, 3DES, MD5 та SHA. Протокол Діффі-Хеллмана є криптографічним протоколом, заснованим на застосуванні відкритих ключів. Він дозволяє двом сторонам узгодити загальний секретний ключ, не маючи достатньо надійного каналу зв'язку. Загальні секретні ключі потрібні для алгоритмів DES та НМАС. Алгоритм Діффі-Хеллмана використовується в рамках IKE для створення ключових сеансів. Групи Diffie-Hellman (DH) визначають «силу» ключа шифрування, який використовується в процедурі обміну ключами. Чим вищий номер групи, тим «сильніший» і безпечніший ключ. Однак слід враховувати той факт, що при збільшенні номер групи DH збільшується «сила» та рівень безпеки ключа, однак одночасно збільшується навантаження на центральний процесор, оскільки для генерації «сильнішого» ключа необхідно більше часу та ресурсів.

Пристрої WatchGuard підтримують DH групи 1, 2 та 5:

    DH group 1: 768-bit key

    DH group 2: 1024-bit key

    DH group 5: 1536-bit key

Обидва пристрої, які обмінюються даними через VPN, повинні використовувати одну і ту ж групу DH. Група DH, яка використовуватиметься пристроями, вибирається під час IPSec Phase 1 процедури.

Протоколи 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 дозволяє надійно захистити трафік у внутрішній мережі.

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

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

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

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

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

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

Протокол АН

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

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

Протокол ESP

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 НМАС.


Шифрування охоплює лише дані корисного вантажу, a ESP з хешуванням ESP НМАС - заголовок ESP і дані корисного вантажу. Заголовок IP не захищається. Сервіс ESP НМАС не може використовуватися самостійно, а повинен бути об'єднаний із протоколом шифрування ESP.

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

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


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


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

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

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

IPsec являє собою не один протокол, а систему протоколів, призначену для захисту даних на мережевому рівні IP-мереж. У цій статті буде описано теорію застосування IPsec для створення VPN тунелю.

Вступ

VPN, заснований на технології IPsec, можна розділити на дві частини:

  • Протокол Internet Key Exchange (IKE)
  • Протоколи IPsec (AH/ESP/both)

Перша частина (IKE) є фазою узгодження, під час якої дві VPN-точки вибирають які методи будуть використовуватися для захисту IP трафіку, що посилається між ними. Крім цього, IKE також використовується для управління з'єднаннями, для цього вводиться поняття Security Associations (SA) для кожного з'єднання. SA спрямовані лише в одну сторону, тому типове IPsec з'єднання використовує два SA.

Друга частина – це ті дані, які необхідно зашифрувати і аутентифікувати перед передачею методами, узгодженими в першій частині (IKE). Існують різні протоколи IPsec, які можна використовувати: AH, ESP чи обидва.

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

  • IKE узгоджує захист рівня IKE
  • IKE узгоджує захист рівня IPsec
  • дані, що захищаються передаються через VPN IPsec

IKE, Internet Key Exchange

Для шифрування та аутентифікації даних потрібно вибрати спосіб шифрування/аутентифікації (алгоритм) та ключі, що використовуються в них. Завдання Internet Key Exchange protocol, IKE, у разі зводиться до поширення даних “ключів сесії” і узгодження алгоритмів, якими захищатимуться дані між VPN-точками.

Основні завдання IKE:

  • Аутентифікація VPN-крапок один одного
  • Організація нових IPsec з'єднань (через створення SA пар)
  • Управління поточними з'єднаннями

IKE веде облік з'єднань шляхом призначення кожному з них такого собі Security Associations, SA. SA описує параметри конкретного з'єднання, включаючи протокол IPsec (AH/ESP або обидва), ключі сесії, які використовуються для шифрування/дешифрування та/або аутентифікації даних. SA є односпрямованою, тому використовується кілька SA на одне з'єднання. У більшості випадків, коли використовується тільки ESP або AH, створюються лише дві SA для кожного з підключень, одна для вхідного трафіку, а друга для вихідного. Коли ESP та AH використовуються разом, SA потрібно чотири.

Процес узгодження IKE відбувається через кілька етапів (фаз). Дані фази включають:

  1. IKE першої фази (IKE Phase-1):
    - Узгоджується захист самого IKE (ISAKMP tunnel)
  2. IKE другої фази (IKE Phase-2):
    — Узгоджується захист IPsec
    — Отримання даних із першої фази для формування ключів сесії

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

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

IKE першої фази - узгодження захисту IKE (ISAKMP Tunnel)
На першій фазі узгодження VPN-точки аутентифікують один одного на основі загального ключа (Pre-Shared Key). Для аутентифікації використовують хеш алгоритм: MD5, SHA-1, SHA-2.
Однак перед тим як аутентифікувати один одного, щоб не передавати інформацію відкритим текстом, точки VPN виконують обмін списками пропозицій (Proposals), описаний раніше. Тільки після того, як пропозиція обрана, що влаштовує обох VPN-точок, відбувається автентифікація VPN-точка один одного.
Аутентифікацію можна здійснювати різними способами: через загальні ключі (Pre-Shared Keys), сертифікати або . Загальні ключі є найпоширенішим способом автентифікації.
Узгодження IKE першої фази може відбуватися в одному з двох режимів: main (основний) та aggressive (агресивний). Основний режим більш тривалий, зате і захищений. У його процесії відбувається обмін шістьма повідомленнями. Агресивний режим відбувається швидше, обмежуючись трьома повідомленнями.
Основна робота першої фази IKE лежить в обміні ключами Діффі-Хеллмана. Він заснований на шифруванні з відкритим ключем, кожна зі сторін шифрує автентифікаційний параметр (Pre-Shared Key) відкритим ключем сусіда, який отримав це повідомленнярозшифровує його своїм закритим ключем. Інший спосіб аутентифікації сторін один одного - використання сертифікатів.

IKE другої фази – узгодження захисту IPsec
У другій фазі здійснюється вибір способу захисту IPsec підключення.
Для другої фази використовується матеріал (keying material) вилучений з обміну ключами Діффі-Хеллмана (Diffie-Hellman key exchange), що відбувся на першій фазі. На основі цього матеріалу створюються ключі сесії (session keys), що використовуються для захисту даних у VPN-тунелі.

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

Режим роботи другої фази узгодження IKE лише один, він називається quick mode – швидкий режим. У процесі узгодження другої фази відбувається обмін трьома повідомленнями.

Після закінчення другої фази встановлюється VPN-підключення.

Параметри IKE.
Під час встановлення з'єднання використовуються кілька параметрів, без узгодження яких неможливо встановити підключення VPN.

  • Ідентифікація кінцевих вузлів
    Як вузли аутентифікують один одного. Найчастіше використовується загальний ключ. Аутентифікація, заснована на загальному ключі, використовує алгоритм Діффі-Хеллмана.
  • Локальна та віддалена мережа/хост
    Визначає трафік, який пускатиметься через VPN-тунель.
  • Режим тунелю чи транспорту.
    IPsec може працювати у двох режимах: тунельному та транспортному. Вибір режиму залежить від об'єктів, що захищаються.
    Тунельний режимзастосовується захисту між віддаленими об'єктами, тобто. IP-пакет повністю інкапсулюється в новий і для спостерігача збоку буде видно лише з'єднання між двома VPN-точками. Реальні IP-адреси джерела та одержувача будуть видні лише після декапсуляції пакета при прийомі його на VPN-точці отримання. Таким чином, тунельний режим найчастіше використовується для VPN-підключень.
    Транспортний режимзахищає дані IP-пакету (TCP, UDP та протоколи верхніх рівнів), а сам заголовок оригінального IP-пакету буде збережено. Таким чином, для спостерігача буде видно оригінальне джерело і призначення, але не дані. Цей режим найчастіше використовується при захисті з'єднання локальної мережіміж хостами.
  • Віддалений шлюз
    VPN-точка одержувач захищеного з'єднання, яка розшифровуватиме/аутентифікуватиме дані з іншого боку і відправлятиме їх до остаточного місця призначення.
  • Режим роботи IKE
    IKE узгодження може працювати у двох режимах: Основнийі агресивному.
    Різниця між ними полягає в тому, що в агресивному режимі використовується менша кількість пакетом, що дозволяє досягти більш швидкого встановлення з'єднання. З іншого боку, агресивний режим не передає деякі параметри узгодження, такі як Діффі-Хеллман групи та PFS, що вимагає попереднього ідентичного настроювання їх на точках учасницях підключення.
  • IPsec протоколи
    Існує два протоколи IPsec: Authentication Header (AH) та Encapsulating Security Payload (ESP), які виконують функції шифрування та аутентифікації.
    ESP дозволяє шифрувати, аутентифікувати окремо або одночасно.
    AH дозволяє лише аутентифікувати. Різниця з ESP автентифікацією в тому, що AH аутентифікує також зовнішній IP заголовок, дозволяючи підтвердити, що пакет прибув дійсно від джерела вказаного в ньому.
  • IKE шифрування
    Вказує алгоритм шифрування IKE та його ключі. Підтримуються різні симетричні алгоритми шифрування, наприклад DES, 3DES, AES.
  • IKE автентифікація
    Алгоритм аутентифікації використовуваний у IKE узгодженні. Можуть бути: SHA, MD5.
  • IKE Діффі-Хеллмана (DH) групи
    Група DF для обміну ключами в IKE. Чим більше група, тим більше розмір ключів обміну.
  • Тривалість життя IKE підключення
    Вказується як у часі (секундах), і за розміром переданих даних (кілобайтах). Як тільки один із лічильників досягне порогового значення, запускається нова перша фаза. Якщо з моменту створення IKE з'єднання не було передано жодних даних, жодних нових підключень не буде створено доти, доки одна зі сторін не захоче створити VPN з'єднання.
  • PFS
    При відключеному PFS матеріал для створення ключів буде вилучено у першій фазі узгодження IKE у момент обміну ключів. У другій фазі узгодження IKE ключі сесії будуть створені ґрунтуючись на отриманому матеріалі. При увімкненому PFS під час створення нових ключів сесії матеріал для них буде використовуватися щоразу новий. Таким чином при компроматі ключа, на основі нього неможливо створити нові ключі.
    PFS може бути використаний у двох режимах: перший PFS на ключах (PFS on keys), запускатиме новий обмін ключами в першій фазі IKE щоразу, коли запускається узгодження
    другий фази. Другий режим PFS на ідентифікаторах (PFS on identities), видалятиме SA першої фази щоразу, після проходження узгодження другої фази, гарантуючи тим самим, що жодне узгодження другої фази не буде зашифроване ідентичним попереднім ключем.
  • IPsec DH групи
    Дані DF групи аналогічні тим, що використовуються в IKE, тільки використовуються для PFS.
  • IPsec шифрування
    Алгоритм, що використовується для шифрування даних. Використовується у разі використання ESP у режимі шифрування. Приклади алгоритмів: DES, 3DES, AES.
  • IPsec автентифікація
    Алгоритм використовується для аутентифікації даних, що передаються. Використовується у випадку AH або ESP у режимі автентифікації. Приклади алгоритмів: SHA, MD5.
  • Час життя IPsec
    Час життя VPN з'єднання вказується як за часом (секундами), так і за розміром переданих даних (кілобайти). Лічильник першим, хто досяг ліміту, запустить перестворення ключів сесії. Якщо з моменту створення IKE з'єднання не було передано жодних даних, жодних нових підключень не буде створено доти, доки одна зі сторін не захоче створити VPN з'єднання.

Методи аутентифікації IKE

  • Ручний режим
    Найпростіший із методів, при якому IKE не використовується, а ключі аутентифікації та шифрування, а також деякі інші параметри задаються вручну на обох точках підключення VPN.
  • Через загальні ключі (Pre-Shared Keys, PSK)
    Заздалегідь введений загальний ключ на обох точках з'єднання VPN. Відмінність від попереднього методу в тому, що використовується IKE, що дозволяє аутентифікувати кінцеві точки і використовувати ключі сесії, що змінюються, замість фіксованих ключів шифрування.
  • Сертифікати
    Кожна точка VPN використовує свій приватний ключ, свій відкритий ключ, свій сертифікат, що включає свій відкритий ключ і підписаний довіреним центром сертифікації. На відміну від попереднього методу, дозволяє уникнути введення одного загального ключа на всіх точках VPN з'єднання, замінюючи його особистими сертифікатами, підписаними довіреним центром.

Протоколи IPsec

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

AH (Authentication Header)

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

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

ESP (Encapsulating Security Payload)

ESP протокол використовується для шифрування, для аутентифікації або і того, і іншого щодо IP пакета.

У режимі транспорту ESP протокол вставляє свій заголовок після оригінального IP заголовка.
У режимі тунелю ESP заголовок знаходиться після зовнішнього (нового) IP заголовка та перед внутрішнім (оригінальним).

Дві основні відмінності між ESP і AH:

  • ESP крім аутентифікації надає можливість шифрування (AH цього не надає)
  • ESP у режимі тунелю аутентифікує лише оригінальний IP-заголовок (AH аутентифікує також зовнішній).

Робота за NAT (NAT Traversal)
Для підтримки роботи за NAT було реалізовано окрему специфікацію. Якщо точка VPN підтримує цю специфікацію, IPsec підтримує роботу за NAT, однак існують певні вимоги.
Підтримка NAT складається із двох частин:

  • На рівні IKE кінцеві пристрої обмінюються один з одним інформацією про підтримку, NAT Traversal і версією специфікації, що підтримується.
  • На рівні ESP сформований пакет інкапсулюється в UDP.

NAT Traversal використовується лише у тому випадку, якщо обидві точки підтримують його.
Визначення NAT: обидві точки VPN посилають хеші своїх IP адрес разом з UDP портом джерела IKE узгодження. Ця інформація використовується одержувачем, щоб визначити, чи було змінено IP адресу та/або порт джерела. Якщо ці параметри були змінені, то трафік не проходить через NAT і механізм NAT Traversal не потрібен. Якщо адресу або порт змінено, то між пристроями знаходиться NAT.

Як тільки кінцеві точки визначать, що необхідний NAT Traversal, узгодження IKE переміщуються з порту UDP 500 на порт 4500. Це робиться тому, що деякі пристрої неправильно обробляють IKE сесію на порту 500 при використанні NAT.
Інша проблема виникає через те, що ESP протокол – протокол транспортного рівня та розташовується безпосередньо поверх IP. Через це до нього не застосовні поняття TCP/UDP порту, що унеможливлює підключення через NAT більше одного клієнта до одного шлюзу. Для вирішення цієї проблеми ESP запаковується в UDP дейтаграму і посилається на порт 4500, той самий, який використовує IKE при включеному NAT Traversal.
NAT Traversal вбудований у роботу протоколів, що його підтримують і працює без попереднього налаштування.



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