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