3.5. Безпека в snmpv3

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

Основні проблеми, які необхідно було вирішити за допомогою моделі USM:

Зміна даних сутностями не пройшли аутентифікацію;

1. Можливість відкладання яких-небудь дій на невизначений час або повторення одних і тих же дій з довільними інтервалами;

2. Можливість заблокувати обмін даними між сутностями;

3. Можливість перехоплення трафіку при передачі між сутностями;

4. Можливість «маскараду», тобто сутність не пройшла аутентифікацію, могла прикинутися сутністю минулої аутентифікацію.

Проблему вирішили таким чином: для кожного мережевого пристрою пароль перетворюється в деякий унікальний ключ. Це забезпечує додаткову безпеку тому навіть у тому випадку, якщо ключ буде перехоплений, зловмисник отримає доступ тільки до одного мережного пристрою. Для шифрування пароля використовується алгоритм MD5, але розробники мабуть вирішили, що це не забезпечить достатній схоронності пароля і тому блок PDU двічі хешіруется за допомогою двох різних ключів, які в свою чергу генеруються із закритого ключа. Пізніше, перші 12 октетів використовуються як код аутентифікації повідомлення, який додається до повідомлення. Такий же процес доводиться проводити на іншій стороні, але тільки у зворотному порядку. Незважаючи на всю складність і енергоємність процесу передачі даних між сутностями SNMP, на думку розробників, алгоритм шифрування (DES) насправді не забезпечує достатнього захисту інформації, тому надалі передбачається використовувати інші алгоритми. Наприклад, алгоритм Діффі-Хіллмана (Diffie-Hillman)

Розробниками передбачено 3 рівня безпеки:

1. noAuthNoPriv - паролі передаються у відкритому вигляді, конфіденційність даних відсутній.

2. authNoPriv - аутентифікація без конфіденційності. Більшість пользователейіспользует саме цей рівень т.к рівень захищеності в ньому вже досить високий, а мережеві пристрої не перевантажуються шифруванням даних.

3. authPriv - аутентифікація та шифрування. Максимальний рівень захищеності.

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

На даний момент завершено розробку нової специфікації DataOverCableServiceInterfaceSpecification <см. стандарт RFC 3256>, а для управління ключами багато користувачів вже використовують алгоритми Діффі-Хіллмана (Diffie-Hillman) і Kerberosвместо DES. Скорее все, це означає, що скоро можна буде очікувати вихід нової версії протоколу SNMP.

Інтернет - гігантська мережа. Напрошується питання, як вона зберігає свою цілісність і функціональність без єдиного управління? Якщо ж врахувати різнорідність ЕОМ, маршрутизаторів і програмного забезпечення, які використовуються в мережі, саме існування Інтернет випаде просто дивом. Так як же вирішуються проблеми управління в Інтернет? Частково на це питання вже дана відповідь - мережа зберігає працездатність за рахунок жорсткої регламентації протокольної. "Запас міцності" закладений в самих протоколах. Функції діагностики покладено, як було сказано вище, на протокол ICMP. Враховуючи важливість функції управління, для цих цілей створено два протоколи SNMP (Simple Network Management Protocol, RFC-1157, -1215, -1187, -1089, std-15 розроблений в 1988 році) і CMOT (Common Management Information services and protocol over TCP / IP, RFC-1095, останнім часом застосування цього протоколу обмежена). Зазвичай керуюча прикладна програма впливає на мережу по ланцюжку SNMP-UDP-IP-Ethernet. Найбільш важливим об'єктом управління зазвичай є зовнішній порт мережі (gateway) або маршрутизатор мережі. Кожному керованої об'єкту присвоюється унікальний ідентифікатор.

Протокол SNMP працює на базі транспортних можливостей UDP (можливі реалізації і на основі ТСР) і призначений для використання мережними керуючими станціями. Він дозволяє керуючим станціям збирати інформацію про становище в мережі Інтернет. Протокол визначає формат даних, а їх обробка та інтерпретація залишаються на розсуд керуючих станцій або менеджера мережі.

SNMP-повідомлення не мають фіксованого формату і фіксованих полів. При своїй роботі SNMP використовує управляючу базу даних (MIB - management information base, RFC-1213, -1212, std-17).

Алгоритми управління в Інтернет зазвичай описують у нотації ASN.1 (Abstract Syntax Notation). Всі об'єкти в Інтернет розділені на 10 груп і описані в MIB: система, інтерфейси, обміни, трансляція адрес, IP, ICMP, TCP, UDP, EGP, SNMP. До групи "система" входить назва і версія обладнання, операційної системи, мережевого програмного забезпечення тощо. До групи "інтерфейси" входить число підтримуваних інтерфейсів, тип інтерфейсу, що працює під IP (Ethernet, LAPB etc.), Розмір дейтограмм, швидкість обміну, адреса інтерфейсу. IP-група включає в себе час життя дейтограмм, інформація про фрагментацію, маски субсетей і т.д. В TCP-групу входить алгоритм повторної пересилки, максимальне число повторних пересиланьтаі ін. В табл.. 3.3 і на рис.3.2 наведені команди (pdu - protocol data unit) SNMP:

Команди SNMP

Таблиця 3.3.

Команда snmp	Тип pdu	Призначення
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):

S NMP - заголовок 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-протокол служить прикладом системи управління, де для досягнення потрібного результату видається не команда, а здійснюється обмін інформацією, рішення ж приймається "на місці" відповідно до отриманих даних. Впроваджено подсітеми аутентифікації, інформаційної безпеки та управління доступом.