Презентація на тему:
Захист інформації в операційних системах, базах даних і мережах

Захист інформації в операційних системах, базах даних і мережах Віртуальні приватні мережі - VPN

План Поняття про віртуальні захищені (приватні) мережі (VPN) Види віртуальних приватних мереж Сервіси VPN Способи утворення захищених тунелів Рівні реалізації VPN Протоколи: SSL, SOCKS, IPSec, PPTP, L2F, L2TF

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

Поняття про віртуальні приватні мережі (VPN) Об’єднання локальних мереж і окремих комп’ютерів через відкрите зовнішнє середовище передавання інформації в єдину віртуальну мережу, яка забезпечує захист інформації, що в ній циркулює, називається захищеною (або приватною) віртуальною мережею (англ. – Virtual Private Network, VPN) Термін “віртуальна” означає, що така мережа формується як деяка підмножина реальної мережі, з каналами зв’язку, що моделюються реальними каналами Особливою ознакою віртуальної приватної (захищеної) мережі є її відокремлення від реальної мережі, яке повинне бути достатньо надійним для гарантування конфіденційності та цілісності інформації, що в ній передається, а також для забезпечення автентифікації сторін і унеможливлення відмовлення від авторства (англ. – Non-Repudiation)

Види віртуальних приватних мереж виділяють три основних види віртуальних приватних мереж: VPN віддаленого доступу (англ. – Remote Access VPN) корпоративні VPN (англ. – Intranet VPN) міжкорпоративні VPN (англ. – Extranet VPN)

VPN віддаленого доступу Віртуальні приватні мережі віддаленого доступу дозволяють значно скоротити витрати на використання комутованих та виділених ліній Принцип їх роботи: користувачі встановлюють з’єднання з місцевою точкою доступу до глобальної мережі (точкою присутності провайдера Інтернет) дані, які передають користувачі, “тунелюються” через Інтернет, що дозволяє уникнути плати за міжміський та міжнародний зв’язок дані від усіх користувачів концентруються на спеціальних пристроях – шлюзах віртуальної приватної мережі – и передаються у корпоративну мережу Суттєва економія від застосування цього типу VPN є потужним стимулом, але використання відкритого Інтернет в якості магістралі для транспорту чутливого (конфіденційного) корпоративного трафіка приймає погрожуючі розміри, що робить механізми захисту інформації життєво важливими елементами цієї технології

Корпоративна мережа VPN Організації, що бажають організувати для своїх філій та відділень доступ до централізованих сховищ інформації, звичайно підключають віддалені вузли через виділені лінії або з використанням технології Frame Relay Використання виділених ліній означає зростання поточних витрат по мірі збільшення смуги пропускання та відстані між об’єктами Витрати на зв’язок по виділеним лініям перетворюються в одну з головних статей витрат на експлуатацію корпоративної інформаційної системи Для скорочення витрат організація може з’єднати вузли за допомогою віртуальної приватної мережі Для цього достатньо відмовитись від використання дорогих виділених ліній, замінивши їх більш дешевим зв’язком через Інтернет Це суттєво скорочує витрати, оскільки в Інтернеті відстань ніяк не впливає на вартість з’єднання

Міжкорпоративна мережа VPN Extranet – це мережна технологія, яка забезпечує прямий доступ з мережі однієї організації до мережі іншої організації і таким чином сприяє підвищенню якості зв’язку, що підтримується в ході ділового співробітництва Мережі Extranet VPN в цілому подібні до корпоративних VPN з тією різницею, що проблема захисту інформації є для них ще гострішою Коли кілька організацій приймають рішення працювати разом і відкривають одна для одної свої мережі, вони повинні потурбуватись про те, щоби їхні нові партнери мали доступ лише до визначеного кола інформації При цьому конфіденційна інформація повинна бути надійно захищеною від несанкціонованого використання У міжкорпоративних мережах велике значення повинно надаватись контролю доступу з використанням міжмережних екранів (англ. – Firewalling) Також особливо важливою є автентифікація користувачів, яка повинна гарантувати, що доступ до інформації отримують лише ті, кому він дійсно дозволений Розгорнута система захисту від несанкціонованого доступу повинна бути максимально прозорою і не вимагати втручання користувачів

Сервіси VPN Забезпечення конфіденційності Забезпечення цілісності Автентифікація та запобігання відмовленню від авторства

Забезпечення конфіденційності Найпростішим і найпоширенішим способом забезпечення конфіденційності інформації є її шифрування, або криптографічне закриття Незважаючи на те, що самі алгоритми шифрування дуже складні, їх реалізація великих утруднень не викликає Доволі значну проблему становить керування ключами, особливо в разі значного збільшення кількості користувачів В реалізації VPN керування ключами є одною з головних проблем, що потребує надійного і ефективного рішення Шифрування має неминучий побічний ефект – деяку втрату продуктивності Апаратно реалізоване шифрування звільняє пристрої захисту від додаткового навантаження, пов’язаного з виконанням алгоритмів шифрування, і забезпечує кодування трафіка без втрати швидкості обміну У разі здійснення атаки на засоби захисту VPN існує загроза підміни програмних компонентів, в тому числі саме тих, що забезпечують шифрування. Загроза несанкціонованого впливу на апаратні засоби є значно менш ймовірною Для апаратної реалізації шифрування застосовуються спеціалізовані інтегральні схеми прикладної орієнтації (англ. – Application-Specific Integrated Circuit, ASIC)

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

Автентифікація та запобігання відмовленню від авторства Запобігання відмовленню від авторства (англ. – Non-Repudiation) – це додаткова функція, що реалізується на базі автентифікації У захищеному спілкуванні часто виникають випадки, коли крім підтвердження того, що абонент є саме тим, за кого він себе намагається видати, важливо отримати незаперечні докази того, що повідомлення одержано від конкретного користувача Також буває необхідним доказове підтвердження того, що певний користувач дійсно одержав деяке повідомлення Ці функції захисту у ряді випадків повинні бути невід’ємною складовою реалізації VPN

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

Кінцеві точки тунелю співпадають з кінцевими точками потоку повідомлень Цей варіант є найкращим з міркувань безпеки Приклади кінцевих точок: сервер у центральному офісі компанії і робоча станція користувача у віддаленій філії портативний комп’ютер співробітника, який перебуває у відрядженні Перевагою такого варіанту є те, що захист інформаційного обміну забезпечується на всьому шляху пакетів повідомлень Суттєвий недолік цього варіанту – децентралізація керування Засоби утворення захищених тунелів повинні встановлюватись і належним чином налаштовуватись на кожному клієнтському комп’ютері, що у великих мережах є занадто трудомісткою задачею

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

Кінцеві точки захищеного тунелю – засоби, що встановлені на теренах провайдерів Інтернету Переваги: Виключається найскладніша задачу – адміністрування засобів утворення захищених тунелів, що встановлені на комп’ютерах (в тому числі портативних пристроях), з яких здійснюється віддалений доступ Підвищена масштабованість і керованість мережі Прозорість доступу Аргументація на користь припустимості такого зниження захищеності: Саме Інтернет, як і інші мережі з комутацією пакетів, є найбільш вразливими для дій порушників Канали телефонної мережі та виділені лінії, які використовуються між кінцевими вузлами віддаленого доступу і провайдерами, і які в цьому випадку є незахищеними, не настільки вразливі Одночасно з економією коштів на адмініструванні кінцевих вузлів зростають витрати на послуги провайдерів, крім того, провайдеру при цьому необхідно довіряти

Рівні реалізації VPN Реалізація VPN можлива засобами протоколів Сеансового рівня (SSL/TLS, SOCKS) Мережного рівня (IPsec) Канального рівня (PPTP, L2TP) Поза розглядом залишаються системи шифрування на прикладному рівні, які реалізуються у деяких протоколах (SHTTP тощо), або просто деякими спеціальними прикладними програмами (наприклад, PGP) Зазначені засоби здатні забезпечити захист інформаційного обміну, але вони не є прозорими для прикладних програм як правило, вони не забезпечують усіх необхідних функцій вони не відносяться до засобів утворення VPN

Захист віртуальних каналів на канальному рівні Утворення захищених тунелів на канальному рівні моделі OSI забезпечує незалежність від протоколів мережного рівня і всіх вищих рівнів Таким чином досягається максимальна прозорість VPN Недоліки: Ускладнюються задачі конфігурації і підтримки віртуальних каналів Ускладнюється керування криптографічними ключами Зменшується набір реалізованих функцій безпеки В якості протоколів на цьому рівні використовуються: PPTP (англ. – Point-to-Point Tunneling Protocol) L2F (англ. – Layer-2 Forwarding) L2TP (англ. – Layer-2 Tunneling Protocol) Усі названі протоколи не специфікують протоколи автентифікації та шифрування

Протокол PPTP Протокол PPTP (англ. – Point-to-Point Tunneling Protocol) був розроблений компанією Microsoft за підтримки компаній Ascend Communications, 3Com/Primary Access, ECI-Telematics та US Robotics Фактично, цей протокол є розширенням протоколу PPP (англ. – Point-to-Point Protocol), яке дозволяє створювати криптозахищені тунелі на канальному рівні моделі OSI IETF RFC-2637, Point-to-Point Tunneling Protocol (PPTP) / K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn. – July 1999 Протокол PPTP отримав статус проекту стандарту Internet, однак в якості стандарту так і не був затверджений. Головне призначення протоколу – організація доступу віддалених користувачів до локальних мереж як у випадку прямого з’єднання віддаленого комп’ютера з публічною мережею, так і у випадку підключення до публічної мережі по телефонній лінії через провайдера При цьому для віддаленого користувача, який підключений до локальної мережі через сервер віддаленого доступу (RAS), імітується знаходження його комп’ютера безпосередньо в локальній мережі. Це досягається завдяки тунелюванню пакетів повідомлень.

Автентифікація в PPTP Для автентифікації в PPTP можуть застосовуватись різні протоколи В реалізації PPTP від Microsoft підтримуються протоколи: PAP (англ. – Password Authentication Protocol – протокол автентифікації за паролем) Передбачає передачу ідентифікаторів і паролів у відкритому вигляді CHAP (англ. – Challenge-Handshaking Authentication Protocol – протокол автентифікації за процедурою рукостискання) Передбачає одержання від сервера випадкового числа і шифрування на ньому пароля Таким чином, не лише пароль не передається по мережі у відкритому вигляді, але й зашифровані образи пароля кожного разу різні

Структура пакетів PPTP Вихідні пакети (IP, IPX або NetBEUI), якими здійснюється інформаційний обмін між комп’ютером віддаленого користувача і локальною мережею, зашифровуються та інкапсулюються у пакети PPP Протокол PPP є стандартним протоколом віддаленого доступу, і в протоколі PPTP він застосовується: для взаємодії віддаленого комп’ютера з RAS провайдера для його взаємодії через тунель з RAS локальної мережі Пакет PPP разом з додатковою інформацією, що міститься у заголовку GRE (англ. – General Routing Encapsulation – загальний метод інкапсуляції для маршрутизації), інкапсулюються у пакет IP

Схеми застосування протоколу PPTP У протоколі PPTP передбачені три схеми його застосування: пряме з’єднання комп’ютера віддаленого користувача з Інтернет комп’ютер віддаленого користувача з’єднується з Інтернет по телефонній лінії через провайдера, криптозахищений тунель утворюється між сервером провайдера і граничним маршрутизатором локальної мережі комп’ютер віддаленого користувача з’єднується з Інтернет по телефонній лінії через провайдера, криптозахищений тунель утворюється між кінцевими точками взаємодії

Пряме з’єднання комп’ютера віддаленого користувача з Інтернет за протоколом PPTP Вимагає встановлення: на комп’ютері віддаленого користувача клієнта RAS драйвера PPTP на сервері віддаленого доступу локальної мережі сервера RAS драйвера PPTP В продуктах Microsoft відповідні програмні компоненти реалізовані

Криптозахищений тунель утворюється між сервером провайдера і граничним маршрутизатором локальної мережі Ця схема передбачає захист трафіка, що проходить через Інтернет, але не захищає обмін між комп’ютером віддаленого користувача і провайдером Інтернет Недоліки: необхідність довіряти провайдеру підвищення витрат на послуги провайдера сервер віддаленого доступу провайдера повинен підтримувати протокол PPTP PPTP є “рідним” для продуктів Microsoft, а провайдери, як правило, обирають в якості RAS інші засоби

Криптозахищений тунель утворюється між кінцевими точками взаємодії Від провайдера нічого додаткового не вимагається Ця схема менш зручна для кінцевого користувача, оскільки він має двічі встановлювати з’єднання: спочатку за протоколом PPP з RAS провайдера (виконуючи необхідну процедуру автентифікації) потім, після отримання доступу до Інтернет, за протоколом PPTP з RAS локальної мережі (подібно до першої схеми) Єдиний вихід, який при цьому пропонують – використовувати написання сценаріїв, які автоматизують дії користувача Але при цьому паролі вписуються у сценарій

Протокол L2F Розроблений компанією Cisco Systems за підтримки компаній Shiva та Northern Telecom IETF RFC-2341, Cisco Layer Two Forwarding (Protocol) «L2F» / A. Valencia, M. Littlewood, T. Kolar. – May 1998 На відміну від PPTP, L2F значно зручніший для провайдерів Інтернет L2F підтримує різні мережні протоколи крім протоколу PPP для зв’язку комп’ютера віддаленого користувача із сервером провайдера можуть застосовуватись протоколи SLIP та інші публічна мережа, яка з’єднує сервери провайдера і локальної мережі, не обов’язково повинна бути IP-мережею В цілому, L2F дуже подібний до PPTP (аналогічна структура пакету) Схема застосування протоколу L2F подібна до схеми 2 застосування протоколу PPTP (Захищений тунель утворюється лише між сервером провайдера і сервером локальної мережі) Це означає прозорість для кінцевих вузлів Не забезпечується захист з’єднання комп’ютера віддаленого користувача із сервером провайдера У цій схемі застосування протоколу PPTP передбачалось, що дані про облікові записи користувачів повинні зберігатись у провайдера, в L2F вони повинні знаходитись лише на сервері локальної мережі Для утворення криптозахищеного тунелю між кінцевими точками інформаційного обміну в L2F пропонується використовувати IPSec

Протокол L2TP Протокол L2TP розроблений організацією IETF на основі протоколів PPTP і L2F IETF RFC-2661, Layer Two Tunneling Protocol «L2TP» / W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter. – August 1999 Протокол увібрав в себе кращі риси PPTP і L2F і підтримує також деякі додаткові функції Обмеженням протоколу, як і в L2F, є те, що не забезпечується захист з’єднання комп’ютера віддаленого користувача із сервером провайдера Захищений тунель утворюється лише між сервером провайдера і сервером локальної мережі Як і в L2F, пропонується використання IPSec для утворення захищених тунелів між кінцевими точками

Захист віртуальних каналів на мережному рівні Утворення захищених віртуальних каналів на мережному рівні дозволяє досягти оптимального співвідношення між прозорістю і якістю захисту Реалізація засобів захисту на цьому рівні робить їх прозорими для мережних застосувань, оскільки мережний рівень завжди буде відокремлений від застосування реалізацією транспортного рівня З іншого боку, на мережному рівні можлива достатньо повна реалізація функцій захисту трафіка і керування ключами, оскільки саме мережний рівень відповідає за маршрутизацію пакетів Стандартні засоби захисту на мережному рівні для IP мережі визначаються набором протоколів IPSec (англ. – Internet Protocol Security) IPSec є складовою частиною IPv6 IPSec є сумісним з версією протоколу IPv4 (підтримка IPSec не є обов’язковою, але бажана, і в наш час, як правило, реалізована) IPSec вимагає підтримки стандарту IPSec лише від пристроїв по обидва боки з’єднання, що спілкуються між собою Всі інші пристрої, що розташовані між ними, просто забезпечують передачу IP-пакетів

Архітектура засобів захисту IPSec Технологія IPSec охоплює кілька абсолютно різних областей, в число яких входять: шифрування, автентифікація керування ключами Відповідно до IPSec, архітектура засобів безпеки інформаційного обміну поділяється на три рівня RFC-4301, Security Architecture for the Internet Protocol / S. Kent, K. Seo. – December 2005

Рівні архітектури IPSec Верхній рівень – протоколи захисту віртуального каналу і узгодження параметрів захисту Протоколи AH та ESP не залежать від конкретних алгоритмів шифрування й автентифікації. Можуть застосовуватись різні: методи автентифікації типи ключів алгоритми шифрування та розподілу ключів Протоколи AH та ESP зареєстровані організацією IANA (Internet Address Naming Authority) під номерами 51 та 50, відповідно Середній рівень – криптографічні алгоритми, що використовуються в протоколах AH та ESP, а також певні алгоритми узгодження і керування ключами, які використовує протокол ISAKMP Нижній рівень – так званий “домен інтерпретації” (Domain of Interpretation, DOI) Це, фактично, база даних, яка містить інформацію про усі протоколи і алгоритми, що застосовуються в IPSec, а також про їхні параметри, ідентифікатори тощо Наявність такої бази пояснюється тим, що відкрита архітектура IPSec припускає застосування протоколів і алгоритмів, які не розроблялись для неї чи з урахуванням її вимог Необхідною умовою застосування сторонніх алгоритмів автентифікації або шифрування (наприклад, тих, що відповідають національним стандартам) є реєстрація їх у домені інтерпретації

Архітектура засобів захисту IPSec

Верхній рівень IPSec Протокол автентифікаційного заголовку (Authentication Header, AH) RFC-4302, IP Authentication Header / S. Kent. – December 2005 Протокол AH передбачає автентифікацію джерела даних перевірку їхньої цілісності і справжності після одержання захист від нав’язування повторних повідомлень Протокол інкапсулюючого захисту вмісту (Encapsulating Security Payload, ESP) RFC-4303, IP Encapsulating Security Payload (ESP) / S. Kent. – December 2005 Протокол ESP крім усіх функцій протоколу AH забезпечує ще й криптографічне закриття пакетів повідомлень Протокол узгодження параметрів віртуального каналу й керування ключами (англ. – Internet Security Association Key Management Protocol, ISAKMP) RFC-4306, Internet Key Exchange (IKEv2) Protocol / C. Kaufman, Ed. – December 2005 Призначений для попереднього узгодження алгоритмів та їхніх параметрів сторонами, що взаємодіють за протоколами AH та ESP Забезпечує створення сторонами, що взаємодіють, спільного контексту, елементи якого в подальшому вони можуть вільно використовувати.

Асоціації захисту (SA) Контекст, у якому взаємодіють сторони, що використовують технологію IPSec, визначають терміном “асоціація захисту” (Security Association, SA) Асоціація захисту функціонує на основі угоди, що заключається сторонами Елементами асоціації захисту є: учасники зв’язку: IP-адреси відправника й одержувача; криптографічний алгоритм; порядок обміну ключами; розміри ключів; термін дії ключів; алгоритм автентифікації. Асоціації захисту утворюються відповідно до протоколу ISAKMP

Автентифікаційний заголовок (AH) Поле SPI (Security Parameters Index) – це “покажчик параметрів безпеки” 32-розрядне число, що вказує на протоколи захисту, що використовуються В це поле включені індекси алгоритмів і типи ключів Фактично, воно визначає асоціацію захисту Порядковий номер (Sequence Number) визначає кількість пакетів, що відправлені, і забезпечує захист від хибного повторення даних

Протокол інкапсулюючого захисту (ESP)

Протокол інкапсулюючого захисту (ESP) Протокол ESP забезпечує шифрування IP-інформації на рівні пакетів Передбачено використання різних алгоритмів шифрування Протокол ESP забезпечує автентифікацію даних із застосуванням різних алгоритмів автентифікації Слід звернути увагу на таке: заголовок ESP розташований між заголовком IP та рештою вмісту пакета; поля покажчика SPI та порядкового номера виконують ту ж функцію, що й у заголовку AH; поле заголовку TCP (або UDP, або іншого протоколу), дані та кінцевик (трейлер) ESP зашифровані; поле вирівнювання має змінну довжину в діапазоні 0-255 біт, і забезпечує, по-перше, що поле “Наступний заголовок” закінчується на межі 32-розрядного слова, а по-друге, що розмір зашифрованої частини кратний розміру блоку застосованого алгоритму шифрування; ESP забезпечує автентифікацію даних у тому ж порядку, що й AH.

Режим тунелювання та транспортний режим Як для AH, так і для ESP існують два режими Транспортний режим (Transport Mode) Призначений для забезпечення зв’язку між двома хостами Не передбачає інкапсуляції IP-пакета в інший пакет У випадку прослуховування трафіка, порушник зможе прочитати справжні IP-адреси відправника й одержувача Режим тунелювання (Tunnel Mode) Весь IP-пакет поміщається в поле даних пакета IPSec. Далі для пакета вказується нові IP-адреси відправника та одержувача, і додаються захисні заголовки та автентифікаційні трейлери. В новому заголовку адреси відправника й одержувача відрізняються від тих, що вказані у вихідному пакеті Порушник, який несанкціоновано перехопив пакет, не зможе встановити, які саме станції спілкуються між собою Заголовок ESP не шифрується, щоби станція, що приймає повідомлення, мала змогу зрозуміти, що одержаний пакет є пакетом IPSec ESP Вихідний IP-заголовок, дані TCP, інформація, яку передають, та кінцевик ESP шифруються. Ці елементи складають вміст поля даних зовнішнього пакета

Транспортний режим Режим тунелювання

Обмін ключами В IPSec застосовуються два способи передачі ключів: Вручну Ключі вручну завантажуються у відповідні пристрої IPsec безпосередньо на об’єктах Шифруванню ці ключі не піддаються, вони або передаються системному адміністратору особисто, або надсилаються поштою Введення ключів вручну виправдано лише у невеликій мережі Шляхом обміну через IP-мережу (Internet Key Exchange, IKE) Коли масштаби мережі зростають, виникає потреба в механізмі створення асоціацій захисту за вимогою (SA on Demand) За створення асоціацій захисту відповідає протокол ISAKMP, який описує базові технології, але не специфікує конкретні алгоритми Для обміну ключами можуть застосовуватись окремі протоколи Був обраний протокол Oakley, що використовує алгоритм Діффі-Хелмана Поєднання протоколів ISAKMP та Oakley було відомо як специфікації ISAKMP/Oakley, тепер воно отримало назву протоколу IKE

Протокол IKE Призначений для узгодження параметрів асоціацій захисту, що створюються, і для автентифікованого обміну ключами, якими будуть користуватись учасники цих асоціацій Дозволяє утворити між двома учасниками обміну (IKE SA) автентифікований захищений тунель, за яким будуть узгоджуватись параметри асоціації захисту, що створюється для IPSec Протокол на базі UDP, передбачає використання порту 500 Може функціонувати у трьох режимах: Основний режим (Main Mode) застосовується, коли дві сторони вперше встановили зв’язок, щоби узгодити параметри асоціації захисту, яка забезпечить конфіденційність їх подальшого обміну “Активний” режим (Aggressive Mode) є скороченою версією основного режиму, має те ж призначення, що й основний режим, і може використовуватись замість нього Швидкісний режим (Quick Mode) застосовується, коли асоціація захисту вже створена в результаті використання основного або активного режиму, але існує необхідність в узгодженні функцій захисту або обміну новими ключами оскільки захищений канал був утворений ще до застосування швидкісного режиму, останній забезпечує надійний захист без додаткових витрат, які притаманні основному або активному режиму

Автентифікація у протоколі IKE Протокол IKE передбачає кілька способів автентифікації Коли спільно використовуються одні й ті ж ключі Всі хост-системи (або шлюзи VPN) володіють одними й тими ж таємними ключами IKE автентифікує різних учасників обміну по хешу ключа При використанні криптографії з відкритим ключем Кожна сторона генерує випадкове число і шифрує його відкритим ключем іншої сторони Автентифікація відбувається, коли інша сторона може розрахувати хеш-функцію цього випадкового числа і надіслати результат першій стороні Технології цифрового підпису Кожний пристрій “підписує” набори даних, що відсилає іншій стороні Цей метод подібний до шифрування відкритим ключем, але додатково забезпечує захист від відмовлення від авторства При використанні асиметричної криптографії (цифровий підпис, шифрування відкритим ключем), необхідно використання цифрових сертифікатів, що підтверджують взаємну відповідність і справжність відкритих та секретних ключів Протокол IKE дозволяє отримати доступ до сертифікату в односторонньому порядку або у формі обміну при виконанні сторонами процедури IKE

Захист віртуальних каналів на сеансовому рівні Сеансовий рівень є найвищим рівнем моделі взаємодії відкритих систем, на якому можливо формування захищених віртуальних каналів Побудова VPN на цьому рівні дозволяє досягти: найбільшої функціональної повноти захисту інформаційного обміну, надійності контролю доступу, простоти налаштовування системи безпеки. При побудові захищених віртуальних мереж на сеансовому рівні є можливість здійснити: криптографічний захист інформації, включаючи автентифікацію найбільшого поширення дістав протокол SSL/TLS (Secure Sockets Layer / Transport Layer Security), який був розроблений компанією Netscape Communications деяких функцій посередництва між сторонами, що взаємодіють (саме сеансовий рівень відповідає за встановлення логічних з’єднань і керування ними) IETF прийняла в якості стандарту протокол SOCKS

Прозорість захисту віртуальних каналів на сеансовому рівні Протоколи формування захищених віртуальних каналів на сеансовому рівні є прозорими для прикладних протоколів захисту, а також для протоколів прикладного рівня, таких як HTTP, FTP, POP3, SMTP З іншого боку, на сеансовому рівні існує залежність від програм, які реалізують високорівневі протоколи На відміну від еталонної моделі OSI, у стеці протоколів TCP/IP розрізняють лише чотири рівні Функції сеансового рівня можуть реалізовуватись або протоколами транспортного рівня (TCP), або протоколами верхнього (прикладного) рівня Реалізація протоколів захисту інформаційного обміну, що відносяться до сеансового рівня, у багатьох випадках вимагає внесення змін у високорівневі мережеві програмні засоби

Протокол SSL/TLS Протокол Secure Sockets Layer / Transport Layer Security орієнтований на захист інформаційного обміну між клієнтом і сервером комп’ютерної мережі Версія TLS 1.0 фактично є розвитком версії SSL 3.0 і мало відрізняється від неї, хоча розробники попереджають про відсутність сумісності Специфікація SSL 3.0 – Netscape Communications, 1996 http://wp.netscape.com/eng/ssl3/ RFC-4346, The Transport Layer Security (TLS) Protocol Version 1.1 / T. Dierks, E. Rescorla. – April 2006 RFC-4366, Transport Layer Security (TLS) Extensions / S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright. – April 2006 SSL став загальновизнаним стандартом захисту в Інтернет та інтранет-мережах і практично витіснив конкуруючі технології шифрування на прикладному рівні, такі як, наприклад, Secure HTTP (SHTTP) Основу протоколу складає технологія комплексного використання асиметричних і симетричних криптосистем Як базові використовуються криптографічні алгоритми: для асиметричного шифрування – RSA, для симетричного шифрування – RC2, RC4, DES та потрійний DES (Triple DES), для хешування – MD5 і SHA-1. Починаючи з версії SSL 3.0 набір криптографічних алгоритмів може розширюватись Для автентифікації сторін, що взаємодіють, і для криптографічного захисту ключа симетричного шифрування застосовуються цифрові сертифікати відкритих ключів, що відповідають стандарту X.509

Процедура встановлення SSL-сесії У відповідності до протоколу SSL криптозахищені тунелі утворюються між кінцевими точками віртуальної мережі. Ініціаторами кожного тунелю є клієнт і сервер. Протокол SSL передбачає дві стадії їхньої взаємодії: встановлення SSL-сесії захищена взаємодія Процедура встановлення SSL-сесії називається “рукостисканням”. Вона виконується за протоколом рукостискання (Handshake Protocol), який входить до складу SSL. В ході цієї процедури вирішуються такі завдання: автентифікація сторін; узгодження криптографічних алгоритмів та алгоритмів стискання, які будуть використовуватись при захищеному інформаційному обміні; формування спільного секретного майстер-ключа; генерація на основі майстер-ключа спільних секретних сеансових ключів для криптозахисту інформаційного обміну. У версії SSL 3.0 підтримуються три режими автентифікації: взаємна автентифікація сторін; одностороння автентифікація сервера без автентифікації клієнта; повна анонімність. В останньому режимі реалізується захищений обмін між клієнтом і сервером, але не надається жодних гарантій щодо автентичності сторін, що взаємодіють.

Послідовність процедури автентифікації – 1/4 Наведено послідовність процедури автентифікації, що відповідає другому режиму (автентифікація сервера без автентифікації клієнта) Клієнт надсилає серверу запит на встановлення захищеного з’єднання. У запиті передається: поточний час і дата; випадкова послідовність RAND_CL; набір алгоритмів симетричного шифрування та алгоритмів обчислення хеш-функцій, які підтримує клієнт; набір алгоритмів стискання, які підтримує клієнт. Сервер надсилає у відповідь узгоджений набір параметрів, який містить: ідентифікатор SSL-сесії; обрані криптографічні алгоритми з числа тих, що запропонував клієнт (якщо запропоновані алгоритми чи їхні параметри з якихось причин не влаштовують сервер, то сесія закривається); сертифікат сервера, завірений цифровим підписом центру сертифікації; випадкову послідовність RAND_SERV.

Послідовність процедури автентифікації – 2/4 Клієнт, використовуючи відкритий ключ центра сертифікації, здійснює перевірку одержаного сертифіката сервера Якщо перевірка дає негативний результат, то сесія закривається Якщо результат позитивний, то клієнт здійснює такі дії: виробляє випадкову 48-байтну послідовність Pre-MasterSecret, зашифровує її на відкритому ключі сервера, який містився в сертифікаті сервера, і надсилає її серверу; використовуючи обраний сервером алгоритм хешування, виробляє спільний таємний майстер-ключ (MasterSecret), використовуючи для цього послідовності Pre-MasterSecret, RAND_SERV і RAND_CL; використовуючи MasterSecret, обчислює сеансові таємні ключі для симетричного шифрування і обчислення хеш-функцій; переходить у режим захищеної взаємодії.

Послідовність процедури автентифікації – 3/4 Сервер, отримавши зашифровану послідовність Pre-MasterSecret, розшифровує її, користуючись своїм таємним ключем, а далі виконує такі операції: точно так, як і клієнт, використовуючи обраний алгоритм хешування, виробляє спільний таємний майстер-ключ (MasterSecret), використовуючи для цього послідовності Pre-MasterSecret, RAND_SERV і RAND_CL; оскільки і алгоритм і вихідні послідовності ті ж самі, що й у клієнта, результат (MasterSecret) повинен бути ідентичним точно так, як і клієнт, використовуючи MasterSecret, обчислює сеансові таємні ключі для симетричного шифрування і обчислення хеш-функцій; знову ж, результати повинні бути ідентичні тим, що отримав клієнт переходить у режим захищеної взаємодії.

Послідовність процедури автентифікації – 4/4 Клієнт і сервер здійснюють перевірку ідентичності параметрів SSL-сесії (ключів): клієнт формує тестове повідомлення із: тих даних, що він відправляв серверу на кроці 1, тих даних, що він одержав від сервера на кроці 2, послідовності MasterSecret; далі він формує код перевірки цілісності повідомлення (MAC), зашифровує повідомлення на спільному таємному сеансовому ключі і надсилає серверу; сервер аналогічним чином формує тестове повідомлення і надсилає його клієнту; кожна із сторін розшифровує одержане тестове повідомлення і здійснює перевірку цілісності. В разі успіху перевірки ідентичності параметрів SSL-сесія вважається встановленою і сторони розпочинають захищену взаємодію В ході подальшої захищеної взаємодії Кожна з сторін при відправленні кожного повідомлення формує MAC-код для перевірки цілісності повідомлення, а потім зашифровує повідомлення разом з MAC-кодом При одержанні кожного повідомлення воно розшифровується і здійснюється перевірка його цілісності. В разі виявлення порушення цілісності повідомлення SSL-сесія закривається

Протокол SOCKS Протокол SOCKS був розроблений у 1990 році для організації посередництва при взаємодії між клієнт-серверними застосуваннями на сеансовому рівні моделі OSI SOCKS може застосовуватись для реалізації багатьох функцій посередництва, таких як трансляція мережних адрес (Network Address Translation, NAT), контроль за напрямками інформаційних потоків, розмежування доступу в залежності від атрибутів користувачів та інформації. У порівнянні з посередницькими функціями, що реалізуються на прикладному рівні, SOCKS пропонує більшу швидкодію та незалежність від високорівневих протоколів, таких як HTTP, FTP, POP3, SMTP тощо. Протокол SOCKS не залежить від операційних систем, а також не прив’язаний до протоколу IP

Особливості протоколу SOCKS На основі протоколів мережного і канального рівнів захищені тунелі формуються між комп’ютерами (або маршрутизаторами, брандмауерами), а на основі протоколу SOCKS захищені тунелі можуть утворюватись для кожного окремого застосування і сеансу Розрізняють SOCKS-сервер, який здебільшого встановлюють на шлюз або брандмауер мережі, та SOCKS-клієнти, які встановлюють на кожний комп’ютер користувача SOCKS-сервер взаємодіє з будь-яким прикладним сервером від імені прикладного клієнта, що відповідає цьому серверу SOCKS-клієнт перехоплює запити від справжніх клієнтів до прикладних серверів і передає ці запити SOCKS-серверу

Протокол SOCKS v5 Версія 5 протоколу SOCKS (SOCKS v5) запропонована в якості стандарту Інтернет RFC-1928, SOCKS Protocol Version 5 / M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones. – March 1996 RFC-1929, Username/Password Authentication for SOCKS V5 / M. Leech. – March 1996 SOCKS v5 підтримує протоколи TCP та UDP. Таким чином, охоплюються майже всі прикладні протоколи. Але протокол ICMP не підтримується! Разом із виключенням численних проблем з безпекою, недоступними становляться і діагностичні утиліти ping та tracert Передбачена автентифікація не лише SOCKS-клієнтів, але й користувачів, від імені яких ці клієнти звертаються. Також можлива двостороння автентифікація. SOCKS v5 припускає використання схем адресації як IPv4, так і IPv6 Автентифікація користувача, яку виконує SOCKS-сервер, може бути основаною на сертифікатах X.509 або на паролях Для шифрування трафіка між SOCKS-клієнтом і SOCKS-сервером можуть застосовуватись будь-які протоколи, орієнтовані на сеансовий або нижчі рівні моделі OSI

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