Fatal编程技术网
  • snmp/
  • SNMP'；默认的OID访问

SNMP'；默认的OID访问

snmp

SNMP'；默认的OID访问,snmp,net-snmp,snmpv2c,Snmp,Net Snmp,Snmpv2c,我已经编写了一个自定义SNMPV2C代理（agentx协议）来扩展netsnmp，现在我允许查看snmpd.conf中的所有内容，如下所示 view all included .1 它公开看起来不错的mgmt（RFC1213），还公开snmpV2 mib（snmpMIB、snmpFrameworkMIB、VacmMIB等） 我找不到任何最佳实践文档来详细说明，除了打开我们的企业oid树之外，应该公开哪些内容，哪些是安全风险等等 安全风险是什么 使用SNMPv2c，您既没有加密，也没有签名。这意

我已经编写了一个自定义SNMPV2C代理（agentx协议）来扩展netsnmp，现在我允许查看snmpd.conf中的所有内容，如下所示

view all included .1
它公开看起来不错的mgmt（RFC1213），还公开snmpV2 mib（snmpMIB、snmpFrameworkMIB、VacmMIB等）

我找不到任何最佳实践文档来详细说明，除了打开我们的企业oid树之外，应该公开哪些内容，哪些是安全风险等等

安全风险是什么

使用SNMPv2c，您既没有加密，也没有签名。这意味着中间人攻击可以同时进行：

  • 泄露数据
  • 更改Set请求中的内容，以触发目标上不可删除的内容（例如，可以通过这种方式重新启动某些目标）
此外，查询可以通过UDP完成，因此IP源地址不需要正确路由回源。因此，IP欺骗可用于绕过IP ACL，并从假IP源向目标发送SNMPSet请求

请注意，使用SNMPv3，可以避免所有这些风险

因此，要么通过添加另一个网络层（例如IPsec）来提高安全性，要么只公开带有公共内容的只读OID

例如，性能计数器或基本配置参数（如IP地址、主机名、计数器）可能会公开。也许你应该做一个风险分析，以找出哪些信息可以真正暴露出来

起初，SNMP v1根本不安全。
因此，SNMP v2被提议添加安全性和其他新特性。但它是如此复杂，以至于新的安全功能被删除，其他功能被保留，协议最终以SNMPv2c的名称发布。最后，创建SNMPv3主要是为了提供安全功能，但实现起来要比使用SNMP v2更简单。

在整个ISO（
.1
）树上进行全面访问（甚至是只读）时要格外小心，尤其是在使用SNMPv3进行身份验证和授权时

USM用户数据库在MIB本身中公开（
usmUserTable
），因此：

  • 通过对它的只读访问，对手可以简单地遍历表并获得所有有效的主体（引擎ID/用户名组合）值
  • 通过读写访问，对手将能够破坏随机–甚至所有用户存储的身份验证和/或隐私密钥，从而导致拒绝服务。（例如，这可以通过运行
    snmpusm（1）
    和旧/新密码的垃圾来实现。）
同样，VACM MIB包含访问策略信息，例如：

  • 哪个SNMP上下文在本地可用（
    vacmContextTable
    ）
  • 哪个USM用户或SNMPv2c社区映射到哪个VACM组（
    vacmSecurityToGroupTable
    ）
  • 哪个VACM组可以访问OID树的哪个部分（
    vacmAccessTable
    和
    vacmViewTreeFamilyTable
    ）
我认为Net SNMP不允许对这些VACM表进行读写访问（该策略取自
/etc/SNMP/snmpd.conf
，并且未经代理修改），但即使是只读访问也可能会显示太多信息。例如，它可能让攻击者找出哪个USM用户有权访问攻击者感兴趣的视图，并对该特定USM用户发起密码破解攻击

SNMPv3 USM和VACM RFC本身明确警告您这些表有多敏感：

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]).
以及：

我建议至少明确排除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
我建议使用
snmpwalk-v2c-c community localhost.1 |你的_pager
浏览你能看到的所有信息。 然后决定哪些信息你可能不想被看到

例如，在Linux上，您通常可以看到所有进程及其参数以及安装的磁盘设备和文件系统。

谢谢，我们将在下一版本中迁移到SNMP v3，对于此版本，我们只允许只读访问。。但我主要担心的是默认模块（我应该启用或禁用什么）。。目前，请查看所有内容。1。我看到RFC1213和SNMPV2（1.3.6.1.6.3.X）被暴露。。只读访问这些模块是否存在任何安全风险？MIB-2 OID在只读时并不意味着特定的安全风险：它们只包含基本信息。但有些人可能会认为共享一些基本信息是一种风险：例如，发布您的MAC地址可能会将信息泄漏到远离本地以太网的远程主机（当然，在您的本地网络上，这些信息是公开的）。您的本地MAC地址是一条信息，可以帮助您发现服务器的制造商。知道这家制造商，攻击者可以尝试他们服务器的一些公开漏洞…因此，这并不特别危险，但取决于处理威胁的方式，有些人可能不希望这些信息公开。谢谢你回答了我的问题，但是否有任何最佳实践或任何规则，我应该允许默认模块的最低限度？如果客户正在使用自定义NMS，则它不应中断。就像他们可能需要发出多少get请求一样，我们的企业OID来自sys模块等。SNMP v2c和MIB-2的最佳实践是以只读方式将其完全打开，并且必须使用IP访问控制列表和非默认社区字符串限制访问。 
view most included .1
view most excluded .1.3.6.1.6.3.15
view most excluded .1.3.6.1.6.3.16