_dreamer_ Опубликовано 1 августа, 2014 · Жалоба Начал работать с устройством 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'е. У кого проблем не было - тем все равно, а тем у кого были - приятно. Делов-то на несколько минут. Вот. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Victor Pestov Опубликовано 4 августа, 2014 · Жалоба Добрый день! 1) Это скорее не баг, а фича: в устройствах SNR-ERD Community является одновременно и паролем от устройства. Если пароль будет содержаться в трапе, потеряется смысл такой защиты. 2) Спасибо за информацию, учтем этот момент. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_dreamer_ Опубликовано 4 августа, 2014 · Жалоба 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 в трапах, это была бы хоть и не очень нужная, но фича. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dmitry Polyakov Опубликовано 4 августа, 2014 · Жалоба 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, трапы отображаются как вам надо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_dreamer_ Опубликовано 4 августа, 2014 (изменено) · Жалоба Значит есть устройство, которое отправляет трапы как положено. Тогда тем более предлагаю исходя из всего вышесказанного считать описываемое поведение SNR-ERD-3.2 пусть мелким и незначительным (хотя кому как), но багом или недоработкой. Поэтому предлагаю: 1. Подумайте, может все таки стоит (если есть такая возможность) обратить внимание руководства на этот вопрос? Ведь это хорошо, когда админ (читай покупатель) будет сам решать, с каким community должны отправляться трапы. Это не только хорошо, но и правильно, в конце концов. Не думаю, что исправление займет много времени, или что это очень уж сложно. 2. Ладно, пусть требуется значительное количество заинтересованных, чтобы что-то там изменить в планах, и взяться за исправление этого бага. Не организовать ли тогда опрос, чтобы тема была на виду у всех? Что касается SNR-ERD-Pro-mini... Как я понял, где-то в загашнике у нас отыскалось достаточно много завалявшихся без дела SNR-ERD-3.2. Поэтому возиться мне придется именно с ними. У нас никто покупать SNR-ERD-Pro-mini не будет, тем более, что они почти на 700 р дороже, чем SNR-ERD-3.2 при достаточно похожем функционале. Отличия в этих устройствах для нас несущественны. Изменено 4 августа, 2014 пользователем _dreamer_ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
reddylab Опубликовано 31 октября, 2014 · Жалоба Та же проблема, но с SNR-ERD-2.3 (создал тему http://forum.nag.ru/forum/index.php?showtopic=98513) Нет возможности менять trap community. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
