Доступ OID по умолчанию для SNMP
Я написал собственный агент SNMPV2C (протокол agentx), расширяющий netsnmp. На данный момент я разрешаю доступ для просмотра всем в snmpd.conf следующим образом
view all included .1
это выставляет mgmt (RFC1213), который выглядит хорошо, это также выставляет mmp snmpV2 ( snmpMIB, snmpFrameworkMIB, VacmMIB и т. д.).
Я не смог найти ни одного документа о лучших практиках, который бы подробно описывал бы, кроме открытия нашего корпоративного дерева oid, что все должно быть раскрыто, каковы риски безопасности и т. Д.
3 ответа
Будьте предельно осторожны с общим доступом (даже для чтения) ко всему ISO (.1
) дерево, особенно если вы используете SNMPv3 USM для аутентификации и VACM для авторизации.
База данных пользователей USM представлена в самой MIB (usmUserTable
), так:
- Имея доступ только для чтения к нему, злоумышленник может просто пройти по таблице и получить все действительные основные значения (комбинация идентификатора механизма / имени пользователя);
- С доступом для чтения и записи злоумышленник сможет повредить сохраненные ключи аутентификации и / или конфиденциальности случайныхили даже всех пользователей, что приведет к отказу в обслуживании. (Например, это можно сделать, запустив
snmpusm(1)
с мусором для старых / новых парольных фраз.)
Аналогично, VACM MIB содержит информацию о политике доступа, такую как:
- Какой контекст SNMP доступен локально (
vacmContextTable
); - Какой пользователь USM или сообщество SNMPv2c сопоставляется с какой группой VACM (
vacmSecurityToGroupTable
); - Какая группа VACM может получить доступ к какой части (ам) дерева OID (
vacmAccessTable
а такжеvacmViewTreeFamilyTable
).
Я не думаю, что Net-SNMP разрешает доступ на чтение и запись к этим таблицам VACM (политика взята из /etc/snmp/snmpd.conf
и не изменяется агентом), но даже доступ только для чтения может раскрыть слишком много информации. Например, он может позволить злоумышленнику выяснить, какой пользователь USM имеет доступ к представлению, в котором он заинтересован, и провести атаку по взлому пароля для этого конкретного пользователя USM.
RFC SNMPv3 USM и VACM явно предупреждают вас о том, насколько чувствительны эти таблицы:
11.5 Access to the SNMP-USER-BASED-SM-MIB
The objects in this MIB may be considered sensitive in many
environments. Specifically the objects in the usmUserTable contain
information about users and their authentication and privacy
protocols. It is important to closely control (both read and write)
access to these MIB objects by using appropriately configured Access
Control models (for example the View-based Access Control Model as
specified in [RFC3415]).
А также:
7.4. Access to the SNMP-VIEW-BASED-ACM-MIB
The objects in this MIB control the access to all MIB data that is
accessible via the SNMP engine and they may be considered sensitive
in many environments. It is important to closely control (both read
and write) access to these to these MIB objects by using
appropriately configured Access Control models (for example the
View-based Access Control Model as specified in this document).
Я бы порекомендовал исключить как минимум USM и VACM MIB. Пример:
view most included .1
view most excluded .1.3.6.1.6.3.15
view most excluded .1.3.6.1.6.3.16
каковы риски безопасности
С SNMP v2c у вас нет ни шифрования, ни подписи. Это означает, что атаки "человек посередине" могут:
- утечка данных,
- измените содержимое в запросе Set, чтобы вызвать что-то нежелательное для цели (например, вы можете перезагрузить некоторые цели таким образом).
Более того, запросы могут выполняться по UDP, поэтому нет необходимости правильно направлять IP-адрес источника обратно на источник. Таким образом, IP-спуфинг может использоваться для обхода списков ACL IP-адресов и отправки запросов Set SNMP Set целевому объекту из поддельного IP-источника.
Обратите внимание, что с SNMP v3 все эти риски можно избежать.
Таким образом, либо увеличьте свою безопасность, добавив еще один сетевой уровень (например, IPsec), либо предоставьте только READ-ONLY OID с общедоступным контентом.
Например, могут отображаться счетчики производительности или основные параметры конфигурации, такие как IP-адрес, имя хоста, счетчик. Возможно, вам следует провести анализ рисков, чтобы выяснить, какая информация действительно может быть раскрыта.
Сначала SNMP v1 вообще не был защищен. Таким образом, SNMP v2 было предложено добавить безопасность среди других новых функций. Но это было настолько сложно, что новые функции безопасности были удалены, а другие функции были сохранены, и протокол был наконец опубликован с именем SNMP v2c. Наконец, SNMP v3 был создан, главным образом, для обеспечения функций безопасности, но проще в реализации, чем с SNMP v2.
Не добавляя к общим советам, данным в ответах ранее, я бы рекомендовал использовать
snmpwalk -v2c -c community localhost .1 | your_pager
чтобы просмотреть всю информацию, которую вы можете увидеть. Затем решите, какую информацию вы, возможно, не хотите видеть.
Например, в Linux вы обычно видите все процессы и их аргументы, а также смонтированные дисковые устройства и файловые системы.