IPsec

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
Версія для друку більше не підтримується і може мати помилки обробки. Будь ласка, оновіть свої закладки браузера, а також використовуйте натомість базову функцію друку у браузері.
Модель TCP/IP (RFC 1122)
Прикладний рівень
Транспортний рівень
Мережевий рівень
Канальний рівень
Цей шаблон:
Протоколи безпеки
Інтернет
Керування ключами
Рівень застосувань
Система доменних імен
Рівень Інтернет

IPsec (скорочення від IP Security) — набір протоколів для забезпечення захисту даних, що передаються за допомогою протоколу IP, дозволяє здійснювати підтвердження справжності та/або шифрування IP-пакетів. IPsec також містить в собі протоколи для захищеного обміну ключами в мережі Інтернет.

Стандарти

  • RFC 2401 (Security Architecture for the Internet Protocol) — Архітектура захисту для протоколу IP.
  • RFC 2402 (IP Authentication header) — аутентифікаційні заголовок IP.
  • RFC 2403 (The Use of HMAC-MD5-96 within ESP and AH) — Використання алгоритму хешування MD-5 для створення аутентифікаційні заголовка.
  • RFC 2404 (The Use of HMAC-SHA-1-96 within ESP and AH) — Використання алгоритму хешування SHA-1 для створення аутентифікаційні заголовка.
  • RFC 2405 (The ESP DES-CBC Cipher Algorithm With Explicit IV) — Використання алгоритму шифрування DES.
  • RFC 2406 (IP Encapsulating Security Payload (ESP)) — Шифрування даних.
  • RFC 2407 (The Internet IP Security Domain of Interpretation for ISAKMP) — Область застосування протоколу управління ключами.
  • RFC 2408 (Internet Security Association and Key Management Protocol (ISAKMP)) — Управління ключами і аутентифікатором захищених з'єднань.
  • RFC 2409 (The Internet Key Exchange (IKE)) — Обмін ключами.
  • RFC 2410 (The NULL Encryption Algorithm and Its Use With IPsec) — Нульовий алгоритм шифрування і його використання.
  • RFC 2411 (IP Security Document Roadmap) — Подальший розвиток стандарту.
  • RFC 2412 (The OAKLEY Key Determination Protocol) — Перевірка відповідності ключа.

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

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

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

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

Security Association

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

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

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

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

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

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

В SADB містяться:

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

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

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

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

Authentication Header

Authentication Header format
Offsets Octet16 0 1 2 3
Octet16 Bit10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Next Header Payload Len Reserved
4 32 Security Parameters Index (SPI)
8 64 Sequence Number
C 96 Integrity Check Value (ICV)
…
… …
Next Header (8 bits)
Тип заголовка протоколу, що йде після заголовка AH. По цьому полю приймальний IP-sec модуль дізнається про захищається протоколі верхнього рівня. Значення цього поля для різних протоколів можна подивитися в RFC 1700.
Payload Len (8 bits)
Це поле визначає загальний розмір АН-заголовка в 32-бітових словах, мінус 2. Незважаючи на це, при використанні IPv6 довжина заголовка повинна бути кратна 8 байтам.
Reserved (16 bits)
Зарезервовано. Заповнюється нулями.
Security Parameters Index (32 bits)
Індекс параметрів безпеки. Значення цього поля разом з IP-адресою одержувача і протоколом безпеки (АН-протокол), однозначно визначає захищене віртуальне з'єднання (SA) для даного пакета. Діапазон значень SPI 1 … 255 зарезервований IANA.
Sequence Number (32 bits)
Послідовний номер. Служить для захисту від повторної передачі. Поле містить монотонно зростаюче значення параметра. Незважаючи на те, що одержувач може відмовитися від послуги із захисту від повторної передачі пакетів, воно є обов'язковим і завжди присутній в AH-заголовку. Передавальний IPsec-модуль завжди використовує це поле, але одержувач може його і не обробляти.
Integrity Check Value
Контрольна сума. Повинна бути кратна 8-байтам для IPv6, і 4-байтам для IPv4.

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

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

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

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

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

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

Encapsulating Security Payload

Encapsulating Security Payload format
Offsets Octet 16 0 1 2 3
Octet 16 Bit 10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Security Parameters Index (SPI)
4 32 Sequence Number
8 64 Payload data
… …
… …
… … Padding (0-255 octets)
… … Pad Length Next Header
… … Integrity Check Value (ICV)
…
… …
Security Parameters Index (32 bits)
Індекс параметрів безпеки. Значення цього поля разом з IP-адресою одержувача і протоколом безпеки (АН-протокол), однозначно визначає захищене віртуальне з'єднання (SA) для даного пакета. Діапазон значень SPI 1 … 255 зарезервований IANA для подальшого використання.
Sequence Number (32 bits)
Послідовний номер. Служить для захисту від повторної передачі. Поле містить монотонно зростаюче значення параметра. Незважаючи на те, що одержувач може і відмовитися від послуги із захисту від повторної передачі пакетів, воно завжди присутній в AH-заголовку. Відправник (передавальний IPsec-модуль) повинен завжди використовувати це поле, але одержувач може і не мати потребу в його обробці.
Payload data (variable)
Це поле містить дані відповідно до полем «Next Header». Це поле є обов'язковим і складається з цілого числа байтів. Якщо алгоритм, який використовується для шифрування цього поля, вимагає даних для синхронізації криптопроцесів (наприклад, вектор ініціалізації — «Initialization Vector»), то це поле може містити ці дані в явному вигляді.
Padding (0-255 octets)
Доповнення. Необхідно, наприклад, для алгоритмів, які вимагають, щоб відкритий текст був кратний певному числу байтів), наприклад, розміром блоку для блочного шифру.
Pad Length (8 bits)
Розмір доповнення (в байтах).
Next Header (8 bits)
Це поле визначає тип даних, що містяться в поле «Payload data».
Integrity Check Value
Контрольна сума. Повинна бути кратна 8-байтам для IPv6, і 4-байтам для IPv4.


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

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

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

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

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

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

Посилання

{{{alt}}} Це незавершена стаття про комп'ютерні мережі.
Ви можете допомогти проєкту, виправивши або дописавши її.
Отримано з https://uk.wikipedia.org/w/index.php?title=IPsec&oldid=42209838