Реализация SNMP v3 на примере Coriant hiT7300

3 версия протокола SNMP (Simple Network Management Protocol) появилась достаточно давно в ответ на слабые возможности 2 версии в аспекте безопасности. Однако, несмотря на доступность и широкое распространение описаний версии 3 протокола[1], существует мало описаний реализаций, основанных на SNMP v3. Текущий пост отражает опыт автора по исследованию дампов обмена ‘Coriant Element Manager GUI’ (далее EM) и Multi-Haul Transport Platform hiT7300 (далее hiT).

Мы рассмотрим серию SNMP get и set запросов, выдаваемых EM в момент запуска и аутентификации приложения, и ответы hiT на эти запросы. Прежде чем углубиться в последовательность и содержание запросов, необходимо обратить внимание на следующее:

  1)      Клиент(EM), для успешной аутентификации, должен обладать информацией о следующих USM параметрах (RFC 3414):

·         Username – напр. ‘Administrator’,

·         Authentication protocol – MD5,

·         Authentication key - напр. ‘12345’,

·         Privacy protocol – AES,

·         Privacy key – напр. ‘12345’,

·         Context name – ‘tnms’.

  2)      При создании UDP соединения на клиентской стороне операционной системой производится выделение ‘source port’ (не путать с ‘destination port’, который для SNMP по умолчанию 161). Значение ‘source port’ может изменяться при различных запусках клиентского приложения. В рассматриваемой реализации значение ‘source port’ используется при динамическом формировании OID. Например, при выделении ‘source port’ = 60583, имеем побайтово 0xEC и 0xA7, и динамический суффикс в составе OID вида ‘.236.167’.

  

  3)      Собственный IP адрес известен клиентской стороне и используется при динамическом формировании OID. Например, для IP адреса клиента ’10.60.1.5’ в составе OID некоторых запросов будет присутствовать часть ’.10.60.1.5.’.

  4)      Упомянутое выше значение Username используется также при формировании OID. Например, для ‘Administrator’ в составе OID некоторых запросов будет присутствовать часть ’ .65.100.109.105.110.105.115.116.114.97.116.111.114.’ (ASCII).

Обратимся теперь к последовательности и содержанию get и set запросов при запуске EM, аутентификации и создании сессии (часть дампа далее не приводится):

Запросы 1 и 2. В соответствии с RFC 5343 производим "discovery" параметров EngineID, EngineBoots и EngineTime,

Request:

data: get-request,

msgData: plaintext,

variable-bindings: -

Answer:

data: report,

msgData: plaintext,

variable-bindings: (1 item)

1.3.6.1.6.3.15.1.1.4 (usmStatsUnknownEngineIDs)(Integer32) ==> 1.

Интересно, что полученные значения EngineBoots и EngineTime используются, начиная с запроса 4, а в запросе 3 для них необходимо установить нулевые значения.

Запрос 3. Запрос usmStatsNotInTimeWindows

Request:

data: get-request,

msgData: encryptedPDU,

variable-bindings: -

Answer:

data: report,

msgData: encryptedPDU,

variable-bindings: (1 item)

1.3.6.1.6.3.15.1.1.2.0 (usmStatsNotInTimeWindows)(Integer32) ==> 0.

Общее количество пакетов, полученных SNMP engine вне авторитативного окна.

Запрос 4. Запрос snmpAgentState.

Request:

data: get-request,

msgData: encryptedPDU,

variable-bindings: (1 item)

1.3.6.1.4.1.42229.1.1.1.7.128.6.0

Answer:

data: get-responce,

msgData: encryptedPDU,

variable-bindings: (1 item)

1.3.6.1.4.1.42229.1.1.1.7.128.6.0 (snmpAgentState)(Integer32) ==> 3(ENABLED).

Состояние агента.

Запрос 5. Запрос sysDescr

Request:

data: get-request,

msgData: encryptedPDU,

variable-bindings: (1 item)

1.3.6.1.2.1.1.1.0 (sysDescr)

Answer:

data: get-responce,

msgData: encryptedPDU,

variable-bindings: (1 item)

1.3.6.1.2.1.1.1.0 (sysDescr)==> ’--------- Copyright 2019 Coriant. All rights reserved.’ (OctetString)

Запрос 6. Запрос interfaceVersion структурно аналогичен 4 и 5.

Запрос 7. Запрос usmXUserLastSuccessfulLogin

Request:

data: get-request,

msgData: encryptedPDU,

variable-bindings: (1 item)

1.3.6.1.4.1.42229.1.1.1.9.2.1.13.13.65.100.109.105.110.105.115.116.114.97.116.111.114

Answer:

data: get-responce,

msgData: encryptedPDU,

variable-bindings: (1 item)

1.3.6.1.4.1.42229.1.1.1.9.2.1.13.13.65.100.109.105.110.105.115.116.114.97.116.111.114 (usmXUserLastSuccessfulLogin)

==> 07:e3:09:0a:06:1f:36:00:2b:00:00(OctetString)

 ==>2019-09-10 и т.д.

Непосредственно в OID включено Username (‘Administrator’) -’.65.100.109.105.110.105.115.116.114.97.116.111.114.’ , для которого запрашивается время его последней успешной аутентификации.

Запрос 8. Запрос создания сессии

Request:

data: set-request,

msgData: encryptedPDU,

variable-bindings: (4 items)

1.3.6.1.4.1.42229.1.1.1.9.6.1.2.6.10.60.1.5.236.167==>4(Integer32)==> createAndGo    1.3.6.1.4.1.42229.1.1.1.9.6.1.5.6.10.60.1.5.236.167==>2(Integer32)==> sessionRemoteLogin

1.3.6.1.4.1.42229.1.1.1.9.6.1.3.6.10.60.1.5.236.167==>41646d696e6973747261746f72(OctetString)==> sessionUserName(‘Administrator’)

1.3.6.1.4.1.42229.1.1.1.9.6.1.4.6.10.60.1.5.236.167==> 4043542020(OctetString)==>sessionManager ==> 'root'

Answer:

data: get-responce,

msgData: encryptedPDU,

variable-bindings: (4 items)

1.3.6.1.4.1.42229.1.1.1.9.6.1.2.6.10.60.1.5.236.167==>4(Integer32)==> createAndGo    1.3.6.1.4.1.42229.1.1.1.9.6.1.5.6.10.60.1.5.236.167==>2(Integer32)==> sessionRemoteLogin

1.3.6.1.4.1.42229.1.1.1.9.6.1.3.6.10.60.1.5.236.167==>41646d696e6973747261746f72(OctetString)==> sessionUserName(‘Administrator’)

1.3.6.1.4.1.42229.1.1.1.9.6.1.4.6.10.60.1.5.236.167==> 4043542020(OctetString)==>sessionManager ==> 'root'

Непосредственно в OID включены IP адрес и порт-источник : ‘.10.60.1.5.236.167’.

В посте кратко проиллюстрированы особенности реализации SNMP v3, присущие hiT7300.

[1] Douglas R. Mauro and Kevin J. Schmidt “Essential SNMP” (second edition).

[2] gtacknowledge.extremenetworks.com/articles/How_To/How-to-decrypt-SNMPv3-packets-in-Wireshark
[3] labs.spritelink.net/talking-snmpv3-with-nsn-hit7300

[4] hiT7300 misc docs

[5] SNMP Version 3 Concepts

Программа управления дизельными электростанциями DSE

Программа предназначена для мониторинга и управления дизельными электростанциями под управлением контроллеров DSE (Deep See Electronics) (одновременно до 500 штук) с использованием протокола Modbus (TCP/IP или RS-485 через преобразователи Ethernet-RS-485) . 

 Программа предназначена для решения следующих задач:

1. Авторизации и разграничения доступа пользователей к функциям программы. 

2. Графического отображения территориального расположения или схемного соединения ДЭС с использованием статических карт-схем с возможностью перехода с карты на карту или с карты в окно состояния/управления ДЭС.

3. Отображения окна состояния/управления ДЭС по выбору пользователя с актуальными (с учетом цикла опроса) значениями параметров.

4. Ведения журнала аварийных состояний ДЭС, c автоматической очисткой и экспортом в папку пользователя по окончании суток в виде файлов.

5. Редактирования конфигурации программы:

• внешнего вида (выбор из предоставляемого набора цветов фона окон программы, логотипов и языков отображения текстовых сообщений);
• состава карт-схем и размещенных на них ДЭС с помощью подпрограммы редактора конфигурации ;
• индивидуальных параметров подключения и мониторинга контроллеров ДЭС;
• выборочного импорта конфигурации программы DSE Scada Suite в настройки программы.

6. Протоколирования действий пользователей в части управления ДЭС и редактирования конфигурации.

7. Отображения аварийных ситуаций всех ДЭС, подключенных к программе, в постоянно отображаемом отдельном окне с рассылкой SMS подписанным пользователям.

Мониторинг оборудования Benning через адаптер MCU

Электро-питающие установки Benning для удаленного мониторинга (Ethernet) требуют использования адаптера TCP/IP MCU . Интересно, что основными интерфейсами являются HTTP и SNMP, а таблицу Modbus TCP предлагается получить через Web-интерфейс при работе адаптера с контроллером MCU 2500. В чем тут фишка, я до конца не понял, кроме того мониторинг написал на SNMP. Следует обратить внимание на то, что для получения полных и корректных данных об оборудовании контроллер MCU должен быть правильно сконфигурирован. Так, напрасно ожидать данные о состоянии батарей от адаптера - если контроллер MCU 2500 не работает правильно с модулем BATTS.
Было намерение (в основном из-за фантастической цены адаптера) разобраться с протоколом обмена между адаптером и контроллером MCU (RS-232). Нашел в сети вот такой документ - но за его достоверность и полезность ручаться не могу.  

Мониторинг оборудования Emerson Network Power через адаптер PSNA

Контроллер M500D не позволяет удаленно (Ethernet) производить мониторинг обслуживания электрооборудования. Для решения этой задачи используем адаптер  PSNA (Web/SNMP Agent Network card). Web - интерфейс адаптера предоставляет значительно больше возможностей, нежели доступ по SNMP, но в некоторых случаях без SNMP не обойтись. MIB-файл содержит малое количество параметров, если отбросить информацию о производителе, изделии и проч. останется только лишь:

The voltage of battery in 0.1 VDC.

The total current of the batteries in 0.1 ADC.

The temperature around the battery in 0.1 Celsius degree.

The current of battery1 in 0.1 ADC.

The current of battery2 in 0.1 ADC.

The temperature around battery1 in 0.1 Celsius degree.

The temperature around battery2 in 0.1 Celsius degree.

The temperature around ambient1 in 0.1 Celsius degree

The temperature around ambient2 in 0.1 Celsius degree

The AC line A voltage in 0.1 VAC.

The AC line B voltage in 0.1 VAC.

The AC line C voltage in 0.1 VAC.

The DC voltage of the Power System in 0.1 VDC.

The DC current of the Power System in 0.1 ADC.

The alarm status of the Power System. (unknown-1,normal-2,alarm-3)

The status of communication with the Power System.  unknown-1,normal-2,interrupt-3

The AUTO/MANUAL control mode of the Power System. unknown-1,auto-2,manual-3

The status of battery charging, unknown(1), floatCharging(2), equalizeCharging(3), testing(4).

The present number of active alarams.

Однако радует присутствие динамически заполняемой таблицы аварий. Обратите внимание, что адаптер работает с SNMP только 1 версии.

 но динамически заполняемая таблица присутствующих аварий необходима.

Мониторинг кондиционеров STULZ

Кондиционеры STULZ для удаленного мониторинга предоставляют свои данные через специализированный адаптер WIB 8000, который приводит многообразие контроллеров отдельных кондиционеров RS-485 к общему интерфейсу Ethernet. На выходе пользователь получает  WEB-интерфейс (не слишком удобный) и возможность опроса по протоколу SNMPv2. Следует обратить внимание на то, что адаптер, да и контроллеры кондиционеров - устройства достаточно достаточно медленные, ещё более в то время, когда адаптер опрашивает контроллеры кондиционеров он может вообще проигнорировать запросы по SNMP и "подвесить" картинку по HTTP. Период этого опроса регулируется параметром "refresh time" и составляет 60 секунд по умолчанию. Так что примерно раз в минуту устройство может не ответить на запрос по SNMP - и увеличение таймаута не помогает. Впрочем и наблюдаемые процессы тоже медленные - так что это не предмет для беспокойства.
MIB-файл, описывающий SNMP адаптера WIB 8000 доступен в "классической " и XML формах. Принцип формирования OID для адресного обращения к параметрам отдельных контроллеров кондиционеров поясним примером.
Контроллер на шине 1 и адрес 7 требует добавления к OID параметра своей адресации

unitOnOff : "1.3.6.1.4.1.29462.10.2.1.4.1.1.1.1013" + ".1"+".7"+".1".

Возможная проблема - отсутствие этого параметра для данного типа контроллера кондиционера - но тут надо разбираться индивидуально. В остальном всё достаточно просто, работает устойчиво и зависит от потребностей приложения.

Теоретически, можно обойтись без WIB 8000 и обращаться к контроллерам кондиционеров напрямую по RS-485 (и/или использовать другой адаптер для перехода на Ethernet). Судя по попадающимся в сети описаниям (достоверность которых можно проверить только экспериментом). STULZ использует Modbus RTU. Если у читателя есть такой опыт - пишите. 

Странное поведение клиента SNMP при работе с неадекватным сервером.

История следующая.


Пользователь клентской программы указал для некоторого устройства, опрашиваемого (чтение данных по некоторым OID)  по SNMP - IP адрес, несовпадающий с IP адресом опрашиваемого устройства. В результате - клиентская программа с грохотом упала. В ходе "разбора полётов" было выяснено следующее:

•      В локальной сети находилось SNMP устройство другого типа ( и другого производителя) , опрашивать которое клиент не планировал и информацией об OID которого не располагал, но IP адрес которого был ошибочно введён.

•     "Community" для чтения этих устройств совпали (да оно и понятно - 'public' -   по умолчанию).

•     Обработка ошибок от функции snmp_sess_synch_response в клиентской программе была организована из рук вон плохо - ну и понятно, возникло нарушение доступа к памяти и т.д. и т.п.

Казалось бы, всё ясно - не используйте одинаковые 'community' для разных устройств, обрабатывайте правильно ответы на неправильные запросы  и проблем не будет... Но.

В ходе более глубокого копания выяснилась некоторая неоднозначность возврата из функции snmp_sess_synch_response.

Берём устройство (или эмулятор) IP, OIDы и community которого мы знаем и обращаемся к нему с запросом данных по несуществующим у него OID (IP и commutity совпадают). Примерно так (часть кода пропущена):

struct snmp_session *sess;

struct snmp_pdu **response;
void *ptr=NULL;
snmp_sess_init(sess);
  
sess->version=SNMP_VERSION_2c;
sess->peername=ip;
sess->community=(unsigned char*)community;
sess->community_len = strlen(community);

ptr = snmp_sess_open(sess);

pdu=snmp_pdu_create(SNMP_MSG_GET);

snmp_parse_oid(buff, anOID, &anOID_len);
snmp_add_null_var(pdu, anOID, anOID_len);

int Ret = snmp_sess_synch_response(ptr, pdu, response);


Варианты возврата из последней функции (для разных, но несуществующих OID) следующие:

•     Ret==STAT_SUCCESS и (*response)->errstat==SNMP_ERR_NOSUCHNAME
•     Ret==STAT_TIMEOUT и (*response)==NULL;  
•     Ret==STAT_SUCCESS и (*response)->errstat==SNMP_ERR_NOERROR;

 ПОЧЕМУ? Ведь проблема одна и та же - агент получил запрос на отсутствующую у него информацию. А потому что ответственность за ответ на запрос c неизвестным OID лежит на агенте SNMP, то есть на том, кто пишет софт для устройства или эмулятора. Ответственность эта - понимается по-разному.

Но не всё потеряно - даже в последнем варианте можно пойти дальше - и обработать возникшую ошибку. Попробуем проанализировать содержимое полученного ответа

 netsnmp_variable_list *vars = pdu_receive->variables;

Список у нас содержит только одну переменную, поэтому посмотрим содержимое её поля type. В нашем случае имеем тип SNMP_NOSUCHINSTANCE.

И конечно, не следует забывать о функции snmp_sess_error. Она не всегда возвращает пустые данные.

Программа учета расхода топлива и отпущенной энергии для малых дизельных электростанций (ПУ МДЭС)

Обеспечение бесперебойного электрического питания объектов различного назначения давно стало общим местом, в котором большую роль играют малые дизельные электростанции (МДЭС) различных типов от разных производителей. Вместе с тем остаётся нерешенным вопрос учета выработанной электроэнергии и израсходованного топлива. Проблема заключается в отсутствии в составе МДЭС приборов коммерческого учета, соответствующих российским требованиям. С другой стороны, многообразие применяемых МДЭС приводит к необходимости "выведения за скобки" подсистемы учета (то есть программно-аппаратных решений, которые можно было бы применять независимо от основного оборудования). Другой проблемой остаётся необходимость защищённого удалённого доступа к подсистеме учета (через Интернет). Для решения описанных проблем может служить описываемая ниже ПУ МДЭС, использующая аппаратные компоненты, имеющие должную российскую сертификацию, а именно

• счетчики ЗАО"Энергомера",
• расходомеры производства ЗАО «Технотон».

Программная реализация использует свободно-распространяемые WEB-сервер на основе Apache и базу данных на основе MySQL, что упрощает и удешевляет разработку и облегчает при необходимости перенос ПУМДЭС на другие операционные системы.

Описание ПУ МДЭС в существующем виде можно скачать здесь.