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

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

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 get/set по умолчанию 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 ******. 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, присущие MHTP.

[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

Пример использования SNMPv3