Протоколи формування захищених каналів на сеансовому рівні

internet-300x300Найвищим рівнем моделі OSI, на якому можливе формування захищених віртуальних каналів, є п’ятий – сеансовий рівень, При побудові захищених віртуальних мереж на сеансовому рівні з’являється можливість криптографічного захисту інформаційного обміну, включаючи аутентифікацію, а також реалізації ряду функцій посередництва між взаємодіючими сторонами.

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

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

Для захисту інформаційного обміну на сеансовому рівні широке розповсюдження отримав протокол SSL (Secure Sockets Layer). Для виконання на сеансовому рівні функцій посередництва між взаємодіючими сторонами організацією IETF (Internet Engineering Task Force) в якості стандарту прийнятий протокол SOCKS.

Протоколи SSL / TLS

Протокол SSL застосовується як протоколу захищеного каналу, який працює на сеансовому рівні моделі OSI. Цей протокол використовує криптографічні методи захисту інформації для забезпечення безпеки інформаційного обміну. Протокол SSL виконує всі функції по створенню захищеного каналу між двома абонентами мережі, включаючи їх взаємну аутентифікацію, забезпечення конфіденційності, цілісності та автентичності переданих даних. Ядром протоколу SSL є технологія комплексного використання асиметричних і симетричних криптосистем.

Взаємна аутентифікація обох сторін у SSL виконується шляхом обміну цифровими сертифікатами відкритих ключів користувачів (клієнта і сервера), завіреними підписом спеціальних сертифікаційних центрів. Протокол SSL підтримує сертифікати, відповідні загальноприйнятому стандарту Х.509, а також стандарти інфраструктури відкритих ключів PKI (Public Key Infrastructure), за допомогою якої організовується видача та перевірка достовірності сертифікатів.

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

В якості алгоритмів асиметричного шифрування використовуються алгоритм RSA, а також алгоритм Діффі – Хеллмана. Допустимими алгоритмами симетричного шифрування є RC2, RC4, DES, 3DES і AES. Для обчислення хеш-функцій можуть застосовуватися стандарти MD5 і SHA-1. У протоколі SSL версії 3.0 набір криптографічних алгоритмів є розширюваною.

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

Криптозахищені тунелі, сформовані на основі протоколу SSL.

Протокол SSL передбачає наступні етапи взаємодії клієнта і сервера при формуванні та підтримці захищається з’єднання:
• встановлення SSL-сесії;
• захищене взаємодія.

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

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

При встановленні повторних з’єднань між клієнтом і сервером сторони можуть, за взаємною згодою, формувати нові сеансові ключі на основі «старого» загального «секрету» (дана процедура називається «продовженням» SSL сесії).

Протокол SSL 3.0 підтримує три режими аутентифікації:
• взаємну аутентифікацію сторін;
• односторонню аутентифікацію сервера без аутентифікації клієнта;
• повну анонімність.

При використанні останнього варіанту забезпечується захист інформаційного обміну без будь-яких гарантій щодо достовірності сторін. У цьому випадку взаємодіючі сторони не ‘захищені від атак, пов’язаних з підміною учасників взаємодії.

У реалізаціях протоколу SSL для аутентифікації взаємодіючих сторін і формування загальних секретних ключів зазвичай використовують алгоритм RSA.

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

Протокол SSL пройшов перевірку часом, працюючи в популярних браузерах Netscape Navigator і Internet Explorer, а також Web-серверах провідних виробників. У січні 1999 р на зміну версії SSL 3.0 прийшов протокол TLS (Transport Layer Security), який базується на протоколі SSL і в даний час є стандартом Інтернету. Відмінності між протоколами SSL 3.0 і TLS 1.0 не надто суттєві. Протокол SSL став промисловим протоколом, розвиває і просуваються поза технічних координуючих інститутів Internet.

Протокол SSL підтримується ПО серверів і клієнтів, що випускаються провідними західними компаніями. Істотним недоліком протоколу SSLявляется те, що практично всі продукти, що підтримують SSL, через експортних обмежень доступні за межами США лише в усіченому варіанті (з довжиною сеансового ключа 40 біт для алгоритмів симетричного шифрування і 512 біт для алгоритму RSA, використовуваного на етапі встановлення SSL -сессіі).

До недоліків протоколів SSL і TLS можна віднести те, що для транспортування своїх повідомлень вони використовують тільки один протокол мережевого рівня – IP, і, отже, можуть працювати тільки в IP-мережах.

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

Протокол SOCKS

Протокол SOCKS організовує процедуру взаємодії клієнт-серверних додатків на сеансовому рівні моделі OSI через сервер-посередник, іліproxy-сервер.

У загальному випадку програми-посередники, які традиційно використовуються в МЕ, можуть виконувати такі функції:
• ідентифікацію та аутентифікацію користувачів;
• криптозащиту переданих даних;
• розмежування доступу до ресурсів внутрішньої мережі;
• розмежування доступу до ресурсів зовнішньої мережі;
• фільтрацію і перетворення потоку повідомлень, наприклад пошук вірусів і прозоре шифрування інформації;
• трансляцію внутрішніх мережевих адрес для вихідних потоків повідомлень.

Спочатку протокол SOCKS розроблявся тільки для перенаправлення запитів до серверів з боку клієнтських додатків, а також повернення цих додатків отриманих відповідей. Перенаправлення запитів і відповідей між клієнт-серверними додатками вже дозволяє реалізувати функцію трансляції мережевих IP-адрес NAT (Network Address Translation). Заміна у вихідних пакетів внутрішніх IP-адрес відправників одним IP-адресою шлюзу дозволяє приховати топологію внутрішньої мережі від зовнішніх користувачів і тим самим ускладнити завдання НСД.

На основі протоколу SOCKS можуть бути реалізовані й інші функції посередництва по захисту мережевої взаємодії. Наприклад, протокол SOCKSможет застосовуватися для контролю над напрямами інформаційних потоків та розмежування доступу в залежності від атрибутів користувачів і інформації. Ефективність використання протоколу SOCKS для виконання функцій посередництва забезпечується його орієнтацією на сеансовий рівень моделі OSI. У порівнянні з посередниками прикладного рівня на сеансовому рівні досягається більш високу швидкодію і незалежність від високорівневих протоколів (HTTP, FTP, РОРЗ, SMTP та ін.). Крім того, протокол SOCKS не прив’язаний до протоколу IP і не залежить від ОС. Наприклад, для обміну інформацією між клієнтськими додатками і посередником може використовуватися протокол IPX.

Завдяки протоколу SOCKS МЕ і віртуальні приватні мережі можуть організувати безпечне взаємодію та обмін інформацією між різними мережами. Протокол SOCKS дозволяє реалізувати безпечне управління цими системами на основі уніфікованої стратегії. Слід зазначити, що на основі протоколу SOCKS можуть створюватися захищені тунелі для кожної програми і сеансу окремо.

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

Протокол SOCKS v5 схвалений організацією IETF (Internet Engineering Task Force) в якості стандарту Internet і включений в RFC 1928.

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

Аутентифікація користувача, виконувана SOCKS-сервером, може грунтуватися на цифрових сертифікатах у форматі Х.509 або паролі. Для шифрування трафіку між SOCKS-клієнтом і SOCKS-сервером можуть бути використані протоколи, орієнтовані на сеансовий або більш низькі рівні моделі OSI. Крім аутентифікації користувачів, трансляції IP-адрес і криптозахисту трафіку, SOCKS-сервер може виконувати також такі функції, як:
• розмежування доступу до ресурсів внутрішньої мережі;
• розмежування доступу до ресурсів зовнішньої мережі;
• фільтрація потоку повідомлень, наприклад, динамічний пошук вірусів;
• реєстрація подій та реагування на поставлені події;
• кешування даних, запитуваних із зовнішньої мережі.

Протокол SOCKS здійснює вбудовану підтримку популярних Web-навігаторів Netscape Navigator і Netscape Communicator компанії Netscape, а також Internet Explorer компанії Microsoft.

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

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

Компанія «Сучасні системи безпеки бізнесу» активно впроваджує передові технології в сфери безпеки бізнесу та технічного захисту інформації. Основними напрямками нашої діяльності є: пошук закладних пристроїв (захист від прослуховування, прихованих камер і т.д.); проектування, монтаж і обслуговування систем безпеки бізнесу: відеоспостереження; контроль доступу; облік робочого часу; охоронна і пожежна сигналізаціявимірювання тепловтрат приміщень та рекомендації щодо теплоізоляції; вимірювання радіоактивного фону в приміщеннях і на територіях. Дзвоніть нам за вказаним номером телефону і ми відповімо на всі Ваші запитання:

(044) 227-90-21

(096) 875-77-51

(099) 448-83-83

Добавить комментарий

%d такие блоггеры, как: