3 ѕричини усп≥ху в≥ддалених атак

3.1 ѕричини усп≥ху загроз безпец≥ розпод≥лених систем

јнал≥з механ≥зм≥в практичних реал≥зац≥й атак у мереж≥ Internet дозвол¤ють сформулювати причини, по ¤ких реал≥зац≥¤ даних загроз ви¤вилас¤ можливою. ќсобливо в≥дзначимо, що розгл¤нут≥ нижче причини ірунтуютьс¤ на базових принципах побудови мережноњ взаЇмод≥њ об'Їкт≥в розпод≥леноњ обчислювальноњ исстеми.

ƒл¤ усуненн¤ причин атак на ≥нфраструктуру ≥ базов≥ протоколи мереж≥ найчаст≥ше необх≥дно або в≥дмовитис¤ в≥д певних служб (наприклад, DNS), або зм≥нити конф≥гурац≥ю системи (на¤вн≥сть широкомовного середовища приводить до можливост≥ програмного прослуховуванн¤ каналу), або зм≥нити систему в ц≥лому.

3.1.1 ¬≥дсутн≥сть вид≥леного каналу зв'¤зку

ѕершою розгл¤дуваною в≥ддаленою атакою був Уанал≥з мережного траф≥куФ. ЌагадаЇмо, що дана атака пол¤гаЇ в прослуховуванн≥ каналу передач≥ пов≥домлень у мереж≥. –езультат ц≥Їњ атаки ‑ по-перше, з'¤суванн¤ лог≥ки роботи розпод≥леноњ обчислювальноњ системи ≥, по-друге, перехопленн¤ потоку ≥нформац≥њ, ¤ким обм≥нюютьс¤ об'Їкти системи. “ака атака програмно можлива т≥льки у випадку, ¤кщо кракер знаходитьс¤ в мереж≥ з ф≥зично широкомовним середовищем передач≥ даних, ¤к, наприклад, ус≥м в≥доме середовище Ethernet (на в≥дм≥ну в≥д Token Ring, що не Ї широкомовноњ, але й не маЇ достатнього поширенн¤). ќчевидно, що дана атака була б неможливою, ¤кби в кожного об'Їкта системи дл¤ зв'¤зку з будь-¤ким ≥ншим об'Їктом мавс¤ вид≥лений канал (вар≥ант ф≥зичного прослуховуванн¤ такого каналу не розгл¤даЇтьс¤, тому що без специф≥чних апаратних засоб≥в п≥дключенн¤ до нього неможливо). р≥м ф≥зичного вид≥леного каналу звТ¤зку проблему вир≥шить також використанн¤ в≥ртуальних приватних мереж.

ќтже, причина усп≥ху даноњ атаки ‑ на¤вн≥сть широкомовного середовища передач≥ даних чи в≥дсутн≥сть вид≥леного каналу зв'¤зку м≥ж об'Їктами розпод≥леноњ обчислювальноњ системи.

3.1.2 Ќедостатн¤ ≥дентиф≥кац≥¤ й аутентиф≥кац≥¤

як уже п≥дкреслювалос¤, проблема ≥дентиф≥кац≥њ й аутентиф≥кац≥њ суб'Їкт≥в ≥ об'Їкт≥в розпод≥леноњ системи маЇ надзвичайно важливе значенн¤. ¬≥д њњ розвТ¤занн¤ залежить безпека розпод≥леноњ обчислювальноњ системи у ц≥лому. ѕриклади усп≥шно зд≥йснених в≥ддалених атак, розгл¤нут≥ у попередн≥х пунктах, довод¤ть, що в≥дсутн≥сть у розроблювач≥в заздалег≥дь визначеноњ концепц≥њ ≥ принцип≥в ≥дентиф≥кац≥њ об'Їкт≥в розпод≥леноњ обчислювальноњ системи залишають кракеров≥ потенц≥йну можлив≥сть компрометац≥њ об'Їкт≥в системи. —тандартними способами компрометац≥њ суб'Їкт≥в ≥ об'Їкт≥в –ќ Ї:

Ј видача себе за ¤кий-небудь об'Їкт чи суб'Їкт ≥з присвоЇнн¤м його прав ≥ повноважень дл¤ доступу в систему (наприклад, розгл¤нут≥ загрози повТ¤зан≥ ≥з п≥дм≥ною дов≥реного суб'Їкта чи об'Їкта мереж≥);

Ј введенн¤ у систему помилкового об'Їкта, що видаЇ себе за дов≥рений об'Їкт системи (наприклад, загроза Ухибний об'Їкт розпод≥леноњ обчислювальноњ системиФ).

3.1.2.1 ¬заЇмод≥¤ об'Їкт≥в без встановленн¤ в≥ртуального каналу

ќдним з найважлив≥ших питань, на ¤к≥ необх≥дно в≥дпов≥сти, говор¤чи про ≥дентиф≥кац≥ю й аутентиф≥кац≥ю об'Їкт≥в ≥ суб'Їкт≥в розпод≥леноњ обчислювальноњ системи, Ї питанн¤ про види взаЇмод≥њ м≥ж суб'Їктами й об'Їктами у межах розпод≥леноњ системи. ¬заЇмод≥¤ м≥ж суб'Їктами й об'Їктами може бути двох вид≥в:

Ј з використанн¤м в≥ртуального каналу;

Ј без використанн¤ в≥ртуального каналу.

ѕрактика показуЇ, що 99% взаЇмод≥й м≥ж об'Їктами в мереж≥ Internet проходить ≥з встановленн¤м такого каналу (при будь-¤кому FTP-, TELNET-, HTTP- ≥ т.п. п≥дключенн≥ використовуЇтьс¤ протокол TCP, а отже, створюЇтьс¤ ¬ ). ÷е в≥дбуваЇтьс¤ тому, що взаЇмод≥¤ по в≥ртуальному канал≥ Ї Їдиним динам≥чним способом захисту мережного з'Їднанн¤ об'Їкт≥в розпод≥леноњ обчислювальноњ системи: у процес≥ створенн¤ ¬ об'Їкти обм≥нюютьс¤ динам≥чно вироблюваною ключовою ≥нформац≥Їю, що дозвол¤Ї ун≥кально ≥дентиф≥кувати канал. ” противному випадку дл¤ розп≥знаванн¤ об'Їкт≥в розпод≥леноњ системи довелос¤ б використовувати масив статичноњ ≥дентиф≥кац≥йноњ ≥нформац≥њ, ун≥кальний дл¤ кожного об'Їкта. ј це означаЇ, що ми одержуЇмо стандартну проблему статичного розпод≥лу ключ≥в (матриц¤ ), що можливе т≥льки на обмежен≥й п≥дмножин≥ об'Їкт≥в, але не в Internet.

ќтже ≥дентиф≥кац≥¤ об'Їкт≥в –ќћ при в≥дсутност≥ статичноњ ключовоњ ≥нформац≥њ можлива т≥льки при взаЇмод≥њ об'Їкт≥в з використанн¤м в≥ртуального каналу. “обто взаЇмод≥¤ без встановленн¤ ¬ Ї одн≥Їю з можливих причин усп≥ху в≥ддалених атак на розпод≥лен≥ обчислювальн≥ системи.

ќднак помилково вважати розпод≥лену обчислювальну систему безпечною, нав≥ть ¤кщо ус¤ взаЇмод≥¤ об'Їкт≥в в≥дбуваЇтьс¤ з≥ створенн¤м ¬ . ѕро це мова йтиме в наступному параграф≥.

3.1.2.2 ¬икористанн¤ нест≥йких алгоритм≥в ≥дентиф≥кац≥њ

Ќа жаль, взаЇмод≥¤ об'Їкт≥в по в≥ртуальному канал≥ у розпод≥лен≥й систем≥ не Ї панацеЇю в≥д ус≥х проблем, зв'¤заних з ≥дентиф≥кац≥Їю об'Їкт≥в розпод≥леноњ обчислювальноњ системи. ¬ - необх≥дна, але не достатн¤ умова безпечноњ взаЇмод≥њ. Ќадзвичайно важливим у даному випадку стаЇ виб≥р алгоритму ≥дентиф≥кац≥њ при створенн≥ в≥ртуального каналу. ќсновна вимога, котра предТ¤вл¤Їтьс¤ до цих алгоритм≥в, пол¤гаЇ в наступному: перехопленн¤ ключовоњ ≥нформац≥њ, ¤кою обм≥нюютьс¤ об'Їкти розпод≥леноњ обчислювальноњ системи при створенн≥ ¬ , не повинна дозволити атакуючому одержати п≥дсумков≥ ≥дентиф≥катори каналу й об'Їкт≥в (див. параграф Уѕричини усп≥ху в≥ддалених атак у мереж≥ InternetФ). ќднак у базових алгоритмах ≥дентиф≥кац≥њ, використовуваних при створенн≥ ¬ в б≥льшост≥ ≥снуючих мережних ќ—, ц¤ вимога практично не враховуЇтьс¤. “ак, наприклад, у протокол≥ TCP ≥дентиф≥каторами каналу й об'Їкт≥в Ї два 32-б≥тних числа, формованих у процес≥ створенн¤ TCP-з'Їднанн¤ (див. параграф Уѕ≥дм≥на одного ≥з суб'Їкт≥в TCP-з'Їднанн¤ в мереж≥ InternetФ).

ќчевидно, що створенн¤ в≥ртуального каналу з використанн¤м нест≥йкого алгоритму ≥дентиф≥кац≥њ не дозвол¤Ї над≥йно убезпечити розпод≥лену обчислювальну систему в≥д п≥дм≥ни об'Їкт≥в ≥ виступаЇ в ¤кост≥ одн≥Їњ з причин усп≥ху в≥ддалених атак на розпод≥лен≥ обчислювальн≥ системи.

3.1.3 ¬≥дсутн≥сть контролю за в≥ртуальними каналами зв'¤зку

ќб'Їкти розпод≥леноњ системи, взаЇмод≥ючи по в≥ртуальних каналах, можуть п≥ддаватис¤ типов≥й атац≥ Ув≥дмова в обслуговуванн≥Ф. ѓњ особлив≥сть пол¤гаЇ в тому, що, д≥ючи абсолютно легальними засобами системи, можна в≥ддалено добитис¤ порушенн¤ њњ працездатност≥. ЌагадаЇмо, що дана погроза реал≥зуЇтьс¤ за допомогою передач≥ багатьох запит≥в на створенн¤ з'Їднанн¤ (в≥ртуального каналу), у результат≥ чого переповн¤Їтьс¤ черга запит≥в, або система, зайн¤та обробкою в≥дпов≥дей на запити, узагал≥ перестаЇ функц≥онувати. ” чому причина усп≥ху даноњ атаки? ” в≥дсутност≥ необх≥дного контролю над з'Їднанн¤м. ѕри цьому задачу контролю можна под≥лити на дв≥ п≥дзадач≥:

Ј контроль за створенн¤м з'Їднанн¤;

Ј контроль за використанн¤м з'Їднанн¤.

якщо шл¤хи вир≥шенн¤ другоњ задач≥ зрозум≥л≥ Ц ¤к правило з'Їднанн¤ розриваЇтьс¤ по тайм-аут≥, визначеному системою, ‑ так зроблено у вс≥х в≥домих мережних ќ— (однак виникаЇ серйозна проблема вибору конкретного значенн¤ тайм-ауту), то контроль за створенн¤м ¬ досить складний: у систем≥, де в≥дсутн¤ статична ключова ≥нформац≥¤ про вс≥ њњ об'Їкти, неможливо в≥докремити хибн≥ запити на створенн¤ з'Їднанн¤ в≥д справжн≥х. ќчевидно також, що ¤кщо один суб'Їкт мережноњ взаЇмод≥њ буде мати можлив≥сть анон≥мно займати необмежене число канал≥в зв'¤зку з в≥ддаленим об'Їктом, то под≥бна система може бути ц≥лком парал≥зована даним суб'Їктом (саме так працюЇ мережа Internet у стандарт≥ IPv4). “аким чином, ¤кщо будь-¤кий об'Їкт у розпод≥лен≥й систем≥ може анон≥мно послати пов≥домленн¤ в≥д ≥мен≥ ≥ншого об'Їкта (наприклад, у Internet маршрутизатори не перев≥р¤ють IP-адресу в≥дправника), то в под≥бн≥й розпод≥лен≥й обчислювальн≥й мереж≥ практично неможливий контроль за створенн¤м в≥ртуальних з'Їднань. “ому основна причина типовоњ загрози Ув≥дмова в обслуговуванн≥Ф ‑ це в≥дсутн≥сть прийн¤тного вир≥шенн¤ задач≥ контролю за маршрутом пов≥домлень.

9. †DB of hosting serveces

3.1.4 ¬≥дсутн≥сть можливост≥ контролювати маршрут пов≥домлень

” розпод≥лених обчислювальних мережах ¤к початковою ≥нформац≥ю, що ≥дентиф≥куЇ об'Їкт, зазвичай виступаЇ його адреса. ѕ≥д адресою об'Їкта розум≥Їтьс¤ визначена системою ун≥кальна ≥нформац≥¤, ¤кою в≥н над≥л¤Їтьс¤ при п≥дключенн≥ до розпод≥леноњ обчислювальноњ мереж≥. “епер ус≥ пов≥домленн¤ в≥д ≥нших об'Їкт≥в розпод≥леноњ обчислювальноњ мереж≥, послан≥ на цю адресу, над≥йдуть на даний об'Їкт. Ўл¤х, чи, ¤к прийн¤то говорити, маршрут пов≥домленн¤, визначаЇтьс¤ тополог≥Їю розпод≥леноњ обчислювальноњ мереж≥ ≥ проходить через сукупн≥сть вузл≥в ‑ маршрутизатор≥в (роутер≥в). ќтже, у кожному пакет≥, що приходить на об'Їкт, може бути ц≥лком описаний його маршрут ‑ список адрес маршрутизатор≥в, пройдених на шл¤ху до адресата. “акий збережений у пакет≥ маршрут стане ≥нформац≥Їю, що аутентиф≥куватиме (п≥дтверджуватиме) з точн≥стю до п≥дмереж≥ справжн≥сть адреси в≥дправника (ц¤ ≥де¤ вже реал≥зована в систем≥ електронноњ пошти, що використовуЇ протокол SMTP). ≤нший вар≥ант аутентиф≥кац≥њ даноњ адреси ‑ ф≥льтрац≥¤ маршрутизатором пакет≥в з хибною адресою.

якщо в на розпод≥лен≥й обчислювальн≥й мереж≥ не передбачити под≥бного контролю за маршрутом пов≥домленн¤, то адреса в≥дправника пов≥домленн¤, не зможе бути н≥чим п≥дтвердженою. “аким чином, у систем≥ буде ≥снувати можлив≥сть роботи в≥д ≥мен≥ будь-¤кого об'Їкта шл¤хом вказуванн¤ у заголовку пов≥домленн¤ чужоњ адреси в≥дправника (IP Spoofing). ” под≥бн≥й розпод≥лен≥й обчислювальн≥й мереж≥ важко буде визначити, в≥дк≥л¤ насправд≥ прийшло пов≥домленн¤, а отже визначити координати атакуючого (у Internet неможливо знайти ≥н≥ц≥атора односпр¤мованоњ в≥ддаленоњ атаки).

ќтже, в≥дсутн≥сть у розпод≥лен≥й обчислювальн≥й мереж≥ можливост≥ контролювати маршрут пов≥домлень також Ї причиною усп≥ху в≥ддалених атак, по-перше, через складн≥сть контролю за створенн¤м зТЇднанн¤ ≥, по-друге, через можлив≥сть анон≥много в≥дправленн¤ пов≥домленн¤.

3.1.5 ¬≥дсутн≥сть повноњ ≥нформац≥њ про об'Їкти розпод≥леноњ обчислювальноњ мереж≥

” розпод≥лен≥й систем≥ з розгалуженою структурою, що складаЇтьс¤ з великого числа об'Їкт≥в, може виникнути ситуац≥¤, коли дл¤ доступу до визначеного хосту в суб'Їкта взаЇмод≥њ не ви¤витьс¤ необх≥дноњ ≥нформац≥њ, тобто адреси даного об'Їкта.

ѕо¤снимо це на простому приклад≥. ѕрипустимо, що користувач мереж≥ Internet вир≥шив п≥дключитис¤, наприклад, до WWW-сервера ф≥рми Novell. ¬≥н знаЇ њњ назву, але не маЇ ≥нформац≥њ про IP-адресу чи ≥мен≥ њњ сервера. ” цьому випадку користувач може послати циркул¤рний запит ус≥м хостам у мереж≥, спод≥ваючись, що ц≥кавл¤чий його сервер над≥шле шукану адресу. ќчевидно, що в глобальн≥й мереж≥ використанн¤ даноњ схеми, щонайменше, нерозумно. “ому користувач може п≥дключитис¤ до найближчого в≥домого йому пошуковому серверу (наприклад www.google.com) щоб запросити адресу шуканоњ ф≥рми.

ќтже, можлив≥ наступн≥ алгоритми в≥ддаленого пошуку. ” першому випадку, коли такий пошук зд≥йснюЇтьс¤ усередин≥ сегмента мереж≥, суб'Їкт системи надсилаЇ циркул¤рний запит, що одержують ус≥ об'Їкти розпод≥леноњ обчислювальноњ мереж≥, ≥ той з них, дл¤ кого призначалос¤ пов≥домленн¤, передаЇ у в≥дпов≥дь необх≥дну дл¤ адресац≥њ ≥нформац≥ю. ¬ другому випадку, коли необх≥дно зд≥йснити глобальний пошук, суб'Їкт розпод≥леноњ системи надсилаЇ запит на найближчий ≥нформац≥йно-пошуковий сервер, що, просканувавши свою базу, або в≥д≥шле у в≥дпов≥дь на запит знайдену адресу, або звернетьс¤ до наступного в систем≥ пошуково-≥нформац≥йному серверу. “аким чином, ¤кщо в розпод≥лен≥й систем≥ ≥снують об'Їкти, ≥нформац≥¤ про ¤к≥ апр≥орно не визначена, то дл¤ забезпеченн¤ нормального функц≥онуванн¤ системи необх≥дно використовувати описан≥ вище алгоритми в≥ддаленого пошуку.

ѕрикладом розпод≥леноњ обчислювальноњ мереж≥ ≥з закладеною невизначен≥стю Ї Internet, у ¤к≥й, по-перше, у хост≥в, що знаход¤тьс¤ в одному сегмент≥ може не бути ≥нформац≥њ про апаратн≥ адреси один одного ≥, по-друге, застосовуютьс¤ не придатн≥ дл¤ безпосередньоњ адресац≥њ мнемон≥чн≥ ≥мена хост≥в.

ќчевидно, що в систем≥ под≥бного типу ≥снуЇ потенц≥йна небезпека внесенн¤ помилкового об'Їкта ≥ п≥дм≥ни одного об'Їкта ≥ншим шл¤хом передач≥ хибноњ в≥дпов≥д≥ на пошуковий запит.

3.1.6 ¬≥дсутн≥сть криптозахисту пов≥домлень

” розпод≥лених системах зв'¤зок м≥ж њњ об'Їктами зд≥йснюЇтьс¤ по в≥ртуальних каналах зв'¤зку, а отже, кракер маЇ принципову можлив≥сть прослухати канал, одержавши несанкц≥онований доступ до ≥нформац≥њ, ¤кою обм≥нюютьс¤ по мереж≥ њњ абоненти. якщо ц¤ ≥нформац≥¤ не зашифрована, то виникаЇ загроза атаки типу Уанал≥з мережевого траф≥каФ.

¬икористанн¤ криптост≥йких алгоритм≥в шифруванн¤ пакет≥в обм≥ну м≥ж об'Їктами розпод≥леноњ обчислювальноњ системи на канальному (що звичайно виконуЇтьс¤ апаратно ≥ на сьогодн≥шн≥й день р≥дко зустр≥чаЇтьс¤ в звичайних мережах) ≥ прикладному р≥вн¤х OSI робить мережний анал≥з практично безглуздим. якщо в мереж≥ використовуютьс¤ алгоритми шифруванн¤ пакет≥в на мережному ‑ прикладному р≥вн¤х, то шифруванн¤ застосовуЇтьс¤ т≥льки до пол≥в даних пакет≥в в≥дпов≥дних р≥вн≥в, але не до њхн≥х заголовк≥в; таким чином, атакуючий, перехопивши пакет, може анал≥зувати отриману службову ≥нформац≥ю.

3.2 ѕричини усп≥ху в≥ддалених атак у мереж≥ Internet

Internet ¤вл¤Ї собою розпод≥лену обчислювальну систему, ≥нфраструктура ¤коњ загальнов≥дома ≥ добре описана. “ому розгл¤нут≥ в попередньому параграф≥ причини усп≥ху в≥ддалених атак на розпод≥лен≥ обчислювальн≥ системи природно проектуютьс¤ на Internet, з чого можна зробити висновок про ≥снуванн¤ в дан≥й мереж≥ серйозних проблем у забезпеченн≥ безпеки.

3.2.1 ¬≥дсутн≥сть вид≥леного каналу зв'¤зку м≥ж об'Їктами мереж≥ Internet

√лобальна мережа не може бути побудована за принципом пр¤мого зв'¤зку м≥ж об'Їктами, оск≥льки дл¤ кожного об'Їкта неможливо забезпечити вид≥лений канал зв'¤зку з будь-¤ким ≥ншим об'Їктом. “ому в Internet зв'¤зок зд≥йснюЇтьс¤ через ланцюжок маршрутизатор≥в, а отже, пов≥домленн¤, проход¤чи через велику к≥льк≥сть пром≥жних п≥дмереж, може бути перехоплено. “акож до Internet п≥дключено велике число локальних п≥дмереж, що використовують тополог≥ю Узагальна шинаФ; у мережах з такою тополог≥Їю нескладно програмно зд≥йснювати перехопленн¤ пов≥домлень.

3.2.2 Ќедостатн≥ ≥дентиф≥кац≥¤ й аутентиф≥кац≥¤

” базових протоколах обм≥ну ≥дентиф≥кац≥¤ й аутентиф≥кац≥¤ об'Їкт≥в практично в≥дсутн≥. “ак, наприклад, у прикладних протоколах FTP, TELNET, POP3 ≥мена ≥ парол≥ користувач≥в передаютьс¤ по мереж≥ у вид≥ в≥дкритих незашифрованих пов≥домлень. ¬ ≥снуючому стандарт≥ IPv4 протокол мережного р≥вн¤ IP не передбачаЇ жодноњ ≥дентиф≥кац≥њ й аутентиф≥кац≥њ об'Їкт≥в (за вин¤тком IP-адреси в≥дправника, справжн≥сть ¤кого, у свою чергу, неможливо п≥дтвердити). ”с≥ проблеми з ≥дентиф≥кац≥Їю розроблювач≥ переклали на наступний, транспортний, р≥вень, за ¤кий в≥дпов≥дають протоколи UDP ≥ TCP. “ак ¤к протокол UDP не м≥стить у соб≥ жодноњ додатковоњ ≥дентиф≥куючоњ ≥нформац≥њ, Їдиним протоколом, покликаним забезпечити безпеку в Internet, Ї TCP, котрий створюЇ в≥ртуальний канал.

9. †hosting serveces database

3.2.2.1 ¬заЇмод≥¤ в мереж≥ Internet об'Їкт≥в без установленн¤ в≥ртуального каналу

ќдн≥Їњ з особливостей Internet Ї взаЇмод≥¤ об'Їкт≥в без створенн¤ в≥ртуального каналу. ќчевидно, що розроблювач≥ планували под≥бну взаЇмод≥ю в тому випадку, ¤кщо забезпеченн¤ безпеки не потр≥бно. ќднак ≥ дл¤ керуючих ICMP-пов≥домлень, ≥ дл¤ DNS-запит≥в використовуЇтьс¤ зв'¤зок без ¬ , що приводить до можливост≥ зд≥йсненн¤ атак, розгл¤нутих у попередньому розд≥л≥.

3.2.2.2 ¬икористанн¤ нест≥йких алгоритм≥в ≥дентиф≥кац≥њ об'Їкт≥в при створенн≥ в≥ртуального TCP-з'Їднанн¤

як уже п≥дкреслювалос¤, протокол TCP Ї Їдиним базовим протоколом транспортного р≥вн¤, у функц≥њ ¤кого закладений захист з'Їднанн¤. ќднак використанн¤ найпрост≥шого алгоритму ≥дентиф≥кац≥њ об'Їкт≥в при створенн≥ в≥ртуального “—–-каналу (див. параграф Уѕ≥дм≥на одного ≥з суб'Їкт≥в TCP-з'Їднанн¤ в мереж≥ InternetєФ), особливо за умови застосуванн¤ в мережних ќ— найпрост≥ших часозалежних закон≥в генерац≥њ TCP-≥дентиф≥катор≥в (ISN), зводить нан≥вець ус≥ спроби забезпеченн¤ ≥дентиф≥кац≥њ каналу й об'Їкт≥в при њх взаЇмод≥њ по протоколу TCP.

3.2.3 Ќеможлив≥сть контролю за в≥ртуальними каналами звТ¤зку

¬ ≥снуючому стандарт≥ мереж≥ Internet не можна забезпечити контроль за мережними з'Їднанн¤ми, тому що в одного суб'Їкта мережноњ взаЇмод≥њ ≥снуЇ можлив≥сть зайн¤ти необмежене число канал≥в звТ¤зку з в≥ддаленим об'Їктом ≥ при цьому залишитис¤ анон≥мним. „ерез це будь-¤кий хост у мереж≥ Internet може бути ц≥лком парал≥зований.

3.2.4 ¬≥дсутн≥сть можливост≥ контролю за маршрутом пов≥домлений

Ќеможлив≥сть контролю в Internet за в≥ртуальними каналами обумовлено в≥дсутн≥стю в мереж≥ контролю за маршрутом пов≥домлень, а саме: в ≥снуючому стандарт≥ IPv4 не можна дл¤ пов≥домленн¤, що прийшло на хост, визначити шл¤х, через ¤кий воно пройшло, а отже, не можна перев≥рити справжн≥сть адреси в≥дправника.

3.2.5 ¬≥дсутн≥сть повноњ ≥нформац≥њ про об'Їкти Internet

ќчевидно, що в глобальн≥й мереж≥ неможливо забезпечити на кожному об'Їкт≥ на¤вн≥сть ≥нформац≥њ про будь-¤кий ≥нший об'Їкт. “ому, ¤к говорилось ран≥ше, необх≥дно використовувати потенц≥йно небезпечн≥ алгоритми в≥ддаленого пошуку. ” мереж≥ Internet використовуютьс¤, щонайменше, дав алгоритми в≥ддаленого пошуку: ARP ≥ DNS.

3.2.6 ¬≥дсутн≥сть криптозахисту пов≥домлень

¬ ≥снуючих базових протоколах с≥мейства TCP/IP, що забезпечують взаЇмод≥ю на мережному ≥ транспортному р≥вн¤х, не передбачена можлив≥сть шифруванн¤ пов≥домлень, хоча очевидно, що додати њњ до протоколу TCP не було складно. –озроблювач≥ вир≥шили перекласти задачу криптозахисту на протоколи б≥льш високих р≥вн≥в, наприклад прикладного р≥вн¤. ѕри цьому базов≥ протоколи прикладного piвн¤ (FTP, TELNET, HTTP ≥ ≥н.) також не передбачали жодного шифруванн¤ пов≥домлень. Ћише не давно з'¤вивс¤ загальнодоступний прикладний протокол SSL, вбудований у б≥льш≥сть попул¤рних броузер≥в, що дозвол¤Ї ¤к над≥йно зашифрувати пов≥домленн¤, так ≥ п≥дтвердити його справжн≥сть.

Ќа зак≥нченн¤ хот≥лос¤ б в≥дм≥тити, що вс≥ описан≥ вище причини, по ¤ких можлива усп≥шна реал≥зац≥¤ загроз безпец≥ розпод≥лених обчислювальних систем, робл¤ть мережу Internet незахищеною в≥д описаних в≥ддалених атак (див. ). “аким чином ус≥ користувач≥ мереж≥ можуть бути атакован≥ в будь-¤кий момент.

–ис. 3.1. ѕричини усп≥ху в≥ддалених атак

Ќа головну стор≥нку