SNMP默认OID访问

3

我编写了一个基于agentx协议扩展netsnmp的自定义SNMPV2C代理,目前我在snmpd.conf中允许所有人查看如下

view all included .1

它公开了mgmt(RFC1213),看起来很好,它还公开了snmpV2 mib的(snmpMIB、snmpFrameworkMIB、VacmMIB等)。

我没有找到任何最佳实践文档来详细说明除了打开我们的企业oid树之外,应该公开什么,有哪些安全风险等。

3个回答

3

请非常小心整个ISO (.1)树的全局访问权限(即使是只读),特别是如果您使用SNMPv3 USM 进行身份验证和VACM进行授权。

USM用户数据库在MIB本身中暴露出来(usmUserTable),因此:

  • 具有只读访问权限的对手可以简单地遍历表并获取所有有效的主体(引擎ID /用户名组合)值;
  • 具有读写访问权限的对手将能够破坏随机或甚至所有用户的存储身份验证和/或隐私密钥,从而导致拒绝服务。 (例如,这可以通过使用旧/新密码短语的垃圾运行snmpusm(1)来完成。)

同样,VACM MIB包含访问策略信息,例如:

  • 可用的本地SNMP上下文 (vacmContextTable);
  • 哪个USM用户或SNMPv2c社区映射到哪个VACM组 (vacmSecurityToGroupTable);
  • 哪个VACM组可以访问OID树的哪些部分 (vacmAccessTablevacmViewTreeFamilyTable)。

我认为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]).

而且:

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

3
安全风险是什么?
使用SNMP v2c,您没有加密和签名。这意味着中间人攻击可以泄露数据并更改Set请求中的内容,以触发目标上的不良操作(例如,您可以以此重新启动某些目标)。
此外,查询可以通过UDP完成,因此IP源地址无需正确路由回源。因此,IP欺骗可用于绕过IP ACL并从伪造的IP源发送SNMP Set请求到目标。
请注意,使用SNMP v3可以避免所有这些风险。
因此,要么增加安全性添加另一个网络层(例如IPsec),要么仅公开带有公共内容的READ-ONLY OIDs。
例如,性能计数器或基本配置参数(如IP地址、主机名、计数器)可能会暴露。也许你应该进行风险分析来找出哪些信息真正可以暴露。
起初,SNMP v1根本没有安全性。因此,SNMP v2被提出来增加安全性,以及其他新特性。但它太复杂了,新的安全功能被删除,而其他功能被保留,并且协议最终以SNMP v2c的名称发布。最后,主要创建SNMP v3以提供安全功能,但比使用SNMP v2实现更容易。

谢谢,我们将在下一个版本中迁移到SNMP v3,在本版本中我们只允许只读访问。但我主要担心默认模块(我应该启用或禁用哪些),现在使用查看所有.1,我看到RFC1213和SNMPV2(1.3.6.1.6.3.X)被公开... 只读访问这些模块是否存在安全风险? - DevC
MIB-2 OID在只读时不会暗示特定的安全风险:它们仅包含基本信息。但是,共享一些基本信息可能被某些人视为风险:例如,发布您的MAC地址可能会向远程主机泄露信息,这些主机远离您的本地以太网网络(在您的本地网络上,当然,此信息是公开的)。而您的本地MAC地址是可以帮助发现服务器制造商的信息。知道了这个制造商,攻击者可以尝试利用他们服务器上的一些公共漏洞... - Alexandre Fenyo
因此,它并不特别危险,但根据处理威胁的方式,有些人可能不希望这些信息公开。 - Alexandre Fenyo
谢谢,这在某种程度上回答了我的问题,但是是否有任何最佳实践或规则,我应该至少允许默认模块?如果客户正在使用自定义NMS,则不应该对他们造成破坏。比如他们可能需要知道已经进行了多少个get请求,我们企业OID来自sys模块等。 - DevC
1
使用SNMP v2c和MIB-2的最佳实践是将其设置为“只读”模式,并且访问必须通过IP访问控制列表和非默认社区字符串进行限制。 - Alexandre Fenyo

0

除了之前回答中给出的一般建议外,我建议使用snmpwalk -v2c -c community localhost .1 | your_pager来浏览您可以看到的所有信息。 然后决定哪些信息可能不想被看到。

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


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接