Вступ

Дана стаття присвячена протоколу SNMP (Simple Network Management Protocol) –
одному з протоколів моделі OSI, який практично не було порушено у
документації просторів RU-нету. Автор спробував заповнити цей вакуум,
надавши читачеві грунт для роздумів і самовдосконалення, щодо
цього, можливо нового для Вас, питання. Цей документ не претендує на звання
"Документації для розробника", а просто відображає бажання автора, наскільки це
можливо, висвітлити аспекти роботи з даним протоколом, показати його слабкі
місця, уразливості в системі "security", цілі переслідували творці і
пояснити його призначення.

Призначення


Протокол SNMP був розроблений з метою перевірки функціонування мережевих
маршрутизаторів і мостів. Згодом сфера дії протоколу охопила і
інші мережеві пристрої, такі як хаби, шлюзи, термінальні сервери, LAN
Manager сервера, машини під управлінням Windows NT і т.д. Крім того, протокол
допускає можливість внесення змін у функціонування зазначених пристроїв.

Теорія


Основними взаємодіючими особами протоколу є агенти і системи
управління. Якщо розглядати ці два поняття мовою "клієнт-сервер", то роль
сервера виконують агенти, тобто ті самі пристрої, для опитування стану
яких і був розроблений розглянутий нами протокол. Відповідно, роль
клієнтів відводиться системам управління – мережним додаткам, необхідним для
збору інформації про функціонування агентів. Крім цих двох суб'єктів в моделі
протоколу можна виділити також ще два: керуючу інформацію і сам протокол
обміну даними.

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

Крім сказаного вище розглянутий протокол володіє ще однією вельми
важливою особливістю, а саме можливістю модифікувати дані на агентах.
Безумовно, було б дурістю дозволити модифікацію абсолютно будь-якого параметра,
але, не дивлячись на це, і кількість тих параметрів, для яких допускається
операція запису просто лякає. З першого погляду це повністю спростовує всю
теорію мережевої безпеки, але, якщо заглибитися в питання, то стає ясно,
що не все так запущено, як здається з першого погляду. "Вовків боятися – в ліс
не ходити ". Адже при невеликих зусиллях адміністратора мережі можна звести ризик
успішного завершення атаки до мінімуму. Але цей аспект ми обговоримо пізніше.

Зупинимося на тому, яку ж все-таки інформацію може почерпнути система
управління з надр SNMP. Вся інформація про об'єкти системи-агента потримається в
так званої MIB (management information base) – базі керуючої інформації,
іншими словами MIB являє собою сукупність об'єктів, доступних для
операцій запису-читання для кожного конкретного клієнта, в залежності від
структури та призначення самого клієнта. Адже не має сенсу питати у
термінального сервера кількість відкинутих пакетів, так як ці дані не
мають ніякого відношення до його роботи, так як і інформація про адміністратора
для маршрутизатора. Тому керуюча система повинна точно уявляти собі,
що і в кого запитувати. На даний момент існує чотири бази MIB:


  1. Internet MIB – база даних об'єктів для забезпечення діагностики помилок і
    конфігурацій. Включає в себе 171 об'єкт (в тому числі і об'єкти MIB I).
  2. LAN manager MIB – база з 90 об'єктів – паролі, сесії, користувачі, загальні
    ресурси.
  3. WINS MIB – база об'єктів, необхідних для функціонування WINS сервера
    (WINSMIB.DLL).
  4. DHCP MIB – база об'єктів, необхідних для функціонування DHCP сервера
    (DHCPMIB.DLL), службовця для динамічного виділення IP адрес в
    мережі.

Всі імена MIB мають ієрархічну структуру. Існує десять кореневих
аліасів: 1) System – дана група MIB II містить у собі сім об'єктів, кожен
з яких служить для зберігання інформації про систему (версія ОС, час роботи і
т.д.). 2) Interfaces – містить 23 об'єкти, необхідних для ведення статистики
мережевих інтерфейсів агентів (кількість інтерфейсів, розмір MTU, швидкість
передачі, фізичні адреси і т.д.). 3) AT (3 об'єкти) – відповідають за
трансляцію адрес. Більш не використовується. Була включена в MIB I. Прикладом
використання об'єктів AT може послужити проста ARP таблиця (більш докладно про
ARP протоколі можна почитати в статті "Нестандартне використання протоколу
ARP ", яку можна знайти на сайті http://www.uinc.ru
в розділі "Articles") відповідності фізичних (MAC) адрес мережевих карт IP
адресами машин. У SNMP v2 ця інформація була перенесена в MIB для
відповідних протоколів. 4) IP (42 об'єкти) – дані про що проходять IP пакетах
(Кількість запитів, відповідей, відкинутих пакетів). 5) ICMP (26 об'єктів) –
інформація про контрольні повідомленнях (вхідні та вихідні повідомлення, помилки і
т.д.). 6) TCP (19) – все, що стосується однойменного транспортного протоколу
(Алгоритми, константи, з'єднання, відкриті порти тощо). 7) UDP (6) –
аналогічно, тільки для UDP протоколу (вхідні / вихідні датаграми, порти,
помилки). 8) EGP (20) – дані про трафік Exterior Gateway Protocol (використовується
маршрутизаторами, об'єкти зберігають інформацію про прийняті / відісланих / відкинутих
кардіо). 9) Transmission – зарезервована для специфічних MIB. 10) SNMP (29)
– Статистика по SNMP – вхідні / вихідні пакети, обмеження пакетів по
розміром, помилки, дані про оброблених запитах і багато іншого.

Кожен з них представимо у вигляді дерева, що росте вниз, (система до болю
нагадує організацію DNS). Наприклад, до адреси адміністратора ми можемо
звернутися за допомогою такого шляху: system.sysContact.0, до часу роботи
системи system.sysUpTime.0, до опису системи (версія, ядро і інша
інформація про ОС): system.sysDescr.0. З іншого боку ті ж дані можуть
задаватися і в точковій нотації. Так system.sysUpTime.0 відповідає значення
1.3.0, так як system має індекс "1" в групах MIB II, а sysUpTime – 3 у
ієрархії групи system. Нуль в кінці шляху говорить про скалярному типі збережених
даних. Посилання на повний список (256 об'єктів MIB II) Ви можете знайти в кінці
статті в розділі "Додаток". У процесі роботи символьні імена об'єктів не
використовуються, тобто якщо менеджер запитує у агента вміст параметра
system.sysDescr.0, то в рядку запиту посилання на об'єкт буде перетворена в
"1.1.0", а не буде передана "як є". Далі ми розглянемо BULK-запит і тоді
стане ясно, чому це так важливо. На цьому ми завершимо огляд структури MIB II
і перейдемо безпосередньо до опису взаємодії менеджерів (систем
управління) і агентів.

У SNMP клієнт взаємодіє із сервером за принципом запит-відповідь. Сам по
собі агент здатний ініціювати тільки воно дію, зване пасткою
перериванням (у деякій літературі "trap" – пастка). Крім цього, всі
дії агентів зводяться до відповідей на запити, які посилає менеджерами.
Менеджери ж мають набагато більший "простір для творчості", вони в стані
здійснювати чотири види запитів:


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


Крім цього менеждера можуть обмінюватися один з одним інформацією про свою
локальної MIB. Такий тип запитів носить назву InformRequest.

Наведу значення числових констант для всіх видів запитів:

#define SNMP_MSG_GET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x0)
#define SNMP_MSG_GETNEXT (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x1)
#define SNMP_MSG_RESPONSE (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x2)
#define SNMP_MSG_SET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x3)
/ * PDU для SNMPv1 * /
#define SNMP_MSG_TRAP (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x4)
/ * PDU для SNMPv2 * /
#define SNMP_MSG_GETBULK (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x5)
#define SNMP_MSG_INFORM (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x6)
#define SNMP_MSG_TRAP2 (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x7)

Ось тут то ми стикаємося з ще однією цікавою деталлю, як бачите для
пастці є 2 числові константи. Насправді існує 2 основні версії
протоколу SNMP (v1 & v2) і найважливіше те, що вони не є сумісними
(Насправді версій значно більше-SNMP v2 {p | c | u} etc, тільки всі ці
модифікації досить незначні, оскільки, наприклад, введення підтримки md5 і
тощо).

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

Але це не означає, що ніякий інший протокол не може переносити пакети
SNMP. Таким може бути IPX протокол (наприклад, в мережах NetWare), також у вигляді
транспорту можуть виступати кард Ethernet, осередки ATM. Відмінною
особливістю розглянутого протоколу є те, що передача даних
здійснюється без встановлення з'єднання.

Припустимо менеджер послав кілька пакетів різних агентам, як же системі
управління в подальшому визначити, який із приходять пакетів стосується перших і
Другий агента? Для цього кожному пакету приписується певний ID – числове
значення. Коли агент отримує запит від менеджера, він генерує відповідь і
вставляє в пакет значення ID, отримане ним із запиту (не змінюючи його).
Одним з ключових понять в SNMP є поняття group (група). Процедура
авторизації менеджера являє собою просту перевірку на приналежність його
до певної групи, зі списку, що знаходиться у агента. Якщо агент не знаходить
групи менеджера в своєму списку, їх подальшу взаємодію неможливо. До
цього ми кілька разів стикалися з першою і другою версією SNMP. Звернемо
увагу на відмінність між ними.

Насамперед зауважимо, що в SNMP v2 включена підтримка шифрування трафіку,
для чого, залежно від реалізації, використовуються алгоритми DES, MD5.

Це веде до того що при передачі даних найбільш важливі дані недоступні
для вилучення сніффінгом, в тому числі й інформація про групи мережі. Все це
привело в збільшенню самого трафіку і ускладнення структури пакета. Сам по собі,
на даний момент, v2 практично ніде не використовується. Машини під управлінням
Windows NT використовують SNMP v1. Таким чином ми повільно переходимо до, мабуть,
самої цікавої частини статті, а саме до проблем Security. Про це давайте і
поговоримо …

Практика і безпеку


У наш час питання мережевої безпеки набувають особливого значення,
особливо коли мова йде про протоколи передачі даних, тим більше в корпоративних
мережах. Навіть після поверхневого знайомства з SNMP v1/v2 стає зрозуміло, що
розробники протоколу думали про це в останню чергу або ж їх жорстко
підтискали терміни здачі проекту% -).

Створюється враження що протокол розрахований на роботу в середовищі так званих
"Довірених хостів". Уявимо собі якусь віртуальну особистість. Людини,
точніше якийсь IP адреса, володар якого має намір отримати вигоду,
або ж просто насолити адміністратору шляхом порушення роботи якоїсь мережі. Станемо
на місце цієї особи. Розгляд цього питання зведемо до двох пунктів:

a) ми знаходимося поза "ворожої мережі". Яким же чином ми можемо зробити
свою чорну справу? У першу чергу припускаємо що ми знаємо адресу шлюзу мережі.
Згідно RFC, з'єднання системи управління з агентом відбувається по сто шістьдесят першому
порту (UDP). Згадаємо про те що для вдалої роботи необхідне знання групи. Тут
зловмисникові на допомогу приходить те, що часто адміністратори залишають
значення (імена) груп, виставлені за замовчуванням, а за умовчанням для SNMP
існує дві групи – "private" і "public". У випадку якщо адміністратор не
передбачив подібного розвитку подій, недоброзичливець може доставити йому
масу неприємностей. Як відомо, SNMP протокол є частиною
FingerPrintering. При бажанні, завдяки групі system MIB II, є можливість
дізнатися досить великий обсяг інформації про систему. Чого хоча б коштує read-only
параметр sysDescr. Адже знаючи точно версію програмного забезпечення, є шанс,
використовуючи засоби для відповідної ОС отримати повний контроль над системою.
Я не даремно згадав атрибут read-only цього параметра. Адже не порившись в
исходниках snmpd (у разі UNIX подібної ОС), цей параметр змінити не можна, то
є агент сумлінно видасть зловмисникові всі необхідні для нього дані.
Але ж не треба забувати про те, що реалізації агентів під Windows постачаються
без вихідних кодів, а знання операційної системи – 50% успіху атаки. Крім
того, згадаємо про те, що безліч параметрів мають атрибут rw (read-write), і
серед таких параметрів – форвардинг! Уявіть собі наслідки встановлення його
в режим "notForwarding (2)". Наприклад в Linux реалізації ПО для SNMP під
назва ucd-snmp є можливість віддаленого запуску скриптів на сервера, шляхом
посилки відповідного запиту. Думаю, всім зрозуміло до чого можуть призвести
"Недоробки адміністратора".

б) зловмисник знаходиться на локальній машині. У такому випадку ймовірність
звільнення адміна різко зростає. Адже знаходження в одному сегменті мережі дає
можливість простим сніффінгом відловити назви груп, а з ними і безліч
системної інформації. Цього випадку також стосується все сказане в пункті (а).

Перейдемо до "практичних занять". Що ж може на знадобитися. У першу
чергу програмне забезпечення. Його можна дістати на http://net-snmp.sourceforge.net
. Приклади я буду наводити для ОС Лінукс, але синтаксис команд аналогічний Windows
ПЗ.

Установка пакета стандартна:

gunzip udc-snmp-3.5.3.tar.gz
tar -xvf udc-snmp-3.5.3.tar
cd udc-snmp-3.5.3
./configure
make
make install

Запуск демона (агента)

snmpd

Після інсталяції Вам доступні програми:

snmpget
snmpset
snmpgetnext
snmpwalk
snmpbulkwalk
snmpcheck
snmptest
snmpdelta
snmpnetstat
snmpstatus
snmptable
snmptrap
snmptranstat
і демон
snmptrapd

Подивимося, як виглядають описані вище операції на практиці. Запит
GetRequest реалізує однойменна програма snmpget Для отримання необхідної
інформації виконаємо наступну команду:

root@darkstar:~# snmpget 10.0.0.2 public system.sysDescr.0

На що сервер сумлінно повідомить нам:

system.sysDescr.0 = Hardware: x86 Family 6 Model 5 Stepping 0
AT/AT COMPATIBLE – Software: Windows NT Version 4.0
(Build Number: 1381 Uniprocessor Free )

(Чи не так – досить змістовно), або ж

system.sysDescr.0 = Linux darkstar 2.4.5
#1 SMP Fri Aug 17 09:42:17 EEST 2001 i586

Прямо-таки – керівництво по проникненню. Припустимо, ми хочемо щось
змінити в налаштуваннях агента. Проробимо наступну операцію:

root @ darkstar: ~ # snmpset 10.0.0.2 public system.sysContact.0 s test@test.com

і отримаємо відповідь:

system.sysContact.0 = test@test.com


Список об'єктів MIB II з атрибутами можна знайти пішовши по посиланню, зазначеної в
"Додатку". Думаю, настав час розглянути SNMP на пакетному рівні.



Цей пакет був виловлені сніффером NetXRay на мережевому інтерфейсі агента. Як
бачимо – практика не далека від теорії. Спостерігаємо Request ID і параметри запиту.

На повному скріншоті можна побачити стек протоколів – від кадрів
Ethernet, через UDP доходимо до Simple Network Management Protocol. А
цей
пакет був отриманий з інтерфейсу менеджера. Як бачите, назва групи
абсолютно ніяк не шифрується (про що в свою чергу говорить Protocol version
number : 1
). Хочеться відзначити, що згідно специфікації протоколу, пакети
SNMP не мають чітко визначеної довжини. Існує обмеження зверху рівне
довжині UDP повідомлення, рівне 65507 байт, в свою чергу сам пртокол накладає
інше максимальне значення – лише 484 байта. У свою чергу не має
встановленого значення і довжина заголовка пакета (headerLength).


Ну ось ми у загальних рисах і ознайомилися з протоколом SNMP. Що ще можна
додати до сказаного вище … Можна лише дати кілька порад мережевим
адміністраторам, щоб зменшити ризик виникнення пролом з безпекою
мережі … У першу чергу належну увагу варто приділити настроюванню файрволінга.
По-друге – змінити встановлені по замовчуванню імена груп. Розумним було б
жорстко зафіксувати адреси машин (менеджерів), з яких дозволяється опитування
агентів.

На цьому, вважаю, статтю можна і закінчити. Хочеться вірити, що вона здалася
Вам цікавою.

Додаток


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*