DNS під прицілом

1. Помилковий DNS-сервер в мережі Internet.
2. ОСНОВИ DNS
3. ПЕРЕХОПЛЕННЯ ЗАПРОСА DNS
4. "ШТОРМ" хибні відповіді DNS
5. МЕТА - СЕРВЕР DNS
6. ТРОХИ ТЕОРІЇ
7. Аналіз мережевого трафіку
8. Підміна довіреного об'єкта або суб'єкта розподіленої ВС
9. Помилковий об'єкт розподіленої ВС
10. Використання помилкового об'єкта для організації віддаленої атаки
11. Відмова в обслуговуванні

Помилковий DNS-сервер в мережі Internet.

ТРОХИ ТЕОРІЇ
Дистанційні атаки в мережі Internet

Останнім часом в комп'ютерній пресі все більше уваги приділяється проблемі порушення інформаційної безпеки в Internet. При цьому сама проблема зазвичай висвітлюється в жанрі або детективного роману ( "Хакери зламали сервер компанії ..."), або рекламного проспекту ( "Firewall - абсолютний захист Internet"). Причому нічого не говориться про те, а чому, власне, вдалося здійснити цей злом, т. Е. Які вразливі місця системи використовував атакуючий? Тому після ознайомлення з літературою подібного роду численні користувачі Мережі, які в переважній більшості своїй не є фахівцями в області інформаційної безпеки, переймаються упевненістю, що мережа Internet далеко небезпечна (і це дійсно так!) І що звідти постійно виходить якась "невідома" загроза зі боку "всемогутніх" хакерів. Що за небезпека, запитає читач? Вся справа в тому, що у пресі (на відміну від електронних конференцій) практично повністю відсутні статті з описом механізмів реалізації тих самих "невідомих" загроз, а точніше, віддалених атак в Мережі. Саме тому, з метою підвищення рівня інформованості користувачів Мережі про які загрожують в ній небезпеки, і був задуманий даний цикл статей, присвячений детальному аналізу всіляких віддалених атак в Internet.

Заздалегідь відкидаючи можливі закиди в пропаганді хакерства, автор хотів би зауважити, що пора вже перестати ховати голову в пісок, ігноруючи загрози, пов'язані з Internet, і взяти на озброєння гасло, яким і керувався автор в написанні даних статей: "Хто попереджений - той озброєний ".

ОСНОВИ DNS

Як відомо, для звернення до хостам в мережі Internet використовуються 32-розрядні IP-адреси, однозначно ідентифікують будь-який мережевий комп'ютер в цій глобальній мережі. Однак для користувачів застосування IP-адрес при зверненні до хостам не дуже зручно. Тому в Internet прийнято присвоювати імена всіх комп'ютерів в Мережі. Використання імен дає користувачеві можливість краще орієнтуватися в кіберпросторі Internet - куди простіше запам'ятати, наприклад, ім'я www.ferrari.it , Ніж чотириланкова ланцюжок IP-адреси. Застосування в Internet мнемонічно зрозумілих для користувачів імен породило проблему їх перетворення в IP-адреси. Таке перетворення необхідно, так як на мережевому рівні адресація пакетів здійснюється не по іменах, а по IP-адресами, отже, для безпосередньої адресації повідомлень в Internet імена не годяться. На ранньому етапі розвитку Internet, коли в мережу (тоді вона ще не називалася Мережа) було об'єднано невелику кількість комп'ютерів, Інформаційний центр мережі (Network Information Center, NIC) для вирішення проблеми перетворення імен в адреси завів спеціальний файл (файл hosts), в який вносилися імена і відповідні їм IP-адреси всіх хостів в мережі. Даний файл регулярно оновлювався і поширювався по всій мережі. Але в міру розвитку Internet число хостів, об'єднаних в мережу, збільшувалася, і дана схема ставала все менш і менш працездатною. Тому була створена нова система перетворення імен, що дозволяє користувачеві в разі відсутності у нього інформації про відповідність імен і IP-адрес отримати необхідні відомості від найближчого інформаційно-пошукового сервера (DNS-сервера). Ця система отримала назву системи імен доменів - DNS (Domain Name System).

Для реалізації системи DNS був створений спеціальний мережевий протокол DNS; крім того, в мережі створювалися спеціальні виділені інформаційно-пошукові сервери - DNS-сервери. Пояснимо основне завдання, що вирішується службою DNS. У сучасній Мережі хост при зверненні до віддаленого сервера зазвичай обізнаний тільки про його імені і не знає IP-адреси, який необхідний для безпосередньої адресації. Отже, перед хостом виникає стандартна проблема віддаленого пошуку: по імені віддаленого хоста знайти його IP-адресу. Вирішенням цієї проблеми і займається служба DNS на базі протоколу DNS.

Розглянемо DNS-алгоритм віддаленого пошуку IP-адреси по імені в Мережі:

Аналізуючи з точки зору безпеки вразливість цієї схеми віддаленого пошуку за допомогою протоколу DNS, можна зробити висновок про можливість здійснення в мережі, що використовує протокол DNS, типової віддаленої атаки "Помилковий об'єкт РВС (розподіленої обчислювальної системи)". За допомогою такої атаки вдається внедpіть пpомежуточний хост, чеpез котоpого буде йти потік инфоpмации між атакується об'єктом і сеpвеpом (напpимеp, Telnet-сеpвеpом). Практичні дослідження і критичний аналіз безпеки служби DNS дозволяють припустити, що існує три можливих варіанти віддаленої атаки на цю службу.

ПЕРЕХОПЛЕННЯ ЗАПРОСА DNS

В даному випадку віддалена атака пов'язана з перехопленням пошукового DNS-запиту. Перед тим як розглянути алгоритм атаки на службу DNS, необхідно звернути увагу на деякі тонкощі в роботі цієї служби. По-перше, за замовчуванням служба DNS функціонує на базі протоколу UDP (хоча можливо і використання протоколу TCP), що, природно, робить її менш захищеною, так як протокол UDP, на відміну від TCP, взагалі не передбачає коштів ідентифікації повідомлень. Для того щоб перейти від UDP до TCP, адміністратору DNS-сервера доведеться дуже серйозно вивчити документацію (в стандартній документації на демон named в ОС Linux немає жодної згадки про можливий вибір протоколу (UDP або TCP), з яким буде працювати

DNS-сервер). Крім того, цей перехід кілька знизить швидкість роботи системи, так як при використанні TCP потрібне створення віртуального з'єднання, а кінцеві мережеві ОС спочатку посилають DNS-запит за допомогою протоколу UDP. У тому випадку, якщо їм прийде спеціальний відповідь від DNS-сервера, мережева ОС посилає DNS-запит з використанням TCP. По-друге, необхідно звернути увагу на те, що значення поля "порт відправника" в UDP-пакеті спочатку приймається рівним 1 023, а потім збільшується з кожним переданим DNS-запиту. По-третє, в разі передачі DNS-запиту з хоста значення ідентифікатора (ID) DNS-запиту залежить від конкретного мережевого додатки, що генерує DNS-запит. Автор статті на своєму досвіді переконався, що в разі передачі запиту з оболонки командного інтерпретатора (SHELL) операційних систем Linux і Windows 95 (наприклад, ftp nic.funet.fi) це значення завжди дорівнює одиниці. Якщо ж DNS-запит передається з Netscape Navigator, то браузер з кожним новим запитом збільшує це значення на одиницю. Якщо ж запит передається безпосередньо DNS-сервером, то сервер збільшує значення ідентифікатора на одиницю з кожним знову переданим запитом. Всі ці тонкощі мають значення у разі атаки без перехоплення DNS-запиту.

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

UDP-порта відправника запиту, двухбайтовое значення ID ідентифікатора DNS-запиту і шукане ім'я і потім послати помилковий DNS-відповідь на вказаний в DNS-запит UDP-порт, в якому вказати в якості шуканого IP-адреси IP-адреса помилкового DNS-сервера. Це дозволить в подальшому повністю перехопити і активно впливати за схемою "Помилковий об'єкт РВС" на трафік між "обдуреним" хостом і сервером.

Найпростішим варіантом атаки з використанням помилкового DNS-сервера буде видача себе за довірений об'єкт (сервер) з подальшим присвоєнням прав і повноважень користувача. Це може бути досягнуто шляхом передачі на клієнтський хост запрошення, ідентичного запрошення реального сервера.

Користувач вводить своє ім'я (це може бути і ім'я администpатоpу системи), а потім - пароль. Помилковий сервер, перехопивши цю інформацію, виводить будь-яку фіктивну помилку (наприклад, неправильний пароль) і від'єднується. Все, "справжній" сервер вже на кpючке.

Розглянемо узагальнену схему роботи помилкового DNS-сервера (Рис. 1):

( 1x1 )

Малюнок 1.Функціональная схема помилкового DNS-сервера: а) фаза очікування атакуючим DNS-запиту (він знаходиться або на ЛС1, або на ЛС2); б) фаза передачі атакуючим помилкового DNS-відповіді; в) фаза прийому, аналізу, впливу і передачі перехопленої інформації на хибному сервері.

У тому випадку, хоча це і мало ймовірно, якщо відповідь від справжнього DNS-сервера прийде швидше помилкового відповіді від атакуючого, то атака не відбудуться.

Необхідною умовою здійснення даного варіанту атаки є перехоплення DNS-запиту. Це можливо тільки в тому випадку, якщо атакуючий знаходиться або на шляху основного трафіку, або в сегменті справжнього DNS-сервера. Виконання одного з цих умов робить подібну віддалену атаку важко здійсненною на практиці (потрапити в сегмент DNS-сервера, і тим більше в межсегментний канал зв'язку, атакуючому швидше за все не вдасться). Однак в цьому випадку є можливість здійснити міжсегментного віддалену атаку на Internet.

Відзначимо, що моделювання даної віддаленої атаки виявило ряд цікавих особливостей в роботі протоколу FTP і в механізмі ідентифікації TCP-пакетів. У разі, якщо FTP-клієнт на хості підключався до віддаленого FTP-сервера через помилковий DNS-сервер, виявлялося, що кожен раз після видачі користувачем прикладної команди FTP (наприклад, ls, get, put і т. Д.) FTP-клієнт виробляв команду PORT, яка складалася в передачі на FTP-сервер в поле даних TCP-пакета номера порту і IP-адреси клієнтського хоста. (Не так-то просто зрозуміти, навіщо кожен раз передавати на FTP-сервер IP-адреса клієнта!) Це призводило до того, що якщо на хибному

DNS-сервері не змінити IP-адресу, що міститься в полі даних TCP-пакета, і цей пакет на FTP-сервер передати по звичайної схемою, то наступний пакет пересилається FTP-сервером на хост FTP-клієнта, минаючи помилковий DNS-сервер, і, що найцікавіше, цей пакет сприймається як нормальний. Надалі помилковий DNS-сервер втрачає контроль над трафіком між FTP-сервером і FTP-клієнтом! Це пов'язано з тим, що звичайний FTP-сервер не передбачає ніякої додаткової ідентифікації FTP-клієнта, крім початкової з використанням імені та пароля, а перекладає всі проблеми ідентифікації пакетів і з'єднання на більш низький рівень - а саме TCP (транспортний).

"ШТОРМ" хибні відповіді DNS

Інший варіант проведення віддаленої атаки, спрямованої на службу DNS, заснований на другому різновиді типовий УА "Помилковий об'єкт РВС". У цьому випадку атакуючий здійснює постійну передачу на атакується хост заздалегідь підготовленого помилкового DNS-відповіді від імені справжнього DNS-сервера без прийому DNS-запиту! Іншими словами, атакуючий створює в мережі Internet спрямований "шторм" помилкових DNS-відповідей. Це можливо, так як зазвичай для передачі DNS-запиту використовується протокол UDP, в якому відсутні засоби ідентифікації пакетів. Критерії, що пред'являються мережевий ОС хоста до отриманого від DNS-сервера відповіді, - це, по-перше, збіг IP-адреси відправника відповіді з IP-адресою DNS-сервера; по-друге, необхідно, щоб в DNS-відповіді було зазначено те ж ім'я, що і в DNS-запит; по-третє, DNS-відповідь повинен бути спрямований на той же UDP-порт, з якого був посланий DNS-запит (це перша реальна утруднення для атакуючого), і, по-четверте, в DNS-відповіді поле ідентифікатор запиту в заголовку DNS ( ID) повинно містити те ж значення, що і в переданому DNS-запит (це друга проблема).

Так як атакуючий не має можливості перехопити DNS-запит, основна перешкода для нього представляє номер UDP-порта, з якого був посланий запит. Однак, як було зазначено раніше, номер порту відправника приймає обмежений набір значень (1023), і атакуючому досить діяти простим перебором, направляючи помилкові відповіді на відповідний перелік портів. На перший погляд другою проблемою може бути багатобайтових ідентифікатор DNS-запиту, але, як було зазначено раніше, він або дорівнює одиниці, або в разі DNS-запиту (від Netscape Navigator, наприклад) має значення порядку одиниці (кожен запит ID збільшується на 1).

Тому для здійснення даної віддаленої атаки атакуючому необхідно вибрати що цікавить його хост (скажімо, TOP.SECRET.COM), маршрут до якого потрібно змінити так, щоб він проходив через помилковий сервер (хост) атакуючого. Це досягається постійною передачею (спрямованим "штормом") атакуючим помилкових DNS-відповідей на атакується хост від імені справжнього DNS-сервера на передбачувані UDP-порти. У цих помилкових DNS-відповідях вказується як IP-адреси хоста TOP.SECRET.COM IP-адреса атакуючого. Далі атака розвивається за такою схемою. Як тільки мета атаки (атакується хост) звернеться по імені до хосту TOP.SECRET.COM, то від цього хоста в мережу буде переданий DNS-запит. Атакуючий його ніколи не отримає, це, однак, і не потрібно, так як на хост відразу ж надійде постійно передається помилковий DNS-відповідь, який і буде сприйнятий ОС атакується хоста як справжня відповідь від DNS-сервера. Усе! Атака відбулася, і тепер атакується хост буде передавати всі пакети, призначені для TOP.SECRET.COM, на IP-адреса хоста атакуючого, який, в свою чергу, стане переправляти їх на TOP.SECRET.COM, впливаючи на перехоплену інформацію за схемою " помилковий об'єкт РВС ".

Розглянемо функціональну схему запропонованої віддаленої атаки на службу DNS (Рис. 2):

( 1x1 )

Малюнок 2.Внедреніе в Internet помилкового сервера шляхом створення спрямованого "шторму" помилкових DNS-відповідей на атакується хост: а) атакуючий створює спрямований "шторм" помилкових DNS-відповідей на Хост 1; б) Хост 1 посилає DNS-запит і негайно отримує помилковий DNS-відповідь; в) фаза прийому, впливу і передачі перехопленої інформації на хибному сервері.

Таким чином, реалізація даної віддаленої атаки, що використовує прогалини в безпеці служби DNS, дозволяє з будь-якої точки Мережі порушити маршрутизацію між двома заданими об'єктами (хостами)! Т. е. Дана віддалена атака здійснюється міжсегментного по відношенню до мети атаки і загрожує безпеці будь-якого хоста Internet, що використовує звичайну службу DNS.

МЕТА - СЕРВЕР DNS

З розглянутої Ранее схеми віддаленого DNS-поиска слід, что в тому випадка, если Вказаним в запіті имя DNS-сервер не виявило у життя без базі імен, то запит відсілається сервером на один з Коренєва DNS-серверів, адреси якіх містяться в файлі налаштування сервера root .cache. Т. е. У тому випадка, если DNS-сервер не має відомостей про запитуваній хості, ВІН пересілає запит далі - це означає, что теперь сам DNS-сервер є ініціатором віддаленого DNS-поиска. Тому ніщо НЕ заважає атакуючому, діючі опис вищє методами, перенести свой удар безпосередно на DNS-сервер. Інакше Кажучи, в якості мети атаки тепер буде віступаті НЕ хост, а DNS-сервер и Помилкові DNS-відповіді будут направляти атакуючім від імені Коренєва DNS-сервера на атакується DNS-сервер. При цьом важліво враховуваті таку особлівість роботи DNS-сервера. Для прискореного роботи КОЖЕН DNS-сервер кешує в області пам'яті свою таблицю відповідності імен и IP-адреса хостів. У тому чіслі в кеш заноситися дінамічно змінна інформація про імена и IP-адреси хостів, знайденіх в процесі Функціонування DNS-сервера. Т. е. Якщо DNS-сервер, отримавши запит, не знаходить у себе в кеш-таблиці відповідного запису, він пересилає відповідь на наступний сервер і, отримавши відповідь, заносить знайдені відомості в кеш-таблицю. Таким чином, при отриманні наступного запиту DNS-сервера вже не потрібно вести віддалений пошук, так як необхідна інформація вже знаходиться у нього в пам'яті.

( 1x1 )

Малюнок 3.Внедреніе в Internet помилкового сервера шляхом перехоплення DNS-запиту від DNS-сервера: а) фаза очікування атакуючим DNS-запиту від DNS-сервера (для прискорення атакуючий генерує необхідний DNS-запит); б) фаза передачі атакуючим помилкового DNS-відповіді на DNS-сервер 1; в) кеш-таблиця DNS-сервера містить інформацію про відповідність імені TOP.SECRET.COM IP-адресою хоста атакуючого.

З аналізу тільки що описаної схеми віддаленого DNS-пошуку стає очевидно, що в тому випадку якщо у відповідь на запит від DNS-сервера атакуючий направить помилковий DNS-відповідь (або в разі "шторму" помилкових відповідей буде вести їх постійну передачу), то в кеш-таблиці сервера з'явиться відповідний запис з неправдивими відомостями, і в подальшому всі хости, які звернулися до даного DNS-сервера, будуть дезінформовані, і при зверненні до хоста, маршрут до якого атакуючий вирішив змінити, зв'язок з ним буде здійснюватися через хост атакуючого за схемою "Помилковий б'ект РВС "! І, що найгірше, з плином часу ця неправдива інформація, що потрапила в кеш DNS-сервера, буде поширюватися на сусідні DNS-сервери вищих рівнів, а отже, все більше хостів в Internet виявляться дезінформовані і атаковані!

Очевидно, що в тому випадку, якщо атакуючий не може перехопити DNS-запит від DNS-сервера, для реалізації атаки йому необхідний "шторм" помилкових DNS-відповідей, спрямований на DNS-сервер. При цьому виникає наступна основна заковика, відмінна від проблеми підбору портів в разі атаки, спрямованої на хост. Як вже зазначалося раніше, DNS-сервер, посилаючи запит на інший DNS-сервер, ідентифікує цей запит двобайтовим значенням (ID). Це значення збільшується на одиницю з кожним переданим запитом. Атакуючому дізнатися це поточне значення ідентифікатора DNS-запиту не представляється можливим. Тому, крім перебору 216 можливих значень ID, запропонувати що-небудь досить складно. Зате відпадає проблема перебору портів, так як всі DNS-запити передаються DNS-сервером на 53 порт.

( 1x1 )

Малюнок 4.Внедреніе в Internet помилкового сервера шляхом створення спрямованого "шторму" помилкових DNS-відповідей на атакується DNS-сервер: а) атакуючий створює спрямований "шторм" помилкових DNS-відповідей від імені одного з кореневих DNS-серверів і при цьому провокує атакується DNS -сервер, посилаючи DNS-запит; б) DNS-сервер передає DNS-запит на primary DNS-сервер і негайно отримує помилковий DNS-відповідь від атакуючого; в) кеш-таблиця DNS-сервера містить інформацію про відповідність імені TOP.SECRET.COM IP-адресою хоста атакуючого.

Є ще одна умова здійснення цієї віддаленої атаки на DNS-сервер при направленому "штормі" помилкових DNS-відповідей: справа в тому, що атака буде мати успіх, тільки якщо DNS-сервер пошле запит на пошук певного імені (яке міститься в хибному DNS- відповіді). DNS-сервер посилає цей такий необхідний і бажаний для атакуючого запит в тому випадку, якщо на нього прийде DNS-запит від будь-якого хоста на пошук даного імені, і цього імені не виявиться в кеш-таблиці DNS-сервера. В принципі цей запит може прийти коли завгодно, і атакуючому цілком ймовірно доведеться чекати результатів атаки як завгодно довго. Однак ніщо не заважає атакуючому, не чекаючи нікого, самому послати на атакується DNS-сервер подібний DNS-запит і спровокувати DNS-сервер на пошук зазначеного в запиті імені! Тоді ця атака з великою ймовірністю буде мати успіх практично відразу ж після початку її здійснення!

Для прикладу згадаємо недавній скандал (28 жовтня 1996 року), винуватцем якого виявився один з московських провайдерів Internet - компанія РОСНЕТ, коли її користувачі при зверненні до звичайного інформаційного WWW-серверу потрапляли, як було сказано в телевізійному репортажі, на WWW-сервер "сумнівного "змісту (напевно, www.playboy.com ). Оскільки ніхто так толком і не зрозумів, що ж сталося - ні журналісти (їх можна вибачити, вони не фахівці в цьому питанні), ні ті, хто проводив прес-конференцію (фахівців до спілкування з пресою, напевно, просто не допустили), інформаційні повідомлення про дану подію виявилися настільки убогі, що усвідомити причини події виявилося практично неможливо. Однак, можливо, те, що сталося в Москві, цілком укладається в тільки що описану схему віддаленої атаки на DNS-сервер. За одним винятком: замість адреси хоста атакуючого в кеш-таблицю DNS-сервера був занесений IP-адреса хоста www.playboy.com .

Однак, мабуть, в більшості своїй російські кракери ще не доросли до такого витончених методів мережевого злому, як атака на DNS. Після того як стаття була написана, автору довелось ознайомитись з інтерв'ю, яке нібито дав кракер, який здійснив цей злом. З нього випливало, що атакуючий використовував одну з відомих "дірок" в WWW-сервері Роснет, що і дозволило підмінити одне посилання на іншу. Здійснення атак такого типу є по суті тривіальним і не вимагає від зломщика практично ніякої кваліфікації (підкреслюю, мова йде про здійснення атаки, а не про пошук цієї "діри"). Висока кваліфікація необхідна саме для пошуку тієї самої вразливою точки, використовуючи яку, можна зламати систему. Але, на глибоке переконання автора, виявляють слабке місце і здійснюють на його базі злом, швидше за все, різні люди, так як саме висока кваліфікація фахівця, який знайшов "дірку", не дозволить йому завдати шкоди простим користувачам. (Р. Т. Морріс не був винятком. Просто його черв'як через помилки в коді вийшов з-під контролю, внаслідок чого користувачам мережі було завдано певної шкоди.)

На закінчення автор хотів би знову повернутися до служби DNS і відзначити, що, як випливає з попередніх пунктів, використання в Мережі служби віддаленого пошуку DNS дозволяє атакуючому організувати в Internet віддалену атаку на будь-який хост, який користується послугами даної служби, і цілком може пробити серйозну пробоїну в системі захисту цієї та так аж ніяк не безпечної глобальної мережі. Нагадаю, що як вказував С. М. Белловін в що стала майже класичної роботі "Security Problems in the TCP / IP Protocol Suite": "Комбінація атаки на доменну систему і механізми маршрутизації можуть привести до катастрофи".

Хотілося б ще додати, що з докладним описом механізмів реалізації основних видів атак в Internet ви зможете ознайомитися в написаній мною в співавторстві з Павлом Семьянова новій книзі "Атака через Internet".

ТРОХИ ТЕОРІЇ

Дистанційні атаки в мережі Internet

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

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

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

Далі коротко охарактеризуємо типові віддалені атаки і механізми їх реалізації.

Аналіз мережевого трафіку

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

Підміна довіреного об'єкта або суб'єкта розподіленої ВС

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

Помилковий об'єкт розподіленої ВС

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

Якщо ж інфраструктура мережі така, що для взаємодії хостів необхідно використовувати алгоритми віддаленого пошуку (наприклад, SAP (NetWare), ARP і DNS (Internet)), це також дозволяє впровадити в систему помилковий об'єкт. Отже, існують дві принципово різні причини, які обумовлюють появу типової віддаленої атаки "Помилковий об'єкт розподіленої ВС":

Використання помилкового об'єкта для організації віддаленої атаки

Так як описана вище типова віддалена атака "Помилковий об'єкт розподіленої ВС" виявляється на рідкість типовою для мереж різних типів (Novell NetWare, Internet) і являє для них серйозну загрозу безпеці, то має сенс коротко розглянути можливі методи впливу на перехоплену помилковим об'єктом інформацію.

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

1. Селекція і збереження потоку інформації.

2. Модифікація інформації:

3. Підміна інформації.

Відмова в обслуговуванні

У разі, якщо в мережі не передбачено коштів аутентифікації адреси відправника, т. Е. Інфраструктура мережі дозволяє з одного хоста передавати на інший хост, що атакується нескінченне число анонімних запитів на підключення від імені інших хостів, то матиме успіх типова віддалена атака - "Відмова в обслуговуванні ". Результат проведення цієї віддаленої атаки - порушення на атакованому хості працездатності відповідної служби надання віддаленого доступу.

Другий різновид цієї типової віддаленої атаки полягає в передачі з однієї адреси такої кількості запитів на підключення до атакованого хосту, яке може "вмістити" трафік (спрямований "шторм" запитів). Якщо в системі не передбачені правила, що обмежують кількість прийнятих запитів з однієї адреси в одиницю часу, результатом такої атаки може стати як переповнення черги запитів і відмова однієї з мережевих служб (як і в попередньому випадку), так і повна зупинка комп'ютера через неможливість системи займатися нічим іншим, крім обробки запитів.