跳到主要内容

11. 安全考虑

11.1. 推荐实践​

本节描述了有助于本备忘录定义机制安全有效运行的实践.

  • SNMP引擎必须丢弃不对应任何当前未完成请求消息的SNMP响应消息.消息处理模块负责处理此问题.例如,可以使用msgID来实现.

    SNMP命令生成器应用程序必须丢弃任何没有当前未完成的已确认类PDU对应的响应类PDU;例如对于SNMPv2 [RFC3416] PDU,可以使用PDU中的request-id组件来关联响应与未完成的请求.

    尽管SNMP引擎和SNMP命令生成器应用程序通常会自然地执行此操作,但在使用这些安全协议时,由于可能存在消息重复（恶意或其他原因）,这一点非常重要.

  • 如果SNMP引擎使用msgID来关联响应消息与未完成的请求消息,那么在时间窗口(150秒)期间发送的所有此类请求消息中,它必须使用不同的msgID.

    命令生成器或通知发起者应用程序必须在时间窗口(150秒)期间发送的所有请求PDU中使用不同的request-id.

    这样做是为了防止消息重复（恶意或其他原因）的可能性.

    例如,从msgID和/或request-id值为零开始操作不是一个好主意.使用不可预测的数字进行初始化（使其在每次重启后不会从相同值开始）,然后递增1是可以接受的.

  • SNMP引擎应使用经过身份验证的消息执行时间同步,以防止消息重复（恶意或其他原因）的可能性.

  • 当向托管的权威SNMP引擎发送状态更改消息时,命令生成器应用程序应延迟向该托管SNMP引擎发送后续消息,直到收到前一条消息的肯定确认或前一条消息过期.

    SNMP不强制任何消息顺序.消息可能以相对于其生成时间的任何顺序接收,每条消息都将按接收顺序处理.请注意,当经过身份验证的消息发送到托管SNMP引擎时,在正常情况下它将在大约150秒的时间内有效,并在此期间可能被重放.实际上,SNMP引擎和SNMP命令生成器应用程序必须能够应对由于网络异常导致的消息丢失和重新排序.

    但是,托管对象snmpSetSerialNo [RFC3418]专门定义用于SNMP Set操作,以提供一种机制来确保SNMP消息的处理按特定顺序进行.

  • 基于用户的安全模型用户的密钥更改频率与其使用频率间接相关.

    保护密钥不被泄露对于协议的整体安全性至关重要.频繁使用密钥会持续提供数据源,密码分析者可能利用这些数据来利用算法中已知或感知的弱点.频繁更改密钥可以避免这种漏洞.

    每次使用后更改密钥通常被认为是最安全的做法,但可能会带来大量开销.

    另外请注意,在本地环境中,泄露的威胁可能不太严重,因此更改密钥的频率可能会降低.但是,当使用公共数据网络作为通信路径时,应更加谨慎.

11.2 定义用户​

本文档定义的机制采用了代表用户发送消息的概念.如何定义"用户"取决于网络管理的安全策略.例如,用户可以是个人（如"joe"或"jane"）,或特定角色（如"operator"或"administrator"）,或组合（如"joe-operator"、"jane-operator"或"joe-admin"）.此外,用户可以是逻辑实体,例如SNMP应用程序或一组SNMP应用程序,代表个人或角色,或一组个人,或一组角色,包括组合.

附录A描述了一种将用户"密码"映射到16/20八位字节值的算法,用作用户的身份验证密钥或隐私密钥（或两者）.但请注意,对身份验证和隐私使用相同的密码（因此使用相同的密钥）是非常糟糕的安全实践,应强烈反对.密码通常由人类生成、记忆和输入.人类生成的密码可能少于身份验证和隐私协议所需的16/20八位字节,并且对相对较短的ASCII字符集的暴力攻击可能非常容易.因此,附录A中的算法对密码执行转换.如果使用附录A算法,SNMP实现（和SNMP配置应用程序）必须确保密码至少为8个字符长度.请注意,具有重复字符串的较长密码可能会导致完全相同的密钥.例如,密码'bertbert'将产生与密码'bertbertbert'完全相同的密钥.

由于附录A算法（几乎）直接使用此类密码,因此它们不易被猜测非常重要.建议它们由混合大小写字母数字和标点符号字符组成,这些字符不会形成字典中可能找到的单词或短语.较长的密码可以提高系统的安全性.用户可能希望输入多词短语,使其密码字符串更长,同时确保它是可记忆的.

由于人类用户维护每个SNMP引擎的不同密码是不可行的,但安全要求强烈反对为多个SNMP引擎使用相同的密钥,因此基于用户的安全模型采用了[Localized-key]中提出的折衷方案.它从用户的密码派生SNMP引擎的用户密钥,使得实际上不可能从SNMP引擎上的任何用户密钥组合中确定用户的密码或用户在另一个SNMP引擎上的密钥.

但请注意,如果用户的密码被泄露,那么密钥本地化将无济于事,在这种情况下网络安全可能会受到损害.因此,用户的密码或非本地化密钥不得存储在托管设备/节点上.相反,应该存储本地化密钥（如果存储的话）,这样,如果设备确实受到损害,其他托管或管理设备不会受到损害.

11.3. 一致性​

要被称为基于用户的安全模型的"安全SNMP实现",SNMP实现必须:

  • 实现一个或多个身份验证协议.本备忘录中定义的HMAC-MD5-96和HMAC-SHA-96身份验证协议是此类协议的示例.

  • 在最大程度上,在所有情况下禁止访问其在本地配置数据存储(LCD)中维护的每个用户的密钥,除非需要生成和/或验证关于该用户的SNMP消息.

  • 实现密钥本地化机制.

  • 实现SNMP-USER-BASED-SM-MIB.

此外,权威SNMP引擎应按照附录A.1提供初始配置.

实现隐私协议（本备忘录中定义的DES对称加密协议就是这样一种协议）是可选的.

11.4. 报告的使用​

使用不安全的报告（即,以noAuthNoPriv的securityLevel发送它们）可能会使非权威SNMP引擎暴露于某种形式的攻击.有些人认为这些是拒绝服务攻击,有些人则不这么认为.安装前应评估部署不安全报告PDU所涉及的风险.

11.5 访问SNMP-USER-BASED-SM-MIB​

在许多环境中,此MIB中的对象可能被视为敏感的.具体来说,usmUserTable中的对象包含有关用户及其身份验证和隐私协议的信息.通过使用适当配置的访问控制模型（例如[RFC3415]中指定的基于视图的访问控制模型）,密切控制对这些MIB对象的访问（读和写）非常重要.

最后于 更新