D-Link не соблюдает стандарт RFC3414
Дело в том, что даже после исправления EngineID на всех коммутаторах, на некоторых коммутаторах проблема повторялась. После перезагрузки коммутатора, Zabbix считал коммутатор недоступным по SNMP. Если разбираться глубже, с помощью приведённых в прошлой заметке OID'ов, то оказывается, что на коммутаторе после перезагрузки значение EngineBoots остаётся прежним или даже уменьшается! Первым делом были проверены версии прошивок - возможно эта проблема уже была исправлена и надо только обновить прошивку. Но оказалось, что прошивки на проблемных коммутаторах были самые свежие. Поискал в интернете, сталкивался ли кто-нибудь с подобной проблемой, и нашёл аж три темы, в которых открытым текстом утверждается, что эта проблема известна производителю и исправлять он её не собирается:
Поразмыслив, я решил, что можно было бы отключить проверку монотонности возрастания EngineBoots. В конце концов, лучше использовать SNMP третьей версии без защиты от повторного воспроизведения запросов, но зато с более безопасной аутентификацией и с защитой информации от подслушивания, чем вернуться к использованию SNMP второй или первой версии и передавать по сети в открытом виде и строку сообщества и сами запросы и ответы. Решено - будем править библиотеку.
Подготовка к пересборке Net-SNMP
Для начала отредактируем файл /etc/apt/sources.list и добавим строчки с репозиториями deb-src с исходными текстами:
deb http://mirror.ufanet.ru/debian/ wheezy main contrib non-free deb http://mirror.ufanet.ru/debian/ wheezy-updates main contrib non-free deb http://mirror.ufanet.ru/debian/ wheezy-proposed-updates main contrib non-free deb http://mirror.ufanet.ru/debian-security wheezy/updates main contrib non-free deb-src http://mirror.ufanet.ru/debian/ wheezy main contrib non-free deb-src http://mirror.ufanet.ru/debian/ wheezy-updates main contrib non-free deb-src http://mirror.ufanet.ru/debian/ wheezy-proposed-updates main contrib non-free deb-src http://mirror.ufanet.ru/debian-security wheezy/updates main contrib non-freeОбновим список доступных пакетов, чтобы можно было скачать из вновь подключенных репозиториев пакеты с исходными текстами:
# apt-get updateСкачаем и распакуем исходные тексты, а затем перейдём в каталог с распакованными исходными текстами:
$ apt-get source snmp $ cd net-snmp-5.4.3~dfsg/Описание исправлений, внесённых в Net-SNMP
Поиск показал, что константа USM_TIME_WINDOW со значением 150 используется только в файле snmplib/snmpusm.c. Первым делом я нашёл строчку, в которой проверяется, что значение EngineBoots должно быть больше или равно значению из кэша:
if (theirBoots == ENGINEBOOT_MAX || theirBoots > boots_uint) {Если значение EngineBoots не изменилось, то используются значение EngineTime, сохранённое в кэше. Если значение стало больше, то новые значения EngineBoots и EngineTime сохраняются в кэш. Если значение уменьшилось, то запрос завершается ошибкой SNMPERR_USM_NOTINTIMEWINDOW.
Это строчку я исправил следующим образом:
if (theirBoots == ENGINEBOOT_MAX) {То есть при любом изменении значения EngineBoots новое значение будет сохранено в кэш для дальнейшего использования.
После этого я проделал описанные ниже процедуры по сборке пакета, установил исправленный пакет в систему и перезапустил Zabbix. Прошла пара дней, после чего стало понятно, что это исправление учитывает не все возможные случаи. Некоторые коммутаторы после перезагрузки всё-таки переставали опрашиваться.
Детальное изучение проблемы показало, что при перезагрузке значение EngineBoots у них не изменилось, зато EngineTime становилось меньше прошлого, т.к. отсчёт времени после перезагрузки начинался с нуля. В этом случае вступал в силу другой фрагмент кода, который при равенстве полученного значения EngineBoots и имеющегося в кэше проверяет соответствие времени. Если время из ответа больше расчётного, то библиотека запоминает новое значение времени в кэше и принимает ответ. Если время из ответа отстаёт от расчётного менее чем на 150 секунд, то такой ответ тоже принимается. Если же время из ответа отстаёт от расчётного более чем на 150 секунд, то ответ отбрасывается, а запрос завершается всё той же ошибкой SNMPERR_USM_NOTINTIMEWINDOW. Этот фрагмент кода выглядит следующим образом:
/* * Boots is ok, see if the boots is the same but the time * is old. */ if (theirBoots == boots_uint && time_uint < theirLastTime) { if (time_difference > USM_TIME_WINDOW) { DEBUGMSGTL(("usm", "%s\n", "Message too old.")); *error = SNMPERR_USM_NOTINTIMEWINDOW; return -1; } else { /* Old, but acceptable */ *error = SNMPERR_SUCCESS; return 0; } }Его я исправил следующим образом:
/* * Boots is ok, see if the boots is the same but the time * is acceptable old. */ if (theirBoots == boots_uint && time_uint < theirLastTime && time_difference < USM_TIME_WINDOW) { *error = SNMPERR_SUCCESS; return 0; }Снова собрал пакет, установил его в систему и перезапустил Zabbix. Через несколько дней стало понятно, что это исправление помогло и опрос по SNMP третьей версии теперь продолжает работать даже после перезагрузок коммутаторов, когда значение EngineBoots не меняется или меняется в меньшую сторону. Был достигнут неприятный компромисс, на который пришлось пойти ради общего увеличения безопасности системы.
Сборка исправленных пакетов Net-SNMP
Теперь уже, когда в деталях раскрыта подноготная исправлений, опишу до конца процесс сборки пакета.
Скачиваем и устанавливаем пакеты, которые используются в процессе сборки Net-SNMP:
# apt-get build-dep snmpСкачиваем патч:
$ wget http://stupin.su/files/netsnmp543_snmpv3.diffТут же, если вы используете библиотеку Net-SNMP из Python, можно скачать ещё один патч, описанный в заметке Исправление Python-прослойки библиотеки Net-SNMP:
$ wget http://stupin.su/files/netsnmp543_python_client.diffТеперь перейдём в каталог с исходными текстами и наложим наши патчи:
# cd net-snmp-5.4.3~dfsg/ # patch -Np0 --ignore-whitespace < netsnmp543_snmpv3.diff # patch -Np0 --ignore-whitespace < netsnmp543_python_client.diffДобавим наши патчи в будущий пакет:
# dpkg-source --commitУкажем имя патча snmpv3-python_client. В окне редактирования информации о патче введём что-нибудь подобное следующему (вплоть до двух нижних строчек, с которых начинается сам текст патча):
Description: Fixed Python bindings and SNMPv3 time window logic Author: Vladimir Stupin <vladimir@stupin.su> Last-Update: <2016-09-06> --- net-snmp-5.4.3~dfsg.orig/python/netsnmp/client_intf.c +++ net-snmp-5.4.3~dfsg/python/netsnmp/client_intf.cТеперь отметим изменения, внесённые в пакет:
# dch -iВ окне редактирования введём информацию о нашей версии пакета:
net-snmp (5.4.3~dfsg-2.8+deb7u2) UNRELEASED; urgency=low * Fixed Python bindings for IPv4 parameter in SET-requests * Fixed SNMPv3 time window logic -- Vladimir Stupin <vladimir@stupin.su> Tue, 06 Sep 2016 16:01:20 +0500Осталось собрать пакеты:
# dpkg-buildpackage -us -uc -rfakerootТеперь можно установить необходимые пакеты в систему:
# cd .. # dpkg -i libsnmp-base_5.4.3~dfsg-2.8+deb7u2_amd64.deb # dpkg -i libsnmp15_5.4.3~dfsg-2.8+deb7u2_amd64.deb # dpkg -i snmp_5.4.3~dfsg-2.8+deb7u2_amd64.deb # dpkg -i libsnmp-python_5.4.3~dfsg-2.8+deb7u2_amd64.debPython и SNMPv3 в Net-SNMP
Двух пересборок пакетов, на самом деле, оказалось недостаточно. Дело в том, что модуль netsnmp для Python не работает с SNMP третьей версии. Как оказалось, при попытке выполнить из программы на Python запроса SNMP с настройками третьей версии, библиотека "молчит" - в сеть не уходит ни единый пакет. В то же время я вспомнил, что на одном из серверов под управлением FreeBSD всё работало превосходно. Сразу же в глаза бросилось различие в версиях Net-SNMP во FreeBSD на том сервере и на сервере под управлением Debian Wheezy. Во FreeBSD был установлен Net-SNMP версии 5.7.2, а в Debian - 5.4.3. Чтобы проверить свои предположения о том, что этот функционал был исправлен в версии 5.7.2, я воспользовался Net-SNMP из Debian Jessie. Набросал небольшую тестовую программку на Python, запустил - всё отработало на ура.
После этого я заменил в файле /etc/apt/sources.list репозитории deb-src с релиза Wheezy на релиз Jessie и повторил проделанные выше операции, получив таким образом пропатченный бэкпорт Net-SNMP из Jessie для Wheezy. Дело, однако, этим не ограничилось. В бэкпорте вместо библиотеки libsnmp15 была библиотека libsnmp30, а пакет libsnmp-python был переименован в python-netsnmp. К библиотеке libsnmp15 были привязаны Zabbix и PHP5. Пришлось пересобрать и их, в том числе с использованием моих патчей Zabbix, описанных в заметке Установка и настройка Zabbix 2.2.0 в Debian Wheezy.
Патчи, адаптированные для Net-SNMP версии 5.7.2.1 из Jessie, можно взять по следующим ссылкам:
Мне невероятно "везёт" с программами, которыми я пользуюсь. Или просто я слишком часто стал заходить на никем ещё не топтанные дорожки?
1 комментарий:
Спасибо, все очень понятно расписали.
А не правили ли вы snmpd версии 5.9? В частности 5.9+dfsg-4+deb11u1?
Если да, не могли бы вы поделиться то, что делали? Код отличается.
Заранее спасибо
Отправить комментарий