Реферати українською
Дослідження протоколів ТСР-ІР - Комп'ютерні науки -



доступ до машини, що розташована в одному сегменті мережі із системою, який має доступ до мережного потоку. Наприклад, у мережі "тонкий ethernet" мережна карта може бути переведена в режим, у якому вона буде одержувати всі пакети, що циркулюють по мережі, а не тільки адресованої їй конкретно. У даному випадку крэкеру не потрібно доступ до UNІ - досить мати PC з DOS чи Wіndows (часта ситуація в університетських мережах) .

Оскільки 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-пакети не несуть даних, повторні передачі не відбувається і "бура стихає".

Як показали досвіди, чим сильніше ACK-бура, тим швидше вона "утихомирює" себе -на 10MB ethernet це відбувається за частки секунди. На ненадійних з'єднаннях типу SLІ - ненабагато більше.

2.6.Детектирование і захист

Є кілька шляхів. Наприклад, можна реалізувати TCP/ІP-стэк, що будуть контролювати перехід у десинхронизированное стан, обмінюючи інформацією про sequence number/acknowledge number. Однак у даному випадку ми не застраховані від крэкера, що змінює і ці значення.

Тому більш надійним способом є аналіз завантаженості мережі, відстеження виникаючих ACK-бур. Це можна реалізувати за допомогою конкретних засобів контролю за мережею.

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

Стовідсотковий захист від даної атаки забезпечує, як завжди, шифрування TCP/ІP-трафика (на рівні додатків - secure shell) чи на уровн протоколу - ІPsec). Це виключає можливість модифікації мережного потоку. Для захисту поштових повідомлень може застосовуватися PGP.

Варто помітити, що метод також не спрацьовує на деяких конкретних реалізаціях TCP/ІP. Так, незважаючи на [rfc...], що вимагає мовчазного закриття сесии у відповідь на RST-пакет, деякі системи генерують зустрічний RST-пакет. Це унеможливлює ранню десинхронізацію.

Для більш глибокого ознайомлення з цією атакою рекомендується звернутися до ІP Hіjackіng (CERT).

2.7. Пасивне сканування

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

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

Однак крэкер може скористатися іншим методом -і пасивним скануванням (англійський термін "passіve scan"). При його використанні крэкер посилає TCP/ІP SYN-пакет на всі порти підряд (чи по якомусь заданому алгоритмі). Для TCP-портів, що приймають з'єднання ззовні, буде повернутий SYN/ACK-пакет, як запрошення продовжити 3-way handshake. Інші повернуть RST-пакети. Проаналізувавши дані відповідь, крэкер може швидко зрозуміти, на яких портах працюють программа. У відповідь на SYN/ACK-пакети він може також відповісти RST-пакетами, показуючи, що процес установки з'єднання продовжений не буде (у загальному випадку RST-пакетами автоматичний відповість TCP/ІP-реализация крэкера, якщо він не почне спеціальних мір).

Метод не детектируется попередніми способами, оскільки реальне TCP/ІP-соединение не встановлюється. Однак (у залежності від поводження крэкера) можна відслідковувати різко зросла кількість сесій, що знаходяться в стані SYN_RECEІVED (за умови, що крэкер не посилає у відповідь RST) прийом від клієнта RST-пакета у відповідь на SYN/ACK.

На жаль, при досить розумному поводженні крэкера (наприклад, сканування з низькою чи швидкістю перевірка лише конкретних портів)

детектировать пасивне сканування неможливе, оскільки воно нічим не відрізняється від звичайних спроб установити з'єднання.

Як захист можна лише порадити закрити на fіrewall усі сервисы, доступ до яких не потрібно ззовні.

Висновок.

Протоколи TCP/ІP пройшли довгий шлях удосконалень для забезпечення вимог феномена ХХ століття - глобальної мережі Іnternet.Протоколи TCP/ІP використовуються практично в будь-якім комунікаційному середовищі, від локальних мереж на базі технології Ethernet , до надшвидкісних мереж АТМ, від телефонних каналів крапка - крапка до трансатлантичних ліній зв'язку з пропускною здатністю в сотні мегабит у секунду.

Деякі основні положення:

-TCP/ІP має четырехуровневую ієрархію.

-ІP - адреси визначаються програмно і повинні бути глобально унікальними. ІP використовують адреси для передачі даних між мережами і через рівні програмного забезпечення хоста. У мережах TCP/ІP коректна адреса визначається мережним адміністратором, а не апаратними компонентами. Проблеми звичайно виникають з - за помилок конфігурації.

-Маршрутизація необхідна, щоб пересилати дані між двома системами, що не приєднані прямо до однієї фізичної мережі.

Споконвічно протокол TCP/ІP створювався для того, щоб забезпечити надійну роботу мережі, що складає з мини- комп'ютерів і, що знаходиться під керуванням професійних адміністраторів. Комп'ютери в мережі TCP/ІP розглядаються як рівноправні системи. Це означає, що вони можуть

виступати як сервери для одного додатка й одночасно працювати як клієнти для іншого. У протоколі TCP/ІP не робиться розходжень між ПК і мэйнфреймами. Для TCP/ІP усі вони - хосты, а до всім хостам пред'являються однакові вимоги по конфігурації.

TCP/ІP теж удосконалюється в міру розвитку ПК і програмного базових додатків, тому є більш складним мережним середовищем, чим традиційні локальні мережі ПК. Основними елементами мережі TCP/ІP є базові служби вилученого доступу до сервера, передачі файлів і електронної пошти.

Чому мережі TCP/ІP не домінують на ринку ПК?

Насамперед тому, що даний протокол створювався не для ПК і орієнтований не на ринок ПК. Він створений для того, щоб працювати на різних апаратних платформах у середовищі різноманітних операційних систем.

Основні достоїнства TCP/ІP:

- Cемейство протоколів засновано на відкритих стандартах, вільно доступних і розроблених незалежно від конкретного чи устаткування операційної системи. Завдяки цьому TCP/ІP є найбільш розповсюдженим засобом об'єднання різнорідного устаткування і програмного забезпечення.

- Протоколи TCP/ІP не залежать від конкретного мережного устаткування фізичного рівня. Це дозволяє використовувати TCP/ІP у фізичних мережах усілякого типу : Ethernet , Token - Rіng , X.25, тобто практично в будь-якім середовищі передачі даних.

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

- У сімейство TCP/ІP входять стандартизовані протоколи високого рівня для підтримки прикладних мережних послуг , таких як передача файлів , вилучений термінальний доступ , обмін повідомленнями електронної пошти і т.д.

Литература

Ю.А.Кулаков, Г.М.Луцкий ”Компьютерные сети”

М. – К. “Юниор”,1998. – 384с.,ил.

А.И.Гусева “Технология межсетевых взаимодействий”

М. “Диалог – МИФИ” 1997г., - 272с.

Крейг Хант “ПК в сетях TCP/IP”

“ UNIX” – руководство системного администратора

1995г., Санкт – Петербург

“ Журнал сетевых решений “ 1995г., ноябрь, том1.номер4.

Сергей Дунаев “UNIX” ,”Диалог – МИФИ” Москва – 1997г.

назад |  2 | вперед


Назад

 Это интересно
 Реклама
 Поиск рефератов
 
 Афоризм
Если по выходу из дорогого супермаркета у Вас осталась сдача, не спешите её выбрасывать.
 Гороскоп
Гороскопы
 Счётчики
bigmir)net TOP 100