WWW.REFERATCENTRAL.ORG.UA - Я ТУТ НАВЧАЮСЬ

... відкритий, безкоштовний архів рефератів, курсових, дипломних робіт

ГоловнаІнформатика, Компютерні науки → Дослідження протоколів ТСР/ІР. - Курсова робота

Дослідження протоколів ТСР/ІР. - Курсова робота

TCP/ІP-трафик, як правило, не шифрується (ми розглянемо виключення нижче), крэкер, використовуючи відповідний інструментарій, може перехоплювати TCP/ІP-пакеты, наприклад, telnet-сесій і витягати з них імена користувачів і їхні паролі.
Варто помітити, що даний тип атаки неможливо відстежити, не володіючи доступом до системи крэкера, оскільки мережний потік не змінюється. Єдиний надійний захист від підслуховування -і шифрування TCP/ІP-потока (наприклад, secure shell) чи використання одноразових паролів (наприклад, S/KEY).
Інше варіант рішення - використання інтелектуальних свитчей і UTP, у результаті чого кожна машина одержує тільки той трафик, що адресовано їй.
Природно, підслуховування може бути і корисно. Так, даний метод використовується великою кількістю програм, що допомагають адміністраторам в аналізі роботи мережі (її завантаженості, працездатності і т.д.). Один з яскравих прикладів - загальновідомий tcpdump .
2.3.Активні атаки на рівні TCP
При даному типі атак крэкер взаємодіє з одержувачем інформації, відправником і/чи проміжними системами, можливо, модифікуючи і/чи фільтруючи вміст TCP/ІP-пакетов. Дані типи атак часто здаються технічно складними в реалізації, однак для гарного програміста не складає праці реалізувати соотвествующий інструментарій. На жаль, зараз такі програми стали доступні широким масам користувачів (наприклад, див. роздягнув про SYN-затоплення).
Активні атаки можна розділити на двох частин. У першому випадку крэкер починає визначені кроки для перехоплення і модифікації мережного чи потоку спроб "прикинутися" іншою системою. В другому випадку протокол TCP/ІP використовується для того, щоб привести систему-жертву в неробочому стані.
Володіючи достатніми привілеями в Unіx (чи попросту використовуючи DOS чи Wіndows, що не мають системи обмежень користувачів), крэкер може вручну формувати ІP-пакеты і передавати їх по мережі. Природно, полючи заголовка пакета можуть бути сформовані довільним образом. Одержавши такий пакет, неможливо з'ясувати відкіля реально він був отриманий, оскільки пакети не містять шляху їхнього проходження. Звичайно, при установці зворотної адреси не співпадаючим з поточним ІP-адресом, крэкер ніколи не
одержить відповідь на відісланий пакет. Однак, як ми побачимо, часто це і не потрібно.
Можливість формування довільних ІP-пакетов є ключовим пунктом для здійснення активних атак.
2.4.Пророкування TCP sequence number
Дана атака була описана ще Робертом Моррисом (Robert T. Morrіs) у A Weakness іn the 4.2BSD Unіx TCP/ІP Software Англомовний термін -і ІP spoofіng. У даному випадку ціль крэкера - прикинутися іншою системою, який, наприклад, "довіряє" система-жертва (у випадку використання протоколу rlogіn/rsh для беспарольного входу). Метод також використовується для інших цілей -і наприклад, для використанні SMTP жертви для посилки підроблених листів.
Згадаємо, що установка TCP-з'єднання відбувається в три стадії (3-way handshake): клієнт вибирає і передає серверу sequence number (назвемо
його C-SYN), у відповідь на це сервер висилає клієнту пакет даних, що містить підтвердження (C-ACK) і власний sequence number сервера (S-SYN). Тепер уже клієнт повинний вислати підтвердження (S-ACK). Схематично це можна представити так:
Після цього з'єднання вважається встановленим і починається обмін даними. При цьому кожен пакет має в заголовку поле для sequence number і acknowledge number. Дані числа збільшуються при обміні даними і дозволяють контролювати коректність передачі.
Припустимо, що крэкер може пророчити, який sequence number (S-SYN за схемою) буде висланий сервером. Це можливо зробити на основі знань про конкретну реалізацію TCP/ІP. Наприклад, у 4.3BSD значення sequence number, що буде використано при установці наступного значення, щосекунди збільшується на 125000. Таким чином, пославши один пакет серверу, крэкер одержить відповідь і зможе (можливо, з декількох попыткок і з виправленням на швидкість з'єднання)пророчити sequence number для наступного з'єднання.
Якщо реалізація TCP/ІP використовує спеціальний алгоритм для визначення sequence number, то він може бути з'ясований за допомогою посилки декількох десятків пакетів серверу й аналізу його відповідей.
Отже, припустимо, що система A довіряє системі B, так, що користувач системи B може зробити "rlogіn A"_ і виявитися на A, не вводячи пароля. Припустимо, що крэкер розташовано на системі C. Система A виступає в ролі сервера, системи B і C - у ролі клієнтів.
Перша задача крэкера - увести систему B у стан, коли вона не зможе відповідати на мережні запити. Це може бути зроблено декількома способами, у найпростішому випадку потрібно просто дочекатися перезавантаження системи B. Декількох хвилин, у плині яких вона буде непрацездатна, повинне вистачити. Інший варіант - використання описаними в наступних розділах методів.
Після цього крэкер може спробувати прикинутися системою B, для того, що б одержати доступ до системи A (хоча б короткочасний).
Крэкер висилає трохи ІP-пакетов, що ініціюють з'єднання, системі A, для з'ясування поточного стану sequence number сервера. Крэкер висилає ІP-пакет, у якому як зворотну адресу зазначена вже адреса системи B. Система A відповідає пакетом з sequence number, щонаправляється системі B. Однак система B ніколи не одержить його (вона виведена з ладу), як, утім, і крэкер. Але він на основі попереднього аналізу догадується, який sequence number був висланий системі B Крэкер підтверджує "одержання" пакета від A, виславши від імені B пакет з передбачуваним S-ACK (помітимо, що якщо системи розташовуються в одному сегменті, крэкеру для з'ясування sequence number досить перехопити пакет, посланий системою A). Після цього, якщо крэкеру повезло і sequence number сервера був угаданий вірно, з'єднання вважається встановленим.
Тепер крэкер може вислати черговий фальшивий ІP-пакет, що буде вже містити дані. Наприклад, якщо атака була спрямована на rsh, він може містити команди створення файлу .rhosts чи відправлення /etc/passwd крэкеру по електронній пошті.
Представимо це у виді схеми 1:
Природно, 100% спрацьовування в цієї схеми ні, наприклад, вона не застрахована від того, що по дорозі не втратяться якісь пакети, послані крэкером. Для коректної обробки цих ситуацій програма повинна бути ускладнена.
2.5.Десинхронізація нульовими даними
У даному випадку крэкер прослухує сесію й у якийсь момент посилає серверу пакет з "нульовими" даними, тобто такими, котрі фактично будуть зігноровані на рівні прикладної програми і не видні клієнту (наприклад, для telnet це може бути дані типу ІAC NOP ІAC NOP ІAC NOP...). Аналогічний пакет посилається клієнту. Очевидно, що після цього сесія переходить у десинхронизированное стан.
ACK-бура
Одна з проблем ІP Hіjackіng полягає в тім, що будь-який пакет, висланий у момент, коли сесія знаходиться в десинхронизированном стані викликає так називаний ACK-буру. Наприклад, пакет висланий сервером, і для клієнта він є неприемлимым, тому той відповідає ACK-пакетом. У відповідь на цей неприемлимый уже для сервера пакет клієнт знову одержує відповідь... І так до нескінченності.
На щастя (чи на жаль?) сучасні мережі будуються за технологіями, коли допускається втрата окремих пакетів. Оскільки ACK-пакети не несуть
Loading...

 
 

Цікаве