LINUX.ORG.RU

Как сохранить секъюрность?

 , , , ,


0

1

Всем привет, есть такая задачка. Комъюнити и пароли для net-snmp храняться в зашифрованном виде в БД. Достать и расшифровать мы из можем. Но как сказать snmpd о том какие комъюнити использовать? Сохранить их snmpd.conf не очень секъюрно, т.к. теряется смысл в шифровании таковых в БД. Можно ли как-то сообщить об этом snmpd помимо snmpd.conf?



Последнее исправление: Klymedy (всего исправлений: 1)

Хакнуть snmpd: встроить в него клиент для ldap + tls, а можно проще, перед запуском некий скрипт/демон секьюрно вытащив данные из БД генерирует файл snmpd.conf, запускает snmpd и удаляет этот файл.

А вообще это ССЗБ. Как только будет доступ к серверу и будет ясна авторизация в вашей БД первым делом вытащать все данные из БД, а потом будет разбор полетов для snmp.

Более того, если у вас 161-162 порты на остальных железках находятся вне отдельных транков, то следует сначала позаботится об этом. Также имеет смысл иметь разные группы communities, которые прописаны только там где нужно, а если прописаны и в централизованной БД, то доступ к это БД должен свестись к минимуму. Потому что как сказано выше - сольют напрочь все, потому что есть огромный шанс откопать помимо snmp паролей пользовательские пароли, ssh ключи, списки email, контактных лиц и т.п. Что касается атаки на оборудование, то у вас есть acl и файрволлы, нефиг пускать весь мир к себе. А также следует настроить аудит заходов на ваши сервера и уведомлять об этом хотя бы по email, а лучше с доп. серверов syslog и запись на него.

gh0stwizard ★★★★★
()
Последнее исправление: gh0stwizard (всего исправлений: 1)
Ответ на: комментарий от gh0stwizard

По поводу сгенерить snmpd.conf, а потом удалить его это я тоже думал, но есть миг, в который все-таки этот файл можно скопировать. А нет ли у net-snmp какого-нибудь метода api, который бы говорил snmpd где брать значения конфигурации? что-то вроде колбэка. Я рылся и не нашел((((

igormat
() автор топика
Ответ на: комментарий от igormat

Нет. Это security by obscurity. Словить файл будет сложнее, если генерировать в /tmp (ща в новых ядрах добавлена совсем навороченная система :).

Просто мне не совсем ясны мотивы такой нужды, ибо доступ на сервак уже нежалательно (снифинг, доступ в локалку, к остальным сервисам и т.п.), а тут забота о каком-то snmpd. Есть очень много вариантов напакостить без snmpd. Поэтому нет смысла пытаться как его «обезопасить». Самый надежный способ - выключить совсем :)

А нет ли у net-snmp какого-нибудь метода api, который бы говорил snmpd где брать значения конфигурации?

У него есть параметр в командной строке "-C". Я бы сделал примерно так: есть машина, которая имеет скрипт/демон. Он в свою очередь имеет доступ к БД и возможность исполнять команды на целевом (там где snmpd) сервере. Далее, генерируется конфиг, копируется, запускается snmpd на удаленном сервере с указанием конф. файла. Проверяется, что snmpd включился (если нет - пишем событие), удаляем всегда конфиг на удаленном сервере. Для перезапуска: все тоже самое, но сначала прибиваем демон snmpd.

gh0stwizard ★★★★★
()
Последнее исправление: gh0stwizard (всего исправлений: 1)
Ответ на: комментарий от gh0stwizard

БД и snmpd на одном серваке, поэтому в принципе все еще более секъюрно. Это пароноидальное желание сохранить пароль. А вот насчет нагадить, так это можно очень серьезно, ведь написан субагент, который принимает запросы, поэтому изменение данных, через snmp должно быть санкционированным.

igormat
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.