ChSTU repository
ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets
Learn More
Please use this identifier to cite or link to this item:
https://er.chdtu.edu.ua/handle/ChSTU/6326| Title: | Протоколи захисту даних в сучасних цифрових системах передачі даних |
| Authors: | Нечипоренко, Ольга Володимирівна Дягілєв, Олександр Пилипович |
| Issue Date: | Jun-2022 |
| Abstract: | Метою роботи був аналіз і порівняння протоколів захисту даних в сучасних цифрових системах передачі даних. Для досягнення поставленої мети були розв’язати такі задачі, як: аналіз існуючих протоколів та технологій захисту інформації, вибір найбільш актуальних та ефективних рішень. Проведено повторний поглиблений аналіз протоколів та технологій захисту інформації, з розгляданням реалізації та можливих вразливостей, зроблені висновки та сформульовані рекомендації, по вибору та комбінуванню протоколів та технологій. По результатам первинного аналізу, були обрані найбільш актуальні для сьогодення технології. І проведений їх поглиблений аналіз, проілюстровані слабкі місця та вразливостей даних рішень, а також проведено порівняння протоколів між собою. Був вироблений алгоритм по прийняттю на озброєння того чи іншого протоколу, а також утворені висновки по комплексному зміцненню захисту мережі. В цілому варто зазначити, що саме комплекс протоколів, має найкращій ефект в запобіганні або ж послабленні атак на систему. Нажаль, тут виникає інше питання, доцільність використання дороговартісного комплексу для захисту тої чи іншої мережі. |
| URI: | https://er.chdtu.edu.ua/handle/ChSTU/6326 |
| Appears in Collections: | 123 Комп’ютерна інженерія (Спеціалізовані комп’ютерні системи) |
Files in This Item:
| File | Description | Size | Format | |
|---|---|---|---|---|
| Б_123_2022_Дягілєв.pdf Restricted Access | 1.34 MB | Adobe PDF | View/Open Request a copy |
Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ КОМП’ЮТЕРНИХ СИСТЕМ Пояснювальна записка до кваліфікаційної роботи освітнього ступеня «бакалавр» на тему: ПРОТОКОЛИ ЗАХИСТУ ДАНИХ В СУЧАСНИХ ЦИФРОВИХ СИСТЕМАХ ПЕРЕДАЧІ ДАНИХ В иконав: студент 4 курсу, групи СКС-187 спеціальності 123 - Комп’ютерна інженерія Дягілєв О. П. (прізвище та ініціали) Керівник Нечипоренко О. В. (прізвище та ініціали) Рецензент (прізвище та ініціали) Черкаси 2022 року ЗМІСТ СПИСОК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ ..................................... 3 ВСТУП ..................................................................................................................... 5 1 АНАЛІЗ ПРОТОКОЛІВ ЗАХИСТУ ПЕРЕДАЧІ ДАНИХ ........................... 7 1.1 Протокол PPTP ............................................................................................... 7 1.2 Протокол SSH ................................................................................................. 8 1.3 Протокол SSL ................................................................................................. 9 1.4 Протокол TLS ............................................................................................... 10 1.5 Технологія VPN ............................................................................................ 12 2 ТЕХНІЧНА РЕАЛІЗАЦІЯ ПРОТОКОЛІВ ЗАХИСТУ ПЕРЕДАЧІ ДАНИХ ................................................................................................................... 15 2.1 Технічна реалізація протоколу SSH ........................................................... 15 2.1.1 Узгодження шифрування сеансу .......................................................... 15 2.1.2 Аутентифікація користувача ................................................................ 16 2.2 Технічна реалізація протоколу TLS ........................................................... 17 2.2.1 Центри сертифікації ............................................................................... 18 2.2.2 Встановлення з’єднання в протоколі TLS ........................................... 21 2.3 Технічна реалізація технології IPsec .......................................................... 28 2.3.1 Internet Key Exchange ............................................................................. 30 3 ЗАСТОСУВАННЯ ПРОТОКОЛІВ ЗАХИСТУ ДАНИХ В ЦИФРОВИХ СИСТЕМАХ ПЕРЕДАЧІ ДАНИХ ...................................................................... 33 3.1 Вразливості IРsec ......................................................................................... 33 3.2 Вразливості SSL VPN .................................................................................. 40 3.3 Відомі вразливості в протоколі SSH .......................................................... 48 3.4 Порівняння IPsec, SSL VPN ТА SSH ......................................................... 51 3.5 Порівняльна характеристика ...................................................................... 52 3.6 Проведення тестів протоколів зазисту для конкретного підприємства . 57 ВИСНОВКИ ........................................................................................................... 59 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ............................................................. 61 ЧДТУ.229887.001 ПЗ Змн. Арк. № докум. Підпис Дата Розроб. Дягілєв Застосування протоколів Літ. Лист. Листів Перевір. Нечипоренко захисту даних в сучасних 2 62 Реценз. цифрових системах передачі Н. Контр. даних. ЧДТУ, СКС-187 Затверд. Лукашенко Пояснювальна записка СПИСОК СКОРОЧЕНЬ ТА УМОВНИХ ПОЗНАЧЕНЬ AC – Certificate Authority – Акредито́ваний центр сертифіка́ції ключів́ AH – Authentication header – заголовок аутентифікації COVID-19 – COronaVIrus Disease 2019 – коронавірусная інфекція 2019 року CVE – Common Vulnerabilities and Exposures – база відомих вразливостей DV – Domain of Verefication – сертифікат перевірки домену EAP -- Extensible Authentication Protocol – розширюваний Протокол Аутентифікації ESP – Incapsulation of safety зкщещсщд – інкапсуляція корисного навантаження безпеки EV – Extended validation – розширена валідація IKE – Internet Key Exchange – протокол составляющая IPsec IPsec – IP Security – протокол захисту IP MacOs – Macintosh Operating System – сімейство пропрієтарних операційних систем від компанії Apple MS-CHAP v2 – Microsoft Challenge Handshake Authentication Protocol – протокол перевірки істинності з’еднання між сервером и клієнтом NAT – Network Address Translation – "перетворення мережевих адрес" OV – Verification of organization – сертифікат феревікації організації PPTP – Point-to-Point Tunneling Protocol – тунельний протокол крапка- крапка. RSA – абревіатура від прізвищ Rivest, Shamir і Adleman SA – Set of parameters – набір параметрів SSH – Secure Shell – безпечна оболочка SSL – Secure Sockets Layer – рівень захищених сокетів TCP – Transmission Control Protocol – протокол управління передачею TLS – Transport Layer Security – Протокол захисту транспортного рівня Лист ЧДТУ.229887.001 ПЗ 3 Змн. Арк. № докум. Підпис Дата VPN – Virtual private network – віртуальна приватна мережа Web PKI – Public key infrastructure – інфраструктура відкритих ключів Лист ЧДТУ.229887.001 ПЗ 4 Змн. Арк. № докум. Підпис Дата ВСТУП Актуальність теми Протоколи захисту інформації є важливим рішенням, що складають значну частину системи безпеки будь якої компанії. Аналіз ринку, показує, що актуальність теми захисту даних не тільки не падає, а й невпинно зростає з кожним днем. В першу чергу, інтерес компаній до цієї галузі, можна пояснити впливом COVID-19. Велика кількість співробітників. В зв’язку з карантином, була змушена перейти на роботу з дому, а тому підприємства та компанії, мали забезпечити працівникам, можливість безпечного доступу до інформації або системи, з дому. В подібній ситуації, аналіз існуючих рішень, з рекомендаціями та урахуванням особливостей підприємства, є значною допомогою при виборі протоколу чи технології (або ж їх комплексу). Мета і завдання дослідження. Метою роботи є аналіз і порівняння протоколів захисту даних в сучасних цифрових системах передачі даних. Для досягнення поставленої мети необхідно розв’язати такі задачі: 1. Виконати аналіз існуючих протоколів та технологій захисту інформації 2. Вибрати найбільш актуальні та ефективні рішення 3. Провести повторний поглиблений аналіз протоколів та технологій захисту інформації, з розгляданням реалізації та можливих вразливостей. 4. Зробити висновки та сформувати рекомендації Об’єкт дослідження – існуючі протоколи та технології захисту даних в сучасних цифрових системах. Предмет дослідження – застосування розглянутих протоколів та технологій захисту інформації в сучасних цифрових системах передачі даних. Лист ЧДТУ.229887.001 ПЗ 5 Змн. Арк. № докум. Підпис Дата Методи дослідження – У процесі дослідження застосовувались: методи статистики, аналізу і синтезу для розгляду ефективності та використання конкретного рішення, моделювання і фізична реалізація для порівняння протоколів та технологій. Лист ЧДТУ.229887.001 ПЗ 6 Змн. Арк. № докум. Підпис Дата 1 АНАЛІЗ ПРОТОКОЛІВ ЗАХИСТУ ПЕРЕДАЧІ ДАНИХ В цій частині роботи буде розглянуто існуючи реалізації протоколів захисту даних (та технологій загалом) в цифровій мережі. 1.1 Протокол PPTP PPTP – тунельний протокол типу крапка-крапка, який дозволяє комп’ютеру встановити захищене з’єднання з сервером, за рахунок, створення тунелю (рис. 1.1). Рисунок 1.1 – Схема роботи протоколу РРТР [13] Протокол був розроблений в 1995 році асоціацією яка підпорядковувалась, компанії Microsoft, став широко вживаним стандартом VPN який використовується й досі. Причиною популярності даного протоколу, стало те, що саме PPTP був першим протоколом тунелювання, який був підтриманий корпорацією Microsoft [2],. Як основні переваги даного протоколу, варто відзначити: • Найбільшу швидкість створення з’єднання і передачі даних (серед аналогів). • Значну кросплатформеність (можна запустити і з Windows, і з Linux, і з MacOS) • Простоту в налаштуванні Лист ЧДТУ.229887.001 ПЗ 7 Змн. Арк. № докум. Підпис Дата При цьому протокол має й досить значні недоліки, а саме: • відсутність інкапсуляції аутентифікації MS-CHAP v2 (може також використовуватись EAP-TLS) • Протокол не підтримує NAT • З часу створення протоколу з’явилось багато системних рішень по дешифровці захищених ним даних. По суті, даний протокол хоч і використовується й досі, але в значній мірі застарів, через що, втратив свою актуальність. 1.2 Протокол SSH SSH – тунельний протокол який крім того, що виконує шифрування даних, також дає можливість віддаленого керування операційною системою (є аналогом Telnet, але на відмінно від нього - захищений). Історія даного протоколу починається з версії 1 (SSH-1), яка була реалізована в 1995 році Тату Юленіним (дослідником Технологічного університету Хельсінки). Даний протокол був створений після атаки на університетську мережу з якою працював дослідник. Пізніше SSH-1 був розповсюджений як безкоштовне ПО і досить швидко набув популярності. До кінця 1995 року, база користувачів протоколу, налічувала 20 000 осіб [16]. В 2006 році, вийшла нова версія протоколу SSH – 2, створена робочою групою IETF. Серед основних переваг даного протоколу, можна зазначити можливість запуску будь-якої кількості сеансів через єдине з’єднання, ну і звісно покращені характеристики безпеки, порівняно з SSH- 1 (досягається це, за рахунок обміну ключами Деффі-Хельдмана і перевірки цілісності за допомогою ключів аутентифікації). Серед особливостей протоколу версії SSH-2 варто зазначити його несумісність з протоколом SSH-1. Це пов’язано з різницею в технічній реалізації протоколів. Хоч ці протоколи виконують ті самі функції, Лист ЧДТУ.229887.001 ПЗ 8 Змн. Арк. № докум. Підпис Дата технічно, варто було б розглядати їх як два різні технології. Тому якщо до прикладу, мається два пристрої, один з яких, працює по SSH-1, а другий, по SSH-2, виконати з’єднання між ними не вдалось би. Ще однією важливою особливістю протоколу, можна зазначити наявність двох реалізацій: комерційної та безкоштовної (OpenSSH). Саме OpenSSH є найбільш популярною реалізацією даного протоколу, на момент написання тексту. В першу чергу, подібна популярність викликана, звісно ж тим що дана реалізація безкоштовна, але й доступність відкритого коду, зіграла в подібній розповсюдженості, значну роль. 1.3 Протокол SSL SSL – це криптографічний протокол, основна задача якого, забезпечити безпечний канал зв’язку між двома пристроями. Протокол використовує асиметричну криптографію для аутентифікації ключей обміну, симетричну криптографію для збереження конфіденційності та коди аутентифікації для збереження цілісності повідомлення (рис. 1.2). Рисунок 1.2 – Історія розвитку протоколів SSL/TLS [13] Історія протоколу починається у 1994 році. SSl.1.0 був створений компанією Netscape Communication Company. Нажаль, перша версія протоколу, мала критичні вразливості безпеки, а тому не була видана. Лист ЧДТУ.229887.001 ПЗ 9 Змн. Арк. № докум. Підпис Дата У 1995 році, була створена 2-га версія протоколу (SSL.2.0) яка вже вийшла в широкий загал (в 2011 році протокол перестав підтримуватись). Тепер при отримані запиту через цей протокол, сервери відхиляють його). Нажаль і ця версія протоколу, мала критичні вразливості, через що, вже в наступному році, була створена третя версія протоколу (SSL.3.0). Яка і стала основною для більш сучасного і широковживаного зараз протоколу – TLS. Третя версія протоколу SSL з технічної точки зору, в значній мірі відрізняється від другої [18]. Вона була розроблена компаніями Paul Kocher, Netscape Phil Karlton, Alan Freier та Consensus Development. Цікавою особливістю стало то те, що зараз протокол SSL практично не використовується, на відмінно від TLS, але через розповсюдженість назви і звичку інтернет суспільства, сертифікати і загалом технологія, продовжують називатись SSL, хочу на справді, вже давно стали TLS. В 2014 році в протоколі SSL була знайдена критична вразливість (оновлення національної бази даних вразливостей США NVD. Номер в NVD CVE-2014-3566), через що, почався активний процес переходу з SSL на TLS. 1.4 Протокол TLS TLS – криптографічний протокол транспортного рівня, забезпечує захищену передачу даних між вузлами в мережі Інтернет. Перша версія протоколу (TLS.1.0), з’явилась досить давно, ще у 1999 році у вигляді оновлення до SSL.3.0. Як і його попередники, з часом, протокол став вразливим до хакерських атак (основна проблема в атаках Logjam, але є й інші не менш значні вразливості). В 2018 році вийшло звернення від PCI DDC з закликом до відмови від даної версії протоколу. І в 2020 році, підтримка даного протоколу була припинена. Лист ЧДТУ.229887.001 ПЗ 10 Змн. Арк. № докум. Підпис Дата Наступною версією - став TLS.1.1, який вийшов в світ у 2006 році. В цій версії, був покращений захист, та виправлені деякі помилки попередника. Основною зміною можна рахувати використання явного вектору ініціалізації та регістрацію числових кодів та параметрів від IANA. Але й ця версія протоколу була визнана застарілою у 2020 році. Останніми на даний момент можна рахувати версії TLS.1.2, та TLS.1.3. TLS.1.2 вийшов у 2008 році й досі залишається актуальною версією протоколу. Основною зміною, стала відмова від застарілих криптографічних хеш функцій накшталт MD5 та SHA-1 замість них почала використовуватись функція SHA-256. А вже в 2018 році була представлена версія TLS.1.3. В цій версії знову ж таки були внесені значні зміни. Серед деяких найбільш актуальних оновлень є відмова від допоміжних повідомлень та стиснення інформації, знову ж таки були змінені шифру на більш нові. Цікавою особливістю протоколу TLS є те що всі версії до TLS.1.3 були кросплатформеними (тобто підтримувались усіма браузерами та більшістю платформ). Остання версія, нажаль не підтримується Google Chrome. 1.5 Технологія IPsec Ipsec – це набір протоколів що використовуються для забезпечення приватності і аутентифікації на мережевому рівні (модель OSI). Ці протоколи можна розділити на два класи: протоколи захисту даних, та протоколи обміну ключами. Серед особливостей даної технології варто зазначити, що вона використовує декілька протоколів які дають змогу обирати параметри захисту, такі як: використання різних механізмів обміну ключами, алгоритмів захисту або хеш функції. Лист ЧДТУ.229887.001 ПЗ 11 Змн. Арк. № докум. Підпис Дата Дана технологія була розроблена між 1992 – 1995 роком (стандартизація проводилась IETF, але в самій розробці приймали участь, досить багато компаній, університетів і навіть лабораторія військово- морських досліджень США. Тому визначити основного виконавця, досить складно і напевно навіть непотрібно) Сама технологія складається з трьох протоколів: • Authentication Header (АН) - протокол використовується для аутентифікації відправника інформації, для забезпечення цілісності даних, а також, опціонально може бути використаний для захисту від повторної передачі даних. • Encapsulating Security Payload (ESP) - протокол, забезпечує конфіденційність та захист даних. ESP повністю інкапсулює пакети його можна використовувати як самостійно, так і разом з протоколом AH. • Internet Security Association and Key Management Protocol (ISAKMP) - протокол забезпечує налаштування з’єднання між кінцевими пристроями, обмін ключами, а також взаємну аутентифікацію між кінцевими вузлами В наш час дана технологія набула значної популярності і використовується як самостійно, так і як одна з реалізацій VPN. 1.6 Технологія VPN VPN – це загальна назва технологій, що дозволяють встановити одне або кілька мережевих з'єднань, над основною мережею. Статистика використання VPN у 2021 році наведена на рис. 1.3. Технологія VPN створювалась протягом декількох десятиліть (і продовжує розвиватись й досі). Спочатку вона призначалась для вирішення проблем безпеки державних установ, наукових центрів, великих підприємств, які володіють важливою інформацією і не можуть собі дозволити втрати їх при підключенні до Інтернету. За допомогою VPN ці Лист ЧДТУ.229887.001 ПЗ 12 Змн. Арк. № докум. Підпис Дата структури отримали безпечне підключення до Інтернету, що дало можливість користувачам працювати віддалено, отримувати інформацію від головного офісу, перебуваючи в дочірніх підприємствах та, уникаючи небезпеки розсекретити інформацію. Рисунок 1.3 – Статистика використання VPN у 2021 році [9] Зараз ці технології використовуються для захисту інформації, що передається, збереження конфіденційності користувача та обходу блокувань. Усі раніше описані технології так або інакше, являють собою варіанти реалізації VPN. Наприклад протокол PPTP був основою для перших VPN. Зараз цей протокол рекомендують не використовувати для віртуальної приватної мережі, але через його простоту в налаштуванні і швидкості роботи, нерідко, цими порадами нехтують. Протоколи SSL.3.0 та TLSv1, а також безкоштовна бібліотека OpenSSL, є основою для протоколу OpenVPN який в свою чергу є основою для багатьох сучасних VPN рішень (найчастіше використовується для доступу користувача до веб-порталу, або при роботі з електронною комерцією). Лист ЧДТУ.229887.001 ПЗ 13 Змн. Арк. № докум. Підпис Дата Теж саме, можна сказати і про раніше описану технологію IPsec, яка також є основою для багатьох VPN рішень. Саме ця технологія є найкращім варіантом при пошуку реалізації VPN загального призначення. Висновки – було проведено ознайомлення з усіма вживаними на даний момент часу, протоколами захисту інформацій в мережі. В подальших розділах, матиметься можливість розглянути вдалі рішення більш детально та відкинути не ефективні або ж застарілі. Лист ЧДТУ.229887.001 ПЗ 14 Змн. Арк. № докум. Підпис Дата 2 ТЕХНІЧНА РЕАЛІЗАЦІЯ ПРОТОКОЛІВ ЗАХИСТУ ПЕРЕДАЧІ ДАНИХ В цьому розділі стисло буде описана технічна реалізація раніше описаних протоколів та технологій. Описані будуть лише найбільш актуальні в даний момент технології. 2.1 Технічна реалізація протоколу SSH Для роботи SSH, використовується модель клієнт-сервер. SSH за замовчуванням працює на порту TCP 22 (за необхідності, порт можна змінити). Сервер прослуховує порт 22 для вхідних підключень і якщо на порт поступає запит на з’єднання і кліент проходить аутентифікацію та відкриває правильне середовище оболонки, то перевірка проходить успішно. В першу чергу, клієнт повинен утворити SSH-з'єднання з сервером, ініціюючи рукостискання TCP, забезпечуючи захищене симетричне з'єднання, перевіряючи, чи відповідає ідентичність, що відображається сервером, попереднім записам (як правило, записаним у файлі сховища ключів RSA) та представляючи необхідні облікові дані користувача, для аутентифікації з’єднання. Існує два етапи встановлення з’єднання: • По-перше, обидві системи повинні узгодити стандарти шифрування для захисту майбутної сесії з’єднання. • По-друге, користувач повинен аутентифікуватися. Якщо облікові дані збігаються, користувачу надається доступ. 2.1.1 Узгодження шифрування сеансу Коли клієнт намагається підключитися до сервера через TCP, сервер представляє протоколи шифрування та відповідні версії, які він Лист ЧДТУ.229887.001 ПЗ 15 Змн. Арк. № докум. Підпис Дата підтримує. Якщо клієнт має схожу пару протоколу та версії, досягається угода і розпочинається з’єднання з прийнятим протоколом. Як тільки описані кроки, пройдені, обидві сторони використовують алгоритм обміну ключами Діффі-Хелфмана для створення симетричного ключа. 2.1.2 Аутентифікація користувача Перед тим, як користувач отримує доступ до сервера, йому потрібно аутентифікувати його облікові дані. Для цього більшість користувачів SSH використовують пароль. Користувача просять ввести ім’я користувача, а потім пароль. Хоча паролі зашифровані, все одно не рекомендується використовувати прості паролі для створення з’єднаня. Це пов’язано з тим, що простий пароль можна підібрати, тим самим отримавши доступ до облікового запису. Натомість для спрощення входу до облікових даних, рекомендується використовувати пари ключів SSH. Це набір асиметричних ключів, які використовуються для аутентифікації користувача без необхідності введення пароля (рис. 2.1). Рисунок 2.1 – Спрощена модель встановлення з’єднання [16] Лист ЧДТУ.229887.001 ПЗ 16 Змн. Арк. № докум. Підпис Дата 2.2 Технічна реалізація протоколу TLS TLS використовує комбінацію симетричної та асиметричної криптографії. Подібна реалізація, забезпечую компроміс між продуктивністю та безпекою під час процесу передачі даних. Симетрична криптографія ефективна з точки зору обчислень, але наявність загального секретного ключа означає, що, в першу чергу, цим секретним ключем необхідно поділитися один з одним. Асиметрична криптографія використовує пари ключів - відкритий ключ і закритий ключ. Відкритий ключ математично пов’язаний із закритим ключем, але з огляду на достатню довжину ключа, виводити закритий ключ із відкритого ключа недоцільно з точки зору обчислювань. Це дозволяє відправнику використовувати відкритий ключ одержувача для шифрування даних, які він хоче йому надіслати і ці дані можна розшифрувати лише за допомогою приватного ключа одержувача. Перевага асиметричної криптографії полягає в тому, що процес спільного використання ключів шифрування не повинен бути безпечним, але математичний зв’язок між відкритим і закритим ключами робить необхідним, створення ключа великого розміру. Рекомендована мінімальна довжина ключа становить 1024 біти, бажано 2048 бітів. Це в тисячу разів більше, ніж симетричні ключі еквівалентної сили (наприклад, 2048-бітовий асиметричний ключ приблизно еквівалентний 112-бітовому симетричному ключу). і робить асиметричне шифрування занадто повільним для багатьох цілей. З цієї причини TLS використовує асиметричну криптографію для безпечного генерування та обміну сесійним ключем. Ключ сеансу потім використовується для шифрування даних, переданих однією стороною, і для розшифрування даних, отриманих іншою. Після завершення сеансу ключ сеансу відкидається. Лист ЧДТУ.229887.001 ПЗ 17 Змн. Арк. № докум. Підпис Дата Можна використовувати різноманітні методи генерації та обміну ключів, включаючи RSA, Диффі-Хеллмана, ефемерну криву Діффі- Хеллмана, еліптичну криву Діффі-Хеллмана і ефемерну еліптичну криву Діффі-Хеллмана. З TLS також бажано, щоб клієнт, який підключається до сервера, міг підтвердити право власності на відкритий ключ сервера. Зазвичай це виконується за допомогою цифрового сертифіката, виданого довіреною третьою стороною, відомою як центр сертифікації (CA), який підтверджує справжність відкритого ключа. У деяких випадках сервер може використовувати самопідписаний сертифікат, якому клієнт повинен явно довіряти (браузери повинні відображати попередження, коли зустрічається ненадійний сертифікат), але це може бути прийнятним у приватних мережах. 2.2.1 Центри сертифікації Центр сертифікації — це організація, яка видає цифрові сертифікати, що відповідають стандарту ITU-T X.509. Цифрові сертифікати засвідчують відкритий ключ власника сертифіката (відомий як суб’єкт) і що власник контролює домен, захищений сертифікатом. Таким чином, CA діє як довірена третя сторона, яка дає клієнтам (відомим як довіряючі сторони) впевненість у тому, що вони підключаються до сервера, яким керує перевірений об’єкт. Сертифікати домену самі перевіряються через ланцюг довіри, що походить від кореневого сертифіката. За допомогою асиметричної криптографії можна використовувати закритий ключ кореневого сертифіката для підписання інших сертифікатів, які потім можуть бути перевірені за допомогою відкритого ключа кореневого сертифіката і, отже, успадкувати довіру якою володіє кореневий сертифікат (рис. 2.2). Лист ЧДТУ.229887.001 ПЗ 18 Змн. Арк. № докум. Підпис Дата На практиці сертифікат домена, зазвичай підписуються одним або кількома проміжними, оскільки це захищає кореневий сертифікат у випадку, якщо сертифікат домену видано неправильно або скомпрометовано. Рисунок 2.2 – Приклад кореневого сертифікату [18] Довіра кореневих сертифікатів зазвичай встановлюється шляхом фізичного розповсюдження кореневих сертифікатів в операційних системах або браузерах. Основні програми сертифікації реалізовані Microsoft (Windows і Windows Phone), Apple (OSX і iOS) і Mozilla (Firefox і Linux) Всі вони, вимагають, щоб центри сертифікації відповідали суворим технічним вимогам і заповнювали WebTrust, ETSI EN 319 411-3 (раніше TS Лист ЧДТУ.229887.001 ПЗ 19 Змн. Арк. № докум. Підпис Дата 102 042) з метою включення сертифікатів до бази безпечних і подальшого їх розповсюдження. Вважається, що кореневі сертифікати, що розповсюджуються з основними операційними системами та браузерами, є загальнодоступними а технічні вимоги та вимоги аудиту, по суті, означають, що AC, які видають сертифікати, є транснаціональними корпораціями або урядами. Наразі існує близько п’ятдесяти загальнодоступних AC і більшість з них є членами AC/Browser Forum, який розробляє галузеві рекомендації щодо видачі сертифікатів і керування ними. Однак варто зазначити, що за необхідності можна створити приватні Центри Сертифікації. Довіра же до їх сертифікатів, буде встановлена за допомогою безпечного розповсюдження та встановлення кореневих сертифікатів у клієнтських системах. Ось декілька прикладів регіональних інтернет-ресурсів, які реалізували подібну схему: AfriNIC, ARIN та LACNIC. Одним з недоліків стандарту, що відповідає за роботу центрів сертифікації (X.509) є те, що центри сертифікації можуть видавати сертифікати для будь-якого домену, незалежно від того, чи дійсно запитувач володіє ним, чи іншим чином контролює його. Дана проблема вирішується за допомогою перевірки права володіння доменом. Перевірка зазвичай виконується через надсилання листа з посиланням для аутентифікації на електрону адресу домена. Зазвичай це одна зі стандартних контактних адрес, наприклад “hostmaster@domain”. Варто також зазначити, що сертифікати з перевіркою домену ніяким чином не відображає відношення до юридичної особи, навіть якщо домен може мати з нею зв’язок. З цієї причини центри сертифікації все частіше заохочують клієнтів використовувати сертифікати з перевіркою організації і розширеною валідацією . З сертифікатами OV запитувач підлягає додатковим перевіркам, таким як підтвердження назви організації, адреси та номера телефону за допомогою публічних баз даних. Лист ЧДТУ.229887.001 ПЗ 20 Змн. Арк. № докум. Підпис Дата Сертифікати EV мають додаткові перевірки юридичної установи, фізичного місцезнаходження та особи представників, які мають намір діяти від імені юр. особи. Зазвичай браузери відображають перевірену назву організації зеленим кольором, коли зустрічається дійсний сертифікат EV, хоча, нажаль, немає простого способу відрізнити OV сертифікат від DV сертифікату. 2.2.2 Встановлення з’єднання в протоколі TLS Процес рукостискання в TLS складається з кількох кроків: • Переговори. Клієнт, і сервер мають налаштувати та узгодити версії TLS які вони будуть використовувати, а також перелік прийнятних криптографічних алгоритмів. Фаза переговорів при рукостисканні має на меті знайти спільну мову між конфігураціями клієнта та сервера, щоб безпечно з'єднати обидва пристрої. • Обмін ключами. Суть рукостискання полягає в обміні ключами між двома учасниками. Який алгоритм обміну ключами використовувати? Саме це питання має бути вирішене у рамках переговорного процесу. • Аутентифікація. Зловмиснику, теоретично можливо, видавати себе за будь-яку сторону обміну ключами. З цієї причини обмін ключами повинен бути аутентифікований. • Відновлення сесії. Оскільки браузери часто підключається до сайту більше одного разу (за короткий проміжок часу), процес обміну ключами може критично довгим і буде сповільнювати роботу користувачів. З цієї причини в TLS інтегровано механізми для швидкого відстеження безпечних сеансів без повторного обміну ключами. Розглянемо кожний з кроків, більш детально. Лист ЧДТУ.229887.001 ПЗ 21 Змн. Арк. № докум. Підпис Дата 1. Більша частина складностей в роботі з TLS виникає через узгодження різних рухомих частин протоколу. Нажаль, етап переговорів в рукостисканні TLS також стали джерелом багатьох проблем в історії цього протоколу. Такі атаки, як FREAK, LOGJAM, DROWN тощо, використовували слабкі місця, наявні в старих версіях, щоб зламати новіші версії протоколу (за умови, що сервер запропонував узгодити ці версії. На даний момент, ситуація в роботі з протоколом, виглядає таким чином: браузер користувача може бути найновішим і мати останні оновлення, але при відвідуванні старої веб-сторінки існує ймовірність того, що сервер який відповідає за сайт, підтримує лише версії TLS до 1.2 або навіть 1.1. І навпаки, багато веб-сайтів повинні підтримувати старіші браузери (і, отже, старіші версії TLS), оскільки частина користувачів не бахає робити оновлення браузеру. Більшість версій TLS мають проблеми з безпекою (за винятком TLS 1.2 і TLS 1.3), що змушує нас розмірковувати, що безпечніше ? Підтримувати лише TLS 1.1 і TLS 1.2, або ж працювати з усіма версіями протоколу. На даний момент, нерідко можна знайти бібліотеки TLS, які підтримують старі та зламані версії протоколу, реалізуючи пом’якшення відомих атак. Варто зауважити, що подібні “пом’якшення”, досить часто надто складні для реалізації і постіної підтримки (при високих навантаженнях). Переговори починаються з того, що клієнт надсилає серверу перший запит під назвою Client Hello . Client Hello містить ряд підтримуваних версій TLS, набір криптографічних алгоритмів, які клієнт готовий використовувати, а також деяку додаткову інформацію, яка може бути актуальною для решти процесу рукостискання або для програми. Набір криптографічних алгоритмів включає: • Один або кілька алгоритмів обміну ключами. TLS 1.3 визначає наступні алгоритми, дозволені для переговорів: ECDH з P-256, P-384, P-521, X25519, X448; і FFDH з групами, визначеними в RFC 7919. Лист ЧДТУ.229887.001 ПЗ 22 Змн. Арк. № докум. Підпис Дата Попередні версії TLS також пропонували обмін ключами RSA, але вони були вилучені в останній версії. • Два (для різних частин рукостискання) або більше алгоритмів цифрового підпису . TLS 1.3 визначає RSA PKCS#1 v1.5 і новішу RSA- PSS, а також новіші алгоритми еліптичної кривої, такі як ECDSA і EdDSA. • Одну або кілька хеш-функцій, які будуть використовуватися з HMAC і HKDF. TLS 1.3 визначає SHA-256 і SHA-384, два екземпляри хеш- функції SHA-2 • Один або кілька автентифікованих алгоритмів шифрування. Вони можуть включати AES-GCM (з ключами 128 або 256 біт), Chacha20- Poly1305 і AES-CCM. Потім сервер відповідає повідомленням Server Hello, яке містить по одному з кожного типу криптографічних алгоритмів, вибраних з вибору клієнта (рис. 2.3). Рисунок 2.3 – Приклад рукостискання в протоколі TLS [5] Лист ЧДТУ.229887.001 ПЗ 23 Змн. Арк. № докум. Підпис Дата Якщо сервер не може знайти алгоритм, який він підтримує, він повинен перервати з’єднання. Хоча в деяких випадках сервер не повинен переривати з’єднання і замість цього може попросити клієнта надати більше інформації. Для цього сервер відповідає повідомленням під назвою Hello Retry Request із запитом на певну інформацію. Потім клієнт може повторно надіслати Client Hello, на цей раз із доданою запитаною інформацією. 2. Наступним йде процес обміну ключами. Саме ця частина є найважливішою, оскільки без неї, не можна говорити і про симетричний ключ. Для обміну ключами, клієнт і сервер повинні спочатку обмінятися своїми відповідними відкритими ключами. У TLS 1.2 та попередніх версіях обмін ключами здійснюється, коли обидва учасники знають, який алгоритм обміну ключами використовувати. Це означає, що вони спочатку обговорюють, який алгоритм використовувати, а потім обмінюються своїми відкритими ключами. У TLS 1.3, щоб уникнути цього першого переговорного обміну (одне повідомлення клієнта та одне повідомлення сервера), клієнт спекулятивно надсилає відкритий ключ у першому повідомленні (Client Hello). Якщо клієнту не вдається передбачити вибір сервером алгоритму обміну ключами, тоді клієнту доведеться надіслати новий Client Hello, що містить правильний відкритий ключ. Опишемо алгоритм дій клієнта та сервера: • Клієнт надсилає TLS 1.3 Client Hello, оголошуючи, що він може здійснити обмін ключами X25519 або X448. Сервер також надсилає відкритий ключ X25519. • Сервер не підтримує X25519, але підтримує X448. Він надсилає клієнту запит на повторну спробу Hello, оголошуючи, що підтримує лише X448. • Клієнт надсилає той самий Client Hello, але з відкритим ключем X448[9]. Лист ЧДТУ.229887.001 ПЗ 24 Змн. Арк. № докум. Підпис Дата • Рукостискання триває. TLS 1.3 має багато оптимізацій, які досить актуальні в сьогоденні. В першу чергу ці оптиміації дозволяють в значній мірі пом’якшити нестабільність інтернету або повільне з’єднання. Крім того, у TLS 1.3 і на відміну від попередніх версій протоколу, усі обміни ключами є недовговічними. Це означає, що для кожного нового сеансу клієнт і сервер генерують нові пари ключів, а потім позбавляються від них, як тільки обмін ключами буде завершено. Для отримання різних ключів TLS 1.3 використовує HKDF з узгодженою хеш-функцією [12]. HKDF-Extract використовується на виході обміну ключами (щоб усунути будь-які упередження), тоді як HKDF-Expand використовується з різними параметрами для отримання ключів шифрування. Наприклад, «c hs traffic» використовується для отримання симетричних ключів для клієнта для шифрування на сервері під час ркостискання, «s ap traffic» використовується для отримання симетричного ключа для шифрування сервером для клієнта після рукостискання. 3. Наступна стадія рукостискання є найважливішою частиною - аутентифікація. В Інтернеті аутентифікація в TLS зазвичай є односторонньою. Тільки користувач перевіряє, що сайт.ua справді є сайт.ua,а от сайт.ua, не перевіряє, хто ви (або принаймні ця перевірка не є частиною TLS). Аутентифікація клієнта, частіше за все за все делегується на прикладний рівень тобто за допомогою форми, яка запитує облікові дані. При цьому автентифікація клієнта також може відбуватися в TLS, якщо запитує сервер. Коли обидві сторони з’єднання автентифіковані, можна говорити про взаємну автентифікацію TLS. Аутентифікація клієнта виконується точно так само, як і аутентифікація сервера, і може відбутися в будь-який момент часу після аутентифікації сервера (під час рукостискання або на етапі рукостискання). Лист ЧДТУ.229887.001 ПЗ 25 Змн. Арк. № докум. Підпис Дата Розглянемо, як саме браузер перевіряє, що він почав рукостискання саме з сайт.ua, а не з якимось іншим ресурсом.Подібна можливість реалізується саме завдяки реалізації відкритих ключів (web PKI). Існує дві сторони web PKI: По-перше, браузери повинні довіряти набору кореневих відкритих ключів, які називаються центрами сертифікації. Зазвичай браузери або використовують жорстко запрограмований набір надійних відкритих ключів, або покладаються на їх надання операційною системою. По-друге, веб-сайти, які хочуть використовувати HTTPS, повинні мати спосіб отримати сертифікат від цих АС (підпис їхнього відкритого ключа підписання). Для цього власник веб повинен довести АС, що він є власником певного домену. Наприклад, щоб підтвердити, що ви володієте example.com, CA може попросити вас розмістити файл на example.com/some_path/file.txt, який містить деякі випадкові числа, згенеровані для вашого запиту. Після цього AС може надати підпис над відкритим ключем веб- сайту. Оскільки підпис AС зазвичай дійсний протягом кількох років, можна говорити, що він містить відкритий ключ довгострокового підпису (на відміну від короткочасного відкритого ключа). Точніше, CA фактично не підписують відкриті ключі, а натомість підписують сертифікати. Сертифікат містить довгостроковий відкритий ключ, а також деякі додаткові важливі метадані, як-от ім’я вашого домену, якщо ви є веб-сторінкою. Щоб підтвердити вашому клієнту, що сервер, з яким він спілкується, дійсно є example.com, сервер надсилає ланцюжок сертифікатів як частину рукостискання TLS Після цього браузер може використовувати свою сертифіковану довгострокову пару ключів для підписання всіх повідомлень про рукостискання, які були отримані та надіслані з моменту отримання сертифікату. Лист ЧДТУ.229887.001 ПЗ 26 Змн. Арк. № докум. Підпис Дата Частина аутентифікації рукостискання починається з надсилання сервером ланцюжка сертифікатів клієнту. Ланцюжок сертифікатів починається з листового сертифіката (сертифікат, що містить відкритий ключ веб-сайту та додаткові метадані, як-от ім’я домену) і закінчується кореневим сертифікатом, якому довіряє браузер. Кожен сертифікат містить підпис із сертифіката над ним у ланцюжку. Підпис у повідомленні Certificate Verify підтверджує клієнту те, що сервер бачив до цього часу. Без цього підпису зловмисник міг би перехопити повідомлення про рукостискання сервера та замінити короткочасний відкритий ключ сервера, що міститься в повідомленні Server Hello, і успішно видавати себе за сервер. 4. Обмін ключами може бути дорогим і іноді не потрібним. TLS 1.3 пропонує спосіб уникнути накладних витрат за допомогою спільних ключів. PSK — це просто секретні данні, який знають і клієнт, і сервер, і які можна використовувати для отримання симетричних ключів для сеансу. У TLS 1.3 рукостискання PSK працює, коли клієнт повідомляє у своєму повідомленні Client Hello, що він підтримує список ідентифікаторів PSK. Якщо сервер розпізнає один з них, він може сказати це у своїй відповіді (повідомлення Server Hello), і обидва можуть уникнути обміну ключами. При цьому фаза аутентифікації пропускається, що робить повідомлення Finish в кінці рукостискання важливим для запобігання атакам MITM. Іншим випадком використання PSK є відновлення сеансу. Відновлення сеансу – це повторне використання секретних даних, створених під час попереднього сеансу або підключення. Якщо пристрій вже підключився до example.com ланцюжки сертифікатів вже підтверджені і вже є домовленість про загальний секрет, то необхідність в повторному рукостисканні відпадає. Не менш важливим є й той факт, що зазвичай браузери мають не одне, а декілька TCP-з'єднань до веб-сторінок, які вони відвідують, тому можливість пропуску процедури рукостискання є необхідною. Лист ЧДТУ.229887.001 ПЗ 27 Змн. Арк. № докум. Підпис Дата TLS 1.3 пропонує спосіб генерувати PSK після успішного виконання рукостискання, який можна використовувати в наступних підключеннях, щоб уникнути необхідності повторювати повне рукостискання. Якщо сервер хоче запропонувати цю функцію, він може надіслати новий квиток на сеанс у будь-який час під час фази після рукостискання. Сервер може створювати так звані «квитки на сеанс» кількома способами. Наприклад, сервер може надіслати ідентифікатор, пов’язаний з відповідною інформацією в базі даних (примушуючи сервер зберігати стан), або сервер може надіслати аутентифіковане шифрування необхідної інформації для відновлення сеансу з клієнтом. 2.3 Технічна реалізація технології IPsec Для роботи даного протоколу, потрібні дві однорангові мережі IPsec, які будують тунель IPsec. Щоб встановити тунель IPsec, використовуєтся протокол під назвою IKE (Internet Key Exchange) . Існує два етапи створення тунелю IPsec: На етапі IKE 1 два однорангові партнери обговорюватимуть шифрування, аутентифікацію, хешування та інші протоколи, які вони хочуть використовувати, а також деякі інші необхідні параметри. На цьому етапі встановлюється сеанс ISAKMP (Internet Security Association and Key Management Protocol). Набір параметрів, які будуть використовувати два пристрої, називається SA. Тунель IKE фази 1 використовується лише для керування трафіком. Цей тунель використовується, як безпечний метод для встановленя другого тунелю, який називається тунелем фази 2 IKE або тунелем IPsec, а також для управління трафіком. Після завершення фази 2 IKE утворюється тунель фази 2 IKE (або тунель IPsec), який можна використовувати для захисту даних користувача. Ці дані надсилатимуться через тунель фази 2 IKE: Лист ЧДТУ.229887.001 ПЗ 28 Змн. Арк. № докум. Підпис Дата IKE 1 та 2 може побудувати тунель, але він не аутентифікує та не шифрує дані користувача. Для цього використовується два інших протоколи: AH і ESP відповідають за аутентифікацію та цілісність з’єднання (AH на відміну від ESP не шифрує дані). Через це ESP сьогодні є найпопулярнішим вибором. Обидва протоколи підтримують два різних режими: • Транспортний режим • Тунельний режим Основна відмінність між ними полягає в тому, що в транспортному режимі буде використовуватися оригінальний IP-заголовок , тоді як у тунельному режимі використовується новий IP-заголовок. Транспортний і тунельний режим протоколів AH та ESP наведено на рис. 2.4. Рисунок 2.4 – Транспортний і тунельний режим протоколів AH та ESP [19] Лист ЧДТУ.229887.001 ПЗ 29 Змн. Арк. № докум. Підпис Дата Транспортний режим часто використовується між двома пристроями, які хочуть захистити небезпечний трафік (наприклад, трафік telnet). Тунельний режим зазвичай використовується для VPN типу «сайт- сайт», де потрібно інкапсулювати оригінальний IP-пакет (оскільки це в основному приватні IP-адреси і їх не можна маршрутизувати в Інтернеті). Весь процес роботи протоколу IPsec складається з п'яти кроків: • Ініціація: щось має викликати створення наших тунелів. Наприклад, коли налаштовується IPsec на маршрутизаторі, використовується список доступу, щоб вказати маршрутизатору, які дані захищати. Коли маршрутизатор отримає щось, що відповідає списку доступу, він запускає процес IKE (але за необхідності, процес можна запустити і вручну). • IKE фаза 1: домовлення про асоціацію безпеки для будівництва тунелю IKE фази 1 (тунель ISAKMP). • IKE фаза 2: у тунелі IKE фази 1, будується тунель фази 2 IKE (тунель IPsec). • Передача даних: захищаємо дані користувачів, надсилаючи їх через тунель фази 2 IKE. • Переривання: якщо немає даних користувача для захисту, тунель IPsec буде зачинений через деякий час. 2.3.1 Internet Key Exchange Основна мета IKE фази 1 полягає в тому, щоб створити безпечний тунель, який можна використовувати для IKE фази 2. Можемо розбити фазу 1 на три прості кроки: Крок 1: Переговори Одноранговий пристрій, який має бути захищений, ініціює узгодження фази 1 IKE. Для цього він відправляє необхідні дані: • Хешування : MD5 або SHA. Лист ЧДТУ.229887.001 ПЗ 30 Змн. Арк. № докум. Підпис Дата • Аутентифікація : кожен пристрій який приймає участь в обміні, має довести, що він це він. Двома часто використовуваними варіантами є попередній спільний ключ або цифрові сертифікати. • Група DH (Diffie Hellman) : група DH визначає міцність ключа, який використовується в процесі обміну ключами. Вищі номери груп безпечніші, але обчислення займають більше часу. • Термін служби: скільки часу тунель IKE фази 1 буде відкритий. Чим менший термін служби, тим він безпечніший, тому що його відновлення означає, що також буде використовуватись новий матеріал для ключів. Кожен постачальник використовує різний термін служби, загальне значення за замовчуванням становить 86400 секунд (1 день). • Шифрування : DES, 3DES або AES. Крок 2: Обмін ключами DH Після того, як переговори пройшли успішно, обидва пристрої знатимуть, яку політику використовувати. Тепер вони будуть використовувати групу DH, про яку вони домовилися, для обміну ключовими матеріалами. Кінцевим результатом буде те, що обидва однорангові користувачі матимуть спільний ключ. Крок 3: Аутентифікація Останній крок полягає в тому, що два однорангових пристрої аутентифікують один одного за допомогою методу аутентифікації, про який вони домовилися під час переговорів. Коли аутентифікація пройшла успішно - завершився етап IKE 1. Кінцевим результатом є тунель IKE фази 1 (він же тунель ISAKMP), який є двонаправленим. Це означає, що обидва партнери можуть надсилати та отримувати данні через цей тунель. Наведені вище три кроки можна виконати за допомогою двох різних режимів (рис. 2.5): • Основний режим • Агресивний режим Лист ЧДТУ.229887.001 ПЗ 31 Змн. Арк. № докум. Підпис Дата Рисунок 2.5 – Відображення роботи основного і агресивного режиму [10] Основний режим використовує шість повідомлень, тоді як агресивний режим використовує лише три повідомлення (основний режим вважається більш безпечним). Висновки: В цьому розділі, було детально розглянуті найбільш ефективні та сучасні протоколи захисту інформації на даний момент часу, що дає можливість перейти до наступних розділів, а сам до порівняння та аналізу розглянутих протоколів. Частина протоколів та технологій які розглядались в першому розділі не були описані тут. Це пов’язано з тим, що хоч ці протоколи і використовуються й домі, в цілому вони вже застаріли і мають більш сучасні аналоги. Лист ЧДТУ.229887.001 ПЗ 32 Змн. Арк. № докум. Підпис Дата 3 ЗАСТОСУВАННЯ ПРОТОКОЛІВ ЗАХИСТУ ДАНИХ В ЦИФРОВИХ СИСТЕМАХ ПЕРЕДАЧІ ДАНИХ 3.1 Вразливості IРsec Сьогодні багато організацій використовують віртуальні приватні мережі IPsec для підключення до віддалених місць. Критична інформація, яка проходить через невідомі мережі, захищена криптографією. Тому дуже важливо, щоб обрана технологія використовувала надійну криптографію для захисту трафіку та забезпечення конфіденційності даних. Оскільки COVID-19 набув широкого поширення, майже всі компанії залежать від віддаленої робочої сили, а також VPN на рівні підприємства. В той же час, роки пандемії стали ідеальним періодом для хакерів знайти шлях до ІТ-мереж і цифрових активів. Розглянемо найбільш актуальні та небезпечні загрози для мереж на основі IPsec: CVE-2018-13382 FortiOS: зміна пароля неавтентифікованих користувачів SSL VPN Уразливість неправильної авторизації на веб-порталі SSL VPN може дозволити неавтентифікованому зловмиснику змінити пароль користувача веб-порталу SSL VPN за допомогою спеціально створених HTTP-запитів. Уражені продукти: • FortiOS 6.0.0 до 6.0.4 • FortiOS 5.6.0–5.6.8 • FortiOS 5.4.1–5.4.10 Рішення: оновленя до FortiOS 5.4.11, 5.6.9, 6.0.5, 6.2.0 або вище. CVE-2018-13383 FortiOS: переповнення буфера SSL VPN під час аналізу вмісту javascript href Уразливість переповнення буфера SSL VPN може призвести до припинення роботи SSL VPN для користувачів, які ввійшли в систему, або потенційно віддаленого виконання коду на FortiOS; це трапляється, коли Лист ЧДТУ.229887.001 ПЗ 33 Змн. Арк. № докум. Підпис Дата автентифікований користувач відвідує спеціально створену веб-сторінку з проксі-сервером, і пов’язано з невдачею належної обробки вмісту javascript href. Уражені продукти: • FortiOS 6.0.0 до 6.0.4 • FortiOS 5.6.0–5.6.10 • FortiOS 5.4.0–5.4.12 • FortiOS 5.2.0–5.2.14 Рішення: оновленя до FortiOS 5.2.15, 5.4.13, 5.6.11, 6.0.5 або 6.2.0 і вище. CVE-2020-2050 PAN-OS: вразливість обходу автентифікації під час перевірки сертифіката клієнта GlobalProtect У компоненті GlobalProtect SSL VPN програмного забезпечення PAN- OS Palo Alto Networks існує вразливість для обходу автентифікації, яка дозволяє зловмиснику обійти всі перевірки сертифікатів клієнта за допомогою недійсного сертифіката. Віддалений зловмисник може успішно пройти автентифікацію як будь-який користувач і отримати доступ до обмежених мережевих ресурсів VPN, коли шлюз або портал налаштовані на повну автентифікацію на основі сертифікатів. Уражені функції, які використовують SSL VPN із перевіркою сертифіката клієнта, — це GlobalProtect Gateway, GlobalProtect Portal, GlobalProtect Clientless VPN. Уражені продукти: • Версії PAN-OS 8.1 раніше, ніж PAN-OS 8.1.17 • Версії PAN-OS 9.0 раніше, ніж PAN-OS 9.0.11 • Версії PAN-OS 9.1 раніше, ніж PAN-OS 9.1.5 • Версії PAN-OS 10.0 раніше, ніж PAN-OS 10.0.1 Рішення: цю проблему вирішено в PAN-OS 8.1.17, PAN-OS 9.0.11, PAN-OS 9.1.5, PAN-OS 10.0.1 та у всіх пізніших версіях PAN-OS. Лист ЧДТУ.229887.001 ПЗ 34 Змн. Арк. № докум. Підпис Дата CVE-2020-2005 PAN-OS: викрадення сеансу VPN без клієнта GlobalProtect Уразливість міжсайтових сценаріїв (XSS) існує під час відвідування шкідливих веб-сайтів за допомогою безклієнтської VPN Palo Alto Networks GlobalProtect, яка може порушити активний сеанс користувача. Уражені продукти: • Версії PAN-OS 7.1 раніше, ніж 7.1.26 • Версії PAN-OS 8.1 раніше, ніж 8.1.13 • Версії PAN-OS 9.0 раніше, ніж 9.0.7 • Усі версії PAN-OS 8.0 Рішення: цю проблему вирішено в PAN-OS 7.1.26, PAN-OS 8.1.13, PAN-OS 9.0.7 та у всіх пізніших версіях PAN-OS. CVE-2019-1579 PAN-OS: віддалене виконання коду в інтерфейсі порталу/шлюзу GlobalProtect Palo Alto Networks знає про вразливість віддаленого виконання коду (RCE) на своєму порталі GlobalProtect та інтерфейсних продуктах GlobalProtect Gateway. Проблема вже вирішена в попередніх випусках обслуговування. Успішне використання цієї проблеми дозволяє неавтентифікованому зловмиснику виконувати довільний код. Рішення: PAN-OS 7.1.19 і новіших версій, PAN-OS 8.0.12 і новіших версій і PAN-OS 8.1.3 і новіших версій. CVE-2020-5135 SONIC-OS: вразливість переповнення буфера Уразливість переповнення буфера в SonicOS дозволяє віддаленому зловмиснику викликати відмову в обслуговуванні (DoS) і потенційно виконувати довільний код, надіславши шкідливий запит до брандмауера. Ця вразливість торкнулася SonicOS Gen 6 версії 6.5.4.7, 6.5.1.12, 6.0.5.3, SonicOSv 6.5.4.v і Gen 7 версії 7.0.0.0. Лист ЧДТУ.229887.001 ПЗ 35 Змн. Арк. № докум. Підпис Дата Не знаючи жодного імені користувача та/або пароля, зловмисники можуть просто надіслати створені запити до служби SonicWALL HTTP(S) і викликати пошкодження пам’яті. Уражені продукти: • SonicOS 6.5.4.7-79n і раніше • SonicOS 6.5.1.11-4n і раніше • SonicOS 6.0.5.3-93o і раніше • SonicOSv 6.5.4.4-44v-21-794 і раніше • SonicOS 7.0.0.0-1 Рішення: випущено патч. Портали SSL VPN можуть бути відключені від Інтернету як тимчасове пом’якшення перед застосуванням виправлення. CVE-2019-7481 SonicOS: вразливість сліпої ін'єкції SQL, яку можна використовувати віддалено Уразливість у SonicWall SMA100 дозволяє неавтентифікованим користувачам отримати доступ лише для читання до неавторизованих ресурсів. Уражені продукти: • SonicWall SMA100 9.0.0.3 і раніше Рішення: оновлення до актуальної версії. CVE-2019-7482 SonicOS: Виконання довільні команди без жодних привілеїв на пристрої Переповнення буфера на основі стека в SonicWall SMA100 дозволяє неавтентифікованому користувачеві виконувати довільний код у функції libSys.so. Уражені продукти: • SonicWall SMA100 9.0.0.3 і раніше Рішення: оновлення до актуальної версії. Лист ЧДТУ.229887.001 ПЗ 36 Змн. Арк. № докум. Підпис Дата CVE-2019-7483 SonicOS: вразливість попередньої автентифікації У SonicWall SMA100 неавтентифікована вразливість проходження каталогу в handleWAFRedirect CGI дозволяє користувачеві перевірити наявність файлу на сервері. Уражені продукти: • SonicWall SMA100 9.0.0.3 і раніше Рішення: оновлення до актуальної версії. CVE-2020-3220 Cisco IOS: уразливість програмного забезпечення Cisco IOS XE IPsec VPN при відмові в обслуговуванні Уразливість у драйвері апаратного шифрування програмного забезпечення Cisco IOS XE для маршрутизаторів із інтегрованими службами Cisco серії 4300 і бездротових контролерів Cisco Catalyst 9800-L може дозволити неавтентифікованому віддаленому зловмиснику відключити законні сеанси IPsec VPN до ураженого пристрою. Уразливість пов’язана з недостатньою перевіркою автентичності отриманих пакетів Encapsulating Security Payload (ESP). Зловмисник може скористатись цією вразливістю, підробивши значення відкритого тексту ESP як «людина посередині». Cisco випустила оновлення програмного забезпечення, які усувають цю вразливість. Немає жодних обхідних шляхів для усунення цієї вразливості. Уражені продукти: • Маршрутизатори з інтегрованими послугами Cisco серії 4300 • Бездротові контролери Cisco Catalyst 9800-L Рішення: Cisco надає засіб перевірки програмного забезпечення Cisco для виявлення будь-яких повідомлень про безпеку Cisco, які впливають на конкретну версію програмного забезпечення, і найпершого випуску, який усуває вразливості, описані в кожному. Якщо можливо, інструмент також повертає найраніший випуск, який усуває всі вразливості, описані в усіх виявлених рекомендаціях. Лист ЧДТУ.229887.001 ПЗ 37 Змн. Арк. № докум. Підпис Дата CVE-2020-14511: безпечні маршрутизатори/сервери VPN серії Moxa EDR-G902 і EDR-G903 мають помилку переповнення буфера на основі стека Шкідлива робота створеного файлу cookie веб-браузера може призвести до переповнення буфера на основі стека в системному веб-сервері на маршрутизаторах серії EDR-G902 і EDR-G903 (версії до 5.4). Ці маршрутизатори/сервери VPN мають помилку переповнення буфера на основі стека, яка може призвести до RCE. Moxa EDR-G902 і EDR-G903, що широко використовуються в таких важливих секторах інфраструктури, як виробництво, енергетика та транспорт, є промисловими VPN-серверами з універсальним безпечним маршрутизатором, який включає брандмауер і трансляцію доступу до мережі (NAT). Оскільки EDR G902/G903 часто використовуєтся для доступу до Інтернету, зловмисники потенційно можуть використати виявлену вразливість як шлюз до середовищ цільових операційних технологій (OT). Moxa EDR-G902 і EDR-G903 використовують веб-сервер на основі GoAhead, реалізований у двійковому файлі /magicP/WebServer/webs для обробки запитів HTTP/HTTPS до портів 80 і 443. Щоб перевірити автентифікацію, функція websSecurityHandler перевіряє файл cookie, встановлений користувачем на стороні клієнта. Уражені продукти: • Серія EDR-G902 • Серія EDR-G903 Рішення. Організації, які не можуть негайно застосувати оновлення мікропрограми, можуть прийняти наступні захисні заходи, рекомендовані CISA, щоб рекомендувати використання цієї вразливості: • Звести до мінімуму вплив мережі на всі промислові системи керування (ICS) та пристрої, не підключаючи їх до Інтернету. • Захистити системи та пристрої ICS за допомогою брандмауерів та ізолювати їх від бізнес-мережі організації. Лист ЧДТУ.229887.001 ПЗ 38 Змн. Арк. № докум. Підпис Дата • Використати VPN або інші безпечні методи, коли потрібен віддалений доступ, оновлюючи ці заходи захисту до останньої доступної версії. В табл. 3.1 наведена узагальнююча характеристика рівня загроз технологій IPsec та їх використання. Таблиця 3.1 – Узагальнююча характеристика рівня загроз технологій IPsec та їх використання Назва Ступінь Використання Рішення вразливості загрози CVE-2018- Висока Низька Оновлення FortiOS до 13382 найновіших версій CVE-2020- Висока Немає даних Оновлення до в PAN-OS 2050 8.1.17 і вище CVE-2020- Низька Низька Оновлення до в PAN-OS 2005 8.1.17 і вище CVE-2019- Висока Низька Оновлення до в PAN-OS 1579 8.1.17 і вище CVE-2020- Висока Середня Існує лише пом’якшення 5135 загрози – патч CVE-2019- Низька Низька Оновлення до актуальної 7481 версії CVE-2019- Висока Низька Оновлення до актуальної 7482 версії CVE-2019- Низька Середня Оновлення до актуальної 7483 версії CVE-2020- Висока Середня засіб перевірки 3220 програмного забезпечення CVE-2020- Середня Середня Пом’якшуючі 14511 рекомендації Лист ЧДТУ.229887.001 ПЗ 39 Змн. Арк. № докум. Підпис Дата 3.2 Вразливості SSL VPN CVE-2019-19781 — вразливість для обходу шляху або каталогу в продуктах Citrix ADC, шлюзів і SD-WAN WANOP. Хронологія протидії CVE-2019-19781 наведена на рис. 3.1. Рисунок 3.1 – Хронологія протидії CVE-2019-19781[1] Вразливість була оприлюднена 17 грудня 2019 року. Вона отримала оцінку CVSSv3 9,8. На момент розкриття вразливості жодних виправлень не було. Щоб використати цю вразливість, неавтентифікований віддалений зловмисник може надіслати спеціально створений запит, що містить рядок обходу каталогу, на вразливу кінцеву точку Citrix. Успішне використання дозволяло зловмиснику виконати довільний код. До 10 січня 2020 року, після пильної уваги та аналізу дослідників, скрипти експлойтів стали загальнодоступними. Наступного дня SANS Internet Storm Center повідомив про спроби використання цих скриптів проти своїх honeypots. Citrix нарешті випустила виправлення для CVE-2019-19781 24 січня 2020 року. Виходячи з історії експлуатації, яка триває аж до 2021 року, можна з упевненістю припустити, що багато організацій досі не Лист ЧДТУ.229887.001 ПЗ 40 Змн. Арк. № докум. Підпис Дата застосували ці виправлення через півтора року після того, як вони були звільнені. Використання CVE-2019-19781 почалося невдовзі після його розкриття. Звіти та сповіщення поширювалися протягом 2020 року, завдяки чому загроза отримала статус найбільш експлуатованого CVE за рік. Нажаль, така популярна вразливість не зникла безвісти. Зловмисники продовжують використовувати цю вразливість. CVE-2019-19781 був використаний кількома групами загроз, спрямованими на індустрію охорони здоров’я. Групи програм- вимагачів, такі як Maze (зараз не діючий) і Conti, віддають перевагу атакам на протокол віддаленого робочого столу, але також спостерігали використання CVE-2019-19781 під час атак на сектор охорони здоров’я. Крім того, групи розширених стійких загроз (APT) використали цю вразливість проти цілей, які працюють над розробкою вакцини проти COVID-19. Зловмисники вказали, що віддають перевагу цій уразливості на онлайн- форумах у період із січня 2020 року по березень 2021 року. Згідно з дослідженням Cognyte , CVE-2019-19781 був найпоширенішим CVE на російськомовних та англомовних темних веб-форумах. Він був згаданий у 49 публікаціях, та є другою за кількістю постів. У червні 2021 року дослідники Trend Micro опублікували аналіз групи програм-вимагачів Nefilim. Це дослідження показало, що ця група використовує CVE-2019-19781 як початковий вектор атаки. Trend Micro використала Nefilim як приклад для ілюстрації поведінки «сучасних атак програм-вимагачів», тому цілком зрозуміло, що інші групи програм- вимагачів також використовують цю вразливість у своїх атаках. Уражені продукти: • Citrix ADC і Citrix Gateway версії 13.0 усі підтримувані збірки до 13.0.47.24 • NetScaler ADC і NetScaler Gateway версії 12.1 всі підтримувані збірки до 12.1.55.18 Лист ЧДТУ.229887.001 ПЗ 41 Змн. Арк. № докум. Підпис Дата • NetScaler ADC і NetScaler Gateway версії 12.0 усі підтримувані збірки до 12.0.63.13 • NetScaler ADC і NetScaler Gateway версії 11.1 усі підтримувані збірки до 11.1.63.15 • NetScaler ADC і NetScaler Gateway версії 10.5 усі підтримувані збірки до 10.5.70.12 • Усі моделі пристроїв Citrix SD-WAN WANOP 4000-WO, 4100-WO, 5000-WO та 5100-WO усі підтримувані збірки програмного забезпечення до 10.2.6b та 11.0.3b Рішення: Citrix наполегливо закликає постраждалих клієнтів негайно перейти на фіксовану збірку або застосувати надане пом’якшення, яке однаково застосовується до розгортань Citrix ADC, Citrix Gateway і Citrix SD- WAN WANOP. Клієнти, які вирішили негайно застосувати пом’якшення, повинні потім оновити всі свої вразливі пристрої до фіксованої збірки пристрою якомога раніше. CVE-2019-11510 Pulse Connect Secure (PCS): довільне читання файлів попередньої авторизації Карта вражених CVE-2019-11510 пристроїв наведена на рис. 3.2. У квітні 2019 року Pulse Secure випустила рекомендації щодо позасмугової безпеки , щоб усунути численні вразливості в своєму рішенні Pulse Connect Secure SSL VPN, включаючи кілька недоліків, розкритих дослідниками Мех Чангом і Оранж Цай з дослідницької групи DEVCORE. Найпомітнішою вразливістю, зазначеною в рекомендації, була CVE-2019-11510, уразливість довільного розкриття файлів, якій було присвоєно максимальний бал CVSSv3 10,0. Неавтентифікований віддалений зловмисник може скористатись уразливістю, надіславши HTTP-запит, що містить спеціально створений рядок обходу каталогу. Лист ЧДТУ.229887.001 ПЗ 42 Змн. Арк. № докум. Підпис Дата Рисунок 3.2 – Карта вражених CVE-2019-11510 пристроїв [1] Успішне використання CVE-2019-11510 дозволяє зловмиснику прочитати вміст конфіденційних файлів на вразливому пристрої Pulse Connect Secure. Один файл, зокрема, data.mdb, містить паролі у відкритому тексті для SSL VPN. Якщо зловмисник може прочитати цей файл, він може використовувати паролі простого тексту для автентифікації у вразливому SSL VPN. Сама по собі ця вразливість є значною, оскільки вона легко дозволяє зловмисникам аутентифікуватися в SSL VPN, просто надсилаючи запити на вразливий пристрій. Однак, прив’язавшись до CVE-2019-11539, уразливості після аутентифікації, введеної командою в Pulse Secure, зловмисник може отримати доступ до обмеженого середовища, такого як корпоративна мережа. У серпні 2019 року, після презентацій Чанга і Цая Black Hat і DEF CON 27 щодо їх дослідження кількох VPN-сервісів SSL, на GitHub почали поширюватися сценарії для підтвердження концепції (PoC). Незабаром після цього дослідники помітили зростання кількості спроб сканувати і використовувати вразливі системи Pulse Connect Secure. Лист ЧДТУ.229887.001 ПЗ 43 Змн. Арк. № докум. Підпис Дата На додаток до конфіденційних паролів у відкритому тексті, доступних за допомогою CVE-2019-11510, дослідники також виявили, що зловмисники можуть отримати доступ до облікових даних Active Directory, які були зашифровані за допомогою статичного ключа. У січні 2020 року зловмисники використали CVE-2019-11510, щоб розгорнути програму-вимагач REvil або Sodinokibi. У березні дослідники з відділу 42 Palo Alto Network відзначили, що CVE-2019-11510 також використовувався групою програм-вимагачів MAZE. Це лише одна з уразливостей SSL VPN, які використовуються групами програм-вимагачів, щоб проникнути в мережу. У першому кварталі 2021 року звіт Nuspire показав збільшення на 1527% спроб використання CVE-2019-11510 проти вразливих Pulse Connect Secure SSL VPN. Незважаючи на те, як багато уваги приділено CVE-2019-11510, у квітні 2021 року було оголошено про нульовий день у Pulse Connect Secure, ідентифікований як CVE-2021-22893. Незабаром після цього розкриття дослідники виявили, що китайські зхакери використовували CVE-2021- 22893 , а також інші вразливості після аутентифікації в Pulse Connect Secure на додаток до CVE-2019-11539. Сюди входять CVE-2020-8260 і CVE-2020- 8243 , два недоліки у веб-інтерфейсі адміністратора пристроїв Pulse Connect Secure, які були виправлені у вересні та жовтні 2020 року . Уражені продукти: • Pulse Connect Secure 9.0R1 – 9.0R3.3 • Pulse Connect Secure 8.3R1 – 8.3R7 • Pulse Connect Secure 8.2R1 – 8.2R12 • Pulse Connect Secure 8.1R1 – 8.1R15 • Pulse Policy Secure 9.0R1 – 9.0R3.1 • Pulse Policy Secure 5.4R1 – 5.4R7 • Pulse Policy Secure 5.3R1 – 5.3R12 Лист ЧДТУ.229887.001 ПЗ 44 Змн. Арк. № докум. Підпис Дата • Pulse Policy Secure 5.2R1 – 5.2R12 • Pulse Policy Secure 5.1R1 – 5.1R15 Рішення . Рішенням цих уразливостей є оновлення версії програмного забезпечення сервера Pulse Connect Secure та Pulse Policy Secure до відповідної версії, яка має виправлення. CVE-2018-13379 FortiOS: довільне читання файлів попередньої авторизації У травні 2019 року компанія Fortinet випустила рекомендацію команди реагування на інциденти безпеки продуктів (PSIRT) FG-IR-18-384 для усунення CVE-2018-13379 , уразливості обходу каталогів у їхній FortiOS SSL VPN. Недолік дозволяє неавтентифікованому зловмиснику отримати доступ до довільних системних файлів за допомогою створених HTTP-запитів. Ця вразливість була описана Чангом і Цай з DEVCORE в тих же презентаціях Black Hat USA і DEF CON 27 2019 року, що й уразливість Pulse Secure, згадана раніше. Пара детально розповіла, як CVE-2018-13379 можна використовувати для отримання файлу сеансу, який містить ім’я користувача та відкритий текстовий пароль для користувача VPN, дуже схожий на CVE- 2019-11510. Ці дані виявляться корисними для поєднання додаткових вразливостей у VPN, зокрема CVE-2018-13383, уразливості переповнення буферу після аутентифікації, яка була використана для отримання доступу до віддаленої оболонки на уражених версіях FortiOS SSL VPN. CVE-2018-13383 було розглянуто в консультативній службі PSIRT FG-IR-18-388 у квітні 2019 року, а додаткові гілки випуску, які постраждали, було виправлено в травні, серпні та листопаді 2019 року. Незабаром після конференцій Black Hat і DEF CON компанія Fortinet опублікувала пост у блозі, в якому обговорювалися вразливості та виправлення, закликаючи клієнтів якнайшвидше застосувати виправлення. Протягом місяця після переговорів на конференції зловмисники Лист ЧДТУ.229887.001 ПЗ 45 Змн. Арк. № докум. Підпис Дата почали використовувати вразливі пристрої та випустили кілька PoC для кількох CVE у FortiGate SSL VPN. Хоча CVE-2018-13379 був однією з найулюбленіших уразливостей для зловмисників і груп APT, Fortinet виявив і виправили додаткові недоліки в FortiOS, включаючи CVE-2019-5591 і CVE-2020-12812, які також використовувалися учасниками загроз: • CVE-2019-5591 - вразливість конфігурації за замовчуванням у FortiGate SSL VPN через відсутність підтвердження сертифіката Lightweight Directory Access Protocol (LDAP), який дозволив би зловмиснику збирати конфіденційну інформацію, призначену для законного сервера LDAP. • CVE-2020-12812 – вразливість неправильної автентифікації у FortiGate SSL VPN через неправильно налаштовані параметри двофакторної автентифікації. Це може бути використано, якщо законний користувач змінює регістр свого імені користувача, анулюючи вимогу другого фактора, дозволяючи зловмиснику взагалі обійти двофакторну аутентифікацію. За даними Nuspire, у першому кварталі 2021 року кількість атак із застосуванням CVE-2018-13379 проти SSL VPN від Fortinet зросла на 1916%. У квітневому звіті Kaspersky ICS CERT, розслідування реагування на інцидент показало, що CVE-2018-13379 використовувався як початкова точка входу в корпоративну мережу учасниками загроз, які пізніше розгорнули програмне забезпечення-вимагач Cring. Програма-вимагач Cring — це відносно новий варіант програми-вимагача, який використовує дві форми шифрування та видаляє файли резервної копії, намагаючись змусити жертв сплатити викуп. Завдяки загальнодоступним PoC і великій кількості невиправлених пристроїв для зловмисників, мережі FortiGate SSL VPN залишаться дуже цінними точками входу для зловмисників, якщо не буде вжито заходів для захисту пристроїв та застосування необхідних оновлень безпеки. Оскільки атаки тривають, Fortinet намагається зв’язатися зі своїми клієнтами та Лист ЧДТУ.229887.001 ПЗ 46 Змн. Арк. № докум. Підпис Дата опублікувати регулярні оновлення, включаючи допис у блозі в червні 2021 року, в якому закликає клієнтів вжити негайних дій, щоб застосувати виправлення або пом’якшення, зазначені в їхніх PSIRT. 15 квітня 2021 року Агентство національної безпеки (АНБ) і Федеральне бюро розслідувань (ФБР) опублікували спільне сповіщення про діяльність російської Служби зовнішньої розвідки (СВР), яка використовує всі ці вразливості. Це сталося після повідомлень від 2020 року, які вказували на атаки Китаю, Ірану та Росії за підтримки держав, які використовують ці вразливі місця. Ці вразливості часто використовувалися в ланцюгах експлойтів, що призводили до захоплення контролерів домену за допомогою CVE-2020-1472, також відомого як Zerologon. У травні 2021 року ФБР отримало додаткову рекомендацію , яка закликала негайно виправити CVE-2018-13379, CVE-2020-12812 і CVE-2019- 5591, а також надати індикатори компромісу (IOC), які спостерігалися під час дії APT. CVE-2018-13379, CVE-2019-19781 і CVE-2019-11510 були включені до спільного рекомендаційного списку найбільш часто використовуваних уразливостей 2020 року Центром кібербезпеки та безпеки інфраструктури (CISA) та Національним агентством кібербезпеки Великобританії. Уражені продукти: • FortiOS 6.0 – 6.0.0 – 6.0.4 • FortiOS 5.6 – 5.6.3 – 5.6.7 • FortiOS 5.4 – 5.4.6 – 5.4.12 Рішення: оновленя до FortiOS 5.4.13, 5.6.8, 6.0.5 або 6.2.0 і вище. В табл. 3.2 наведена узагальнююча характеристика рівня загроз технологій SSL VPN та їх використання. Лист ЧДТУ.229887.001 ПЗ 47 Змн. Арк. № докум. Підпис Дата Таблиця 3.2 – Узагальнююча характеристика рівня загроз технологій SSL VPN та їх використання Назва Ступінь Використання Рішення Вразливості Загрози CVE-2019- Висока Висока Пом’мякшуючі рекомендації, 19781 перехід на стабільну версію CVE-2019- Висока Висока Оновлення до актуальної 11510 версії CVE-2018- Висока Висока Оновлення до FortiOS 5.4.13, 13379 5.6.8, 6.0.5 або 6.2.0 CVE-2019- Середня Висока Оновлення до FortiOS 5.4.13, 5591 CVE- 5.6.8, 6.0.5 або 6.2.0 2020-12812 CVE-2020- Середня Висока Оновлення до FortiOS 5.4.13, 12812 5.6.8, 6.0.5 або 6.2.0 3.3 Відомі вразливості в протоколі SSH Проблеми відстеження ключів SSH Нерідко типове велике підприємство з великою кількістю серверів має більше мільйона ключів SSH, що робить, задачу по відстеженню та керуванню ними неймовірно складною або взагалі неможливою. Організації зазвичай накопичують велику кількість ключів SSH, оскільки кінцеві користувачі можуть створювати нові ключі SSH або навіть дублювати їх без нагляду (на відміну від сертифікатів або паролів). З часом накопичується велика кількість ключів SSH в результаті чого організація може, легко втратити частину ключів, наприклад, , коли сервери розробки переміщуються у виробниче середовище (за умови, що облікові дані середовища розробки не очищаються) або коли співробітники залишають компанію. і їх ключі не змінюються. Як результат, невраховані ключі SSH можуть надати Лист ЧДТУ.229887.001 ПЗ 48 Змн. Арк. № докум. Підпис Дата зловмисникам довгостроковий привілейований доступ до корпоративних ресурсів. Рішення: Зміна політики безпеки організації. Незмінні вбудовані ключі SSH Ключі SSH часто вбудовуються в програми або сценарії. Адміністратори часто бояться змінювати їх, оскільки не розуміють коду, в який вбудовані ключі. В результаті статичні ключі SSH, вбудовані в програми, код і сценарії, можуть призвести до постійних бекдорів для зловмисників. Ключі SSH можуть надати хакерам величезну можливість отримати привілейований доступ до мереж, залишатися на зв’язку, видавати себе за легальних користувачів, приховувати свою активність за допомогою шифрування та вільно пересуватися. Рішення: зміна вбудованих ключів. Модернізація політики безпеки компанії. CVE-2010-2632 Множинні вразливості в Openssh Вразливість із середнім ризиком, яка є однією з найбільш поширених у мережах у всьому світі. Ця проблема існує принаймні з 1990 року, але виявилося, що її важко виявити, важко розв’язати або її можна зовсім не помітити. Функція remote_glob у sftp-glob.c та функція process_put у sftp.c у OpenSSH 5.8 та попередніх версіях, які використовуються у FreeBSD 7.3 та 8.1, NetBSD 5.0.2, OpenBSD 4.7 та інших продуктах, дозволяють віддаленим користувачам, що пройшли автентифікацію, викликати відмову в обслуговуванні (витрата ЦП і пам'яті) через створені виразів glob, які не відповідають жодним іменам шляху, як демонструють вирази glob у запитах SSH_FXP_STAT до демона sftp. Рішення: дану вразливість досить важко прибрати повністю, але через свою відомість та популярність, створено багато методів пом’якшеня даної загрози. CVE-2010-2632- можна важати ідентифікатором захисту з’їднаня, Лист ЧДТУ.229887.001 ПЗ 49 Змн. Арк. № докум. Підпис Дата якщо вона не пом’якшена, то це прямо говорить про слабкість захисту з’єднаня. CVE-2018-10933 LibSSHhhh вразливість обходу аутентифікації Вразливість дозволяє зловмиснику повністю обійти крок аутентифікації та підключитися до сервера без надання жодних облікових даних, що є найгіршим недоліком для бібліотеки, яка реалізує SSH. Ця бібліотека використовується багатьма невеликими програмами та вбудованими системами, серед них GnuGK, служба шлюзу VOIP. Ця вразливість була розкрита Пітером Вінтер-Смітом з NCC Group, і виправлені версії вже існують. Рішення: Оновлення LibSSHhhh 0.8.4 або 0.7.6 В табл. 3.3 наведена узагальнююча характеристика рівня загроз протоколу SSH та їх використання. Таблиця 3.3 – Узагальнююча характеристика рівня загроз протоколу SSH та їх використання Назва Ступінь Використання Рішення вразливості загрози Проблеми Висока Висока Зміна політики безпеки. відстеження ключів SSH Незмінні Висока Висока Зміна вбудованих ключів. вбудовані Модернізація політики ключі SSH безпеки. CVE-2018- Висока Висока Оновлення LibSSHhhh 0.8.4 10933 або 0.7.6 CVE-2019- Середня Висока Відомі пом’якшення 5591 CVE- 2020-12812 Лист ЧДТУ.229887.001 ПЗ 50 Змн. Арк. № докум. Підпис Дата 3.4 Порівняння IPsec, SSL VPN ТА SSH В перших розділах розглядались протоколи захисту даних відособлено один від одного. в більш пізніх розділах, була зібрана основна інформація стосовно актуальних технологій захисту даних. Тепер же, розглянемо найбільш перспективні технології на базі згаданих протоколів, порівняємо їх, опишемо їх слабкі та сильні сторони, а також дослідимо доречність використання даних технологій для різних типів підприємств. Безпека підприємств та компаній, залежить в тому числі від ступеню захисту іх даних. Саме тому, за допомогою правильного VPN підприємство може зменшити ризики безпеки, пов’язані з наданням віддаленого доступу до мережі. На рис. 3.3 наведена статистика по працівникам, що працюють з дому в США у 2021 році. Рисунок 3.3 – Статистика по працівникам, що працюють з дому в США у 2021 році [19] Одне з найважливіших рішень при виборі технології захисту даних в мережі, це вибір конкретного рішення. Підприємства повинні збалансувати не тільки різні ризики безпеки кожного типу шифрування мережевого Лист ЧДТУ.229887.001 ПЗ Змн. Арк. № докум. Підпис Дата 51 з’єднання, але й зважувати відносні переваги, пов’язані з продуктивністю мережі, обслуговуванням та конфігурацією. Основна відмінність між IPsec VPN і SSL VPN зводиться до мережевих рівнів , на яких виконуються шифрування та аутентифікація. IPsec працює на мережевому рівні і може використовуватися для шифрування даних, що передаються між будь-якими системами, які можна ідентифікувати за IP- адресами. SSL - або, що більш імовірно, протокол безпеки транспортного рівня (TLS). Інша важлива відмінність полягає в тому, що IPsec не вказує явно шифрування з'єднань, тоді як SSL VPN за замовчуванням шифрують мережевий трафік. Жодне обговорення VPN не було б повним без згадки про SSH , який можна використовувати для забезпечення безпечних тунелів між клієнтами і серверами. SSH реалізує власні протоколи шифрування та аутентифікації для забезпечення безпечних ланцюгів між клієнтом і сервером. Іноді він використовується як своєрідна тимчасова VPN, наприклад, коли віддалені користувачі входять у свою робочу систему для доступу до служб і систем у корпоративній мережі. Розуміння переваг і недоліків IPsec проти SSL VPN починається з розуміння того, як IPsec і SSL працюють для захисту віддалених мережевих з’єднань. І жодне порівняння переваг IPsec та SSL VPN не обходиться без пропозицій щодо тестування продуктів і програмного забезпечення VPN. 3.5 Порівняльна характеристика Вибір між IPsec та SSL VPN повинен ґрунтуватися на умовах та вимогах організації. Хоча для тієї чи іншої моделі можуть бути філософські або теоретичні переваги, фактичне рішення має ґрунтуватися на порівнянні переваг і недоліків, які стосуються фактичного впровадження, на основі фактів (рис. 3.4). Лист ЧДТУ.229887.001 ПЗ 52 Змн. Арк. № докум. Підпис Дата Рисунок 3.4 – Порівняння IPsec з VPN [17] Порівняння IPsec і SSL VPN означає зважування плюсів і мінусів. Першим кроком у порівнянні IPsec з VPN є визначення вимог до організації та її користувачів і визначення найважливіших функцій і функцій VPN. Деякі відмінності між IPsec і SSL VPN включають наступне: • Продуктивність: із сучасним апаратним забезпеченням тип шифрування, який використовується IPsec і SSL VPN, зазвичай не викликає проблем із продуктивністю, але організації повинні використовувати тести для тестування кандидатів на VPN. IPsec VPN налаштовують тунель між клієнтом і сервером за допомогою певного програмного забезпечення на клієнті, що може вимагати відносно тривалого процесу налаштування; SSL VPN, які працюють за допомогою веб-браузерів, зазвичай здатні встановлювати з’єднання набагато швидше. • Безпека: один тип VPN не обов’язково є більш безпечним за будь- яких обставин. Найважливішим фактором у визначенні того, який тип VPN буде більш безпечним, є модель загроз, на якій організація базує свої вимоги Лист ЧДТУ.229887.001 ПЗ 53 Змн. Арк. № докум. Підпис Дата до VPN. Кожен тип VPN слід оцінювати в контексті типу атак, від яких захищається організація. Безпека використовуваних алгоритмів шифрування важлива, але також важлива безпека інших компонентів реалізації. • Аутентифікація даних: VPN можуть шифрувати всі передані дані, але вони також можуть додати автентифікацію даних для захисту від фальсифікацій за допомогою надійних алгоритмів криптографічної аутентифікації, щоб переконатися, що дані не були змінені під час передачі між клієнтами VPN і серверами. Одна з основних проблем в роботі будь якого VPN це потреба безпечного механізму обміну ключами, щоб увімкнути аутентифікацію. У той час як протокол SSL/TLS включає узгодження алгоритмів обміну ключами, IPsec для цієї мети покладається на зовнішній протокол Internet Key Exchange. • Захист від атак: атаки на IPsec VPN і SSL VPN - і захист від цих атак - будуть відрізнятися залежно від основного протоколу VPN, реалізації та додаткових функцій. Ключова відмінність між IPsec і SSL VPN полягає в різниці в кінцевих точках для кожного протоколу. IPsec VPN зазвичай забезпечує віддалений доступ до всієї мережі та всіх пристроїв і послуг, що пропонуються в цій мережі. Якщо зловмисники отримають доступ до захищеного тунелю, вони можуть отримати доступ до будь-чого в приватній мережі. SSL забезпечує з'єднання між пристроєм, конкретними системами та додатками, тому поверхня атаки більш обмежена. • Безпека клієнта: хоча протокол IPsec є частиною набору TCP/IP, він не завжди реалізується як компонент за замовчуванням в ОС, які підтримують TCP/IP. На відміну від цього, SSL VPN покладаються на TLS, який за замовчуванням включений у веб-браузери, а також у багато інших протоколів прикладного рівня. У результаті порівняння IPsec і SSL VPN має включати розгляд того, як клієнти підключаються і використовують VPN, а також наскільки ці параметри безпечні. Розробники повинні враховувати, як Лист ЧДТУ.229887.001 ПЗ 54 Змн. Арк. № докум. Підпис Дата клієнти підключаються до VPN, поверхню атаки клієнтів із підтримкою VPN та профілі користувачів VPN. • Шлюз VPN: VPN SSL, ймовірно, надасть набагато більш детальні параметри конфігурації, аж до обмеження доступу до певних систем або послуг у захищеній мережі. Шлюзи для продуктів IPsec VPN, ймовірно, мають набагато меншу можливість налаштування. Хоча вони можуть мати додані функції фільтрації пакетів, які дозволяють політикам або конфігураціям обмежувати доступ до певних IP-адрес або підмножин захищених мереж, слід подбати про те, щоб уникнути непотрібної складності та додаткових ризиків для безпеки, які виникають із програмними додатками. У будь-якому випадку необхідно розглянути можливість розгортання VPN разом із системою контролю доступу до мережі, яка може підвищити загальну безпеку, обмежуючи доступ до мережевих ресурсів на основі чітко визначених політик. • Наскрізна мережа: TLS використовується на транспортному рівні, тобто на рівні моделі OSI, де здійснюється зв’язок між процесами. На відміну від цього, IPsec працює на рівні мережі, де здійснюється зв’язок між вузлами мережі з IP-адресами. Це ускладнює захист наскрізного шифрування, коли будь-який кінець захищеного VPN-ланцюга знаходиться в мережі, яка використовує трансляцію мережевих адрес (NAT) для віртуалізації IP-адрес. Через що, IPsec VPN для забезпечення безпечного зв’язку через шлюзи NAT потрібні додаткові налаштування. Хоча багато відмінностей між IPsec і SSL VPN пов’язані з відмінностями між базовими протоколами, що реалізуються, слід також враховувати конкретні реалізації. На цьому фоні, протокол SSH є цікавим аналогом зазначених VPN. Він забезпечує той самий рівень захисту, що й SSL/TLS та IPsec, але є досить специфічним для типу служби (доступ до віддалених оболонок). Лист ЧДТУ.229887.001 ПЗ 55 Змн. Арк. № докум. Підпис Дата Захищена оболонка (SSH) є заміною різних протоколів на основі оболонки, таких як telnet та інших віддалених логінів, а також протоколів передачі файлів, таких як FTP, і протоколів віддаленого копіювання файлів, таких як RCP. Недолік цих протоколів полягає в тому, що при автентифікації на сервері, він завжди надсилається у відкритому вигляді. Підслуховувач може легко перехопити ці запити і маскуватися під потенційного користувача. Крім того, всі дані по протоколу telnet, передаються, також у відкритому вигляді. Якщо telnet використовується, для доступу до корпоративної машини, він потенційно може зберігати конфіденційний матеріал, який може потрапити в руки зловмисника. Саме тому, у більшості політик безпеки, рекомендується вимкнути протоколи telnet, ftp та служби віддаленого входу та замінити їх на захищені версії SSH, SFTP та SCP. Зазвичай це виконується як частина рекомендацій щодо зміцнення ОС перед розгортанням продукту. SSH в основному використовується для рішень на основі оболонки і в ідеалі не буде використовуватися для захисту сеансів перегляду веб-сторінок та інших служб додатків (хоча він може використовуватися за допомогою переадресації портів) SSH надає деякі розширювані функції. Дві з них це переадресація портів і безпечне тунелювання. За допомогою переадресації портів можна вказати домену SSH слухати передачу даних на певному порту та пересилати цей зв’язок до зашифрованого сеансу SSH. В табл. 3.4 наведено порівняння характеристик технологій та протоколів захисту даних (1 – найкращій, 2 – середній, 3 – найгірший). Лист ЧДТУ.229887.001 ПЗ 56 Змн. Арк. № докум. Підпис Дата Таблиця 3.4 – Порівняння характеристик технологій та протоколів захисту даних Протокол IPsec VPN SSL VPN SSH Характеристика Швидкість створення з’єднання 3 2 1 Аутентифікація даних 2 1 3 Простота реалізації 3 2 1 3.5 Проведення тестів протоколів захисту для конкретного підприємства Реалізації VPN слід тестувати з таким же ступенем ретельності, як і будь-який продукт безпеки. Належному тестуванню має передувати дослідження щодо реалізацій VPN, які розглядаються. Також, як і інші системи та послуги безпеки, тестування системи VPN ніколи не слід проводити у виробничих системах або мережах. Тестування VPN має розглядати всі аспекти безпеки, особливо якщо вони стосуються моделей загроз організації та поверхонь атак. Тестування VPN має стосуватися наступного: • Інфраструктура VPN: це включає будь-яке обладнання, програмне забезпечення та хмарні програми VPN, а також спосіб їх інтеграції із системами та програмами, які підлягають захисту. Навіть найкраща VPN не може захистити від атак на служби або програми, які самі по собі не захищені, тому їх також слід перевірити. • Криптографічні алгоритми та протоколи VPN: чи реалізують компоненти VPN надійні протоколи шифрування? Чи використовують системи VPN сучасні алгоритми? Певні реалізації IPsec і TLS іноді повільно відмовляються від небезпечних алгоритмів, які можуть включати, такі типи атак, як наприклад уразливість Heartbleed, яка зробила деякі реалізації TLS вразливими. Лист ЧДТУ.229887.001 ПЗ 57 Змн. Арк. № докум. Підпис Дата • Користувачі VPN: людський елемент завжди є критичним аспектом будь-якої системи безпеки. Чи розуміють люди, як потрібно використовувати VPN, та як він працює? Чи можуть вони безпечно ним користуватися? Чи розуміють вони, з якими загрозами можуть зіткнутися при його використані? Чи може обрана система VPN протистояти атакам зловмисників? Висновки: В цьому розділі було проаналізовано актуальні технології захистку інформації. В цілому, можна дійти висновку, що в ідеалі підприємства мають розгортати як IPsec, так і SSL VPN (SSH варіативно, в залежності від поставленої задачі), оскільки кожна з них вирішує дещо різні проблеми безпеки. Однак на практиці потреба в повному покритті може бути перевищена витратами на придбання, тестування, встановлення, адміністрування та керування двома системами VPN. Лист ЧДТУ.229887.001 ПЗ 58 Змн. Арк. № докум. Підпис Дата ВИСНОВКИ Метою роботи був аналіз і порівняння протоколів захисту даних в сучасних цифрових системах передачі даних. Для досягнення поставленої мети були розв’язати такі задачі, як: аналіз існуючих протоколів та технологій захисту інформації, вибір найбільш актуальних та ефективних рішень. Проведено повторний поглиблений аналіз протоколів та технологій захисту інформації, з розгляданням реалізації та можливих вразливостей, зроблені висновки та сформульовані рекомендації, по вибору та комбінуванню протоколів та технологій. Без сумніву в часи пандемії та війни, а також з огляду на сучасні тренди (в тому числі bring your own device), можливість і навіть необхідність роботи з дому стає все більш доречною. На цьому фоні, зростає і без того актуальна проблема захисту мережі. Тому дана кваліфікаційна робота, мала на меті спробу провести аналіз існуючих рішень по захисту мережі. Проаналізовані різноманітні протоколи та їх комплекси. По результатам первинного аналізу, були обрані найбільш актуальні для сьогодення технології. І проведений їх поглиблений аналіз, проілюстровані слабкі місця та вразливостей даних рішень, а також проведено порівняння протоколів між собою. Був вироблений алгоритм по прийняттю на озброєння того чи іншого протоколу, а також утворені висновки по комплексному зміцненню захисту мережі. В цілому варто зазначити, що саме комплекс протоколів, має найкращій ефект в запобіганні або ж послабленні атак на систему. Нажаль, тут виникає інше питання, доцільність використання дороговартісного комплексу для захисту тої чи іншої мережі. В тих випадках коли не можна використати комплекс протоколів для Лист ЧДТУ.229887.001 ПЗ 59 Змн. Арк. № докум. Підпис Дата захисту мережі, особливо необхідно знати про слабкі місця того конкретного рішення яке буде використано для захисту з’єднання. А вже маючі ці дані, можливо розробити кроки протидії. Із конкретних рекомендацій, варто також сказати про необхідність постійного оновлення версій протоколів безпеки та системи в цілому. Також, досить корисним, є постійний перегляд опублікованих в CVE вразливостей і своєчасний пошук протидій ним. Якщо ж загроза з’явилась нещодавно і методів протидій ще не знайдено, необхідно провести всі можливі кроки по мінімізації потенційних втрат від загрози. Найчастіше, одразу після того як про загрозу стає відомо, компанією яка відповідає за продукт з вразливістю, публікуються методи або ж рекомендації по пом’якшенню чи протидії загрози. Тому варто уважно перевіряти наявність подібних рішень і при їх відсутності, звертатись безпосередньо до компанії. Лист ЧДТУ.229887.001 ПЗ 60 Змн. Арк. № докум. Підпис Дата СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 1. BeaglSecurity: Історія розвитку вразливості CVE 2019-19781 [Електронний ресурс] - Режим доступу: https://www.poppelgaard.com/cve- 2019-19781-what-you-should-know-and-how-to-fix-your-citrix-adc-access- gateway (дата звернення: 06.04.2022). – Назва з екрану. 2. Chimica: Опис технології PPTP [Електронний ресурс] - Режим доступу https://wwwdisc.chimica.unipd.it/luigino.feltre/pubblica/unix/winnt_doc/pppt/unde rstanding_pptp.html#:~:text=Introduction- ,Point%2Dto%2DPoint%20Tunneling%20Protocol%20(PPTP)%20is%20a,%2FIP %2Dbased%20data%20networks. (дата звернення: 06.04.2022). – Назва з екрану. 3. Cisco: Технологія IPsec: [Електронний ресурс] - Режим доступу https://networklessons.com/cisco/ccie-routing-switching/ipsec-internet-protocol- security (дата звернення: 05.04.2022). – Назва з екрану. 4. Globalsign: Поглиблений розгляд протоколу SSL PPTP [Електронний ресурс] - Режим доступу https://www.globalsign.com/ru-ru/ssl- information-center/what-is-ssl (дата звернення: 06.04.2022). – Назва з екрану. 5. Intersocieti: Принцип роботи TLS [Електронний ресурс] - Режим доступу https://www.internetsociety.org/deploy360/tls/basics/#:~:text=Transport%20Layer %20Security%20(TLS)%20encrypts,card%20numbers%2C%20and%20personal% 20correspondence (дата звернення: 08.04.2022). – Назва з екрану. 6. ITMO: Принципи роботи SSL і TLS [Електронний ресурс] - Режим доступу https://neerc.ifmo.ru/wiki/index.php?title=SSL/TLS#.D0.92.D0.B8.D0.B4.D1.8B_ .D0.B2.D0.BE.D0.B7.D0.BC.D0.BE.D0.B6.D0.BD.D1.8B.D1.85_.D0.B0.D1.82. D0.B0.D0.BA (дата звернення: 12.04.2022). – Назва з екрану. Лист ЧДТУ.229887.001 ПЗ 61 Змн. Арк. № докум. Підпис Дата 7. Lants: Протокли захисту тунельного рівня [Електронний ресурс] - Режим доступу https://lanmarket.ua/entsiklopediya/telekommunikatsionnye- tekhnologii/ipsec.html (дата звернення: 02.04.2022). – Назва з екрану. 8. LeVPN: Історія VPN [Електронний ресурс] - Режим доступу: https://le-vpn.com/ru/vpn-history/ (дата звернення: 04.04.2022). – Назва з екрану. 9. VPNmentor: VPN Use and Data Privacy Stats for 2021 [Електронний ресурс] - Режим доступу: https://www.vpnmentor.com/blog/vpn- use-data-privacy-stats/ (дата звернення: 06.04.2022). – Назва з екрану. 10. Аліпов Ілля Миколайович: Методи захисту інформації при її передаванні : Автореф. дис... канд. техн. наук: 05.13.08 / Харківський держ. технічний ун-т радіоелектроніки. - Х., 1997. - 22с. 11. Бардіс Ніколас. Розробка підходу і застосування апарату булевих функцій для аналізу і синтезу ефективних криптографічних алгоритмів захисту інформації : Автореф. дис... канд. техн. наук: 05.13.13 / Національний технічний ун-т України "Київський політехнічний ін-т". - К., 1998. - 16с. 12. Боні Смаєр: Детальний опис роботи IKEs VPN VPNmentor: VPN Use and Data Privacy Stats for 2021 [Електронний ресурс] - Режим доступу: https://raxis.com/blog/2018/05/23/ike-vpns-supporting-aggressive-mode (дата звернення: 06.04.2022). – Назва з екрану. 13. Вікипедія: Розгляд протоколу PPTP [Електронний ресурс] - Режим доступу https://en.wikipedia.org/wiki/Virtual_private_network (дата звернення: 06.04.2022). – Назва з екрану. 14. Вікипедія: Розгляд протоколу TLS [Електронний ресурс] - Режим доступу https://ru.wikipedia.org/wiki/TLS (дата звернення: 04.04.2022). – Назва з екрану. 15. Гарбаршук В., Зінович З., Свіц А. Кібернетичний підхід до розробки систем захисту інформації / Української інформатики; Держава Воллінського. Люблінський політехнічний університет - до.; Лутський; Люблін, 2003.- 658S. : Рис. - Бібліографія: с. 648-653. Лист ЧДТУ.229887.001 ПЗ 62 Змн. Арк. № докум. Підпис Дата 16. Джон Вольш: Проблемі та рекомендації по роботі з SSH 2021 [Електронний ресурс] - Режим доступу: https://www.cyberark.com/resources/blog/four-ssh-vulnerabilities-you-should-not- ignore (дата звернення: 06.04.2022). – Назва з екрану. 17. Ігор мельник, Андрій Лунтовський: Проектування та дослідження комп'ютерних мереж: Національний технічний ун-т України "Київський політехнічний ін-т". 2010. - 362с. 18. Історія розвитку SSL, TLS: https://beaglesecurity.com/blog/article/importance-of-tls-1-3-ssl-and-tls- vulnerabilities.html 19. Кси Йоїюан: Опис роботи з технологією IPsec [Електронний ресурс] - Режим доступу: https://info.support.huawei.com/info- finder/encyclopedia/en/IPsec.html (дата звернення: 05.04.2022). – Назва з екрану. 20. Хабр: Розгляд існуючих рішень в сфері захисту данх [Електронний ресурс] - Режим доступу https://habr.com/ru/post/504484/ (дата звернення: 06.04.2022). – Назва з екрану. Лист ЧДТУ.229887.001 ПЗ 63 Змн. Арк. № докум. Підпис Дата