Відмова в обслуговуванніОдному з основних завдань, що покладаються на мережеву ОС, що функціонує на кожному з об'єктів розподіленої ВС, є забезпечення надійного видаленого доступу з будь-якого об'єкту мережі до даного об'єкту. У спільному випадку в розподіленій ВС кожен суб'єкт системи повинен мати можливість підключитися до будь-якого об'єкту РВС і дістати відповідно до своїх прав видалений доступ до його ресурсів. Зазвичай в обчислювальних мережах можливість надання видаленого доступу реалізується таким чином: на об'єкті РВС в мережевій ОС запускаються на виконання ряд програм-серверів (наприклад, FTP-сервер, WWW-сервер і тому подібне), що надають видалений доступ до ресурсів даного об'єкту. Дані програми-сервери входять до складу телекомунікаційних служб надання видаленого доступу. Завдання сервера полягає в тому, щоб, знаходячись в пам'яті операційної системи об'єкту РВС, постійно чекати отримання запиту на підключення від видаленого об'єкту. В разі отримання подібного запиту сервер повинен по можливості передати на об'єкт, що запитав, відповідь, в якій або вирішити підключення, або немає (под-ключение до сервера спеціально описано дуже схемний, оскільки подробиці в даний момент не мають значення). По аналогічній схемі відбувається створення віртуального каналу зв'язку, по якому зазвичай взаємодіють об'єкти РВС. В цьому випадку безпосередньо ядро мережевої ОС обробляє запити, що приходять ззовні, на створення віртуального каналу (ВК) і передає їх відповідно до ідентифікатора запиту (порт або сокет) прикладному процесу, яким є відповідний сервер. Очевидно, що мережева операційна система здатна мати лише обмежене число відкритих віртуальних з'єднань і відповідати лише на обмежене число запитів. Ці обмеження залежать від різних параметрів системи в цілому, основними з яких є швидкодія ЕОМ, об'єм оперативної пам'яті і пропускна спроможність каналу зв'язку (чим вона вища, тим більше число можливих запитів в одиницю часу). Основна проблема полягає в тому, що за відсутності статичної ключової інформації в РВС ідентифікація запиту можлива лише за адресою його відправника. Якщо в розподіленій ВС не передбачено засобів аутентифікації адреси відправника, тобто інфраструктура РВС дозволяє з одного об'єкту системи передавати на інший об'єкт, що атакується, безконечне число анонімних запитів на підключення від імені інших об'єктів, то в цьому випадку матиме успіх типова видалена атака "Відмова в обслуговуванні" (приклад подібної атаки на мережу Internet - п. 4.6). Результат вживання цієї видаленої атаки - порушення на атакованому об'єкті працездатності відповідної служби надання видаленого доступу, тобто неможливість діставання видаленого доступу з інших об'єктів РВС - відмова в обслуговуванні! Другий різновид цієї типової видаленої атаки полягає в передачі з однієї адреси такої кількості запитів на об'єкт, що атакується, яке дозволить трафік (направлений "шторм" запитів). В цьому випадку, якщо в системі не передбачені правила, що обмежують число запитів, що приймаються, з одного об'єкту (адреси) в одиницю часу, то результатом цієї атаки може бути як переповнювання черги запитів і відмови однієї з телекомунікаційних служб, так і повна зупинка комп'ютера із-за неможливості системи займатися нічим іншим, окрім обробки запитів. І останнім, третім різновидом атаки "Відмова в обслуговуванні" є передача на об'єкт некоректного, спеціально підібраного запиту, що атакується. В цьому випадку за наявності помилок у видаленій системі можливе зациклення процедури обробки запиту, переповнювання буфера з подальшим зависанням системи (приклад в п. 4.7.2 - "Ping Death") і тому подібне Типова видалена атака "Відмова в обслуговуванні" є активною дією (клас 1.2), здійснюваною з метою порушення працездатності системи (клас 2.3), безумовно щодо мети атаки (клас 3.3). Дана УА є однонаправленою дією (клас 4.2), як міжсегментною (клас 5.1), так і внутрішньосегментною (клас 5.2), здійснюваною на транспортному (клас 6.4) і прикладному (клас 6.7) рівнях моделі OSI.
|
