Особенность трапов от SNR-ERD-3.2 и MIB-файла.

[_dreamer_]

Начал работать с устройством SNR-ERD-3.2, прошивка firmware_SNR-ERD-3.4.hex.

Первые грабли уже нашел.

 

1. community отправляемых устройством трапов - 'trap', а не то, которое установил я.

 

Пример:

--------------------------------------------------------------------------------

username@my_host:tcpdump | grep 192.168.X.Y

 

замыкаю-размыкаю alarm 1 на GND и вижу

14:41:21.498740 vlan NN, p 0, IP 192.168.X.Y.snmp-trap > my_host.snmp-trap: C=trap Trap(79) E:40418.2.3 192.168.X.Y enterpriseSpecific s=2 65793 [|snmp]

14:41:21.494301 vlan NN, p 0, IP 192.168.X.Y.snmp-trap > my_host.snmp-trap: C=trap Trap(77) E:40418.2.3 192.168.X.Y enterpriseSpecific s=3 65793 [|snmp]

--------------------------------------------------------------------------------

Видим, что C=trap. Что это - баг или фича? Ведь с других устройств (коммутаторы, UPS'ы) трапы приходят с community, заданным админом, т.е. там C=нужное_слово.

Очень хочется, чтобы community в трапах с SNR'ки было то, которое нужно мне. Это важно...

Как быть?

 

 

2. NET-SNMP версии 5.4.2.1 (как другие - не знаю, не проверял) не может нормально работать с MIB, взятой как и прошивка, с этого же форума.

 

Пример:

--------------------------------------------------------------------------------

username@my_host:snmptranslate -On -Td SNR-ERD-3::temperatureSensorRelease

 

No log handling enabled - turning on stderr logging

Expected "(" (_): At line 272 in /usr/share/snmp/mibs/SNR-ERD-3.txt

Should be ACCESS (SetON): At line 272 in /usr/share/snmp/mibs/SNR-ERD-3.txt

Bad parse of OBJECT-TYPE: At line 272 in /usr/share/snmp/mibs/SNR-ERD-3.txt

SNR-ERD-3::temperatureSensorRelease: Unknown Object Identifier

--------------------------------------------------------------------------------

 

Открываем MIB и в этом месте (line 272) видим:

"""

remoteControlContact8 OBJECT-TYPE

SYNTAX INTEGER

{

termostat_set_ON (3),

switch (4),

manual_set_ON (2),

man_off (1),

man_on (0),

auto_off (6),

auto_on (5)

}

MAX-ACCESS read-write

STATUS current

DESCRIPTION "qwerty"

::= { resetsSet 3 }

"""

 

Как оказалось, snmptranslate ругался на строки, содержащие символ '_'.

Тот же пример после правки (удаления этого символа во всем файле, точнее, в 12 строках) текста MIB:

--------------------------------------------------------------------------------

username@my_host:snmptranslate -On -Td SNR-ERD-3-MIB::temperatureSensorRelease

 

.1.3.6.1.4.1.40418.2.3.0.1

temperatureSensorRelease OBJECT-TYPE

-- FROM SNR-ERD-3-MIB

DESCRIPTION "Check the text of message"

::= { iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) snr(40418) snr-erd(2) snr-erd-3(3) erd3TrapGroup(0) 1 }

--------------------------------------------------------------------------------

Красота, да и только!

Кто-нибудь еще наблюдал подобные проблемы?

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

Думаю есть смысл пофиксить это в новом MIB'е. У кого проблем не было - тем все равно, а тем у кого были - приятно. Делов-то на несколько минут.

 

 

Вот.

[Victor Pestov]

Добрый день!

 

1) Это скорее не баг, а фича: в устройствах SNR-ERD Community является одновременно и паролем от устройства. Если пароль будет содержаться в трапе, потеряется смысл такой защиты.

2) Спасибо за информацию, учтем этот момент.

[_dreamer_]

1) Это скорее не баг, а фича: в устройствах SNR-ERD Community является одновременно и паролем от устройства. Если пароль будет содержаться в трапе, потеряется смысл такой защиты.

 

Какая интересная фича!

 

Не вижу никакого смысла в такой защите...

В устройствах SNR-ERD-3.2 (которое, как Вы конечно знаете, использует snmp v1) строка community не только является своего рода паролем, но и передается в открытом (незашифрованном) виде во всех пакетах, таких как get, set, next, response и trap. Согласитесь, при этом считать описанное в п.1 первого поста поведение устройства "защитой" можно только с натяжкой и оговоркой в том плане, что мол после настройки и монтажа от устройства никто ничего не должен хотеть (на него не отправляют set, get, next), и поэтому оно никому не отвечает (response), а только лишь отправляет трапы (да, не содержащие community доступа), и все. Но необходимость в таком поведении, думаю, если и бывает, то редко. Чаще от устройства кто-то чего-то время от времени хочет, и оно что-то отвечает, ну или делает. При этом, повторюсь, строка community передается, причем передается открытой. И если уж некий злоумышленник проник в сеть и сумел перехватить трап (как я понял, Вы говорите именно о таком случае), то скорее всего он сумеет перехватить и другие пакеты [ от | для ] этого устройства. Тогда узнать community и получить полный доступ к устройству просто, как два байта переслать.

 

Думаю, всем будет гораздо удобнее, если в трапах будет отправляться именно то community, которе нужно админу, суть заказчику, а не разработчику устройства. Так что позволю себе не согласиться с Вами в том, что это не баг, и прошу помощи.

 

 

P.S. Вот если бы дополнительно к "главному" community можно было бы менять по своему усмотрению и community в трапах, это была бы хоть и не очень нужная, но фича.

[Dmitry Polyakov]

1) Это скорее не баг, а фича: в устройствах SNR-ERD Community является одновременно и паролем от устройства. Если пароль будет содержаться в трапе, потеряется смысл такой защиты.

 

Какая интересная фича!

 

Не вижу никакого смысла в такой защите...

В устройствах SNR-ERD-3.2 (которое, как Вы конечно знаете, использует snmp v1) строка community не только является своего рода паролем, но и передается в открытом (незашифрованном) виде во всех пакетах, таких как get, set, next, response и trap. Согласитесь, при этом считать описанное в п.1 первого поста поведение устройства "защитой" можно только с натяжкой и оговоркой в том плане, что мол после настройки и монтажа от устройства никто ничего не должен хотеть (на него не отправляют set, get, next), и поэтому оно никому не отвечает (response), а только лишь отправляет трапы (да, не содержащие community доступа), и все. Но необходимость в таком поведении, думаю, если и бывает, то редко. Чаще от устройства кто-то чего-то время от времени хочет, и оно что-то отвечает, ну или делает. При этом, повторюсь, строка community передается, причем передается открытой. И если уж некий злоумышленник проник в сеть и сумел перехватить трап (как я понял, Вы говорите именно о таком случае), то скорее всего он сумеет перехватить и другие пакеты [ от | для ] этого устройства. Тогда узнать community и получить полный доступ к устройству просто, как два байта переслать.

 

Думаю, всем будет гораздо удобнее, если в трапах будет отправляться именно то community, которе нужно админу, суть заказчику, а не разработчику устройства. Так что позволю себе не согласиться с Вами в том, что это не баг, и прошу помощи.

 

 

P.S. Вот если бы дополнительно к "главному" community можно было бы менять по своему усмотрению и community в трапах, это была бы хоть и не очень нужная, но фича.

в краткосрочных планах, нет задачи по изменению стека и trap сообщений в частности.

если в этой ветке будут заинтересованные за такое решение, то можно рассмотреть.

Кстати, в ERD-Pro-mini, трапы отображаются как вам надо.

[_dreamer_]

Значит есть устройство, которое отправляет трапы как положено. Тогда тем более предлагаю исходя из всего вышесказанного считать описываемое поведение SNR-ERD-3.2 пусть мелким и незначительным (хотя кому как), но багом или недоработкой.

 

Поэтому предлагаю:

1. Подумайте, может все таки стоит (если есть такая возможность) обратить внимание руководства на этот вопрос? Ведь это хорошо, когда админ (читай покупатель) будет сам решать, с каким community должны отправляться трапы. Это не только хорошо, но и правильно, в конце концов. Не думаю, что исправление займет много времени, или что это очень уж сложно.

2. Ладно, пусть требуется значительное количество заинтересованных, чтобы что-то там изменить в планах, и взяться за исправление этого бага. Не организовать ли тогда опрос, чтобы тема была на виду у всех?

 

Что касается SNR-ERD-Pro-mini...

Как я понял, где-то в загашнике у нас отыскалось достаточно много завалявшихся без дела SNR-ERD-3.2. Поэтому возиться мне придется именно с ними. У нас никто покупать SNR-ERD-Pro-mini не будет, тем более, что они почти на 700 р дороже, чем SNR-ERD-3.2 при достаточно похожем функционале. Отличия в этих устройствах для нас несущественны.

Edited August 4, 2014 by _dreamer_

[reddylab]

Та же проблема, но с SNR-ERD-2.3 (создал тему http://forum.nag.ru/forum/index.php?showtopic=98513)

Нет возможности менять trap community.