Системы и протоколы управления сетей телекоммуникаций

Тема 3.2. Версии SNMP и протокол RMON

План занятия

Источники: Гребешков А. Ю., с. 103–110; RFC 3414, 3416, 3826, 7860, 2819. Второй час — ОКР № 1

1. Версии и безопасность

v1, v2c, v3: почему понадобилась защита

2. Архитектура SNMPv3

Машина протокола, приложения, представления

3. Защита сообщений

Угрозы, уровни защиты, алгоритмы, окно 150 с

4. RMON

Зонды и девять групп RFC 2819

Почему понадобились новые версии

Гребешков, с. 90, 97, 109–110; RFC 3416

SNMPv1

Защита — только имя сообщества, открытым текстом. Перехватил — может и читать, и менять (Set)

CERT CA-2002-03

Предупреждение о множестве уязвимостей в реализациях SNMP

SNMPv2c

+ GetBulk, Inform, Counter64, новые коды ошибок; защита — прежняя (c — community)

SNMPv3

Модульная архитектура, пользователи, проверка подлинности, шифрование, разграничение доступа

  • Перехвативший имя сообщества может не только читать, но и менять настройки запросом SetRequest.
  • Модель защиты, задуманная в SNMPv2, не прижилась — на практике используется v2c (c — от community).
  • SNMPv3 работает как агент, менеджер или в совмещённом режиме и обрабатывает сообщения v1 и v2 — преемственность (Гребешков, с. 103).

Машина протокола SNMPv3

Гребешков, рис. 5.7, с. 104–107

Диспетчер (выбор по версии)

Обработка сообщений (v1, v2, v3)

Подсистема безопасности

Разграничение доступа (view)

Приложения: команды, уведомления, proxy

Машина протокола есть и у менеджера, и у агента. Представления (view) дают каждому пользователю своё подмножество MIB — отдельно для чтения, записи и уведомлений.

  • Диспетчер по номеру версии в заголовке выбирает способ обработки; подсистема обработки добавляет заголовок при передаче и извлекает PDU при приёме.
  • Приложения: генерация команд (менеджер), выполнение команд (агент), создание и приём уведомлений, доверенное перенаправление — proxy (с. 107).
  • Пример представлений: дежурному оператору открыто чтение всей MIB, а запись — ни в один объект.

Угрозы и защита

RFC 3414, разд. 1.1; Гребешков, с. 106–107

Угроза

Защита в SNMPv3

изменение сообщения

есть — код аутентификации

маскарад

есть — ключ пользователя

перехват и чтение

есть — шифрование

повтор, задержка

частично — окно 150 с

отказ в обслуживании

нет

анализ трафика

нет

  • USM — модель безопасности на основе пользователей (User-based Security Model), RFC 3414.
  • Отказ в обслуживании неотличим от потока сообщений при массовых отказах — с ним должен справляться любой протокол управления (Гребешков, с. 106–107).
  • Окно 150 с: машина SNMP хранит число своих перезагрузок и время работы; сообщение старше окна отбрасывается — перехваченный пакет нельзя «проиграть» через час.

ПроверкаОт чего защищает SNMPv3?

RFC 3414, разд. 1.1. Разложите угрозы по колонкам

Изменение сообщения в пути Маскарад — выдать себя за другого Перехват и чтение Повтор и задержка сообщения Отказ в обслуживании Анализ трафика
Защищаеткод аутентификации, ключ пользователя, шифрование
Частичноокно 150 с
Не защищает

Уровни защиты и алгоритмы

RFC 3414, 3826, 7860; Гребешков, с. 106

noAuthNoPriv

Без проверки и шифрования — например, при обнаружении агента

authNoPriv

Проверка подлинности: HMAC-MD5-96 (обязателен), HMAC-SHA-96; позднее SHA-2

authPriv

+ шифрование: DES-CBC, позднее AES. Шифровать без проверки нельзя

На практике

authPriv с SHA и AES; MD5 и DES — только для старого оборудования (учебное толкование)

  • Формат сообщения v3 (Гребешков, рис. 5.8): msgVersion = 3, msgID, msgMaxSize (от 484 байт), msgFlags — уровень защиты, msgSecurityModel (1 — v1, 2 — v2c, 3 — USM), параметры безопасности, contextEngineID, contextName, PDU.
  • Часть сообщения с PDU может идти открытым или зашифрованным текстом.

КонструкторУровень защиты пользователя SNMPv3

RFC 3414, 3826, 7860. Выберите проверку подлинности и шифрование

Проверка подлинности (auth)
Шифрование (priv)
Уровень

Сравнение версий

Гребешков, с. 90–110; RFC 3414, 3416; последняя строка — учебное толкование

Признак

v1

v2c

v3

Защита

сообщество

сообщество

пользователи, HMAC, шифрование

Доступ

чтение / запись

чтение / запись

представления

Операции

Get, GetNext, Set, Trap

+ GetBulk, Inform

как v2

Counter64

нет

есть

есть

Применять

старое оборудование

мониторинг в закрытой сети

управление (Set)

RMON: девять групп

RFC 2819; ветвь mib-2 16 = 1.3.6.1.2.1.16

№

Группа

Что делает

1–2

statistics, history

статистика интерфейса и её история

3

alarm

пороги → событие

4–6

hosts, hostTopN, matrix

узлы, самые активные, пары «кто с кем»

7–8

filter, capture

отбор и сохранение кадров

9

event

события и журнал

Зонд (probe) ставят на сегмент сети; он сам считает и следит за порогами, а менеджер читает итог по SNMP. Связка alarm + event разгружает сеть управления.

  • Обычный агент знает только о своём устройстве; зонд видит сегмент в целом — кто больше всех передаёт, какие кадры повреждены.
  • Функции зонда может выполнять встроенный модуль коммутатора.
  • RMON по RFC 2819 работает на канальном уровне; RMON2 добавляет статистику сетевого и прикладного уровней.

Перед ОКРКакая версия SNMP?

Гребешков, с. 90–110; RFC 3414, 3416. Разложите признаки по версиям

Только Get, GetNext, Set, Trap Нет Counter64 Появились GetBulk и Inform Counter64 есть, защита — прежнее сообщество Пользователи и HMAC Шифрование DES / AES Представления (view) для разграничения доступа Окно 150 с против повтора Предупреждение CERT CA-2002-03 об уязвимостях реализаций
SNMPv1
SNMPv2c
SNMPv3

Итог

Второй час — обязательная контрольная работа № 1

v1 и v2c

Сообщество открытым текстом; v2 — GetBulk, Inform, Counter64

v3

Пользователи, HMAC, шифрование, окно 150 с, представления

Не защищает

От отказа в обслуживании и анализа трафика

RMON

Зонд в сегменте, 9 групп, mib-2 16

Конец занятия