LU.NET.UA - Захист інформації в інтернеті

:: Меню ::

Головна
Введення

Частина I.
Вивчення мети

1. Попередній збір даних
2. Сканування
3. Інвентаризація

Частина II.
Уразливість систем

4. Уразливість Windows 95/98/me
5. Уразливість Windows NT
6. Уразливість Windows 2000

Частина III.
Уразливість мереж

9. Уразливість видалених з'єднань, РВХ, Voicemail і віртуальних приватних мереж
10. Мережеві пристрої
11. Брандмауери
12. Атаки DOS

   Частина IV.
Уразливість програмного забезпечення

13. Вади засобів видаленого управління
14. Розширені методи
15. Уразливість в Web
16. Атаки на користувачів Internet
 Братани
Карта сайту
Добавити у вибране

:: Друзі ::

--

:: Статистика ::

 

 

 

 

 


Активне дослідження стека

Перш ніж перейти до розгляду можливостей утиліт nmap і queso, необхідно коротко пояснити, в чому ж полягає суть дослідження стека Tcp/ip. Дослідження стека (stack fingerprinting) — це дуже могутня технологія, що дозволяє швидко визначити тип і версію операційної системи вузла з високим ступенем вірогідності. Очевидно, що різні розробники по-різному підходять до реалізації стека Tcp/ip. Зокрема, багато розробників по-своєму трактують рекомендації документів RFC, що згодом виявляється в логіці роботи тих або інших мережевих служб. Таким чином, знаючи про існуючі відмінності і перевіривши реакцію служб системи, що вивчається, на різні ситуації, можна практично однозначно визначити тип і версію відповідної операційної системи. Для досягнення максимальної достовірності при дослідженні стека потрібний принаймні один порт, що знаходиться в режимі очікування запитів. За допомогою утиліти nmap можна висунути припущення про використовувану операційну систему навіть за відсутності таких портів, проте міра його достовірності в цьому випадку буде невисокою. Повний опис процесу дослідження стека можна знайти в статті Федора (Fyodor), що вперше публікується в журналі Phrack Magazine.
Нижче приведений перелік тестів, які можна використовувати в процесі дослідження стека для визначення типу і версії операційної системи.

  •  Передача пакетів FIN (FIN probe). Пакет FIN відсилається у відкритий порт. Як уже згадувалося, згідно документу RFC 793 досліджувана система не повинна відповідати на таке повідомлення. Проте багато реалізацій стека (наприклад, Windows NT) відповідають на них, відправляючи пакет Fin/ack.
  •  Спроба установки прапорів (bogus flag probe). Відсилається пакет SYN зі встановленим прапором в заголовку TCP, значення якого не визначене специфікацією протоколу. Деякі операційні системи, наприклад Linux, в у відповідь пакеті встановлюють цей же прапор.
  •  Вивчення початкової послідовності (Initial Sequence Number (ISN) sampling). Основне завдання цього тесту — спробувати визначити характерні ознаки початкової послідовності, що генерується вузлом при отриманні запиту на установку з'єднання, які характерні для тієї або іншої реалізації TCP.
  •  Моніторинг біта фрагментації ("don't fragment bit" monitoring). Цей біт встановлюється деякими операційними системами для підвищення продуктивності. Перевірка даного біта може допомогти у визначенні типу операційної системи, для якої характерна така поведінка.
  •  Початковий розмір вікна TCP (TCP initial window size). Для деяких реалізацій стека протоколів Tcp/ip даний параметр унікальний, що сприяє точності визначення типу операційної системи.
  •  Значення АСЬК (дек value). У різних реалізаціях стека IP по-різному задається значення поля АСЬК. У одних випадках повертається отриманий від вас номер послідовності, а в інших — значення номера послідовності, збільшене на 1.
  •  Обробка повідомлень про помилки ICMP (ICMP error message quenching). Деякі операційні системи слідують рекомендаціям документа RFC 1812 (www. ietf.org/rfc/rfcl812.txt) і обмежують швидкість передачі повідомлень про помилки. Тому, відправляючи UDP-пакеты на який-небудь порт (зазвичай з великим номером), цілком реально зміряти кількість повідомлень про помилки, що поступила за певний період, і визначити таким чином тип операційної системи.
  •  Вимірювання довжини повідомлень ICMP (ICMP message quoting). При виникненні помилок ICMP різними операційними системами передаються повідомлення різної довжини. Проаналізувавши отримане повідомлення, можна зробити деякі припущення про досліджувану операційну систему.
  •  Перевірка цілісності у відповідь повідомлень про помилки ICMP (ICMP error message-echoing integrity). У деяких реалізаціях стека використовується зміна заголовка IP при поверненні повідомлень про помилки ICMP. Перевіривши тип змін, внесених до заголовка, можна зробити деякі припущення про операційну систему досліджуваного вузла.
  •  Тип служби (TOS — type of service). Можна перевіряти поле TOS для повідомлень "ICMP port unreachable" (порт недоступний). У більшості реалізацій це поле має значення 0, проте іноді використовуються і інші значення.
  •  Обробка фрагментації (fragmentation handling). Як відзначають Томас Пташек (Thomas Ptacek) і Тім Ньюсхам (Tim Newsham) в своїй відомій статті Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection (http://www. clark.net/~roesch/idspaper.html), різні стеки обробляють повідомлення, що перекриваються, по-різному. При збірці фрагментірованньк пакетів деякі стеки записують нові дані поверх старих і навпаки. Перевіривши, яким чином були зібрані тестові пакети, можна зробити припущення про досліджувану операційну систему.
  •  Параметри TCP (TCP options). Параметри TCP визначені в документі RFC 793 і недавно виданому RFC 1323 (www.ietf.org/rfc/rfcl323.txt). Нововведення, описані в RFC 1323, знайшли віддзеркалення тільки в найостанніших реалізаціях стеків. Відправляючи пакет з набором різних параметрів, таких як по operation, maximum segment size, window scale factor, timestamp і так далі, можна зробити вивід про тип і версію операційної системи.
Для того, щоб скористатися утилітою nmap і виконати всі перераховані тести (за винятком обробки фрагментації і обробки повідомлень про помилки ICMP), досить вказати в командному рядку параметр -о. Давайте подивимося, як виглядатиме отриманий результат.

[tsunami] nmap -0192.168.1.10
Starting nmap V. 2.53 by fyodor@insecure.org
Interesting ports on shadow (192.168.1.10) :
Port State Protocol Service
7 open tcp echo
9 open tcp discard
13 open tcp daytime
19 open tcp chargen
21 open tcp ftp
22 open tcp ssh
23 open tcp telnet
25 open tcp smtp
37 open tcp time
111 open tcp sunrpc
512 open tcp exec
513 open tcp login
514 open tcp shell
2049 open tcp nfs
4045 open tcp lockd
TCP Sequence Prediction: Class=randorn positive increments
Difficulty=26590 (Worthy challenge)
Remote operating system guess: Solaris 2.5, 2.51

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

[ tsunami]# nmap -p80 -0 10.10.10.10
Starting nmap V. 2.53 by fyodor@insecure.org
Warning: No ports found open on this machine
OS detection will be
MUCH less reliable
No ports open for host (10.10.10.10)
Remote OS guesses: Linux 2.0.27 - 2.0.30, Linux 2.0.32-34
Linux 2.0.35-36, Linux 2.1.24 POWERPC
Linux 2.1.76, Linux 2.1.91 - 2.1.103
Linux 2.1.122 - 2.1.132; 2.2.0-prel - 2.2.2, Linux 2.2.0-pre6 - 2.2.2-ac5
Nmap run completed -- 1 IP
address (1 host up) scanned in 1 second

Як видно з приведеного лістингу, утиліта nmap навіть без відкритих портів, правильно визначила операційну систему Linux.
Однією з примітних особливостей утиліти nmap є те, що лістинг сигнатур зберігається в окремому файлі з ім'ям nmap-os-fingerprints. При появі кожної нової версії утиліти цей файл також оновлюється, і на момент написання даної книги в нім містилися сотні сигнатур. Якщо ви хочете додати нові сигнатури і підвищити таким чином ефективність утиліти nmap, звернетеся ЗА адресою http://www.insecure.org:80/cgi-bin/nmap-submit.cgi.
Хоча на момент написання даної книги утиліта nmap, мабуть, дозволяє найточніше виконати дослідження стека Tcp/ip, вона, проте, є далеко не першою програмою, в якій реалізована відповідна технологія. До того як Федір вбудував в утиліту nmap засоби визначення операційної системи, для цих же цілей вже була створена утиліта queso (http://www.apostols.org/projectz/ ). Необхідно відзначити, що утиліта queso не дозволяє виконувати сканування портів і може визначати тип операційної системи тільки в досліджуваній системі відкритого порту (за умовчанням використовується порт 80). Якщо порт 80 закритий, необхідно задати інший відкритий порт, як показано в наступному прикладі, в якому за допомогою утиліти queso здійснюється спроба визначити тип операційної системи через порт 25. 

[tsunami] queso 10.10.10.20:25
10.10.10.20:25 * Windoze 95/98/nt

Контрзаходи: захист від визначення операційної системи


Виявлення спроб визначення операційної системи


Багато із згадуваних вище засобів виявлення сканування з успіхом можуть служити і для виявлення спроб визначення типу операційної системи, Хоча вони не проінформують вас про те, що виконувалося спеціальне сканування за допомогою утиліти nmap або queso, з їх допомогою все ж таки вдасться розпізнати сам факт такого особливого сканування, наприклад з установкою прапора SYN.

Попередження спроб визначення операційної системи


Хотілося б порадити який-небудь засіб, що дозволяє протидіяти спробам визначення операційної системи, проте, на жаль, вимушені констатувати, що вирішити цю проблему вельми непросто. Звичайно, можна змінити початковий код операційної системи (природно, якщо він є у вашому розпорядженні) або поміняти її параметри, що впливають на характеристики стека, проте таке втручання може значно змінити функціональність ОС. Наприклад, в системі FREEBSD 4.x є параметр ядра Tcp_drop_synfin, який можна застосувати для ігнорування пакетів Syn+fin, використовуваних утилітою nmap в цілях дослідження стека. Установка цього параметра допоможе присікти спроби визначення типу операційної системи, проте в той же час порушить підтримку RFC 1644 (TCP Extensions for Transactions).
Замість цього ми пропонуємо створювати такі мережі, в яких скануванню могли б піддатися лише надійні і добре захищені proxy-серверы і брандмауери, а не комп'ютери внутрішньої мережі. В цьому випадку, навіть якщо зломщикові і вдасться розвідати тип операційної системи того або іншого вузла, проникнення через пристрої захисту буде значно утруднено.

Пасивне визначення операційної системи


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




:: Реклама ::

>Страница статей


:: Посилання ::

-


:: Рекомендуємо ::

-


 

 

 

 


Copyright © Klab-F 2008