Необхідність захисту даних. Класифікація видалених атак на розподілені обчислювальні системи. Характеристика і механізми реалізації типових видалених атак. Принципи створення захищених систем зв'язку в розподілених обчислювальних системах, страница 22

Ø  Десинхронізація нульовими даними

В даному випадку крекер прослуховує сесію і в якийсь момент посилає серверу пакет з "нульовими" даними, тобто такими, які фактично будуть проігноровані на рівні прикладної програми і не видно клієнту (наприклад, для telnet це може бути дані типа IAC NOP IAC NOP IAC NOP...). Аналогічний пакет посилається клієнту. Очевидно, що після цього сесія переходить в десинхронізірованноє стан.

ACK-буря

Одна з проблем IP Hijacking полягає у тому, що будь-який пакет, висланий в мить, коли сесія знаходиться в десинхронізірованном стані викликає так званий ACK-бурю. Наприклад, пакет висланий сервером, і для клієнта він є непріємлімим, тому той відповідає ACK-пакетом. У відповідь на цей непріємлімий вже для серверу пакет клієнт знов одержує відповідь... І так до безкінечності.

На щастя (або на жаль?) сучасні мережі будуються за технологіями, коли допускається втрата окремих пакетів. Оскільки ACK-пакети не несуть даних, повторних передачі не відбувається і "буря стихає".

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

Детектування і захист

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

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

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

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

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

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

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

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

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

Метод не детектує попередніми способами, оскільки реальне TCP/IP-з‘єднання не встановлюється. Проте (залежно від поведінки крекера) можна відстежувати

Ø  різко збільшена кількість сесій, що знаходяться в стані SYN_RECEIVED. (за умови, що крекер не посилає у відповідь RST)