Відмінності між версіями «SNMP»

Матеріал з Вікі ЦДУ
Перейти до: навігація, пошук
 
(не показані 3 проміжні версії цього учасника)
Рядок 11: Рядок 11:
 
*Ідея баз керуючої інформації (Management Information Bases, MIBs);
 
*Ідея баз керуючої інформації (Management Information Bases, MIBs);
  
−
*Використання синтаксису Abstract Syntax Notation One (ASN.1);
+
*Використання синтаксису Abstract Syntax Notation One ([[ASN.1]]);
  
 
*Частина термінології;
 
*Частина термінології;
Рядок 69: Рядок 69:
 
Згідно з ідеологією SNMP, управління повинне бути простим, нехай навіть ціною втрати потужності, масштабованості і захищеності. Тому при розробці стандартів SNMP враховувалися наступні умови:
 
Згідно з ідеологією SNMP, управління повинне бути простим, нехай навіть ціною втрати потужності, масштабованості і захищеності. Тому при розробці стандартів SNMP враховувалися наступні умови:
  
−
*Повсюдність. Системи під управлінням SNMP можуть бути будь-якими і можуть бути скрізь: від принтерів до мейнфреймів;
+
*Широка сфера застосування. Системи під управлінням SNMP можуть бути будь-якими і можуть бути скрізь: від принтерів до мейнфреймів;
  
 
*Простота додавання керуючих функцій. Керована система обмежена в функціональності управління, дуже проста і не може контролювати себе. Замість цього всі керовані системи контролює складна керуюча система, функціональність якої можна розширювати;
 
*Простота додавання керуючих функцій. Керована система обмежена в функціональності управління, дуже проста і не може контролювати себе. Замість цього всі керовані системи контролює складна керуюча система, функціональність якої можна розширювати;
Рядок 96: Рядок 96:
  
 
Опишемо детальніше і проаналізуємо архітектуру SNMP з позиції досягнення поставлених перед SNMP цілей. Для цього використовуємо поняття архітектурного стилю мережевого програмного забезпечення. Архітектурний стиль - це узгоджений набір архітектурних обмежень, накладених на ролі і особливості архітектурних елементів (компонентів, з'єднувачів і даних) і відносин між ними, яка проявляється у будь-якій архітектурі, і яка задовольняє цьому стилю.
 
Опишемо детальніше і проаналізуємо архітектуру SNMP з позиції досягнення поставлених перед SNMP цілей. Для цього використовуємо поняття архітектурного стилю мережевого програмного забезпечення. Архітектурний стиль - це узгоджений набір архітектурних обмежень, накладених на ролі і особливості архітектурних елементів (компонентів, з'єднувачів і даних) і відносин між ними, яка проявляється у будь-якій архітектурі, і яка задовольняє цьому стилю.
 +
 +
===Компоненти===
 +
 +
Архітектура SNMP передбачає побудову системи управління за схемою «менеджер-агент», тобто використання архітектурного стилю «клієнт-сервер». Система SNMP містить безліч керованих вузлів, на кожному з яких розміщується досить простий сервер - агент SNMP, а також, принаймні, один вузол, що містить складного клієнта - менеджера SNMP.
 +
 +
Менеджер взаємодіє з агентами за допомогою протоколу SNMP з метою обміну керуючою інформацією. В основному, ця взаємодія реалізується у вигляді періодичного опитування менеджером множини агентів, так як агенти всього лише надають доступ до інформації, але не знають, що їм з нею робити. Видно, що система, побудована за такими принципами, втрачає масштабованость, оскільки є виділений клієнт, який займається опитуванням всіх серверів. Зате така схема забезпечує простоту реалізації систем під управлінням SNMP.
 +
 +
Для підвищення масштабованості та адміністративної керованості вводиться поняття проксі-агента, який може переправляти операції протоколу SNMP, а також поняття менеджера проміжного рівня, який приховує несуттєві подробиці керуючої інформації від систем управління мережами верхнього рівня, інтегруючи одержувані від агентів дані. Це дозволяє створювати багаторівневі системи управління, що відповідають архітектурному стилю «багаторівневий клієнт-сервер».
 +
 +
Більш детальна класифікація компонентів за ролями:
 +
 +
1. Менеджер:
 +
 +
*Менеджер проміжного рівня;
 +
 +
*Система управління мережами;
 +
 +
2. Агент:
 +
 +
* Мінімальний агент;
 +
 +
* Проксі-агент;
 +
 +
Компоненти в SNMP узагальнено називаються сутностями SNMP.
 +
 +
===Дані===
 +
 +
Тепер розглянемо дані, якими маніпулюють системи SNMP, тобто керуючу інформацію. У SNMP кожний керований пристрій, на якому розташований агент, представляє свою керуючу інформацію у вигляді змінних. Такими змінними можуть бути, наприклад, ім'я системи, час з моменту її перезапуску, записи в таблиці маршрутизації і т. д. В загальному випадку змінні можна розділити на:
 +
 +
*Скалярні змінні;
 +
 +
*Таблиці змінних;
 +
 +
Схема даних описується структурою керуючої інформації (Structure of Management Information, SMI). Схема даних визначає, як виглядає керуюча інформація, тобто описує її синтаксис. SMI базується на Abstract Syntax Notation One ([[ASN.1]]).
 +
 +
Конкретні набори керуючої інформації для різних типів пристроїв, протоколів і т. д. описуються базами керуючої інформації (Management Information Bases, MIBs). Бази MIB визначають, яка управляюча інформація існує. Наприклад, для пристрою, що підтримує IP, MIB описує таблицю маршрутизації, прапорець активації функції маршрутизації, число переданих і прийнятих пакетів, число помилок різного характеру і т. д.
 +
 +
Таким чином, кожен пристрій містить набір значень змінних, визначених у деякій кількості MIB, описаних за правилами SMI. Цей набір змінних і є даними, що управляє інформацією для протоколу SNMP.
 +
 +
Важливим питанням є іменування змінних. У SNMP кожній змінній присвоюється унікальний ідентифікатор об'єкта (Object Identifier, OID). Простір імен OID є ієрархічним і контролюється організацією по розподілу номерів в Інтернеті (Internet Assigned Numbers Authority, IANA). Кожен компонент імені є числом. В текстовому вигляді імена записуються як десяткові числа, розділені крапками, зліва направо. Числам можуть бути поставлені у відповідність текстові рядки для зручності сприйняття. У цілому, структура імені схожа на систему доменних імен Інтернету (Domain Name System, DNS).
 +
 +
Кожна MIB визначає набір змінних, тобто певну гілку дерева OID, що описує керуючу інформацію в певній галузі. Наприклад, гілка 1.3.6.1.2.1.1 (мнемонічний еквівалент: iso.org.dod.internet.mgmt.mib-2.system) описує загальну інформацію про систему. Опишемо деякі змінні з цієї гілки:
 +
 +
*sysDescr (1.3.6.1.2.1.1.1) - короткий опис системи;
 +
 +
*sysUpTime (1.3.6.1.2.1.1.3) - час з моменту останнього перезапуску;
 +
 +
*sysName (1.3.6.1.2.1.1.5) - назва системи.
 +
 +
Змінні і відомості про їхній тип визначені також в MIB. А самі типи змінних - в SMI.
 +
 +
Крім безпосередньо даних, необхідно ввести операції над ними. Набір цих операцій змінювався і розширювався в міру розвитку SNMP. Основними операціями є:
 +
 +
*Читання змінної;
 +
 +
*Запис змінної;
 +
 +
*Читання змінної, наступної за заданою змінною (необхідне для перегляду таблиць змінних);
 +
 +
Більш докладно операції над даними описані нижче при обговоренні з'єднувачів в архітектурі SNMP.
 +
 +
В цілому, операції над даними в SNMP схожі на віддалене налагодження деякої програми: стан системи описується певним набором змінних, які можна переглядати і змінювати.
 +
 +
===З'єднувачі===
 +
 +
Для обміну даними між компонентами використовуються з'єднувачі. У разі SNMP в якості з'єднувача використовується протокол прикладного рівня Simple Network Management Protocol (SNMP), що звичайно працює поверх стека протоколів TCP / IP.
 +
 +
Розглянемо стек протоколів більш докладно, вказавши прив'язку протоколів до Open Systems Interconnection Reference Model (OSI RM).
 +
 +
<table cellpadding="3" cellspacing="0" bordercolor="#000000" border="1">
 +
  <tr>
 +
    <td>№</td>
 +
    <td>Протокол</td>
 +
    <td>Коментарі</td>
 +
  </tr>
 +
  <tr>
 +
    <td>7</td>
 +
    <td>SNMP</td>
 +
    <td>Повідомлення, PDU, операції</td>
 +
  </tr>
 +
<tr>
 +
    <td>6</td>
 +
    <td>[[ASN.1]] BER</td>
 +
    <td>Кодування даних</td>
 +
  </tr>
 +
<tr>
 +
    <td>5</td>
 +
    <td>-</td>
 +
    <td>-</td>
 +
  </tr>
 +
<tr>
 +
    <td>4</td>
 +
    <td>UDP</td>
 +
    <td>Транспорт між службами</td>
 +
  </tr>
 +
<tr>
 +
    <td>3</td>
 +
    <td>IP</td>
 +
    <td>Зв'язок між вузлами мережі</td>
 +
  </tr>
 +
</table>
 +
 +
SNMP вводить свій протокол прикладного рівня. Є чотири версії даного протоколу: SNMPv1, SNMPv2, SNMPv2c і SNMPv3. У процесі розвитку SNMP розширювалися можливі операції, тобто типи протокольних блоків даних (Protocol Data Units, PDUs), а також вводилися нові формати повідомлень SNMP для забезпечення безпеки.
 +
 +
Повідомлення SNMP містить номер версії SNMP, інформацію про безпеку та протокольний блок даних PDU, який характеризує виконувану операцію і її параметри. Наприклад, SNMPv1 описує наступні PDU і відповідні операції:
 +
 +
*Get-Request - запит на отримання значень 1 .. N змінних;
 +
 +
*Get-Next-Request - запит на отримання значень 1 .. N змінних, чиї OID йдуть слідом за OID зазначених 1 .. N змінних;
 +
 +
*Get-Response - відповідь на запити Get-Request, Get-Next-Request і Set-Request;
 +
 +
*Set-Request - установка значень 1 .. N змінних;
 +
 +
*Trap - пастка (див. нижче);
 +
 +
SNMP - це протокол типу "запит-відповідь", тобто на кожен запит, що надійшов від менеджера, агент повинен передати відповідь.
 +
 +
                                  [[Файл:ZaprOtv.gif]]
 +
 +
Описані PDU, як уже згадувалося, є частиною повідомлення SNMP. Повідомлення кодуються для передачі по мережі за допомогою [[ASN.1]] Basic Encoding Rules (BER). Це функція шостого рівня (рівня подання) еталонної моделі OSI. Далі закодовані повідомлення відправляються одним компонентом SNMP іншого за допомогою транспортного протоколу.
 +
 +
Як вже зазначалося, стандарт передбачає використання різного транспорту для SNMP, але майже завжди використовується протокол користувацьких датаграм (User Datagram Protocol, UDP). Агенти використовують добре відомий порт UDP 161. Цей протокол надає мінімальні транспортні послуги (доставка повідомлень від служби до служби і перевірка контрольної суми) і не передбачає організацію сеансів і потокову передачу даних, як Transmission Control Protocol (TCP). За рахунок цього вдається домогтися великої швидкості реакції і швидкодії, що відповідає поставленим перед SNMP цілям.
 +
 +
Для підвищення швидкості реакції менеджера на термінові події вводиться спеціальний тип операції протоколу SNMP, так звана «пастка» (Trap). Він дозволяє агентам асинхронно інформувати менеджера (за власною ініціативою) про настання обмеженого числа значущих подій. У цьому випадку агент виступає в незвичній для себе ролі клієнта, а менеджер - в ролі сервера. У разі використання транспорту UDP для вхідних з'єднань менеджер використовує добре відомий порт UDP 162.
 +
 +
Як ми бачимо, жодна з цих операцій не припускає, що агент зберігає інформацію про сесії з менеджером. Для виконання операції Trap така інформація зберігається статично, тобто сесія в такому випадку статична і перманентна. Крім цього операції SNMP визначають єдині, уніфіковані інтерфейси агентів і менеджерів SNMP. Таким чином, SNMP - це протокол без збереження стану, який відповідає архітектурному стилю «уніфікований багаторівневий клієнт-сервер без збереження стану».
 +
 +
Опишемо деякі властивості операцій SNMP на прикладі SNMPv1:
 +
 +
<table cellpadding="3" cellspacing="0" bordercolor="#000000" border="1">
 +
  <tr>
 +
    <td>Ім'я</td>
 +
    <td>Безпека</td>
 +
    <td>Підтвердження</td>
 +
    <td>Ідемпотентність</td>
 +
  </tr>
 +
  <tr>
 +
    <td>Get-Request</td>
 +
    <td>1</td>
 +
    <td>1</td>
 +
    <td>1</td>
 +
  </tr>
 +
<tr>
 +
    <td>Get-Next-Request</td>
 +
    <td>1</td>
 +
    <td>1</td>
 +
    <td>1</td>
 +
  </tr>
 +
<tr>
 +
    <td>Get-Response</td>
 +
    <td>1</td>
 +
    <td>0</td>
 +
    <td>?</td>
 +
  </tr>
 +
<tr>
 +
    <td>Set-Request</td>
 +
    <td>0</td>
 +
    <td>1</td>
 +
    <td>?</td>
 +
  </tr>
 +
<tr>
 +
    <td>Trap</td>
 +
    <td>1</td>
 +
    <td>0</td>
 +
    <td>?</td>
 +
  </tr>
 +
</table>
 +
 +
Таким чином, ми розглянули всі основні архітектурні особливості SNMP, крім моделей безпеки. Питання, пов'язані із захистом інформації, будуть розглянуті нижче при обговоренні версій стандартів SNMP.
 +
 +
==Відповідність архітектурному стилю REST==
 +
 +
Архітектурний стиль REST - це уніфікований багаторівневий клієнт-серверний стиль, з кодом за запитом та без збереження стану (Unified-Layered-Code-on-Demand-Client-Cached-Stateless-Server, ULCODCСSS). Як ми визначили в результаті аналізу архітектури SNMP, система SNMP визначається уніфікованим багаторівневим клієнт-серверних стилем без збереження стану (Unified-Layered-Client-Stateless-Server, ULCSS).
 +
 +
Як ми бачимо, на SNMP не накладаються обмеження, пов'язані з реплікацією (наявність кеша) і мобільним кодом (застосування коду за вимогою). У цьому сенсі стиль SNMP - більш вільний, ніж REST, тобто містить менше архітектурних особливостей, які, наприклад, необхідно враховувати при моделюванні систем з такою архітектурою.
 +
 +
Однак, навіть у SNMPv1 є особлива операція Trap, що ініціюється агентом асинхронно по відношенню до менеджера. У SNMPv2 вводиться операція Inform-Request, яка також виконується асинхронно, але між двома менеджерами. При виконанні таких операцій клієнт і сервер міняються ролями. При цьому використовується принцип інтеграції на основі повідомлень. Це елементи однорангового стилю взаємодії (Peer-to-Peer), хоча в даному випадку ролі клієнта і сервера для конкретних типів протокольних операцій виражені явно. У цьому сенсі стиль SNMP - більш обмежений, ніж REST.
 +
 +
Таким чином, при певних обмеженнях система SNMP може бути розглянута як REST-івська розподілена система.
 +
 +
==Структура стандартів==
 +
 +
Стандарти SNMP описують аспекти, відображені нижче:
 +
 +
1. Загальна інформація;
 +
 +
2. Обробка повідомлень (SNMP Messages):
 +
 +
*Прив'язки до транспорту;
 +
 +
*Розбір і диспетчеризація повідомлень;
 +
 +
*Безпека (аутентифікація, шифрування, своєчасність);
 +
 +
3. Обробка протокольних блоків даних (SNMP PDUs):
 +
 +
*Операції протоколу;
 +
 +
*Програми SNMP;
 +
 +
*Управління доступом;
 +
 +
4. Інформаційна модель:
 +
 +
*Структура керуючої інформації (SMI);
 +
 +
*Текстові конвенції;
 +
 +
*Вирази відповідності;
 +
 +
5. Модулі баз керуючої інформації (MIB);
 +
 +
Спочатку в стандартах виділялися не всі ці аспекти. Проте, структура стандартів SNMP всіх версій вписується в цю схему.
 +
 +
==Інформаційна безпека==
 +
 +
Розглянемо, як враховуються в SNMP основні елементи інформаційної безпеки:
 +
 +
*Конфіденційність;
 +
 +
*Цілісність;
 +
 +
*Доступність;
 +
 +
*Контрольованість;
 +
 +
У ході розвитку стандартів SNMP інфраструктура безпеки піддавалася найбільших змін. Для того, щоб простежити ці зміни, спочатку опишемо вимоги безпеки та загрози, потім структуру моделей безпеки, після чого розглянемо використання в різних версіях SNMP моделі.
 +
 +
===Вимоги та загрози безпеці===
 +
 +
Опишемо вимоги безпеки в архітектурі SNMP. Загрозами безпеці, проти яких повинна надавати захист будь-яка модель безпеки SNMP, є:
 +
 +
1. Первинні загрози:
 +
 +
*Модифікація інформації;
 +
 +
*Маскарад;
 +
 +
2. Вторинні загрози:
 +
 +
*Модифікація потоку повідомлень;
 +
 +
*Розголошення;
 +
 +
Загроза модифікації інформації - це можливість того, що деяка неавторизована сутність може змінити повідомлення SNMP, згенеровані за запитом авторизованого принципала, на шляху їх слідування таким чином, що це призведе до неавторизованих операцій управління, включаючи фальсифікацію значення об'єкта (змінної).
 +
 +
Загроза маскараду - це можливість того, що операції управління, не авторизовані для деякого принципала, можуть бути виконані при підстановці ідентифікатора іншого принципала, для якого подібні дії авторизовані.
 +
 +
Загроза модифікації потоку повідомлень полягає в наступному. Протокол SNMP звичайно що грунтується на транспортній службі без організації з'єднання. Перестановка, затримка або повторна посилка повідомлень може відбуватися і відбувається в ході звичайної експлуатації мереж із застосуванням таких протоколів. Загроза модифікацій потоку повідомлень - це можливість того, що повідомлення можуть бути переставлені, затримані чи повторно надіслані зі злим умислом із затримками, які перевищують наявне місце затримки при нормальній експлуатації, з метою виконання неавторизованих операцій управління.
 +
 +
Загроза розголошення - це можливість прослуховування обмінів повідомленнями між сутностями SNMP. Захист від цієї загрози може вимагати локальної політики безпеки.
 +
 +
Модель безпеки може не боротися з такими загрозами, як, наприклад, відмова в обслуговуванні, оскільки стан мережевих збоїв і помилок (нормальне для SNMP) часто не відрізняються від ситуацій відмови в обслуговуванні.
 +
 +
Як ми побачимо нижче, на практиці не кожна модель безпеки SNMP задовольняє вимогам нейтралізації перерахованих загроз.
 +
 +
===Структура моделей безпеки===
 +
 +
Сутність SNMP містить дві підсистеми:
 +
 +
*Підсистема безпеки;
 +
 +
*Підсистема управління доступом;
 +
 +
Підсистема безпеки функціонує на рівні повідомлень SNMP. Вона відповідає за аутентифікацію, шифрування і своєчасність. Документ з безпеки описує модель безпеки, загрози, проти яких вона захищає, цілі моделі безпеки, протоколи, використовувані для досягнення цих цілей, модуль MIB, що описує відповідні структури даних. Такий модуль потрібний у тому числі і для того, щоб віддалено конфігурувати параметри безпеки рівня повідомлень SNMP.
 +
 +
Підсистема управління доступом функціонує на рівні SNMP PDU. Очевидно, що вона відповідає за управління доступом до керованих об'єктів (змінних). Документи, що описують її, також визначають модуль MIB для віддаленого налаштування параметрів.
 +
 +
===Моделі безпеки===
 +
 +
Перелічимо основні моделі безпеки та відповідні їм інфраструктури:
 +
1. SNMPv1:
 +
 +
*SNMPv1 - Community-based Security Model;
 +
 +
2. SNMPv2:
 +
 +
*SNMPv2p - Party-based Security Model;
 +
 +
*SNMPv2c - Community-based Security Model;
 +
 +
*SNMPv2u - User-based Security Model;
 +
 +
3. SNMPv3
 +
 +
*SNMPv3 USM User-based Security Model.
 +
 +
Модель безпеки на основі спільнот (Community-based Security Model) була першою, найпростішою і найбезпечнішою. Вона полягає лише у аутентифікації на основі «рядка спільноти», фактично, пароля, переданого по мережі в тексті повідомлення SNMP у відкритому вигляді. Ця модель безпеки не в змозі боротися ні з однією із загроз інформаційної безпеки в SNMP. Тим не менш, вона часто використовується до цих пір у зв'язку зі своєю простотою, а також завдяки наявності зовнішніх, не пов'язаних з SNMP систем безпеки, наприклад, міжмережевих екранів.
 +
 +
Модель безпеки на основі сторін (Party-based Security Model) передбачає введення поняття сторони. Сторона - це віртуальне оточення виконання, в якому набір допустимих операцій обмежений адміністративно. Сутність SNMP при обробці повідомлення діє як сторона, тому обмежена операціями, визначеними для цієї сторони. Сторона визначається наступними параметрами:
 +
 +
*Унікальний ідентифікатор сторони;
 +
 +
*Логічна мережева адреса (область адрес транспортного протоколу та адреса транспортного протоколу);
 +
 +
*Протокол аутентифікації і параметри, що вимагаються для аутентифікації всіх повідомлень сторони;
 +
 +
*Протокол шифрування і параметри, потрібні для шифрування всіх повідомлень сторони;
 +
 +
Можуть використовуватися різні алгоритми для протоколів аутентифікації і шифрування. Звичайно як алгоритму для протоколу аутентифікації використовують хеш-функцію Message Digest 5 (MD5), а для протоколу шифрування - алгоритм Data Encryption Standard (DES) в режимі Cipher Block Chaining (CBC).
 +
 +
Запроваджуються й інші поняття, що використовуються для реалізації цієї моделі. Проте тут вони докладно не розглядаються, так само як і деталі функціонування моделі. Зазначимо лише, що при використанні відповідних протоколів аутентифікації і шифрування модель успішно справляється з описаними вище загрозами безпеці SNMP. Дана модель безпеки не була широко прийнята, оскільки є занадто складною і заплутаною.
 +
 +
Модель безпеки на основі користувачів (User-based Security Model) вводить поняття користувача, від імені якого діє сутність SNMP. Цей користувач характеризується ім'ям користувача, використовуваними протоколами аутентифікації і шифрування, а також закритим ключем аутентифікації і шифрування. Аутентифікація і шифрування є необов'язковими. Їх наявність описується одним з параметрів моделі, якістю обслуговування (Quality of Service, QoS). Модель безпеки багато в чому схожа на модель сторін, але вона спрощує ідентифікацію користувачів, розподіл ключів і протокольні операції.
 +
 +
==Версії SNMP==
 +
 +
Коротко опишемо відмінності між версіями SNMP і документи, що визначають ці версії. Зауважимо, що тут наведено перші версії RFC кожної з версій SNMP, тобто майже всі з них були заміщені новішими RFC і визнані застарілими. На даний момент єдиною не застарілою версією SNMP є SNMPv3, визначена в RFC 3411-3418.
 +
 +
===SNMPv1===
 +
Перші RFC, що описують стандарти SNMP, з'явилися в 1988 році. Версія 1 піддалася критиці за її слабку модель безпеки на основі спільнот. У той час безпека в Інтернеті не входила в коло першочергових завдань робочих груп IETF.
 +
 +
1. Обробка повідомлень
 +
 +
*[http://tools.ietf.org/html/rfc1067 RFC 1067]. A Simple Network Management Protocol;
 +
 +
2. Обробка PDU
 +
 +
*[http://tools.ietf.org/html/rfc1067 RFC 1067]. A Simple Network Management Protocol;
 +
 +
3. Інформаційна модель
 +
 +
*Структура керуючої інформації
 +
[http://tools.ietf.org/html/rfc1065 RFC 1065]. Structure and Identification of Management Information for TCP / IP-based internets
 +
 +
4. Модулі MIB
 +
 +
*[http://tools.ietf.org/html/rfc1066 RFC 1066]. Management Information Base for Network Management of TCP / IP-based internets
 +
 +
===SNMPv2===
 +
 +
Версія 2, відома, як Party-based SNMPv2, або SNMPv2p, не отримала широкого розповсюдження через серйозні розбіжності з приводу інфраструктури безпеки в стандарті.
 +
 +
SNMPv2 поліпшував версію 1 в області швидкодії, безпеки, конфіденційності і взаємодій «менеджер-менеждер». Він представив новий тип PDU Get-Bulk-Request, альтернативу Get-Next-Request для отримання великих обсягів інформації за допомогою одного запиту. Проте, нова система безпеки на основі сторін виглядала для багатьох як надто складна і не була широко визнана.
 +
 +
1. Загальна інформація
 +
 +
*[http://tools.ietf.org/html/rfc1441 RFC 1441]. Introduction to version 2 of the Internet-standard Network Management Framework
 +
 +
*[http://tools.ietf.org/html/rfc1452 RFC 1452]. Coexistence between version 1 and version 2 of the Internet-standard Network
 +
Management Framework
 +
 +
2. Обробка повідомлень
 +
 +
*Прив'язки до транспорту. [http://tools.ietf.org/html/rfc1448 RFC 1448]. Transport Mappings for SNMPv2
 +
 +
*Безпека. [http://tools.ietf.org/html/rfc1446 RFC 1446]. Security Protocols for SNMPv2
 +
 +
3. Обробка PDU
 +
 +
*Управління доступом. [http://tools.ietf.org/html/rfc1445 RFC 1445]. Administrative Model for SNMPv2
 +
 +
*Протокольні операції. [http://tools.ietf.org/html/rfc1448 RFC 1448]. Protocol Operations for SNMPv2
 +
 +
4. Інформаційна модель
 +
 +
*Структура керуючої інформації. [http://tools.ietf.org/html/rfc1442 RFC 1442]. Structure of Management Information SNMPv2
 +
 +
*Текстові конвенції. [http://tools.ietf.org/html/rfc1443 RFC 1443]. Textual Conventions for SNMPv2
 +
 +
*Вирази відповідності. [http://tools.ietf.org/html/rfc1444 RFC 1444]. Conformance Statements for SNMPv2
 +
 +
5. Модулі MIB
 +
 +
*[http://tools.ietf.org/html/rfc1447 RFC 1447]. Party MIB for SNMPv2
 +
 +
*[http://tools.ietf.org/html/rfc1450 RFC 1450]. MIB for SNMPv2
 +
 +
*[http://tools.ietf.org/html/rfc1451 RFC 1451]. Manager-to-Manager MIB
 +
 +
===SNMPv2c===
 +
 +
Community-based SNMPv2, або SNMPv2c, представив SNMPv2 без нової моделі безпеки версії 2. Замість неї пропонувалося використовувати стару модель безпеки версії 1 на основі спільнот. Відповідну пропозицію RFC було прийнято тільки як чернетку стандарту, однак стало де факто стандартом SNMPv2. Безпека SNMP знову опинилася невирішеним питанням.
 +
 +
1. Обробка повідомлень
 +
*Безпека. [http://tools.ietf.org/html/rfc1901 RFC 1901]. Introduction to Community-based SNMPv2
 +
 +
===SNMPv2u===
 +
 +
User-based SNMPv2, або SNMPv2u, є компромісом між незахищеністю SNMPv1 і надмірною складністю SNMPv2p. Запропонована модель безпеки на основі користувачів була покладена в основу SNMPv3.
 +
 +
1. Обробка повідомлень
 +
 +
*Безпека. [http://tools.ietf.org/html/rfc1909 RFC 1909] - An Administrative Infrastructure for SNMPv2 [http://tools.ietf.org/html/rfc1910 RFC 1910] - User-based Security Model for SNMPv2
 +
 +
2. Обробка PDU
 +
 +
*Управління доступом. [http://tools.ietf.org/html/rfc1909 RFC 1909]. An Administrative Infrastructure for SNMPv2
 +
 +
===SNMPv3===
 +
 +
SNMPv3 нарешті вирішив проблеми з безпекою способом, який багато хто вважав прийнятним. Версія 3 SNMP прийнята IETF як стандарт Інтернету (IETF STD 62). Майже всі попередні RFC визнані застарілими.
 +
 +
1. Загальна інформація
 +
*[http://tools.ietf.org/html/rfc3411 RFC 3411]. An Architecture for Describing SNMP Management Frameworks
 +
 +
2. Обробка повідомлень
 +
 +
*Прив'язки до транспорту. [http://tools.ietf.org/html/rfc3417 RFC 3417]. Transport Mappings for the SNMP
 +
 +
*Розбір і диспетчеризація повідомлень. [http://tools.ietf.org/html/rfc3412 RFC 3412]. Message Processing and Dispatching for the SNMP
 +
 +
*Безпека. [http://tools.ietf.org/html/rfc3414 RFC 3414]. User-based Security Model (USM) for SNMPv3
 +
 +
3. Обробка PDU
 +
 +
*Операції протоколу. [http://tools.ietf.org/html/rfc3416 RFC 3416]. Version 2 of the Protocol Operations for SNMP
 +
 +
*Програми SNMP. [http://tools.ietf.org/html/rfc3413 RFC 3413]. SNMP Applications
 +
 +
*Управління доступом. [http://tools.ietf.org/html/rfc3415 RFC 3415]. View-based Access Control Model (VACM) for the SNMP
 +
 +
4. Модулі MIB. [http://tools.ietf.org/html/rfc3418 RFC 3418]. MIB for the SNMP
 +
 +
==Існуючі реалізації==
 +
 +
Підтримка SNMP - у багатьох значущих системах управління мережами, зокрема:
 +
 +
*HP Network Node Manager;
 +
 +
*IBM Tivoli NetView;
 +
 +
*OpenNMS
 +
 +
==Недоліки SNMP==
 +
 +
Протокол SNMP служить основою багатьох систем управління, хоча має кілька принципових недоліків, які перераховані нижче:
 +
 +
*Відсутність засобів взаємної аутентифікації агентів і менеджерів. Єдиним засобом, який можна було б віднести до засобів аутентифікації, є використання в повідомленнях так званого рядка «community string». Цей рядок передається по мережі у відкритій формі в повідомленні SNMP і служить основою для поділу агентів і менеджерів на «спільноти», так що агент взаємодіє тільки з тими менеджерами, які вказують в поле community string такий же символьний рядок, що й рядок, який зберігається в пам'яті агента. Це, безумовно, не спосіб аутентифікації, а спосіб структурування агентів і менеджерів. Версія SNMP v.2 повинна була ліквідувати цей недолік, але в результаті розбіжностей між розробниками стандарту нові засоби аутентифікації хоча і з'явилися в цій версії, але як необов'язкові.
 +
 +
*Робота через ненадійний протокол UDP (а саме так працює переважна більшість реалізації агентів SNMP) призводить до втрат аварійних повідомлень (повідомлень trap) від агентів до менеджерів, що може призвести до неякісного управління.
 +
 +
==Висновки==
 +
 +
*SNMP широко використовується для управління мережами, особливо IP-мережами
 +
 +
*Успіх SNMP в порівнянні з іншими стандартами управління показує переваги процесу стандартизації IETF
 +
 +
*Історія розвитку SNMP показує важливість завдань захисту інформації
 +
 +
*Архітектура SNMP цікава для аналізу архітектури мережевого програмного забезпечення; вона відповідає поставленим перед SNMP цілям
 +
 +
*Архітектура SNMP відповідає архітектурному стилю ULCSS мережевого програмного забезпечення
 +
 +
*У SNMP для вирішення функцій 6 рівня моделі OSI RM використовується [[ASN.1]], що незвично для стандартів IETF і позитивно впливає на питання формалізації протоколів, однозначності стандартів, зручності проектування додатків
 +
 +
*Структура стандартів SNMP добре продумана і показова для вивчення стандартів
 +
 +
*Лише деякі моделі безпеки SNMP відповідають поставленим перед системою безпеки SNMP цілям
 +
 +
*Агенти та менеджери SNMP прості в програмній реалізації, проте завжди потрібно пам'ятати про інформаційну безпеку
 +
 +
 +
  
 
[[Засоби моніторингу та аналізу мережі]]
 
[[Засоби моніторингу та аналізу мережі]]

Поточна версія на 22:51, 18 грудня 2011

SNMP (англ. Simple Network Management Protocol — простий протокол керування мережею) — це протокол керування мережами зв'язку на основі архітектури TCP/IP.

Історія створення SNMP

Однією з найперших ініціатив з управління мережами була ініціатива ISO Open Systems Interconnection (OSI). Відповідні групи з стандартизації інфраструктури управління OSI (OSI Management Framework) були створені в 1981 році.

До кінця 1980-х років мережа Інтернет стала досить великою і вимагала стандартів управління. Однак група ISO OSI була далека від завершення робіт над сімейством стандартів. Тому в 1987 році спільнотою IETF було прийнято рішення тимчасово створити набір спрощених стандартів управління в Інтернеті на основі напрацювань ISO OSI. Дані стандарти отримали назву Simple Network Management Protocol (SNMP). Надалі передбачалося перейти на стандарти ISO у міру їх готовності. Таким чином, багато ідей SNMP були взяті зі стандартів ISO:

  • Концепція «менеджер-агент»;
  • Ідея баз керуючої інформації (Management Information Bases, MIBs);
  • Використання синтаксису Abstract Syntax Notation One (ASN.1);
  • Частина термінології;

Іншими проектом стандарту, на базі якого почалася розробка SNMP, був проект простого протоколу моніторингу шлюзів (Simple Gateway Monitoring Protocol, SGMP) співтовариства IETF.

Надалі в рамках ISO OSI було запропоновано багато нових ідей, зокрема, об'єктно-орієнтований підхід. Однак ці ідеї вже не ввійшли в стандарти SNMP. Один час IETF продовжувала CMIP over TCP (CMOT), яка передбачала використання загального протоколу керуючої інформації (Common Management Information Protocol, CMIP) стека протоколів ISO OSI в стеку IETF TCP / IP. У 1992 році ця ініціатива була припинена у зв'язку з успіхом і поширеністю SNMP.

Після багатьох засідань IAB (Internet Architecture Board) опублікував у квітні 1988 року епохальний RFC 1052: IAB Recommendations for the Development of Internet Network Management Standards, в якому закликав до якнайшвидшого створення елементів Простого Мережевого Управління (Simple Network Management).

Багато ідей, що лежать сьогодні в основі SNMP, були запозичені у попередніх дослідженнях з моніторингу Internet-маршрутизаторів. І вже в серпні 1988 з'явилися три основні документа:

  • RFC 1065: Structure and Identification of Management Information for TCP / IP-based internets.
  • RFC 1066: Management Information Base for Network Management of TCP / IP-based internets.
  • RFC 1067: A Simple Network Management Protocol.

Згодом ці документи було перевидано і доповнено до визначення наступного покоління SNMP: RFC 1155, 1156 і 1157, які в свою чергу, також піддалися переробкам.

Зрештою, у травні 1991 року була закінчена робота зі створення першої версії протоколу SNMPv1, яка знайшла своє відображення в зведенні таких документів:

  • RFC 1155: Structure and Identification of Management Information for TCP / IP-based internets (Травень, 1990):

- Визначає структуру керуючої інформації у вигляді глобального дерева. - Являє синтаксис визначення імен змінних управління.

  • RFC 1212: Concise MIB Definitions (Березень, 1991)

- Доповнює RFC 1155 в частині синтаксису визначення імен змінних.

  • RFC 1213: Management Information Base for Network Management of TCP / IP-based internets: MIB-II (Березень, 1991):

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

  • RFC 1157: A Simple Network Management Protocol (SNMP) (Травень, 1990)

- Визначає повідомлення, якими обмінюються керуюча станція і об'єкт управління для отримання та оновлення значення змінних. - Визначає trap (alarm)-повідомлення, що посилаються системою при значних змінах у її конфігурації.

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

  • всього спектра мережного обладнання - мостів, маршрутизаторів, модемів ...
  • широкого кола інтерфейсів - Point-to-Point, DS1, DS3, X.25, Frame Relay, Ethernet, Token Ring, FDDI, та ін.

В загальному, стандарти SNMP продовжували розвиватися протягом 1990-х років. Основним напрямком розвитку було вдосконалення питань безпеки. Були розроблені наступні версії SNMP: SNMPv1, SNMPv2, SNMPv2c, SNMPv2u і SNMPv3. Їх обговорення буде продовжено в розділі «Версії SNMP».

Задачі

Сімейство стандартів SNMP створено для вирішення задач обробки помилок і аналізу продуктивності і надійності.

Обробка помилок

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

Аналіз продуктивності і надійності

Оцінка на основі статистичної інформації таких параметрів, як час реакції системи, пропускна спроможність каналів зв'язку, інтенсивність трафіку в окремих сегментах мережі, імовірність спотворення даних, коефіцієнт готовності служб мережі. Результати такого аналізу дозволяють контролювати угоду про рівень обслуговування (Service Level Agreement, SLA).

Згідно з ідеологією SNMP, управління повинне бути простим, нехай навіть ціною втрати потужності, масштабованості і захищеності. Тому при розробці стандартів SNMP враховувалися наступні умови:

  • Широка сфера застосування. Системи під управлінням SNMP можуть бути будь-якими і можуть бути скрізь: від принтерів до мейнфреймів;
  • Простота додавання керуючих функцій. Керована система обмежена в функціональності управління, дуже проста і не може контролювати себе. Замість цього всі керовані системи контролює складна керуюча система, функціональність якої можна розширювати;
  • Стійкість у критичних ситуаціях. Наприклад, при перевантаженні і проблемах в мережі, тобто при множинних помилках.

Архітектура

Архітектуру розподіленої системи можна описати в термінах обробних елементів (або компонентів), що з'єднують елементів (або з'єднувачів) і елементів даних. Перерахуємо складові елементи системи управління SNMP:

1. компоненти:

  • агент;
  • менеджер;

2. з'єднувачі:

  • транспортний протокол;
  • Протокольні блоки даних (Protocol Data Units, PDU) і повідомлення SNMP;

3. дані:

  • Керуюча інформація MIB;

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

Компоненти

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

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

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

Більш детальна класифікація компонентів за ролями:

1. Менеджер:

  • Менеджер проміжного рівня;
  • Система управління мережами;

2. Агент:

  • Мінімальний агент;
  • Проксі-агент;

Компоненти в SNMP узагальнено називаються сутностями SNMP.

Дані

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

  • Скалярні змінні;
  • Таблиці змінних;

Схема даних описується структурою керуючої інформації (Structure of Management Information, SMI). Схема даних визначає, як виглядає керуюча інформація, тобто описує її синтаксис. SMI базується на Abstract Syntax Notation One (ASN.1).

Конкретні набори керуючої інформації для різних типів пристроїв, протоколів і т. д. описуються базами керуючої інформації (Management Information Bases, MIBs). Бази MIB визначають, яка управляюча інформація існує. Наприклад, для пристрою, що підтримує IP, MIB описує таблицю маршрутизації, прапорець активації функції маршрутизації, число переданих і прийнятих пакетів, число помилок різного характеру і т. д.

Таким чином, кожен пристрій містить набір значень змінних, визначених у деякій кількості MIB, описаних за правилами SMI. Цей набір змінних і є даними, що управляє інформацією для протоколу SNMP.

Важливим питанням є іменування змінних. У SNMP кожній змінній присвоюється унікальний ідентифікатор об'єкта (Object Identifier, OID). Простір імен OID є ієрархічним і контролюється організацією по розподілу номерів в Інтернеті (Internet Assigned Numbers Authority, IANA). Кожен компонент імені є числом. В текстовому вигляді імена записуються як десяткові числа, розділені крапками, зліва направо. Числам можуть бути поставлені у відповідність текстові рядки для зручності сприйняття. У цілому, структура імені схожа на систему доменних імен Інтернету (Domain Name System, DNS).

Кожна MIB визначає набір змінних, тобто певну гілку дерева OID, що описує керуючу інформацію в певній галузі. Наприклад, гілка 1.3.6.1.2.1.1 (мнемонічний еквівалент: iso.org.dod.internet.mgmt.mib-2.system) описує загальну інформацію про систему. Опишемо деякі змінні з цієї гілки:

  • sysDescr (1.3.6.1.2.1.1.1) - короткий опис системи;
  • sysUpTime (1.3.6.1.2.1.1.3) - час з моменту останнього перезапуску;
  • sysName (1.3.6.1.2.1.1.5) - назва системи.

Змінні і відомості про їхній тип визначені також в MIB. А самі типи змінних - в SMI.

Крім безпосередньо даних, необхідно ввести операції над ними. Набір цих операцій змінювався і розширювався в міру розвитку SNMP. Основними операціями є:

  • Читання змінної;
  • Запис змінної;
  • Читання змінної, наступної за заданою змінною (необхідне для перегляду таблиць змінних);

Більш докладно операції над даними описані нижче при обговоренні з'єднувачів в архітектурі SNMP.

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

З'єднувачі

Для обміну даними між компонентами використовуються з'єднувачі. У разі SNMP в якості з'єднувача використовується протокол прикладного рівня Simple Network Management Protocol (SNMP), що звичайно працює поверх стека протоколів TCP / IP.

Розглянемо стек протоколів більш докладно, вказавши прив'язку протоколів до Open Systems Interconnection Reference Model (OSI RM).

№ Протокол Коментарі
7 SNMP Повідомлення, PDU, операції
6 ASN.1 BER Кодування даних
5 - -
4 UDP Транспорт між службами
3 IP Зв'язок між вузлами мережі

SNMP вводить свій протокол прикладного рівня. Є чотири версії даного протоколу: SNMPv1, SNMPv2, SNMPv2c і SNMPv3. У процесі розвитку SNMP розширювалися можливі операції, тобто типи протокольних блоків даних (Protocol Data Units, PDUs), а також вводилися нові формати повідомлень SNMP для забезпечення безпеки.

Повідомлення SNMP містить номер версії SNMP, інформацію про безпеку та протокольний блок даних PDU, який характеризує виконувану операцію і її параметри. Наприклад, SNMPv1 описує наступні PDU і відповідні операції:

  • Get-Request - запит на отримання значень 1 .. N змінних;
  • Get-Next-Request - запит на отримання значень 1 .. N змінних, чиї OID йдуть слідом за OID зазначених 1 .. N змінних;
  • Get-Response - відповідь на запити Get-Request, Get-Next-Request і Set-Request;
  • Set-Request - установка значень 1 .. N змінних;
  • Trap - пастка (див. нижче);

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

                                  ZaprOtv.gif

Описані PDU, як уже згадувалося, є частиною повідомлення SNMP. Повідомлення кодуються для передачі по мережі за допомогою ASN.1 Basic Encoding Rules (BER). Це функція шостого рівня (рівня подання) еталонної моделі OSI. Далі закодовані повідомлення відправляються одним компонентом SNMP іншого за допомогою транспортного протоколу.

Як вже зазначалося, стандарт передбачає використання різного транспорту для SNMP, але майже завжди використовується протокол користувацьких датаграм (User Datagram Protocol, UDP). Агенти використовують добре відомий порт UDP 161. Цей протокол надає мінімальні транспортні послуги (доставка повідомлень від служби до служби і перевірка контрольної суми) і не передбачає організацію сеансів і потокову передачу даних, як Transmission Control Protocol (TCP). За рахунок цього вдається домогтися великої швидкості реакції і швидкодії, що відповідає поставленим перед SNMP цілям.

Для підвищення швидкості реакції менеджера на термінові події вводиться спеціальний тип операції протоколу SNMP, так звана «пастка» (Trap). Він дозволяє агентам асинхронно інформувати менеджера (за власною ініціативою) про настання обмеженого числа значущих подій. У цьому випадку агент виступає в незвичній для себе ролі клієнта, а менеджер - в ролі сервера. У разі використання транспорту UDP для вхідних з'єднань менеджер використовує добре відомий порт UDP 162.

Як ми бачимо, жодна з цих операцій не припускає, що агент зберігає інформацію про сесії з менеджером. Для виконання операції Trap така інформація зберігається статично, тобто сесія в такому випадку статична і перманентна. Крім цього операції SNMP визначають єдині, уніфіковані інтерфейси агентів і менеджерів SNMP. Таким чином, SNMP - це протокол без збереження стану, який відповідає архітектурному стилю «уніфікований багаторівневий клієнт-сервер без збереження стану».

Опишемо деякі властивості операцій SNMP на прикладі SNMPv1:

Ім'я Безпека Підтвердження Ідемпотентність
Get-Request 1 1 1
Get-Next-Request 1 1 1
Get-Response 1 0 ?
Set-Request 0 1 ?
Trap 1 0 ?

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

Відповідність архітектурному стилю REST

Архітектурний стиль REST - це уніфікований багаторівневий клієнт-серверний стиль, з кодом за запитом та без збереження стану (Unified-Layered-Code-on-Demand-Client-Cached-Stateless-Server, ULCODCСSS). Як ми визначили в результаті аналізу архітектури SNMP, система SNMP визначається уніфікованим багаторівневим клієнт-серверних стилем без збереження стану (Unified-Layered-Client-Stateless-Server, ULCSS).

Як ми бачимо, на SNMP не накладаються обмеження, пов'язані з реплікацією (наявність кеша) і мобільним кодом (застосування коду за вимогою). У цьому сенсі стиль SNMP - більш вільний, ніж REST, тобто містить менше архітектурних особливостей, які, наприклад, необхідно враховувати при моделюванні систем з такою архітектурою.

Однак, навіть у SNMPv1 є особлива операція Trap, що ініціюється агентом асинхронно по відношенню до менеджера. У SNMPv2 вводиться операція Inform-Request, яка також виконується асинхронно, але між двома менеджерами. При виконанні таких операцій клієнт і сервер міняються ролями. При цьому використовується принцип інтеграції на основі повідомлень. Це елементи однорангового стилю взаємодії (Peer-to-Peer), хоча в даному випадку ролі клієнта і сервера для конкретних типів протокольних операцій виражені явно. У цьому сенсі стиль SNMP - більш обмежений, ніж REST.

Таким чином, при певних обмеженнях система SNMP може бути розглянута як REST-івська розподілена система.

Структура стандартів

Стандарти SNMP описують аспекти, відображені нижче:

1. Загальна інформація;

2. Обробка повідомлень (SNMP Messages):

  • Прив'язки до транспорту;
  • Розбір і диспетчеризація повідомлень;
  • Безпека (аутентифікація, шифрування, своєчасність);

3. Обробка протокольних блоків даних (SNMP PDUs):

  • Операції протоколу;
  • Програми SNMP;
  • Управління доступом;

4. Інформаційна модель:

  • Структура керуючої інформації (SMI);
  • Текстові конвенції;
  • Вирази відповідності;

5. Модулі баз керуючої інформації (MIB);

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

Інформаційна безпека

Розглянемо, як враховуються в SNMP основні елементи інформаційної безпеки:

  • Конфіденційність;
  • Цілісність;
  • Доступність;
  • Контрольованість;

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

Вимоги та загрози безпеці

Опишемо вимоги безпеки в архітектурі SNMP. Загрозами безпеці, проти яких повинна надавати захист будь-яка модель безпеки SNMP, є:

1. Первинні загрози:

  • Модифікація інформації;
  • Маскарад;

2. Вторинні загрози:

  • Модифікація потоку повідомлень;
  • Розголошення;

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

Загроза маскараду - це можливість того, що операції управління, не авторизовані для деякого принципала, можуть бути виконані при підстановці ідентифікатора іншого принципала, для якого подібні дії авторизовані.

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

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

Модель безпеки може не боротися з такими загрозами, як, наприклад, відмова в обслуговуванні, оскільки стан мережевих збоїв і помилок (нормальне для SNMP) часто не відрізняються від ситуацій відмови в обслуговуванні.

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

Структура моделей безпеки

Сутність SNMP містить дві підсистеми:

  • Підсистема безпеки;
  • Підсистема управління доступом;

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

Підсистема управління доступом функціонує на рівні SNMP PDU. Очевидно, що вона відповідає за управління доступом до керованих об'єктів (змінних). Документи, що описують її, також визначають модуль MIB для віддаленого налаштування параметрів.

Моделі безпеки

Перелічимо основні моделі безпеки та відповідні їм інфраструктури: 1. SNMPv1:

  • SNMPv1 - Community-based Security Model;

2. SNMPv2:

  • SNMPv2p - Party-based Security Model;
  • SNMPv2c - Community-based Security Model;
  • SNMPv2u - User-based Security Model;

3. SNMPv3

  • SNMPv3 USM User-based Security Model.

Модель безпеки на основі спільнот (Community-based Security Model) була першою, найпростішою і найбезпечнішою. Вона полягає лише у аутентифікації на основі «рядка спільноти», фактично, пароля, переданого по мережі в тексті повідомлення SNMP у відкритому вигляді. Ця модель безпеки не в змозі боротися ні з однією із загроз інформаційної безпеки в SNMP. Тим не менш, вона часто використовується до цих пір у зв'язку зі своєю простотою, а також завдяки наявності зовнішніх, не пов'язаних з SNMP систем безпеки, наприклад, міжмережевих екранів.

Модель безпеки на основі сторін (Party-based Security Model) передбачає введення поняття сторони. Сторона - це віртуальне оточення виконання, в якому набір допустимих операцій обмежений адміністративно. Сутність SNMP при обробці повідомлення діє як сторона, тому обмежена операціями, визначеними для цієї сторони. Сторона визначається наступними параметрами:

  • Унікальний ідентифікатор сторони;
  • Логічна мережева адреса (область адрес транспортного протоколу та адреса транспортного протоколу);
  • Протокол аутентифікації і параметри, що вимагаються для аутентифікації всіх повідомлень сторони;
  • Протокол шифрування і параметри, потрібні для шифрування всіх повідомлень сторони;

Можуть використовуватися різні алгоритми для протоколів аутентифікації і шифрування. Звичайно як алгоритму для протоколу аутентифікації використовують хеш-функцію Message Digest 5 (MD5), а для протоколу шифрування - алгоритм Data Encryption Standard (DES) в режимі Cipher Block Chaining (CBC).

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

Модель безпеки на основі користувачів (User-based Security Model) вводить поняття користувача, від імені якого діє сутність SNMP. Цей користувач характеризується ім'ям користувача, використовуваними протоколами аутентифікації і шифрування, а також закритим ключем аутентифікації і шифрування. Аутентифікація і шифрування є необов'язковими. Їх наявність описується одним з параметрів моделі, якістю обслуговування (Quality of Service, QoS). Модель безпеки багато в чому схожа на модель сторін, але вона спрощує ідентифікацію користувачів, розподіл ключів і протокольні операції.

Версії SNMP

Коротко опишемо відмінності між версіями SNMP і документи, що визначають ці версії. Зауважимо, що тут наведено перші версії RFC кожної з версій SNMP, тобто майже всі з них були заміщені новішими RFC і визнані застарілими. На даний момент єдиною не застарілою версією SNMP є SNMPv3, визначена в RFC 3411-3418.

SNMPv1

Перші RFC, що описують стандарти SNMP, з'явилися в 1988 році. Версія 1 піддалася критиці за її слабку модель безпеки на основі спільнот. У той час безпека в Інтернеті не входила в коло першочергових завдань робочих груп IETF.

1. Обробка повідомлень

  • RFC 1067. A Simple Network Management Protocol;

2. Обробка PDU

  • RFC 1067. A Simple Network Management Protocol;

3. Інформаційна модель

  • Структура керуючої інформації

RFC 1065. Structure and Identification of Management Information for TCP / IP-based internets

4. Модулі MIB

  • RFC 1066. Management Information Base for Network Management of TCP / IP-based internets

SNMPv2

Версія 2, відома, як Party-based SNMPv2, або SNMPv2p, не отримала широкого розповсюдження через серйозні розбіжності з приводу інфраструктури безпеки в стандарті.

SNMPv2 поліпшував версію 1 в області швидкодії, безпеки, конфіденційності і взаємодій «менеджер-менеждер». Він представив новий тип PDU Get-Bulk-Request, альтернативу Get-Next-Request для отримання великих обсягів інформації за допомогою одного запиту. Проте, нова система безпеки на основі сторін виглядала для багатьох як надто складна і не була широко визнана.

1. Загальна інформація

  • RFC 1441. Introduction to version 2 of the Internet-standard Network Management Framework
  • RFC 1452. Coexistence between version 1 and version 2 of the Internet-standard Network

Management Framework

2. Обробка повідомлень

  • Прив'язки до транспорту. RFC 1448. Transport Mappings for SNMPv2
  • Безпека. RFC 1446. Security Protocols for SNMPv2

3. Обробка PDU

  • Управління доступом. RFC 1445. Administrative Model for SNMPv2
  • Протокольні операції. RFC 1448. Protocol Operations for SNMPv2

4. Інформаційна модель

  • Структура керуючої інформації. RFC 1442. Structure of Management Information SNMPv2
  • Текстові конвенції. RFC 1443. Textual Conventions for SNMPv2
  • Вирази відповідності. RFC 1444. Conformance Statements for SNMPv2

5. Модулі MIB

SNMPv2c

Community-based SNMPv2, або SNMPv2c, представив SNMPv2 без нової моделі безпеки версії 2. Замість неї пропонувалося використовувати стару модель безпеки версії 1 на основі спільнот. Відповідну пропозицію RFC було прийнято тільки як чернетку стандарту, однак стало де факто стандартом SNMPv2. Безпека SNMP знову опинилася невирішеним питанням.

1. Обробка повідомлень

  • Безпека. RFC 1901. Introduction to Community-based SNMPv2

SNMPv2u

User-based SNMPv2, або SNMPv2u, є компромісом між незахищеністю SNMPv1 і надмірною складністю SNMPv2p. Запропонована модель безпеки на основі користувачів була покладена в основу SNMPv3.

1. Обробка повідомлень

  • Безпека. RFC 1909 - An Administrative Infrastructure for SNMPv2 RFC 1910 - User-based Security Model for SNMPv2

2. Обробка PDU

  • Управління доступом. RFC 1909. An Administrative Infrastructure for SNMPv2

SNMPv3

SNMPv3 нарешті вирішив проблеми з безпекою способом, який багато хто вважав прийнятним. Версія 3 SNMP прийнята IETF як стандарт Інтернету (IETF STD 62). Майже всі попередні RFC визнані застарілими.

1. Загальна інформація

  • RFC 3411. An Architecture for Describing SNMP Management Frameworks

2. Обробка повідомлень

  • Прив'язки до транспорту. RFC 3417. Transport Mappings for the SNMP
  • Розбір і диспетчеризація повідомлень. RFC 3412. Message Processing and Dispatching for the SNMP
  • Безпека. RFC 3414. User-based Security Model (USM) for SNMPv3

3. Обробка PDU

  • Операції протоколу. RFC 3416. Version 2 of the Protocol Operations for SNMP
  • Програми SNMP. RFC 3413. SNMP Applications
  • Управління доступом. RFC 3415. View-based Access Control Model (VACM) for the SNMP

4. Модулі MIB. RFC 3418. MIB for the SNMP

Існуючі реалізації

Підтримка SNMP - у багатьох значущих системах управління мережами, зокрема:

  • HP Network Node Manager;
  • IBM Tivoli NetView;
  • OpenNMS

Недоліки SNMP

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

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

Висновки

  • SNMP широко використовується для управління мережами, особливо IP-мережами
  • Успіх SNMP в порівнянні з іншими стандартами управління показує переваги процесу стандартизації IETF
  • Історія розвитку SNMP показує важливість завдань захисту інформації
  • Архітектура SNMP цікава для аналізу архітектури мережевого програмного забезпечення; вона відповідає поставленим перед SNMP цілям
  • Архітектура SNMP відповідає архітектурному стилю ULCSS мережевого програмного забезпечення
  • У SNMP для вирішення функцій 6 рівня моделі OSI RM використовується ASN.1, що незвично для стандартів IETF і позитивно впливає на питання формалізації протоколів, однозначності стандартів, зручності проектування додатків
  • Структура стандартів SNMP добре продумана і показова для вивчення стандартів
  • Лише деякі моделі безпеки SNMP відповідають поставленим перед системою безпеки SNMP цілям
  • Агенти та менеджери SNMP прості в програмній реалізації, проте завжди потрібно пам'ятати про інформаційну безпеку



Засоби моніторингу та аналізу мережі

Отримано з https://wiki.cusu.edu.ua/index.php?title=SNMP&oldid=57385