Jump to content
Калькуляторы

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

Начал работать с устройством 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'е. У кого проблем не было - тем все равно, а тем у кого были - приятно. Делов-то на несколько минут.

 

 

Вот.

Share this post


Link to post
Share on other sites

Добрый день!

 

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

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

Share this post


Link to post
Share on other sites

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 в трапах, это была бы хоть и не очень нужная, но фича.

Share this post


Link to post
Share on other sites

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, трапы отображаются как вам надо.

Share this post


Link to post
Share on other sites

Значит есть устройство, которое отправляет трапы как положено. Тогда тем более предлагаю исходя из всего вышесказанного считать описываемое поведение 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 by _dreamer_

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this