Отже, ми показали, що ідентифікація об'єктів РОС, за відсутності статичної ключової інформації, можлива тільки при взаємодії об'єктів з використанням віртуального каналу. Це, у свою чергу, означає, що взаємодія об'єктів без встановлення ВК є однією з можливих причин успіху видалених атак на РОС.
Але помилково рахувати розподілену обчислювальну систему безпечної, навіть якщо вся взаємодія об'єктів відбувається із створенням ВК. Про це мова піде в наступному пункті.
Використовування нестійких алгоритмів ідентифікації об'єктів при створенні віртуального каналу
Помилково вважати взаємодію об'єктів по віртуальному каналу в розподіленій ОС панацеєю від всіх проблем, пов'язаних з ідентифікацією об'єктів РОС. ВК є необхідним, але не достатньою умовою безо-пасного взаємодії. Надзвичайно важливим в даному випадку стає вибір алгоритму ідентифікації при створенні ВК. Основна вимога, яка слідує пред'являти до даних алгоритмів, полягає в наступному: перехоплення ключової інформації, якій обмінюються об'єкти РОС при створенні ВК не повинен дозволити атакуючому одержати підсумкові ідентифікатори каналу і об'єктів. Це вимога по суті очевидно. Воно повинне пред'являтися до алгоритмів ідентифікації виходячи з принципової можливості прослуховування атакуючим каналу передачі. Проте в більшості існуючих мережних ОС в базових алгоритмах ідентифікації, використовуваних при створенні ВК, цією вимогою розробники практично нехтують. Так, наприклад, в ОС Novell NetWare 3.12- 4.1 ідентифікатор каналу - це число в діапазоні 0-FFh, ідентифікатор об'єкту (робочої станції або файл-серверу) - також число від 0 до FFh; у протоколі TCP ідентифікаторами каналу і об'єктів є два 32-бітові числа, формовані в процесі створення TCP-з'єднання.
Зі всього сказаного ясно, що створення віртуального каналу з використанням нестійкого алгоритму ідентифікації не дозволяє надійно забезпечити РОС від підміни об'єктів взаємодії і виступає одній з причин успіху видалених атак на розподілені обчислювальні системи.
Відсутність контролю за віртуальними каналами зв'язку між об'єктами РОС
Як було показано раніше, об'єкти розподіленої ОС, взаємодіючі по віртуальних каналах, можуть піддаватися типовою УА "Відмова в обслуговуванні" . Особливість цієї атаки полягає у тому, що, діючи абсолютно легальними засобами системи, можна видалений добитися порушення її працездатності. Нагадаємо, що, дана УА реалізується передачею множинних запитів на створення з'єднання (віртуального каналу), внаслідок чого або переповнюється число можливих з'єднань, або система, зайнята обробкою відповідей на запити, взагалі перестає функціонувати. У чому причина успіху даної УА? У попередньому пункті було показано, що взаємодія об'єктів РОС по віртуальних каналах дозволяє єдиним способом забезпечити захист з'єднання в глобальній мережі. Проте у використовуванні ВК є як безперечні плюси, так і очевидні мінуси. До мінусів відноситься необхідність контролю над з'єднанням. При цьому задача контролю розпадається на дві підзадачі:
Ø контроль за створенням з'єднання;
Ø контроль за використовуванням з'єднання.
Якщо друга задача розв'язується досить просто (звичайно з'єднання розривається по тайм-ауту, визначеному системою - так зроблено у всіх відомих мережних ОС), то рішення задачі контролю за створенням з'єднання представляється нетривіальним. Саме відсутність прийнятного рішення цієї задачі є основною причиною успіху типової УА "Відмова в обслуговуванні" . Складність контролю над створенням ВК полягає у тому, що в системі, в якій відсутня статична ключова інформація про всі її об'єкти, неможливо відділити помилкові запити на створення з'єднання від справжніх. Очевидно також, що якщо один суб'єкт мережної взаємодії матиме нагоду анонімно займати необмежене число каналів зв'язку з видаленим об'єктом, то подібна система може бути повністю паралізована даним суб'єктом (приклад - існуюча мережа Internet в стандарті IPv4)! Тому, якщо будь-який об'єкт в розподіленій системі може анонімно послати повідомлення від імені будь-якого іншого об'єкту (наприклад, в Internet маршрутизатори не перевіряють IP-адресу джерела відправлення), то в подібній розподіленій ОС у принципі неможливий контроль за створенням віртуальних з'єднань. Тому основна причина, по якій можлива типова УА "Відмова в обслуговуванні" і їй подібні - це відсутність в РОС можливості контролю за маршрутом повідомлень.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.