Дослідження протоколів TCP/IP, Детальна інформація

Отже, припустимо, що система 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 усі сервисы, доступ до яких не потрібно ззовні.



Висновок.