Моніторинг і аналіз мережевої інфраструктури

GET-request

0

Набути значення вказаної змінної або інформацію про стан мережевого елементу

GET_next_request

1

Набути значення змінної, не знаючи точного її імені (наступний логічний ідентифікатор на дереві MIB)

Команда snmp

Тип pdu

Призначення

SET-request

2

Привласнити змінній відповідне значення. Використовується для опису дії, яка має бути виконане

GET response

3

Відгук на Get-request, Get_next_request і Set-request. Містить також інформацію про стан (коди помилок і інші дані)

TRAP

4

Відгук мережевого об'єкту на подію або на зміну стану

GetBulkRequest

5

Запит пересилки великих об'ємів даних, наприклад, таблиць

InformRequest

6

Менеджер звертає увагу партнера на певну інформацію в MIB

SNMPv3-Trap

7

Відгук на подію (розширення по відношенню v1 і v2)

Report

8

Звіт (функція доки не задана)

Рис. 3.4. Схема команд SNMP

Формат SNMP-повідомлень, що вкладаються в UDP-дейтограмми, має вигляд (рис. 3.5):

SNMP - заголовок Get/set - заголовок Змінні для get/set

Версія 0	Пароль Community	Тип PDU 0-3	Ідентифіктор запиту	Статус помилки (0-5)	Індекс помилки	Ім'я	Значення	***
Тип PDU 4	Фірма	Адреса об'єкта	Тип Trap 0-7	Спец. код	Мітка часу	Ім'я	Значення	***

TRAP - заголовок Потрібні змінні

Рис. 3.5. Формат SNMP-повідомлень, що вкладаються в UDP-дейтограмми

Поле версія містить значення, рівне номеру версії SNMP мінус один. Поле пароль (community - визначає групу доступу) містить послідовність символів, яка є перепусткою при взаємодії менеджера і об'єкта управління. Зазвичай це поле містить 6-байтове рядок public, що означає загальнодоступність. Для запитів GET, GET-next і SET значення ідентифікатора запиту встановлюється менеджером і повертається об'єктом управління у відгуку GET, що дозволяє зв'язувати в пари запити і відгуки. Поле фірма (enterprise) = sysobjectid об'єкта. Поле статус помилки характеризується цілим числом, надісланим об'єктом управління, табл.3.4, 3.5:

Номери та призначення використовуваних портів

Таблиця 3.4.

Призначення	Порт	Пояснення
SNMP	161/TCP	Simple Network Management Protocol
SNMP	162/TCP	Trap
SMUX	199/TCP	SNMP Unix Multiplexer
SMUX	199/UDP	SNMP Unix Multiplexer
synoptics-relay	391/TCP	SynOptics SNMP Relay Port
synoptics-relay	391/UDP	SynOptics SNMP Relay Port
Agentx	705/TCP	AgentX
snmp-tcp-port	1993/TCP	cisco SNMP TCP port
snmp-tcp-port	1993/UDP	cisco SNMP TCP port

Коди помилок

Таблица 3.5.

Статус помилки	Ім'я помилки	Опис
0	Noerror	Все гаразд;
1	Toobig	Об'єкт не може укласти відгук в одне повідомлення;
2	Nosuchname	У операції вказана невідома змінна;
3	badvalue	У команді set використана недопустима величина або неправильний синтаксис;
4	Readonly	Менеджер спробував змінити константу;
5	Generr	Інші помилки.

Якщо сталася помилка, поле індекс помилки (error index) характеризує, до якої з змінних це відноситься. error index є покажчиком змінної і встановлюється об'єктом управління не рівним нулю для помилок badvalue, readonly і nosuchname. Для оператора TRAP (тип PDU = 4) формат повідомлення змінюється. Типи TRAP представлені ??нижче в таблиці 3.6:

Коди TRAP

Таблиця 3.6.

Тип trap	Ім'я trap	Опис
0	Coldstart	Установка початкового стану об'єкту.
1	Warmstart	Відновлення початкового стану об'єкту.
2	Linkdown	Інтерфейс вимкнувся. Перша змінна в повідомленні ідентифікує інтерфейс.
3	Linkup	Інтерфейс включився. Перша змінна в повідомленні ідентифікує інтерфейс.
4	Authenticationfailure	Від менеджера отримано snmp-повідомлення з невірним паролем (community).
5	EGPneighborloss	R$gp-партнер відключився. Перша змінна в повідомленні визначає ip-адресу партнера.
6	Entrprisespecific	Інформація про TRAP міститься в полі спеціальний код.

Для тип TRAP 0-4 поле спеціальний код має дорівнювати нулю. Поле тимчасова мітка містить число сотих часток секунди (число тиків) з моменту ініціалізації об'єкта управління. Так переривання coldstart видається об'єктом через 200 мс після ініціалізації.

Останнім часом широкого поширення набула ідеологія розподіленого протокольного інтерфейсу DPI (Distributed протоколу Interface). Для транспортування SNMP-запросов може використовуватися не тільки UDP-, але і TCP-протокол. Це дає можливість застосовувати SNMP-протокол не тільки в локальних мережах. Формати SNMP-DPI-запитів (версія 2.0) описані в документі RFC-1592. Приклад заголовка SNMP-запиту, зображені поля утворюють єдиний масив, рис.3.6).

1	2	3	4	5	6	7	8	8+6	15	Номер байта
Флаг	L1	T1	L2	Версія	T2	L2	Public	0xA	PDU
0х30		02	1	0 L2	04	6	L3		Типове значення
16	17	18	19	…….					Номер байта
L1	T3	Lіз	Ідентифікатор запиту	T4	L5	C0	T5	L6	I0
			Lіз	2 0 Статус помилки	2 Індекс помилки
									L6
					L4
Флаг	L7	Флаг	L8	06	TM	Цифровий код MIB - змінної	05	00
0x30		0x30		2B		L9
						L8
						L7

Рис.3.6. Формат заголовку SNMP-запиту

Поле Флаг = 0x30 є ознакою ASN.1-заголовка. Коди Ln - представляють собою довжини полів, що починаються з байта, який слідує за кодом довжини, аж до кінця повідомлення-запиту (п - номер поля довжини), якщо не обумовлено інше. Так L1 - довжина пакета-запиту, починаючи з T1 і до кінця пакету, а L3 - довжина поля пароля. Субполя Tn - поля типу наступного за ними субполя запиту. Так T1 = 2 означає, що поле характеризується цілим числом, а T2 = 4 вказує на те, що далі слідує пароль (поле спільноти, у наведеному прикладі = громадськості). Цифри під малюнками означають типові значення субполя. Код 0xA - (.. = 0-4, див. табл.. 3.3) є ознакою GET-запиту, за ним слідує поле коду PDU.

Блок субполя ідентифікатора запиту служить для тих же цілей, що й інші ідентифікатори - для визначення пари запит-відгук. Власне ідентифікатор запиту може займати один або два байти, що визначається значенням Lіз. СО - статус помилки (СО = 0 - помилки немає); ТМ - тип MIB-змінної (у наведеному прикладі = 0x2b); ІВ - індекс помилки. Цифровий код MIB-змінної відображається послідовністю цифрових субполя, що характеризують змінну, наприклад: мінлива 1.3.6.1.2.1.5 (в символьному вираженні iso.org.dod.internet.mgmt.mib.icmp) характеризується послідовністю кодів 0x2b 0x06 0x01 0x01 0x02 0x05 0x00.

Починаючи з січня 1998 року, випущений набір документів, присвячених SNMPv3. У цій версії істотно розширена функціональність, розроблена система безпеки.

У даній версії реалізована модель, що базується на процесорі SNMP (SNMP Engene) і містить кілька підсистем (диспетчер, система обробки повідомлень, безпеки та управління доступом, див. табл. 3.1).

Перераховані підсистеми служать основою функціонування генератора і обробника команд, відправника та обробника повідомлень та проксі-сервера (Proxy Forwarder), що працюють на прикладному рівні. Процесор SNMP ідентифікується з допомогою snmpEngineID, рис.3.7.

Забезпечення безпеки моделі роботи SNMP спрощується зазвичай тим, що обмін запитами-відгуками здійснюється в локальній мережі, а джерела запитів-відгуків легко ідентифікуються.

Рис.3.7. Архітектура суті SNMP (SNMP-entity)

Компоненти процесора SNMP перераховані в таблиці 3.7:

Компоненти процесора SNMP

Таблиця 3.7.

Назва компонента	Функція компонента
Диспетчер	Дозволяє одночасну підтримку декількох версій snmp-повідомлень в процесорі SNMP. Цей компонент відповідальний за прийом протокольних блоків даних (PDU), за передачу PDU підсистемі обробки повідомлень, за передачу і прийом мережевих SNMP -повідомлень
Підсистема обробки повідомлень	Відповідальна за підготовку повідомлень для відправки і за витягання даних з вхідних повідомлень
Підсистема безпеки	Надає послуги, що забезпечують безпеку: аутентифікацію і захищеність повідомлень від перехоплення і спотворення. Допускається реалізація декілька моджелей безпеці
Підсистема управління доступом	Надає ряд послуг авторизації, які можуть використовуватися додатками для перевірки прав доступу.
Генератор команд	Ініціює SNMP -запіті Get, Getnext, Getbulk або Set, призначені для локальної системи, які можуть використовуватися додатками для перевірки прав доступу.
Обробник команд	Сприймає snmp-запіті Get, Getnext, Getbulk або Set, призначені для локальної системи, це відображається тим, що contextengeneid в отриманому запиті дорівнює відповідному значенню в процесорі SNMP. Додаток обробника команд виконує відповідні протокольні операції, генерує повідомлення відгуку і посилає їх откправітелю запиту.
Відправник повідомлень	Моніторує систему на предмет виявлення певних подій або умов і генерує повідомлення Trap або Inform. Джерело повідомлень повинне мати механізм визначення адресата таких повідомлень, а також параметрів безпеки
Одержувач повідомлень	Прослухує повідомлення повідомлення і формує повідомлення-відгуки, коли приходить повідомлення з PDU Inform
Проксі-сервер	Переадресує SNMP -сообщенія. Реалізація цього модуля є опційною

На рис. 3.8 показаний формат повідомлень SNMPv3, який реалізує модель безпеки UBM (User-моделі на основі безпеки).



Зона аутентифікації		MsgVersion	Частина, що генерується і оброблювана моделлю обробки повідомлення
		msgID
		msgMaxSize
		msgSecurtyModel
		msgAuthritativeEngneID	Частина, що генерується і оброблювана моделлю безпеки користувача (USM)
		msgAuthritativeEngneBoots
		msgAuthritativeEngneTime
		msgUserName
		msgAuthenticationParameters
		msgPrivacyParameters
	Область шифрування	contextEngineID
		contextName
		PDU

Рис.3.8. Формат повідомлень SNMPv3 c UBM

Перші п'ять полів формуються відправником у рамках моделі обробки повідомлень і обробляються одержувачем. Наступні шість полів несуть в собі параметри безпеки. Далі слід PDU (блок поля даних) з contextEngeneID і contextName:

- msgVersion (для SNMPv3) = 3

- MsgID - унікальний ідентифікатор, використовуваний SNMP-сутностями для встановлення відповідності між запитом і відгуком. Значення MsgID лежить в діапазоні 0 - (231-1)

- msgMaxSize - визначає максимальний розмір повідомлення в октетах, підтримуваний відправником. Його значення лежить в діапазоні 484 - (231-1) і дорівнює максимальному розміру сегмента, який може сприйняти відправник.

- msgFlags - 1-октетное рядок, що містить три прапори в молодших бітах: reportableFlag, privFlag, authFlag. Якщо reportableFlag = 1, має бути надіслано повідомлення з PDU Report; коли прапор = 0, Report посилати не слід. Прапор reportableFlag = 1 встановлюється відправником у всіх повідомленнях запиту (Get, Set) або Inform. Прапор встановлюється рівним нулю у відгуках, повідомленнях або повідомленнях Пастка звіту. Прапори privFlag і authFlag встановлюються відправником для індикації рівня безпеки для даного повідомлення. Для privFlag = 1 використовується шифрування, а для authFlag = 0 - аутентифікація. Допустимі будь-які комбінації значень прапорів крім privFlag = 1 AND authFlag = 0 (шифрування бех аутентифікації).

- msgSecurityModel - ідентифікатор із значенням в діапазоні 0 - (231-1), який вказує на модель безпеки, використану при формуванні даного повідомлення. Зарезервовані значення 1 для SNMPv1, 2 і 3 - для SNMPv3.

Модель безпеки USM (User-моделі на основі безпеки) використовує концепцію авторизованого сервера (авторитетний Engene). При будь-якій передачі повідомлення одна або дві сутності, передавач або приймач, розглядаються в якості авторизованого SNMP-сервера. Це робиться згідно з такими правилами:

- Коли SNMP-повідомлення містить поле даних, яке передбачає відгук (наприклад, Get, GetNext, GetBulk, Set або Інформ), одержувач такого повідомлення вважається вповноваженим.

- Коли SNMP-повідомлення містить поле даних, яке не передбачає посилку відгуку (наприклад, SNMPv2-Trap, Response або Report), тоді відправник такого повідомлення вважається вповноваженим.

Таким чином, повідомлення, надіслані генератором команд, і повідомлення Інформ, послані відправником повідомлень, одержувач є авторизованим. Для повідомлень, посланих обробником команд або відправником повідомлень Пастка, відправник є авторизованим. Такий підхід має дві мети:

- Своєчасність повідомлення визначається з урахуванням показання годин авторизованого сервера. Коли авторизований сервер посилає повідомлення (Пастка, Response, Report), воно містить поточне показання годин, так що неавторизований одержувач може синхронізувати свої годинники. Коли неавторизований сервер посилає повідомлення (Get, GetNext, GetBulk, Set Інформ), він поміщає туди поточну оцінку показання годин місця призначення, дозволяючи одержувачеві оцінити своєчасність приходу повідомлення.

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

Коли вихідне повідомлення передається процесором повідомлень в USM, USM заповнює поля параметрів безпеки в заголовку повідомлення. Коли вхідний повідомлення передається обробником повідомлень в USM, обробляються значення параметрів безпеки, що містяться в заголоке повідомлення. У параметрах безпеки містяться:

- msgAuthoritativeEngeneID - snmpEngeneID авторизованого сервера, який бере участь в обміні. Таким чином, це значення ідентифікатора відправника для пастки, Response або доповіді або адресата для Get, GetNext, GetBulk, Set або Inform.

- msgAuthoritativeEngeneBoots - snmpEngeneBoots авторизованого сервера, який бере участь в обміні. Об'єкт snmpEngeneBoots є цілим у діапазоні 0 - (231-1). Цей код характеризує число раз, яке SNMP-сервер був перезавантажений з моменту конфігурування.

- msgAuthoritativeEngeneTime - nmpEngeneTime авторизованого сервера, який бере участь в обміні. Значення цього коду лежить в діапазоні 0 - (231-1). Цей код характеризує число секунд, яке пройшло з моменту останньої перезавантаження. Кожен авторизований сервер повинен інкрементіровать цей код один раз в секунду.

- msgUserName - ідентифікатор користувача від імені якого надіслано повідомлення.

- msgAuthenticationParameters - нуль, якщо при обміні не використовується аутентифікація. В іншому випадку - це аутентифікаційні параметр.

- msgPrivacyParameters - нуль - якщо не вимагається дотримання конфімденціальності. В іншому випадку - це параметр безпеки. У діючій моделі USM використовується алгоритм шифрування DES.

Механізм аутентифікації в SNMPv3 припускає, що отримане повідомлення дійсно послано принципалом, ідентифікатор якого міститься в заголовку повідомлення, і він не був модифікований по дорозі. Для реалізації аутентифікації кожен з принципалів, що беруть участь в обміні повинен мати секретний ключ аутентифікації, загальний для всіх учасників (визначається на фазі конфігурації системи). У посилається повідомлення відправник повинен включити код, який є функцією вмісту повідомлення і секретного ключа. Одним із принципів USM є Прверка своєчасності повідомлення (дивись вище), що робить малоймовірною атаку з використанням копій повідомлення.

Система конфігурування агентів дозволяє забезпечити різні рівні доступу до MIB для різних SNMP-менеджерів. Це робиться шляхом обмеження доступу деяким агантам до певних частин MIB, а також за допомогою обмеження переліку допустимих операцій для заданої частини MIB. Така схема управління доступом називається VACM (View-Based Access Control Model). У процесі управління доступом аналізується контекст (vacmContextTable), а також спеціалізовані таблиці vacmSecurityToGroupTable, vacmTreeFamilyTable і vacmAccessTable.

SNMP-протокол служить прикладом системи управління, де для досягнення потрібного результату видається не команда, а здійснюється обмін інформацією, рішення ж приймається "на місці" відповідно до отриманих даних.

Впроваджено подсістеми аутентифікації, інформаційної безпеки та управління доступом.

3.6. Структура SNMP MIB

Оброблюваний агентом список об'єктів і їх типів закладається в нього розробником, а станція управління отримує цю інформацію за допомогою MIB (Management Information Base). MIB - текстовий файл, що описує доступні об'єкти та їх типи мовою, визначеному стандартом SMI (структура та ідентифікація управління інформацією). Агент не використовує цей файл при роботі. MIB ділиться на модулі, деякі модулі приймаються у вигляді стандартів, деякі модулі створюються розробниками обладнання.

Розробник керованого устаткування (розробник агента) повинен надати список підтримуваних агентом модулів. При описі модуля вказується які об'єкти обов'язкові для реалізації, а які - ні. При описі агента можна вказувати які модулі він підтримує, в якому обсязі і з якими модифікаціями.

Ха сьогодні існує декілька стандартів на бази даних керуючої інформації для протоколу SNMP. Основними є стандарти MIB-I і MIB-II, а також версія бази даних для віддаленого управління RMON MIB.

Крім цього існують стандарти для спеціальних пристроїв MIB конкретного типу (наприклад, MIB для концентраторів або MIB для модемів), а також приватні MIB конкретних фірм-виробників устаткування.

Первісна специфікація MIB-I визначала лише операції читання значень змінних. Операції зміни або установки значень об'єкта є частиною специфікацій MIB-II.

База даних MIB-II не дає детальної статистики по характерних помилок кадрів Ethernet, крім цього, вона не відображає зміну характеристик у часі, що часто цікавить мережевого адміністратора.

Ці обмеження були зняті згодом новим стандартом на MIB - RMON MIB, який спеціально орієнтований на збір детальної статистики по протоколу Ethernet, до того ж з підтримкою такої важливої ??функції, як побудова агентом залежностей статистичних характеристик від часу.

3.7 Приклади пристрою протоколу SNMP

NetAgent - це нове покоління програмно-апаратного комплексу SNMP моніторингу (рис. 3.9). Цей комплекс дозволяє дистанційно керувати і ослежівать стан ДБЖ. Пристрій NetAgent II-3Ports крім переліченого, забезпечує зв'язок по модему для тих випадків коли немає постійного з'єднання з інтернетом, а також може також використовуватися для підключення до пристрою "NetFeeler Lite" для отримання даних про температуру і вологість, а також про спрацювання зовнішніх датчиків: диму, газу, відкриття дверей, встановлених в кімнаті з ДБЖ.

FCD-IP - пристрій доступу E1/T1 або Fractional E1/T1 з вбудованим маршрутизатором. FCD-IP - це пристрій доступу до послуг E1/T1 або Fractional E1/T1 з вбудованим маршрутизатором. Пристрій можна замовити з одним або двома портами ЛВС Ethernet, або з вбудованим 4-х портовим комутатором, який заміняє зовнішній хаб або комутатор. Tак само можлива поставка пристрої з додатковим портом даних, з портом подканалов E1/T1 з виділенням каналів, або з 4 аналоговими портами (FXS, FXO, E & M). Швидкість передачі через порт даних може бути обрана кратній 56 або 64 Кбіт / с аж до 1984 Кбіт / с.

FCD-IP поставляється з вбудованим LTU, вибираним програмними засобами, що забезпечує можливість безпосереднього з'єднання з мережею E1 або з'єднання за допомогою зовнішнього LTU. Вбудоване CSU / DSU дозволяє підключитися безпосередньо до мережі T1.

Вбудований маршрутизатор підтримує:

* IP / IPX-маршрутизацію і прозорий бриджинг Solid Firewall ™ (на сеансовий основі)

* Single IP і NAT

* захист PAP / CHAP

* OSPF, RIP-1, RIP-2

FCD-IP може також використовуватися як інтегруючого мультиплексора для передачі даних, трафіку ЛВС і Fractional E1/T1.

FCD-IP може працювати спільно з модульними багатофункціональними вузлами доступу DXC виробництва RAD в додатках для багатоканальної зіркоподібною конфігурації, включаючи доступ до мереж SDH. Управління пристроями DXC і FCD-IP здійснюється за допомогою централізованого мережевого менеджменту на базі SNMP.

Програмоване призначення тимчасових інтервалів дозволяє вводити в тимчасові інтервали послідовно або по черзі дані з портів ЛВС, подканала E1/T1, аналогових портів голосу і порту даних. FCD-IP забезпечує гнучкі можливості розподілу тимчасових інтервалів порту даних. Кожен часовий інтервал порту подканала E1/T1 поміщається на той же часовий інтервал головного каналу E1/T1.

Дані з порту даних можуть або поміщатися на тимчасові інтервали головного каналу в прозорому режимі, або разом з даними ЛВС направлятися через маршрутизатор.

Програми кільця і ??вставляння і виділення каналів

FCD-IP підтримує до 4 каналів Fractional E1 з автоматичним обходом в разі відмови лінії. Пристрій може використовуватися в топологіях "кільце" і "ланцюжок" разом з мультиплексором Megaplex для економічного підключення невеликих вузлів до кільця E1, при такому ж мінімальному часу самовідновлення каналів, як і у великих пристроїв.

Інтерфейс E1 відповідає всім вимогам рекомендацій ITU G.703, G.704, G.706 і G.732.

Інтерфейс T1 сумісний практично з усіма операторськими послугами T1.

Налаштування, управління і стеження, а також отримання діагностичної інформації здійснюються:

* з ASCII-терміналу, що підключається до асинхронного порту управління

* Telnet

* за допомогою мережевого SNMP менеджменту

* внутрішньосмугової по виділеному часового інтервалу

FCD-IP підтримує внутрішній агент SNMP, і управління ним може здійснюватися за допомогою стандартної керуючої станції з SNMP або за допомогою мережевого SNMP менеджменту RADview.

FCD-IP підтримує підключення ззовні по телефонній лінії для позасмугового віддаленого завдання конфігурації і безперервного контролю.Можливості технічного обслуговування включають запуск користувачем місцевих і віддалених перевірок по шлейфу.

Рис. 3.10. Розширення можливостей управління мережним устаткуванням на основі протоколу SNMP

http://www.netams.com/proj_mon.jp)

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

SNMP-агент - це пристрій, який видає інформацію, отриману від контрольованого обладнання за нестандартному протоколу у вигляді SNMP-повідомлень. Часто SNMP-агент реалізується на базі персонального комп'ютера із запущеним на ньому спеціальним програмним забезпеченням - службою SNMP. В цьому випадку з'являється можливість використання будь-якого з інтерфейсів ПК для роботи з контрольованим обладнанням. На минулих наукових сесіях МИФИ ми вже повідомляли про використання SNMP-агентів для управління комунікаційними пристроями за допомогою контролерів "сухих" контактів. Проте, в деяких випадках пристрій, яким необхідно дистанційно керувати, не має спеціальних сигналів, стан яких можна опитати за допомогою контролера "сухих" контактів, але часто вони дозволяють управляти ними за допомогою термінальних програм, що видають стан пристроїв в символьному вигляді. SNMP-агенти можуть працювати і з таким типом устаткування. Програмне забезпечення SNMP-агента виробляє періодичний опитування стану контрольованого обладнання за допомогою команд, що посилаються пристрою через послідовний порт ПК, вибираючи значення з певних полів відповіді. Типова структура такої мережі управління представлена ??на рис.3.11. На ньому наведені контрольовані пристрої, зв'язок з якими SNMP-агент здійснює через послідовний інтерфейс RS232, а також сам SNMP-агент і станція управління, які пов'язані з мережі, що підтримує протокол TCP / IP. У такій конфігурації системи виявляються раніше недоступні можливості управління. Наприклад, з'являється можливість дистанційної роботи з пристроями, підключеними до SNMP-агенту за допомогою термінальної програми, запущеної на комп'ютері в офісі телекомунікаційної компанії. Для цього використовується спеціальний драйвер послідовного порту, який передає всі відправлені на нього дані через мережевий інтерфейс ПК на комп'ютер з SNMP-агентом. На ньому спеціальне програмне забезпечення здійснює прийом даних та їх подальшу передачу через послідовний порт на контрольоване обладнання. Отриманий відповідь передається назад через мережевий інтерфейс на машину, послала дані, де приймається драйвером і відображається на екрані термінальної програми.

Рис. 3.11. Структура мережі управління

(http://www.kross-telecom.ru/katalog/polygon/servRS232)

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

Програмне забезпечення SNMP-агента реалізовано на базі операційної системи Linux (версії 6.0 і вище) і може бути з легкістю встановлено практично на будь-який IBM / PC сумісний персональний комп'ютер з ЦПУ 386SX, HDD 120Mb, RAM 8Mb і вище.

3.8 Недоліки протоколу SNMP

Протокол SNMP служить основою багатьох систем управління, хоча має кілька принципових недоліків, які перераховані нижче.

- Відсутність коштів взаємної аутентифікації агентів і менеджерів. Єдиним засобом, який можна було б віднести до засобів аутентифікації, є використання в повідомленнях так званої «рядка спільноти» - «рядка співтовариства». Цей рядок передається по мережі у відкритій формі в повідомленні SNMP і служить основою для поділу агентів і менеджерів на «спільноти», так що агент взаємодіє тільки з тими менеджерами, які вказують у поле Рядок спільноти ту ж символьну рядок, що й рядок, що зберігається в пам'яті агента. Це, безумовно, не спосіб аутентифікації, а спосіб структурування агентів і менеджерів. Версія SNMP v.2 повинна була ліквідувати цей недолік, але в результаті розбіжностей між розробниками стандарту нові засоби аутентифікації хоча і з'явилися в цій версії, але як необов'язкові.

- Робота через ненадійний протокол UDP (а саме так працює переважна більшість реалізацій агентів SNMP) призводить до втрат аварійних повідомлень (повідомлень пастку) від агентів до менеджерам, що може призвести до неякісного управління. Виправлення ситуації шляхом переходу на надійний транспортний протокол з встановленням сполук може призвести до втрати зв'язку з величезною кількістю вбудованих агентів SNMP, наявних у встановленому в мережах обладнанні. (Протокол CMIP спочатку працює поверх надійного транспорту стека OSI і цим недоліком не страждає.) Розробники платформ управління намагаються подолати ці недоліки. Наприклад, в платформі HP OV Телеком DM TMN, що є платформою для розробки багаторівневих систем управління відповідно до стандартів TMN і ISO, працює нова реалізація SNMP, організуюча надійний обмін повідомленнями між агентами і менеджерами за рахунок самостійної організації повторних передач повідомлень SNMP при їх втрати.

Висновки

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

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

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

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

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

Перелік посилань

1. Компьютерные сети и системы. Принципы, технологии, протоколы./В.Г. Олифер, Н.А. Олифер.- СПб.: Питер, 2001.- 672 с.:ил.

2. Новиков Ю.В., Кондратенко С.В.- Локальные сети: архитектура,алгоритмы, проектирование. М.: Издательство ЭКОМ, 2001.- 312 с.: илл.

3. Олифер Наталья - "Журнал сетевых решений LAN"(июнь 2001), Третья версия SNMP, стр.28.

4. Семенов Ю. А. Протокол управления SNMP, (ГНЦ ИТЭФ)

5. CITForum -- История создания SNMP

6. CITForum - Введение в SNMP

7. http://www.citforum.ru/internet/articles/art_11.shtml

8. http://www.citforum.ru/nets/lvs/glava_7.shtml

9. http://www.citforum.ru/nets/ito/32.shtml

10. http://home.kts.ru:8101/Dimkas/diplom.html

11. http://www.soslan.ru/tcp/tcp25.html

12. Internet Engineering Task Force

13. ITU Telecommunication Standardization Sector

14. International Organization for Standartization

15. SNMP протокол -- принципы, безопасность, применение.

Размещено на Allbest.ru