Управление коммутатором по snmp

Обновлено: 05.07.2024

Пример настройки коммутатора SNR для управления и мониторинга с использованием протоколов SNMP v2 и v3

В данном примере приведен возможный вариант конфигурации SNMP v2\v3 для коммутаторов серии SNR-2900.

snmp-server enable
snmp-server securityip x.x.x.x
snmp-server community rw 0 usergroup
snmp-server user user usergroup authPriv des auth md5
snmp-server group usergroup authpriv read view access 1
snmp-server view view 1.3.6.1.2.1.1. include

access-list 1 permit host-source x.x.x.x

Пример запроса для SNMP v3

snmpwalk -v3 -u user -l authPriv -a md5 -A useruser -x des -X useruser y.y.y.y

Ниже собраны примеры, часто запрашиваемые в технической поддержке для управления коммутаторами по протоколу SNMP.

Так как примеров управления существует великое множество — данная заметка будет периодически обновляться и дополняться.

Включение/выключение порта:

snmpset -v2c -c private x.x.x.x .1.3.6.1.2.1.2.2.1.7. N i 2

x.x.x.x — IP коммутатора,

2 — состояние порта (1 — вкл., 2 — выкл.)

snmpwalk -v2c -c private x.x.x.x .1.3.6.1.2.1.17.4.3.1.1

Выполнение VCT (Virtual-cable-test) и получение состояния:

Запустить VCT на порту:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.3.2.1.18.N i 1

Получить состояние VCT:

snmpget -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.3.2.1.19.N

x.x.x.x — IP коммутатора,

Сохранение настроек коммутатора:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.6.0 i 1

x.x.x.x — IP коммутатора

Перезагрузка коммутатора:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.1.0 i 3

x.x.x.x - IP коммутатора

Получение загрузки CPU коммутатора:

snmpget -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.11.10.0

x.x.x.x — IP коммутатора

Включение/выключение Flow Control на порту:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7 .100.3.2.1.6. N i 1

x.x.x.x — IP коммутатора,

1 — состояние Flow Control (1 — вкл, 0 — выкл)

Создать VLAN

Создаём VLAN 4001 с названием «test»:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.5.1.1.4. 4001 i 1

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.5.1.1.2. 4001 s «test»

Установить native VLAN на порту (switchport access vlan xxx):

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.3.2.1.16. N i M

x.x.x.x — IP коммутатора,

Включить AM (Access Management, IP-MAC-Port Binding) глобально:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.4.1.0 i 1

Выключить AM (Access Management, IP-MAC-Port Binding)глобально:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.4.1.0 i 2

Включить AM (Access Management, IP-MAC-Port Binding) ip-pool на порту N для IP-адреса y.y.y.y:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.4.2.1.2. N . y.y.y.y i 1

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.4.2.1.3. N.y.y.y.y i 1

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.4.2.1.6. N.y.y.y.y i 1

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.4.2.1.7. N.y.y.y.y i 1

Включить AM (Access Management, IP-MAC-Port Binding) mac-ip-pool на порту N для IP-адреса y.y.y.y и MAC-адреса zz-zz-zz-zz-zz-zz:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.4.2.1.2. N . y.y.y.y i 1

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.4.2.1.3. N.y.y.y.y i 2

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.4.2.1.5. N.y.y.y.y s « zz-zz-zz-zz-zz-zz »

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.4.2.1.7. N.y.y.y.y i 1

Выключить AM (Access Management, IP-MAC-Port Binding) на порту N для IP-адреса y.y.y.y

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.4.2.1.7. N.y.y.y.y i 2

Загрузка файлов на TFTP-сервер (Сохранение конфигурации на TFTP-сервер)

Перед сохранением конфигурации на TFTP-сервер, убедитесь в том, что пустой файл, в который будет сохраняться конфигурация, уже создан в папке TFTP-сервера.

1. Задаем IP-адрес TFTP-сервера:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.10.3.0 s « y.y.y.y »

2. Задаем имя файла на коммутаторе:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.10.4.0 s «startup.cfg»

3. Задаем имя файла на TFTP-сервере:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.10.5.0 s «backup-current.cfg»

4. Устанавливаем тип сервера (1-FTP, 2-TFTP):

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.10.7.0 i 2

5. Запускаем процедуру загрузки (1-Upload, 2-Download):

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.10.8.0 i 1

Проверка статуса выполнения команды:

snmpget -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.10.9.0

Результатом будет числовое значение текущего состояния:

Загрузка файлов с TFTP-сервера (Обновление ПО коммутатора)

1. Задаем IP-адрес TFTP-сервера:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.10.3.0 s « y.y.y.y »

2. Задаем имя файла на TFTP-сервере:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.10.4.0 s «6.2.138.103_nos.img»

3. Задаем имя файла на коммутаторе:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.10.5.0 s «nos.img»

4. Устанавливаем тип сервера (1-FTP, 2-TFTP):

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.10.7.0 i 2

5. Запускаем процедуру загрузки (1-Upload, 2-Download):

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.10.8.0 i 2

Проверка статуса выполнения команды:

snmpget -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.1.10.9.0

Результатом будет числовое значение текущего состояния:

Создание IP extended ACL

1. Включаем файрволл (firewall enable)

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.1.1 i 1

2. Создаём ACL c указанным номером (100-199)

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.1.1.4. 101 i 0

3. Создаём правило 1 и выбираем действие a (permit = 1, deny = 0)

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.4.1.4.101. 1 i 1

4. Выбираем протокол IP

2 — IGMP 4 — IP-IP

17 — UDP 47 — GRE

88 — EIGRP 89 — OSPF

103 — PIMv2 108 — PCP

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.4.1.5.101.1 i 6

5. Указываем source :

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.4.1.6.101.1 a y.y.y.y

Опционально wildcard (по умолчанию 255.255.255.255):

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.4.1.7.101.1 a a.a.a.a

Для настройки any-source, задаем source 1.1.1.1 и wildcard 255.255.255.255

6. Указываем destination :

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.4.1.8.101.1 a z.z.z.z

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.4.1.9.101.1 a b.b.b.b

Для настройки any-destination, задаем destination 1.1.1.1 и wildcard 0.0.0.0

7. Указываем source port (для IP/TCP/UDP, любой s-port = 0):

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.4.1.13.101.1 i 0

8. Указываем destination порт:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.4.1.15.101.1 i 135

9. Применяем правило:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.4.1.17.101.1 i 0

Создание MAC ACL

1. Включаем файрволл (firewall enable):

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.1.1 i 1

2. Создаём ACL с указанным номером (700-799):

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.1.1.4. 700 i 0

3. Создаём правило 1 и указываем действие (permit = 1, deny = 0)

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.5.1.4.700. 1 i 0

4. Указываем source MAC:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.5.1.5.700.1 s «xx-xx-xx-xx-xx-xx»

5. Указываем destination MAC (any-destination = 00-00-00-00-00-00)

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.5.1.6.700.1 s "00-00-00-00-00-00»

6. Применяем правило:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.3.5.1.7.700.1 i 0

Привязка ACL к порту

1. Создаём привязку с ID 1 (можно использовать любые значения) ACL 100 к порту 8:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.4.1.1.5.0. 8 . 1 .1 i 100

2. Чтобы включить traffic-statistics (порт 8, ID привязки 1):

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.10.1.4.1.1.6.0. 8 . 1 .1 i 1

QoS

1. Создаём class-map, привязываем к нему ACL и сохраняем его:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.11.2.2.1.2.N. < A.B.C>i 7

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.11.2.2.1.3.N. < A.B.C>s «X»

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.11.2.2.1.5.N. < A.B.C>i 0

N – количество символов в названии class-map

A.B.C. < …>– название class-map

X – номер или название ACL [a]

a = 97, b = 98, c = 99 и т. д.

0 = 48, 1 = 49, 2 = 50, 3 = 51 и т. д.

Например для class-map c1 и access-list 101:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.11.2.2.1.2 . 2.99.49 i 7

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.11.2.2.1.3. 2.99.49 s «101»

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.11.2.2.1.5. 2.99.49 i 0

2. Создаём policy-map с уникальным произвольным номером (например, 1) и сохраняем его:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.11.2.1.1.2. 10 s «PolicyMap1»

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.11.2.1.1.4. 10 i 0

N – номер policy map, любое уникальное число

3. Создаём связку policy-map и class-map и настраиваем параметры полисинга:

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.11.2.4.1.4. 10 .N. < A.B.C>b 1

N. < A.B.C>– то же самое, что и выше, название class-map.

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.11.2.4.1.5. 10 .N. < A.B.C>i 1024

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.11.2.4.1.6. 10 .N. < A.B.C>i 256

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.11.2.4.1.9. 10 .N. < A.B.C>b 0

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.11.2.4.1.15. 10 .N. < A.B.C>b 01

snmpset -v2c -c private x.x.x.x .1.3.6.1.4.1.40418.7.100.11.2.4.1.48. 10 .N. < A.B.C>i 0

4. Применяем policy-map к порту N:

snmpset -v2c -c private x.x.x.x 1.3.6.1.4.1.40418.7.100.11.2.11.1.4.0. N .1 s «PolicyMap1»

snmpset -v2c -c private x.x.x.x 1.3.6.1.4.1.40418.7.100.11.2.11.1.5.0. N .1 i 0

Управление ассоциациями с multicast vlan

snmpset -v2c -c … $IP_ADDRESS 1.3.6.1.4.1.40418.7.100.5.2.1.3.4090 s «$VLAN_ID» — любой влан, один либо последовательность, не переписывает список ассоциаций как таковой, просто задает список для дальнейшего сета
snmpset -v2c -c … $IP_ADDRESS 1.3.6.1.4.1.40418.7.100.5.2.1.4.4090 i 1 (1 — добавить, 0 — удалить вышезаданный список)

Протокол управления SNMP

Simple Network Management Protocol (SNMP) — это протокол прикладного уровня, он делает возможным обмен данными между сетевыми устройствами.

SNMP — это не продукт, а свод правил. Он определен Советом по архитектуре Интернета и является частью пакета TCP/IP. SNMP управляется и поддерживается Инженерной группой Интернета (IETF).

Протокол позволяет системному администратору проводить мониторинг, контролировать производительность сети и изменять конфигурацию подключенных устройств. SNMP используют в сетях любого размера: чем крупнее сеть, тем лучше раскрываются преимущества протокола. Он позволяет просматривать, контролировать и управлять узлами через единый интерфейс с функциями пакетных команд и автоматического оповещения.

Таким образом, SNMP избавляет администратора от необходимости ввода команд вручную. Всего были разработаны и развернуты три версии. Все они используются до сих пор, а самой распространенной стала вторая — SNMPv2с.

Архитектура SNMP


Схема SNMP. Источник: IMB

Компоненты, составляющие архитектуру SNMP:

  • сетевая станция управления, включающая в себя сетевого менеджера;
  • агенты;
  • мастер-агенты;
  • управляемые компоненты.

Сетевая станция управления — NMS

Network Management Station (NMS) удаленно мониторит управляемые устройства, получает данные, собранные мастер-агентами, отслеживает производительность и представляет полученную информацию в графическом виде. Встроенный менеджер NMS отвечает за связь с агентами.

Агенты

Мастер-агент

Это программа, связывающая сетевых менеджеров и субагентов. Мастер-агент анализирует запросы сетевого менеджера NMS и пересылает их субагентам, собирает и формирует ответы субагентов и отправляет их менеджеру. Мастер-агент уведомляет менеджера, если запрос некорректен или запрошенная информация недоступна.

Субагент

Это программа, поставляемая вендором вместе с сетевым устройством. Субагент пересылает собранную информацию мастер-агенту. У каждого управляемого компонента есть соответствующий субагент.

Управляемый компонент

Это подключенное к сети устройство или программное обеспечение с встроенным субагентом. К таким устройствам относятся не только маршрутизаторы, коммутаторы и серверы, но и IP-видеокамеры, МФУ и IP-телефоны. К софту с субагентами также относятся антивирусные программы, системы резервного копирования, ПО для систем ИБП.

База управляющей информации — MIB

MIB — это иерархическая база данных со сведениями об устройстве. У каждого типа устройства своя MIB-таблица: у принтера в ней содержится информация о состоянии картриджей, а у коммутатора — данные о трафике. Благодаря MIB менеджер знает, какую информацию он может запросить у агента устройства.

Идентификатор объекта — OID

Каждый объект в MIB имеет свой уникальный ID — OID, который представлен в числовом формате и имеет иерархическую структуру. OID — это числовой эквивалент пути к файлу. Он присваивает значения каждой таблице в MIB, каждому столбцу в таблице и каждому значению в столбце.

Используя первые 6 цифр этого OID, можно пройти по дереву на схеме.


Схематичное представление дерева OID. Источник: IBM

Часть значений в OID содержит данные о производителе устройства, что позволяет быстро получить определенную информацию о девайсе.

Древовидная иерархия MIB и OID в SNMP выглядит несколько запутанной, но у нее есть свои преимущества. Это простая и гибкая система организации сетевых устройств, она работает вне зависимости от размера сети.

Теория и логика работы протокола SNMP

Предназначение

Изначально протокол должен был предоставить системным администраторам инструмент для управления интернетом. Однако, гибкая архитектура SNMP позволила проводить мониторинг всех сетевых устройств и управлять ими с одной консоли. Это и стало причиной распространения SNMP.

Менеджеры и агенты обмениваются данными через протокол UDP. Вместо него также может использоваться TCP, IPX или протокол MAC-уровня. Обмен данными основан на Protocol Data Unit (PDU).

Всего в SNMP семь PDU:

TRAP, GETBULK — есть только во второй и третьей версиях протокола SNMP.

Схема PDU

IP заголовокTCP/IPTCP/IP
UDP заголовокTCP/IPTCP/IP
Версия SNMPv1/v2/v3PDU
Строка
сообщества		Public, PrivatePDU
Тип PDUGet, GetNext, Response, Set, Trap, GetBulk,
Inform		PDU
ID запросаИдентификатор запросаPDU
Статус ошибки0, 1, 2, 3, 4, 5PDU
Индекс ошибки0, 1PDU
Связанные
переменные		Одна или несколько переменных в
запросе		PDU

Применение

Статусы ошибок и их описание.

Сетевые порты SNMP

По умолчанию SNMP использует UDP-порты 161 и 162. Менеджер отправляет запросы на порт 161 агента. С порта 161 агент отправляет ответ менеджеру. При отправке запроса менеджер добавляет к нему ID, а агент вставляет этот ID в ответ, чтобы менеджер мог связать свой запрос с ответом агента.

Ловушки

Ловушка (Trap) — это важнейший способ коммуникации в SNMP. Менеджер отвечает за большое количество устройств, на многих из них может быть несколько управляемых компонентов. Агент отправляет ловушку по своей инициативе, когда необходимо сообщить менеджеру о событии. Например, ловушка может выслать отчет о перегреве машины или о том, что в тонере закончились чернила.

Получив уведомление, менеджер выбирает нужное действие, например, опрашивает агента, чтобы получить полное представление о том, что произошло. Перечень уведомлений, которые посылает ловушка:

Версии протокола SNMP

SNMPv1

Первая версия протокола создана в 80-х годах XX века. Легка в настройке — требуется только строка community. Версия широко используется до сих пор.

SNMPv2с

Вторая версия протокола SNMP появилась в 1993 году. Разработчики добавили в нее новый запрос GetBulk и ловушку Inform, а также усовершенствовали безопасность.

У этой версии есть два способа коммуницировать с устройствами, поддерживающими SNMPv1: двуязычная система сетевого управления и прокси-агенты. Прокси-агенты выполняют роль мастер-агентов, а в двуязычной системе управления менеджер определяет, какую версию SNMP поддерживает агент, и связывается с ним через SNMPv1 или SNMPv2c.

SNMPv3

Третья версия вышла в 1998 году. Разработчики добавили в SNMP криптографическую защиту, облегчили удаленную настройку и администрирование объектов. Этого удалось достичь за счет определения набора стандартизованных объектов управления, называемых объектами MIB удаленного сетевого мониторинга, — RMON MIB.

Безопасность

Изначально безопасность не была первоочередной задачей разработчиков. Первая версия SNMP была создана для удаленного администрирования во времена, когда угроза несанкционированного доступа была минимальной. Поэтому SNMPv1 слабо защищена от взлома, и злоумышленники могли использовать ее для проникновения в сетевую инфраструктуру.

В работе над второй версией протокола разработчики предложили несколько вариантов решения. Распространение получил вариант SNMPv2c — не самый надежный, но простой в использовании.

Основная проблема с безопасностью в том, что почти все оборудование поддерживает версию SNMPv1. И только часть работает с версиями SNMPv2с и SNMPv3. Именно поэтому самой популярной стала SNMPv2с. Она способна работать с устройствами, которые поддерживают первую или вторую версии SNMP.

Модели безопасности протоколов SNMP по версиям

SNMPv1Community–based security
SNMPv2cCommunity–based security
SNMPv2uUser–based security
SNMPv2Party–based security
SNMPv3User–based security

Community-based Security — модель безопасности на основе строки сообщества. Фактически это идентификатор пользователя или пароль, который отправляется вместе с запросом. Если строка сообщества неверна, агент игнорирует запрос.

Строка сообщества зависит от вендора устройства. Часто вендоры по умолчанию выбирают «PUBLIC» в качестве пароля, поэтому первым делом на новых устройствах нужно изменить строку сообщества для защиты сети от злоумышленников.

Строки сообщества бывают трех видов:

  • только для чтения — позволяет получать данные с устройства;
  • чтение/запись — позволяет получать данные и изменять конфигурацию устройства;
  • строка сообщества SNMP Trap — позволяет получать ловушки.

Строка сообщества широко используется из-за своей простоты и наличия внешних систем безопасности.

Party-based Security Model — модель на основе так называемых «сторон». Для коммуникации между менеджером и агентов выбирается логическая сущность, называемая стороной. Она устанавливает протоколы аутентификации и шифрования, а отправитель и получатель соглашаются со способом шифрования и дешифровки данных. Сложность использования модели помешала ее распространению среди пользователей.

User-based Security Model — модель безопасности на основе пользователей. Уровни аутентификации, безопасности и конфиденциальности протоколов и ключей настраиваются у агента и менеджера.

Лучше всего безопасность проработана в третьей версии SNMP за счет USM и VACM. Упрощенно VACM (View-based Access Control Model) можно описать как модель с разными уровнями доступа для групп менеджеров. При получении запроса агент решает, разрешен ли определенной группе менеджеров доступ к чтению, записи и получению уведомлений.

Типичные проблемы безопасности

  • Периметр сети может быть небезопасен, если запросы SNMP разрешены межсетевыми экранами и пакетными фильтрами.
  • При активации функций SNMP на некоторых устройствах имя строки сообщества по умолчанию PUBLIC. Хакер начнет поиск именно с этого.
  • Прекращение отправки ловушек. Изменив запись в команде snmpEnableAuthenTraps, злоумышленник может прекратить отправку ловушек. В случае неудачной аутентификации он может не беспокоиться о том, что его безуспешные попытки взлома привлекут внимание администратора сети.
  • Удаленный пакетный перехват при помощи снифферов — программ анализа сетевого трафика.
  • Слабый контроль доступа к строке сообщества чтение-запись. Она дает всем пользователям возможность изменять конфигурацию устройств сети SNMP. Администратор должен внимательно следить за этим, иначе бесконтрольное изменение конфигураций поможет злоумышленнику нанести вред системе.

Если системный администратор не использует SNMP, то он должен отключить его на устройствах.

Практическое применение протокола

С помощью SNMP администратор управляет приложениям и облачными сервисами, администрирует локальную сеть и контролирует состояние сервера с одной консоли.

Возможности SNMP-протокола

Благодаря протоколу администратор может:

При помощи стороннего ПО можно также:

  • управлять облачными сервисами;
  • сканировать по диапазону IP-адресов;
  • добавлять данные через кастомные OID.

SNMP и переход с IPv4 на IPv6

Протокол по умолчанию должен работать с IPv4 или IPv6. На практике IPv6 создает определенные проблемы для работы SNMP. Эти проблемы связаны объектами MIB, содержащими сетевые адреса. OID в MIB хранят информацию для нескольких уровней TCP/IP, и различия между IPv4 и IPv6 будут отражены в OID.

Отсутствие поддержки IPv6 в существующих объектах MIB проявляется двумя способами:

  • объекты MIB поддерживают только IPv4, но не IPv6;
  • содержащиеся в OID IPv4-адреса не обязательно представляют собой IP-адрес.

Эти проблемы решаются также двумя способами:

  • созданием новых баз MIB с поддержкой только IPv6 или независимых от версий протокола Protocol-version independent (PVI);
  • модификацией MIB для добавления новых или обновления существующих OID с поддержкой IPv6.

Инсталляция

Настройка SNMP в Windows

Она подробно описана в документации Microsoft.

Настройка данных агента SNMP

Пуск → Панель управления → Администрирование → Управление компьютером.

  1. В дереве консоли надо развернуть узел «Службы и приложения» и выбрать пункт «Службы».
  2. В области справа дважды щелкнуть элемент «Служба SNMP».
  3. Затем открыть вкладку «Агент».
  4. Ввести имя пользователя или администратора компьютера в поле «Контакт», а затем ввести физическое расположение компьютера или контакта в поле «Расположение». Эти комментарии обрабатываются как текст и являются необязательными.
  5. В разделе «Служба» надо установить флажки рядом со службами, предоставляемыми компьютером и нажать «OK».

Настройка сообщества и ловушек SNMP

Пуск → Панель управления → Администрирование → Управление компьютером.

  1. В дереве консоли надо развернуть узел «Службы и приложения» и выбрать пункт «Службы».
  2. В области справа дважды щелкнуть элемент «Служба SNMP».
  3. Открыть вкладку «Треппинг».
  4. В поле «Имя сообщества» ввести имя сообщества и нажать кнопку «Добавить в список».
  5. В разделе «Адресаты ловушек» нажать кнопку «Добавить».
  6. В поле «Host Name» ввести имя, IP-адрес узла и нажать «Добавить». Имя узла или адрес появится в списке назначение ловушек.
  7. Нажать «ОК».

Настройка безопасности SNMP

Пуск → Панель управления → Администрирование → Управление компьютером.

  1. В дереве консоли нужно развернуть узел «Службы и приложения» и выбрать пункт «Службы».
  2. В области справа дважды щелкнуть элемент «Служба SNMP».
  3. Открыть вкладку «Безопасность».
  4. Установить флажок «Пересылка ловушек проверки подлинности», если необходимо, чтобы агент отправлял ловушку при сбое проверки подлинности.
  5. В разделе «Приемлемые имена сообществ» надо нажать кнопку «Добавить».
  6. В поле «Права сообщества» выбрать разрешения, чтобы указать, как узел будет обрабатывать запросы SNMP от выбранного сообщества.
  7. В поле «Имя сообщества» ввести нужное имя сообщества с учетом регистра, а затем нажать кнопку «Добавить».
  8. Затем, чтобы принимать запросы SNMP от любого узла в сети, независимо от их удостоверения, надо выбрать вариант «Принимать пакеты SNMP с любого узла».
  9. Чтобы ограничить принятие пакетов SNMP, нужно нажать «Принимать пакеты SNMP с этих компьютеров», затем нажать «Добавить» и ввести в поле имя узла, IP-адрес или IPX-адрес соответствующего узла. Нажать «Добавить», а затем «ОК».

Настройка SNMP в Linux

Настройка SNMP в CentOS 7

Сначала нужно установить последние обновления при помощи yum/dnf:

затем установить SNMP:

и создать копию конфигурационного файла:

теперь нужно отредактировать настройки агента

и добавить строки:

Локацию и email лучше указать реальные.

Пора добавить сервис в автозагрузку и перезапустить его:

Как проверить, что сервис запущен:

Опрос агента с помощью утилиты snmpwalk:

Опрос сервера локально командой:

Настройка SNMP в Debian 10

Сначала нужно установить демона, клиента и файлы:

После установки переходим к настройке SNMP в Debian.

Файлом настройки SNMP-агента по умолчанию является /etc/snmp/snmpd.conf. Агент SNMP может быть запущен с настройками по умолчанию. Однако для включения удаленного мониторинга нужно сделать несколько изменений. Для этого создайте резервную копию файла:

Теперь нужно изменить директиву agentAdress. Ее текущие настройки разрешают доступ только с локального компьютера. Для включения удаленного мониторинга необходимо определить IP-адрес интерфейса:

Для настройки аутентификации:

rocommunity предоставляет доступ только на чтение, а rwcommunity дает доступ к чтению/записи. В Access Control section нужно поместить строку

rocommunity S3CUrE 192.168.43.100

Кроме того, можно включить запрос с локального хоста rocommunity S3CUrE localhost:

Затем нужно перезапустить SNMP:

Чтобы добавить сервис в автозагрузку, введите:

SNMP — это простой и эффективный способ для сбора и обмена информацией между сетевыми устройствами, которые выпущены разными вендорами и работают на разном ПО. Этот протокол — не идеальное, но все еще одно из лучших решений для мониторинга и управления. На сегодняшний день нет другого инструмента с сопоставимым уровнем поддержки и использования.

Созданный 30 лет назад SNMP продолжает работать, потому что он обладает характеристиками, которых нет ни у одной из его аналогов. Он простой в использовании, бесплатный и поддерживается практически всеми вендорами.

В течении многих лет мы, ввиду специфики работы, постоянно сталкиваемся с необходимостью съема FDB-таблиц (Forwarding DataBase) управляемых коммутаторов с данными о коммутации MAC-адресов абонентов и устройств. За это время мимо нас прошли несколько сотен различных моделей устройств многих производителей, а количество версий их прошивок сложно сосчитать. Накопив опыт – можно им и поделиться.

В данном случае затронем лишь тему съема требуемых данных по SNMP-протоколу.

Заранее отмечу, что мы не лоббируем и не стараемся принизить какого-то вендора или модель. Приведённые для примера модели указаны в информационных целях и были в момент написания статьи под рукой.

Итак – SNMP-метод съема информации
  • удобство подключения по SNMP – есть библиотеки и стандартные функции под многие языки программирования. Нет нужды греть голову с Telnet-подключением и авторизацией (отдельная тема);
  • некоторые модели бюджетных коммутаторов вообще не имеют возможности Telnet-подключений;
  • в большинстве случаев используются стандартные OID для получения требуемой информации.
  • скорость получения информации. Достаточно медленно на объемах (съем 2000 MAC-адресов через snmpwalk займет, в лучшем случае, около 40 секунд, в то время как Telnet их выдаст моментально);
  • SNMP сильнее нагружает процессор коммутатора – в некоторых случаях под 100% при съеме больших объемов на бюджетных моделях;
  • для каждого VLAN (а их могут быть сотни) часто требуется отдельное подключение (об этом ниже);
  • иногда различаются особенности реализации функционала у разных вендоров и моделей.
Немного теории

В FDB-таблице коммутатора содержатся записи о том какой MAC-адрес на каком интерфейсе коммутатора находится. Важное уточнение – интерфейсе это не порт. Это МОЖЕТ быть порт, а может быть – номер VLAN или прочий логический объект. А так как нам требуется именно знать номер порта, то, собственно, вся дальнейшая процедура и затевается.

Порядок получения информации

    Получаем список VLAN
    для большинства коммутаторов:


выдаст соотношение «порт-интерфейс» для VLAN ID: 999

Дело в том, что в некоторые VLAN может быть отдана часть портов, в другие VLAN – другая часть и т.д. И только опросив все VLAN можно сложить общую картину по устройству. Пример по Cisco WS-C3550-48 – записи первого VLAN:


В него отдано только 5 портов. В данном случае номера интерфейсов совпадают с номерами портов.


Возвращаемые данные состоят из трех логических частей — собственно MAC-адрес, номер интерфейса и тип записи, а именно:


Записи отличаются одиннадцатым (в данном примере) разрядом (1, 2, 3) и характеризуют какой именно параметр содержится в значении.

Однако дьявол в деталях — иногда данные возвращаются испорченными


Поэтому не мешает выполнять проверку на валидность MAC-адреса.

А иногда для MAC-адреса может не найтись второй и третьей записи (номер интерфейса и тип записи). SNMP такой SNMP….


В начале – поступит информация о количестве записей в каждом из VLAN. К сожалению она иногда не соответствует действительности.

К примеру в FoxGate S6224-S4 показало:

  • VLAN 1: 22
  • VLAN 82: 1
  • VLAN 130: 4
  • VLAN 888: 115
  • VLAN 2085: 4
  • 6 блоков (0.12.66.164.241.225) – MAC-адрес в десятичной форме
  • 1 блок (888) – номер VLAN

Однако Cisco может и не выдать таблицу по всем OID


И тогда начинается увлекательное занятие – подключение к каждому VLAN и съем с него таблицы, указанной пунктом выше.

Важные моменты
  • если на коммутаторе много VLAN (сотня-другая) – то можно даже не пытаться снимать FDB-таблицу по нему. Никаких вменяемых таймаутов не хватит – обходить их все. Это будет очень долго.
  • индивидуальные решения под разные модели. Тут речь о местном допиливании итоговых данных. Alcatel OmniStack LS 6224 и Allied Telesyn AT-8000S/24 – хоть возвращаются номера портов 49-52, но в реальности у коммутаторов портов меньше и тут используется прошивка со старших моделей. Требуется заменить 49 порт на 25, 50 на 26 и т.д.
  • в некоторых случаях таблица соответствия ИНТЕРФЕЙС-ПОРТ даёт противоречивые данные. Huawei S2326TP-EI-AC хоть и даёт таблицу соответствия, но при этом в FDB выводятся данные с номерами ПОРТОВ, а не интерфейсов и стандартные приёмы преобразования номеров интерфейсов ведут к неправильным данным (двойное преобразование)
  • у стекируемых коммутаторов и у шасси будут особые номера интерфейсов
  • часть бюджетных моделей коммутаторов вообще не выдаст информацию о FDB-таблице по всем VLAN. Не предусмотрено производителем. Пример: D-Link DES-21XX

Несмотря на все вышеуказанные «особенности», SNMP-протокол остаётся самым востребованным и удобным методом получения FDB-таблицы. В большинстве случаев нет необходимостей указанных танцев с бубном и обычный годный D-Link, имеющий единственный VLAN, сходу выдаст красивый список с MAC-адресами, и номера портов будут совпадать с интерфейсами, но как знать…

Если статья будет востребована – в следующий раз расскажу особенности съема по Telnet.

Протокол SNMP (Simple Network Management Protocol ) является протоколом 7 уровня модели OSI , который специально разработан для управления и мониторинга сетевых устройств. Протокол SNMP входит в стек протоколов TCP/IP и позволяет администраторам сетей получать информацию о состоянии устройств сети, обнаруживать и исправлять неисправности и планировать развитие сети.

В настоящее время существует три версии протокола SNMP : SNMP v1 ( RFC 1157), SNMP v2c ( RFC 1901-1908) и SNMP v3 ( RFC 3411-3418). Эти версии отличаются предоставляемым уровнем безопасности при обмене данными между менеджером и агентом SNMP . Коммутаторы D-Link поддерживают все три версии протокола.

Компоненты SNMP

Сеть, управляемая по протоколу SNMP, основывается на архитектуре "клиент/сервер" и состоит из трех основных компонентов: менеджера SNMP, агента SNMP, базы управляющей информации.

Компоненты SNMP

Менеджер SNMP (SNMP Manager) — это программное обеспечение, установленное на рабочей станции управления, наблюдающее за сетевыми устройствами и управляющее ими.

Агент SNMP (SNMP Agent) — это программный модуль для управления сетью, который находится на управляемом сетевом устройстве (маршрутизаторе, коммутаторе, точке доступа, Интернет-шлюзе, принтере и т.д.). Агент обслуживает базу управляющей информации и отвечает на запросы менеджера SNMP.

База управляющей информации (Management Information Base, MIB ) — это совокупность иерархически организованной информации, доступ к которой осуществляется посредством протокола управления сетью.

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

База управляющей информации SNMP

Базы управляющей информации описывают структуру управляющей информации устройств и состоят из управляемых объектов (переменных).

Управляемый объект (или MIB -объект) — это одна из нескольких характеристик управляемого сетевого устройства (например, имя системы, время, прошедшее с ее перезапуска, количество интерфейсов устройства, IP-адрес и т.д.).

Обращение к управляемым объектам MIB происходит посредством идентификаторов объекта ( Object IDentifier , OID ). Каждый управляемый объект имеет уникальный идентификатор в пространстве имен OID и контролируется агентством IANA . Пространство имен OID можно представить в виде иерархической структуры с корнем без названия, идентификаторы верхних уровней которой отданы организациям, контролирующим стандартизацию, а идентификаторы нижних уровней определяются самими этими организациями. Каждая ветвь дерева OID нумеруется целыми числами слева направо, начиная с единицы. Идентификатор представляет собой последовательность целых десятичных цифр, разделенных точкой, записанных слева направо и включает полный путь от корня до управляемого объекта. Числам могут быть поставлены в соответствие текстовые строки для удобства восприятия. В целом структура имени похожа на систему доменных имен Интернета (Domain Name System, DNS).

Пространство имен OID

Производители сетевого оборудования определяют частные ветви пространства имен OID (группа объектов private (4)), куда помещают управляемые объекты для своей продукции. Так, D-Link в качестве вершины иерархии для своей продукции использует OID , равный 1.3.6.1.4.1.171 .

Помимо непосредственного описания данных необходимо вести операции над ними. Первоначальная спецификация MIB -I определяла только операции чтения значений переменных. Спецификация MIB -II дополнительно определяет операции изменения или установки значений управляемых объектов.

Версия SNMP v.2 добавляет к этому набору команду GetBulk , которая позволяет менеджеру получить несколько переменных за один запрос.

Безопасность SNMP

В протоколе SNMP v.1 и v.2c предусмотрена аутентификация пользователей, которая выполняется с помощью строки сообщества ( Community string ). Строки Community string функционирует подобно паролю, который разрешает удаленному менеджеру SNMP доступ к агенту. Менеджер и агент SNMP должны использовать одинаковые строки Community string , т.к. все пакеты от менеджера SNMP, не прошедшего аутентификацию, будут отбрасываться. В коммутаторах с поддержкой SNMP v.1 и v.2c используются следующие Community string по умолчанию:

  • public — позволить авторизованной рабочей станции читать (право "read only") MIB -объекты;
  • private — позволить авторизованной рабочей станции читать и изменять (право "read/write") MIB -объекты.
Внимание: Community string передаются по сети в открытом виде.

Протокол SNMP v.3 использует более сложный процесс аутентификации, который разделен на две части. Первая часть — обработка списка и атрибутов пользователей , которым позволено функционировать в качестве менеджера SNMP. Вторая часть описывает действия, которые каждый пользователь из списка может выполнять в качестве менеджера SNMP.

На коммутаторе SNMP можно создавать группы со списками пользователей (менеджеров SNMP) и настраивать для них общий набор привилегий. Помимо этого, для каждой группы может быть установлена версия используемого ею протокола SNMP. Таким образом, можно создать группу менеджеров SNMP, которым позволено просматривать информацию с правом "read only" или получать ловушки ( trap ), используя SNMP v.1, в то время как другой группе можно настроить наивысший уровень привилегий с правами "read/write" и возможность использования протокола SNMP v.3.

Читайте также: