Реферат: Дослідження протоколів ТСР-ІР

Якщо реалізація 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, тобто практично в будь-якім середовищі передачі даних.