- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
手册下载
H3C无线控制器安全加固手册(V9)-6W100-整本手册.pdf (950.07 KB)
H3C无线控制器安全加固手册(V9)
|
Copyright © 2023 新华三技术有限公司 版权所有，保留一切权利。 非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部， 并不得以任何形式传播。本文档中的信息可能变动，恕不另行通知。 |
|
本手册主要适用于如下工程师：
· 网络规划人员
· 现场技术支持与维护人员
· 负责网络配置和维护的网络管理员
本手册中出现的接口编号仅作示例，并不代表设备上的实际接口编号。实际使用过程中，请以设备上存在的接口编号为准。
本文档不严格与具体软、硬件版本对应，如果使用过程中与产品实际情况有差异，请以设备实际情况为准。
本文档中的配置均是在实验室环境下进行的配置和验证，配置前设备的所有参数均采用出厂时的缺省配置。如果您已经对设备进行了配置，为了保证配置效果，请确认现有配置和以下举例中的配置不冲突。
本文中的内容为通用性技术信息，某些信息可能不适用于您所购买的产品。
本文档针对基于Comware系统的设备，指导用户从管理平面、控制平面和转发平面对设备进行加固维护。
设备的管理平面给网络管理人员提供Telnet、SSH、Web、SNMP等方式来管理设备；设备的控制平面用于控制和管理所有网络协议的运行，为转发平面提供数据转发所必须的各种网络信息和转发查询表项。
由于网络设备之间或网络设备与其它网络实体之间的通信可能会穿过各种各样的中间系统，而中间系统的可信性以及对端身份的真实性会给设备的管理平面和控制平面带来各种安全威胁。另外，如果设备上的安全策略配置不当，也会威胁到设备的安全。
设备的管理平面和控制平面常见的安全威胁主要包括以下几类：
· 非授权的访问
攻击者通过伪装身份、重放管理会话或者中间人攻击来获取管理员权限，这会危害到设备的安全以及设备所处网络的安全。建议管理员使用强身份认证，以及支持防重放、信息完整性验证的安全通道来访问设备。同时，建议在设备上启用操作日志、安全日志功能对管理行为进行记录和审计。
· 弱密钥
弱密钥很容易被破解。设备上支持启用密码策略来防止用户配置弱密钥。
· 敏感信息泄漏
由于网络节点间的通信所经过的中间系统的可信性无法保障，通信内容可能会被窥探；设备存储介质中的信息也可能在介质转移、替换的过程中存在信息泄露的风险。为了防止信息泄露，设备的管理通道需要使用安全协议保护，例如SSH、IPsec、SFTP、HTTPS等，禁止使用Telnet、FTP、TFTP、HTTP等没有保护的通道进行通信。另外，建议使用配置文件加密功能，以及对从现网替换下来且不再使用的存储介质进行格式化。
· 消息篡改和伪造
报文在网络中传输的过程中，可能会被恶意篡改，或者被攻击者捕获之后重放，攻击者借此向设备中注入恶意的数据，或直接破坏设备的合法数据。例如，通过更改路由协议报文的数据来破坏或改变设备的路由表，使用户的流量无法正常转发。为防止该类型攻击，可使用带完整性验证，防重放等功能的安全协议对数据进行保护。
· 管理员配置失误
管理员配置失误会造成设备的访问控制策略、权限控制策略的配置错误，或者造成授权不当的结果。为了及早发现此类问题，可以通过实施前对配置进行审核，实施后定期观察实施效果、查看操作日志和系统运行日志来发现配置中的错误。
设备的转发平面需要处理各端口上大量不同类型数据流量的转发任务。如果数据流量不合法，或者转发平面处理资源被挤占，将会影响设备对正常数据流量的处理效率，甚至导致非法流量向网络中扩散。常见的转发平面威胁如下：
· 畸形报文攻击
畸形报文攻击利用网络设备处理报文的漏洞使设备出现异常，使设备无法提供正常服务。可以打开攻击检测与防范中相应攻击的开关来防止此类攻击。
· 身份仿冒
网络中的很多攻击行为都伴随着身份仿冒，而网络的开放性给身份识别带来了困难，尤其是在转发平面。转发平面提供了一些基本的方法可在一定程度上防止身份仿冒，比如IP Source Guard、SYN Cookie、ARP/ND检测等。
· 消息篡改和伪造
消息的完整性至关重要，虚假的数据会使网络故障、甚至瘫痪。可以使用IPsec等安全协议来保护网络数据，提供完整性、私密性、身份验证等功能。
Comware系统的安全体系架构如图2-1所示：
图2-1 Comware系统安全体系架构图
设备基于以上安全体系架构在不同层面实施相应的安全防护，具体过程如下：
(1) 对于硬件转发类设备，收到目的地址为本机的报文并上送CPU处理前，会通过以下两种通道机制来保证上层的控制平面/管理平面不会受到DoS等大流量的攻击：
¡ 白名单：对于已经建立连接，并确认来源是可靠的报文，设备会下发白名单保证其优先上送CPU。
¡ 优先级队列：对于由控制平面、管理平面处理的应用流量，在设备没有与其建立连接之前，因不能匹配到白名单，会进入优先级队列，根据不同的应用优先级处理。
(2) 对于由转发平面转发的报文，设备提供了一系列的措施来保证设备的安全和网络用户的安全：
¡ 畸形报文检测
¡ 包过滤
¡ 防仿冒，例如IP Source Guard
¡ 资源占用限制：包括连接数限制、ARP/ND表项限制等等
¡ 数据保护协议：IPsec等，为本机和用户数据提供数据私密性、完整性、放重放等安全保护
(3) 对于目的地址为本机的业务报文，可以采用以下安全加固策略：
a. 通过控制平面的QoS策略对上送控制平面/管理平面的流量进行限制，例如限制带宽等。另外，各协议本身（TCP、ICMP/ICMPv6、ARP/ND）也有相应的防护措施。
b. 在控制平面/管理平面，各业务模块采用相应的安全协议或安全选项，对业务报文提供更好的安全服务。
虽然设备可提供丰富的安全加固策略，但对于设备而言，并不是实施的安全加固策略越多效果越好。每一项安全加固措施对网络、业务都有或多或少的影响，比如会影响设备性能、内存资源、部署成本、用户使用习惯。所以，需要根据网络和业务的特点来综合评估可能存在的风险和威胁，并在充分了解到各类安全加固策略可能对网络和业务产生的影响后作出恰当的选择。
安全加固策略选择的普遍原则如下：
· 根据安全风险和威胁发生的可能性由大到小的顺序，依次考虑相应的安全加固策略；
· 按照安全加固策略对网络和业务影响程度由小到大的顺序，逐步实施各策略，并观察效果；
· 每一次安全加固策略实施后要观察效果，并根据效果调整当前策略以及选择后续的加固策略；
· 遵循业务优先原则，将安全加固策略对业务的影响降到最低，或者将其控制在可接受的范围内。
Console口/AUX口均属于物理接口，通过它们进行登录是登录设备的基本方式之一。
对于同时有Console口和AUX口的设备，缺省情况下，通过Console口登录时认证方式为none，可直接登录，登录成功之后用户角色为network-admin；通过AUX口登录时认证方式为password，密码为空，用户回车即可直接登录，登录成功后用户角色为network-operator；对于只有AUX口的设备，通过AUX口登录时认证方式为none，登录成功后用户角色为network-admin。
如果攻击者获取了Console口/AUX口的使用权限，在缺省情况下可以非常容易登录到设备上，获取到设备的管理权限。
可以在用户线/用户线类视图下配置以下两种认证方式，提高通过Console口/AUX口登录设备的安全性：
· password方式：表示下次使用该用户线登录时，需要输入密码。只有密码正确，用户才能登录到设备上。配置认证方式为password后，请妥善保存密码。
· scheme方式：表示下次使用该用户线登录设备时需要进行用户名和密码认证，用户名或密码错误，均会导致登录失败。配置认证方式为scheme后，请妥善保存用户名及密码。
改变Console口/AUX口登录的认证方式后，新认证方式对新登录的用户生效。
· 通过Console口登录（仅以用户线视图为例）
# 在Console用户线视图下设置认证方式为密码认证（password方式）。
<Sysname> system-view
[Sysname] line console 0
[Sysname-line-console0] authentication-mode password
# 设置认证密码为明文Plat&0631!（Plat&0631!仅为示例）。
[Sysname-line-console0] set authentication password simple Plat&0631!
# 在Console用户线视图下设置认证方式为AAA认证（scheme方式）。
<Sysname> system-view
[Sysname] line console 0
[Sysname-line-console0] authentication-mode scheme
[Sysname-line-console0] quit
# 在ISP域视图下为login用户配置认证方法。
如果选择本地认证，请配置本地用户及相关属性；如果选择远程认证，请配置RADIUS、HWTACACS或LDAP方案。相关配置的详细介绍请参见“安全配置指导”中的“AAA”。
· 通过AUX口登录（仅以用户线视图为例）
# 在AUX用户线视图下设置认证方式为密码认证（password方式）。
<Sysname> system-view
[Sysname] line aux 0
[Sysname-line-aux0] authentication-mode password
# 设置认证密码为明文Plat&0631!（Plat&0631!仅为示例）。
[Sysname-line-aux0] set authentication password simple Plat&0631!
# 在AUX用户线视图下设置认证方式为AAA认证（scheme方式）。
<Sysname> system-view
[Sysname] line aux 0
[Sysname-line-aux0] authentication-mode scheme
# 在ISP域视图下为login用户配置认证方法。
如果选择本地认证，请配置本地用户及相关属性；如果选择远程认证，请配置RADIUS、HWTACACS或LDAP方案。相关配置的详细介绍请参见“用户接入与认证配置指导”中的“AAA”。
在使用Stelnet登录设备的组网环境中，设备将会面临以下安全威胁：
· 攻击者监听到设备的SSH服务端口后，可通过多次尝试连接，获取设备的访问权限。
· 设备可支持的SSH用户数有限，攻击者通过伪造IP地址，仿冒大量的合法用户登录设备，使得用户数达到上限后，其他合法用户无法登录。
针对以上攻击行为，可以在设备上配置如下安全策略：
· password认证
利用AAA对客户端身份进行认证。用户在客户端上输入用户名和密码后，该密码将被加密后发送给服务器，通过服务器验证用户名和密码的合法性后，用户才可以登录设备。
· publickey认证
采用数字签名的方式来认证客户端。客户端发送包含用户名、公钥和公钥算法或者携带公钥信息的数字证书的认证请求给服务器端。服务器对公钥进行合法性检查，如果合法，则发送消息请求客户端的数字签名；如果不合法，则直接发送失败消息；服务器收到客户端的数字签名之后，使用客户端的公钥对其进行解密，并根据计算结果返回认证成功或失败的消息。
· password-publickey认证
对于SSH2版本的客户端，要求同时进行password和publickey两种方式的认证，且只有两种认证均通过的情况下，才认为客户端身份认证通过；对于SSH1版本的客户端，只要通过其中任意一种认证即可。
· 关闭Stelnet服务
当设备上开启Stelnet服务器功能后，SSH服务端口号易被攻击者扫描到。安全起见，在不使用Stelnet服务时，可以关闭Stelnet服务器功能。
· 改变SSH服务端口号
缺省情况下，SSH服务的端口号为知名端口号22，易被扫描和攻击。通过修改SSH服务的端口号为非知名端口号，可以降低被扫描的风险。
· 对SSH用户进行访问控制
只有匹配ACL中permit规则的IPv4 SSH客户端可以访问设备，其他客户端不可以访问设备。
· 限制同时在线的最大SSH用户数
当前在线SSH用户数超过设定的最大值时，系统会拒绝新的SSH连接请求。
改变Stelnet登录的认证方式后，新认证方式对新登录的用户生效。
· # 配置服务器采用password认证（用户名client001仅为示例）。
<Sysname> system-view
[Sysname] ssh user client001 service-type stelnet authentication-type password
# 若进行本地认证，则还需要创建本地用户；若在远程服务器（如RADIUS服务器）进行认证，则还需要在服务器上创建相应的SSH用户。相关配置的详细介绍请参见“用户接入与认证配置指导”中的“AAA”。
· # 配置服务器采用publickey认证（用户名client002、公钥clientkey仅为示例）。
<Sysname> system-view
[Sysname] ssh user client002 service-type stelnet authentication-type publickey assign publickey clientkey
# 创建同名的本地用户，用于下发授权属性：工作目录、用户角色。相关配置的详细介绍请参见“用户接入与认证配置指导”中的“AAA”。
· # 关闭Stelnet服务。
<Sysname> system-view
[Sysname] undo ssh server enable
· # 设置SSH服务端口号为1025（1025仅为示例）。
<Sysname> system-view
[Sysname] ssh server port 1025
· # 只允许IPv4地址为1.1.1.1的SSH用户向设备发起SSH访问（ACL2001仅为示例）。
<Sysname> system-view
[Sysname] acl basic 2001
[Sysname-acl-ipv4-basic-2001] rule permit source 1.1.1.1 0
[Sysname-acl-ipv4-basic-2001] quit
[Sysname] ssh server acl 2001
· # 限制同时在线的最大SSH用户数为16（16仅为示例）。
<Sysname> system-view
[Sysname] aaa session-limit ssh 16
设备作为SNMP Agent时，将面临以下安全威胁：
· SNMPv1和SNMPv2c的团体名被窃取，非法NMS使用该团体名访问设备。
· SNMP报文被窃听、篡改。
· NMS对一些重要参数误操作，导致设备不能正常工作。
针对以上攻击行为，设备提供了以下功能来加强通过SNMP访问设备的安全性：
· 当不需要通过NMS管理设备时，可关闭SNMP功能。（SNMP功能缺省处于关闭状态）
· 除了SNMPv1、SNMPv2c版本，设备支持安全性更高的SNMPv3三种版本。SNMPv3采用用户名认证，可配置认证密码和加密密码。其中，
¡ 用户名和认证密码用于对NMS进行身份认证，以免非法NMS访问设备；
¡ 加密密码用于对NMS和设备之间传输的报文进行加密，以免报文被窃听。
· 支持VACM和RBAC两种访问控制方式。
¡ VACM（基于视图的访问控制模型）：将团体名/用户名与指定的MIB视图进行绑定，可以限制NMS能够访问哪些MIB对象，以及对MIB对象可执行读操作还是读写操作。
¡ RBAC（基于角色的访问控制）：创建团体名/用户名时，可以指定对应的用户角色，通过用户角色下制定的规则，来限制NMS能够访问哪些MIB对象，以及对MIB对象可执行读操作还是读写操作。
RBAC配置方式限制的是MIB节点的读写权限，VACM配置方式限制的是MIB视图的读写权限，而一个视图中通常包括多个MIB节点。所以，RBAC配置方式更精准、更灵活。
· 支持引用ACL限制可以登录的NMS。
· 设备在发送告警信息可以携带安全参数，只有符合安全参数要求的NMS才能接收该告警信息。
只有NMS和设备使用的SNMP版本、团体名（或者用户名、密码）相同时，NMS才能和Agent建立连接。
· 关闭SNMP功能。
# 关闭SNMP功能。
<Sysname> system-view
[Sysname] undo snmp-agent
· 配置具有认证和加密机制的SNMPv3版本来管理设备，并通过用户角色控制NMS对MIB节点的访问权限
# 配置设备支持SNMPv3版本。
<Sysname> system-view
[Sysname] snmp-agent sys-info version v3
# 创建用户角色test并配置访问权限：用户只能读节点snmpMIB（OID为1.3.6.1.6.3.1）下的对象，不可以访问其它MIB对象。（各参数仅为示例）
[Sysname] role name test
[Sysname-role-test] rule 1 permit read oid 1.3.6.1.6.3.1
# 配置用户角色test具有system（OID为1.3.6.1.2.1.1）的读权限与interfaces（OID为1.3.6.1.2.1.2）的读写权限，以便接口状态变化时，Agent会向NMS发送告警信息。（各参数仅为示例）
[Sysname-role-test] rule 2 permit read oid 1.3.6.1.2.1.1
[Sysname-role-test] rule 3 permit read write oid 1.3.6.1.2.1.2
[Sysname-role-test] quit
# 创建用户RBACtest，为其绑定用户角色test，认证算法为SHA-1，认证密码为123456TESTauth&!，加密算法为AES，加密密码是123456TESTencr&!。（各参数仅为示例）
[Sysname] snmp-agent usm-user v3 RBACtest user-role test simple authentication-mode sha 123456TESTauth&! privacy-mode aes128 123456TESTencr&!
· 配置ACL限制可以访问设备的NMS
# 创建SNMPv3组testGroup，并加入一个用户testUser，安全级别为认证加密，认证算法为SHA-1，认证密码为123456TESTauth&!，加密算法为AES，加密密码是123456TESTencr&!，只有IP地址为1.1.1.1的NMS可以使用用户名testUser访问设备。
<Sysname> system-view
[Sysname] acl basic 2000
[Sysname-acl-ipv4-basic-2000] rule permit source 1.1.1.1 0
[Sysname-acl-ipv4-basic-2000] rule deny source any
[Sysname-acl-ipv4-basic-2000] quit
[Sysname] snmp-agent group v3 testGroup authentication
[Sysname] snmp-agent usm-user v3 testUser testGroup simple authentication-mode sha 123456TESTauth&! privacy-mode aes128 123456TESTencr&! acl 2000
· 配置NMS告警功能
# 开启NMS告警功能，告警信息发送到主机1.1.1.2，使用的用户名为testUser，需要认证和加密。（各参数仅为示例）
<Sysname> system-view
[Sysname] snmp-agent trap enable
[Sysname] snmp-agent target-host trap address udp-domain 1.1.1.2 params securityname testUser v3 privacy
HTTP登录并不安全，使用明文形式传输数据，攻击者很容易截取到报文。推荐用户使用HTTPS方式进行Web登录，由SSL为应用层传输提供安全性保证。在设备上开启HTTPS服务后，用户即可通过HTTPS登录设备。
缺省情况下，设备作为HTTPS服务器端使用自签名证书与客户端建立SSL连接，且SSL参数均为缺省值，存在一定安全隐患。通过在设备上配置SSL服务器端策略，可以进一步提高HTTPS登录的安全性。
还可以通过配置证书属性访问控制策略控制只有从合法CA服务器获取证书的客户端可以通过HTTPS登录设备。
# 配置SSL服务器端策略myssl。
详细配置请参考“安全配置指导”中的“SSL”。
# 配置证书访问控制策略myacp并建立控制规则。
详细配置请参考“安全配置指导”中的“PKI”。
# 配置HTTPS服务与SSL服务器端策略myssl关联（myssl仅为示例）。
<Sysname> system-view
[Sysname] ip https ssl-server-policy myssl
# 配置HTTPS服务与证书属性访问控制策略myacp关联，确保只有从CA服务器获取证书的HTTPS客户端可以访问HTTPS服务器（myacp仅为示例）。
[Sysname] ip https certificate access-control-policy myacp
# 开启HTTPS服务。
[Sysname] ip https enable
# 在ISP域视图下为login用户配置认证方法。
如果选择本地认证，请配置本地用户及相关属性；如果选择远程认证，请配置RADIUS、HWTACACS或LDAP方案。相关配置的详细介绍请参见“用户接入与认证配置指导”中的“AAA”。
FTP和TFTP是通用的文件传输协议，使用明文形式传输数据，攻击者很容易截取报文，自身的安全性能并不高。
针对以上攻击行为，可采用SFTP（Secure FTP）协议。SFTP协议基于SSH2，使用加密形式传输数据，可提供安全可靠的网络文件传输服务，使得用户可以安全登录到远程设备上进行文件管理操作，且能保证文件传输的安全性。
SFTP提供如下安全策略：
· password认证
利用AAA对客户端身份进行认证。用户在客户端上输入用户名和密码后，该密码将被加密后发送给服务器，通过服务器验证用户名和密码的合法性后，用户才可以登录设备。
· publickey认证
采用数字签名的方式来认证客户端。客户端发送包含用户名、公钥和公钥算法或者携带公钥信息的数字证书的认证请求给服务器端。服务器对公钥进行合法性检查，如果合法，则发送消息请求客户端的数字签名；如果不合法，则直接发送失败消息；服务器收到客户端的数字签名之后，使用客户端的公钥对其进行解密，并根据计算结果返回认证成功或失败的消息。
· password-publickey认证
对于SSH2版本的客户端，要求同时进行password和publickey两种方式的认证，且只有两种认证均通过的情况下，才认为客户端身份认证通过；对于SSH1版本的客户端，只要通过其中任意一种认证即可。
· 改变SSH服务端口号
缺省情况下，SSH服务的端口号为知名端口号22，易被扫描和攻击。通过修改SSH服务的端口号为非知名端口号，可以降低被扫描的风险。
· 对SSH用户进行访问控制
只有匹配ACL中permit规则的IPv4 SSH客户端可以访问设备，其他客户端不可以访问设备。
· 限制同时在线的最大SSH用户数
当前在线SSH用户数超过设定的最大值时，系统会拒绝新的SSH连接请求。
· # 开启SFTP服务器功能，并配置服务器采用password认证（用户名client001仅为示例）。
<Sysname> system-view
[Sysname] sftp server enable
[Sysname] ssh user client001 service-type sftp authentication-type password
# 若进行本地认证，则还需要创建本地用户；若在远程服务器（如RADIUS服务器）进行认证，则还需要在服务器上创建相应的SSH用户。相关配置的详细介绍请参见“用户接入与认证配置指导”中的“AAA”。
· # 开启SFTP服务器功能，并配置服务器采用publickey认证（用户名client002、公钥clientkey仅为示例）。
<Sysname> system-view
[Sysname] sftp server enable
[Sysname] ssh user client002 service-type sftp authentication-type publickey assign publickey clientkey
# 创建同名的本地用户，用于下发授权属性：工作目录、用户角色。相关配置的详细介绍请参见“用户接入与认证配置指导”中的“AAA”
· # 设置SSH服务端口号为1025（1025仅为示例）。
<Sysname> system-view
[Sysname] ssh server port 1025
· # 只允许IPv4地址为1.1.1.1的SSH用户向设备发起SSH访问（ACL2001仅为示例）。
<Sysname> system-view
[Sysname] acl basic 2001
[Sysname-acl-ipv4-basic-2001] rule permit source 1.1.1.1 0
[Sysname-acl-ipv4-basic-2001] quit
[Sysname] ssh server acl 2001
· # 限制同时在线的最大SSH用户数为16（16仅为示例）。
<Sysname> system-view
[Sysname] aaa session-limit ssh 16
RBAC（Role Based Access Control）通过建立“权限<->角色”的关联实现将权限赋予给角色，并通过建立“角色<->用户”的关联实现为用户指定角色，从而使用户获得相应角色所具有的权限。
通常，对登录设备人员的权限管理方式是将用户和权限进行简单的关联，这种绑定关系很难应对人员以及设备安全等级的变化。RBAC的基本思想就是给用户指定角色，这些角色中定义了允许用户操作哪些系统功能以及资源对象。RBAC采用权限与用户分离的思想，提高用户权限分配的灵活性，减小用户授权管理的复杂度，降低管理开销，间接地提高了设备在登录用户管理方面的安全性能。
关于RBAC的详细信息，请参见“基础配置指导”中的“RBAC”。
AAA（Authentication、Authorization、Accounting，认证、授权、计费）是网络安全的一种管理机制，它可以为登录设备的用户提供以下三种安全功能。
· 认证：确认访问网络的远程用户的身份，判断访问者是否为合法的网络用户。
· 授权：对不同用户赋予不同的权限，限制用户可以使用的服务。例如，管理员授权办公用户才能对服务器中的文件进行访问和打印操作，而其它临时访客不具备此权限。
· 计费：记录用户使用网络服务过程中的所有操作，包括使用的服务类型、起始时间、数据流量等，用于收集和记录用户对网络资源的使用情况，并可以实现针对时间、流量的计费需求，也对网络起到监视作用。
AAA可以通过多种协议来实现，这些协议规定了设备与服务器之间如何传递用户信息。目前设备支持RADIUS（Remote Authentication Dial-In User Service，远程认证拨号用户服务）协议、HWTACACS（HW Terminal Access Controller Access Control System，HW终端访问控制器控制系统协议）协议和LDAP（Lightweight Directory Access Protocol，轻量级目录访问协议）协议，在实际应用中，最常使用RADIUS协议。LDAP协议的支持情况与设备的型号有关，请以设备的实际情况为准。
虽然HWTACACS协议与RADIUS协议都实现了认证、授权和计费功能，且都使用共享密钥对传输的用户信息进行加密，也都有较好的灵活性和可扩展性，但是HWTACACS协议还具有以下优点：
· 协议使用TCP，网络传输更可靠。
· 除了HWTACACS报文头，报文主体全部进行加密。
· 协议报文较为复杂，认证和授权分离，使得认证、授权服务可以分离在不同的服务器上实现。
· 支持对设备上命令行的使用进行授权和计费。
缺省情况下，用户登录设备后可以使用的命令行由用户拥有的用户角色决定。当用户线采用AAA认证方式并配置命令行授权功能后，用户可使用的命令行将受到用户角色和AAA授权的双重限制。用户每执行一条命令都会进行授权检查，只有授权成功的命令才被允许执行。
# 开启命令行授权功能，限制用户只能使用授权成功的命令。
<Sysname> system-view
[Sysname] line vty 0 4
[Sysname-line-vty0-4] authentication-mode scheme
[Sysname-line-vty0-4] command authorization
# 在ISP域视图下配置命令行授权方法。命令行授权方法可以和login用户的授权方法相同，也可以不同。相关详细介绍请参见“用户接入与认证配置指导”中的“AAA”。
Password Control是设备提供的密码安全管理功能，它根据管理员定义的安全策略，对本地用户登录密码、super密码的设置、老化、更新等方面进行管理，并对用户的登录状态进行控制。
保存在设备上的用户密码存在一些安全隐患，比如：
· 密码长度短、复杂度低、不限制尝试次数，攻击者可以简单快速地借助密码字典进行爆破攻击。
· 密码未设置老化时间、长期闲置，攻击者可通过长时间持续尝试的方法进行破解，一旦破解了该密码，则一劳永逸。
· 初始密码可能是统一规则的弱密码，如果不作更改，后期被攻破的可能性较大。
Password Control可以解决上述问题，可提供以下密码管理功能：
· 密码最小长度限制
· 密码的组合检测功能
· 密码的复杂度检测功能
· 密码更新管理
· 密码老化管理
· 密码过期提醒
· 密码老化后允许登录管理
· 密码历史记录
· 用户首次登录控制
· 密码尝试次数限制
· 用户帐号闲置时间管理
关于本地用户类型的详细介绍，请参见“用户接入与认证配置指导”中的“AAA”。关于super密码的详细介绍，请参见“基础配置指导”中的“RBAC”。关于Password Control的详细信息，请参见“用户接入与认证配置指导”中的“Password Control”。
设备提供如下几种密码（或密钥）设置方式：
· 明文方式：用户以明文方式输入密码，设备以密文或哈希方式存储该密码（具体以各业务模块实现为准）。
· 密文方式：用户以密文方式输入密码，设备以密文方式存储该密码。
· 哈希方式：用户以密文方式输入密码，设备以哈希方式存储该密码。
为了提高系统的安全性和可维护性，对密码的设置有以下建议：
· 提高密码的长度和复杂度，不要使用弱密码。
· 不同特性的密码不要重复使用，避免攻击者非法获取了某业务的密码后，对其它业务的安全性造成威胁。
· 以密文或哈希方式设置的密码必须可被设备解析，否则无法成功设置。这两种密码设置方式通常用于测试或配置恢复。正常业务需求下，请不要尝试自行构造密文密码或哈希密码用于设置业务密码。
缺省情况下，设备上的密码恢复功能处于开启状态。当用户忘记Console口认证密码或者登录认证失败时，可通过Console口连接设备，并在硬件重启设备过程中根据提示按组合键<Ctrl+B>进入BootWare菜单，再选择对应的BootWare菜单选项来修复这个问题。这会给非法用户访问设备带来便利，非法用户可通过Console口访问设备。
关闭密码恢复功能后，设备将处于一个安全性更高的状态，即当出现上述情况时，若想继续使用Console口登录设备，只能通过BootWare菜单选择将设备恢复为出厂配置之后方可继续操作，这样可以有效地防止非法用户获取启动配置文件。
# 关闭密码恢复功能。
<Sysname> system-view
[Sysname] undo password-recovery enable
如果设备的空闲内存不够，会导致业务模块的表项无法下发，设备的重要数据无法保存，影响设备的正常运行。
使用内存告警门限功能后，系统会实时监控剩余空闲内存大小，当条件达到一级、二级、三级告警门限或者恢复正常状态门限时，就产生相应的告警/告警解除通知，通知关联的业务模块/进程采取相应的措施，以便最大限度的利用内存，又能保证设备的正常运行。
除了一级、二级、三级告警，设备还支持预警功能。预警门限用于内存使用率尚处于正常范围内，但需要提醒用户提前关注内存的情况。预警恢复门限用于解除预警。
预告警（early-warning）、一级（minor）、二级（severe）和三级（critical）门限，对应的剩余空闲内存越来越少，紧急程度越来越严重。
· 当剩余空闲内存值从大于等于变成小于等于预告警门限时，产生预告警。
· 当剩余空闲内存值从大于等于变成小于等于一级告警门限时，产生一级告警。
· 当剩余空闲内存值从大于等于变成小于等于二级告警门限时，产生二级告警。
· 当剩余空闲内存值从大于等于变成小于等于三级告警门限时，产生三级告警。
· 当剩余空闲内存值从小于等于变成大于二级告警门限时，产生三级告警解除通知。
· 当剩余空闲内存值从小于等于变成大于一级告警门限时，产生二级告警解除通知。
· 当剩余空闲内存值小于等于变成大于正常内存大小时，产生一级告警解除通知。
· 当剩余空闲内存值小于等于变成大于预告警内存大小时，产生预告警解除通知。
同一级别的告警/告警解除通知是交替进行的：当剩余空闲内存值小于某级告警门限，设备产生相应级别的告警，后续只有该告警解除了，剩余空闲内存值再次小于某级告警门限时，才会再次生成该级别的告警。
当剩余空闲内存大小如图3-1中曲线所示时，会生成如图3-1所示的告警和解除告警通知。
当设备出现内存告警时，可删除暂时不用的配置或关闭部分功能来释放内存。但因为内存不足，部分配置可能删除失败。
# 配置一级、二级、三级告警门限分别为3000MB、2000MB、1000MB，当剩余空闲内存为3500MB时，恢复到正常状态。（各参数仅为示例）
<Sysname> system-view
[Sysname] memory-threshold minor 3000 severe 2000 critical 1000 normal 3500
开启配置文件加密功能后，管理员每次执行save命令，设备都会先将当前生效的配置进行加密，再保存。配置文件加密功能支持使用公钥和私钥两种方式进行加密，由于所有运行Comware V9平台软件的设备拥有相同的公钥和私钥，因此加密后的文件只能被所有运行Comware V9平台软件的设备识别和解析。为了防止非法用户对加密后配置文件的解析，需确保只有合法用户才能获取加密后的配置文件，进一步提高配置文件的安全性。
开启配置文件加密功能后，将不能使用more命令查看加密配置文件（后缀名为“.cfg”的配置文件）的内容，但是加密配置文件可以作为display diff命令的参数，进行两份配置文件之间的差异比较，可以使用display saved-configuration命令查看加密的下次启动配置文件内容。
· # 设置保存配置文件时使用公钥进行加密。
<Sysname> system-view
[Sysname] configuration encrypt public-key
· # 设置保存配置文件时使用私钥进行加密。
<Sysname> system-view
[Sysname] configuration encrypt private-key
查看系统日志是了解设备状态、定位和排除网络问题的一个重要方法，而在系统日志中与设备安全相关的安全日志显得尤为重要。但通常情况下，安全日志与其它日志一同输出，经常被淹没在大量的系统日志中，很难识别、不便于查看。针对这个问题，系统提供了安全日志同步保存功能和安全日志文件管理功能。
开启安全日志同步保存功能后，安全业务模块根据业务需要，会将某些信息同时封装成普通日志和安全日志，普通日志根据信息中心的配置可以输出到控制台、监视终端、日志缓冲区、日志主机等方向，安全日志只能按周期输出到安全日志文件。这样既实现了安全日志的集中管理，又有利于用户随时快捷地查看安全日志，了解设备状态。
安全日志同步保存功能的配置和安全日志文件的管理相互分离，安全日志文件实行专人专管：
· 设备管理员可配置安全日志同步保存功能，包括开启安全日志同步保存功能，开启安全日志同步保存功能，配置单个安全日志文件最大能占用的存储空间的大小，配置安全日志文件使用率的告警上限等。
· 安全日志管理员才能管理安全日志文件，例如修改安全日志文件的存储路径、手工将安全日志保存到安全日志文件等。安全管理员只能管理安全日志文件，不能对设备执行其他操作。
· 配置安全日志同步保存功能
# 开启安全日志同步保存功能。
<Sysname> system-view
[Sysname] info-center security-logfile enable
# 配置安全日志自动保存到文件的频率为600秒。（600秒仅为示例）
[Sysname] info-center security-logfile frequency 600
# 配置单个安全日志文件最大能占用的存储空间的大小为2MB。（2MB仅为示例）
[Sysname] info-center security-logfile size-quota 2
· 管理安全日志文件
# 以安全日志管理员身份登录设备。
# 配置存放安全日志文件的目录为flash:/test。（flash:/test仅为示例）
<Sysname> mkdir test
Creating directory flash:/test... Done.
<Sysname> system-view
[Sysname] info-center security-logfile directory flash:/test
[Sysname] quit
# 手动将安全日志缓冲区中的内容保存到安全日志文件。
<Sysname> security-logfile save
The contents in the security log file buffer have been saved to the file flash:/seclog/seclog.log.
· BPDU攻击
接入端口一般直接与用户终端（如PC）或文件服务器相连，此时接入端口被设置为边缘端口以实现这些端口的快速迁移；当这些端口接收到BPDU，系统会自动将这些端口设置为非边缘端口，重新计算生成树，从而引起网络拓扑结构的变化。这些端口正常情况下应该不会收到STP的BPDU。如果有人伪造BPDU恶意攻击设备，就会引起网络震荡。
· 根桥攻击
由于维护人员的错误配置或网络中的恶意攻击，网络中的合法根桥有可能会收到优先级更高的BPDU，这样当前合法根桥会失去根桥的地位，引起网络拓扑结构的错误变动。这种不合法的变动，会导致原来应该通过高速链路的流量被牵引到低速链路上，导致网络拥塞。
· TC-BPDU攻击
在有人伪造TC-BPDU恶意攻击设备时，设备短时间内会收到很多的TC-BPDU，频繁的刷新操作给设备带来很大负担，给网络的稳定带来很大隐患。
针对以上攻击行为，可以在设备上配置如下安全策略：
· BPDU保护
在设备上部署BPDU保护功能，可以防止BPDU攻击。如果边缘端口收到了BPDU，系统就将这些端口关闭，同时通知网管这些端口已被生成树协议关闭。
· 根保护
在设备的指定端口上部署根保护功能，通过维护指定端口的角色来保护根桥的地位，可以防止根桥频繁变动。
· TC-BPDU攻击保护
在设备上部署TC-BPDU攻击保护功能，可以防止TC-BPDU攻击。当设备在单位时间（固定为十秒）内收到TC-BPDU的次数大于TC-BPDU攻击保护功能所指定的最高次数（假设为N次），那么该设备在这段时间之内将只进行N次刷新转发地址表项的操作，而对于超出N次的那些TC-BPDU，设备会在这段时间过后再统一进行一次地址表项刷新的操作，这样就可以避免频繁地刷新转发地址表项。
· 配置BPDU保护
# 在系统视图下开启BPDU保护功能。
<Sysname> system-view
[Sysname] stp bpdu-protection
# 在指定的边缘端口上开启BPDU保护功能。
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] stp port bpdu-protection enable
· 配置根保护
# 开启端口的根保护功能。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] stp root-protection
· 配置TC-BPDU攻击保护
# 开启防TC-BPDU攻击保护功能。
<Sysname> system-view
[Sysname] stp tc-protection
# 配置在单位时间（固定为十秒）内，设备收到TC-BPDU后一定时间内，允许收到TC-BPDU后立即刷新转发地址表项的最高次数为10（10仅为示例）。
[Sysname] stp tc-protection threshold 10
· 邻居验证功能
开启邻居验证功能后，如果满足表4-1所示的邻居验证通过条件，则接口可以继续收发数据报文；否则阻塞接口，即接口的链路层状态置为DOWN，且不允许该接口继续收发数据报文。
|
配置的邻居识别信息 |
邻居验证通过条件 |
|
配置邻居Chassis ID TLV识别信息 |
接口从邻居收到的LLDPDU中携带的Chassis ID TLV与配置相同 |
|
配置邻居Port ID TLV识别信息 |
接口从邻居收到的LLDPDU中携带的Port ID TLV与配置相同 |
|
配置邻居Chassis ID TLV和Port ID TLV识别信息 |
接口从邻居收到的LLDPDU中携带的Chassis ID TLV和Port ID TLV与配置全部相同 |
· 超时保护功能
通过部署超时保护功能，可以防止恶意攻击导致邻居老化后接口继续接收报文。邻居老化超时保护功能分为邻居老化超时后阻塞接口和邻居老化超时后关闭接口。
¡ 阻塞接口：在超过老化时间后，如果接口收不到LLDP报文，则阻塞该接口，即接口的链路层状态置为DOWN，且不允许该接口继续收发数据报文；如果接口收到LLDP报文，则该接口可以继续收发数据报文。接口收发协议报文不受影响。
¡ 关闭接口：在超过老化时间后，会立刻关闭接口，即接口的状态置为LLDP DOWN，且不允许该接口继续收发数据报文和协议报文。
· 配置邻居验证功能
# 进入接口视图。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
# 配置邻居Chassis ID TLV识别信息，邻居Chassis ID TLV别信息的邻居设备Chassis ID子类型编号为4，邻居设备Chassis ID为0012-2255-7766。（各参数仅为示例）
[Sysname-GigabitEthernet1/0/1] lldp neighbor-identity chassis-id 4 0012-2255-7766
# 配置邻居Port ID TLV识别信息，邻居Port ID TLV识别信息的邻居设备端口ID子类型编号为5，邻居设备端口ID为gigabitethernet1/0/1。（各参数仅为示例）
[Sysname-GigabitEthernet1/0/1] lldp neighbor-identity port-id 5 gigabitethernet1/0/1
# 开启邻居验证功能。
[Sysname-GigabitEthernet1/0/1] lldp neighbor-protection validation
· 配置超时保护功能
# 在指定接口上开启邻居超时保护功能并指定邻居老化超时后阻塞接口。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] lldp neighbor-protection aging block
# 在指定接口上开启邻居超时保护功能并指定邻居老化超时后关闭接口。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/2
[Sysname-GigabitEthernet1/0/2] lldp neighbor-protection aging shutdown
合法的ARP报文发送端MAC地址为单播，攻击源可以伪造发送端MAC地址为组播的ARP报文。如果网关学习到源MAC为组播地址的ARP表项，那么当它基于该类表项转发报文时，会将报文组播发送，严重占用网络资源。
开启ARP表项的检查功能后，设备将不能学习ARP报文中发送端MAC地址为组播MAC的动态ARP表项，也不能手工添加MAC地址为组播MAC的静态ARP表项。
# 开启动态ARP表项的检查功能。
<Sysname> system-view
[Sysname] arp check enable
如果网络中有主机通过向设备发送大量目标IP地址不能解析的IP报文来攻击设备，则会造成下面的危害：
· 设备向目的网段发送大量ARP请求报文，加重目的网段的负载。
· 设备会试图反复地对目标IP地址进行解析，增加了CPU的负担。
为避免这种IP报文攻击所带来的危害，设备提供了下列两个功能：
· ARP源抑制功能：如果发送攻击报文的源是固定的，可以采用ARP源抑制功能。开启该功能后，如果网络中每5秒内从某IP地址向设备某接口发送目的IP地址不能解析的IP报文超过了设置的阈值，则设备将不再处理由此IP地址发出的IP报文直至该5秒结束，从而避免了恶意攻击所造成的危害。
· ARP黑洞路由功能：无论发送攻击报文的源是否固定，都可以采用ARP黑洞路由功能。开启该功能后，一旦接收到目标IP地址不能解析的IP报文，设备立即产生一个黑洞路由，并同时发起ARP主动探测，如果在黑洞路由老化时间内ARP解析成功，则设备马上删除此黑洞路由并开始转发去往该地址的报文，否则设备直接丢弃该报文。在删除黑洞路由之前，后续去往该地址的IP报文都将被直接丢弃。用户可以通过命令配置ARP请求报文的发送次数和发送时间间隔。等待黑洞路由老化时间过后，如有报文触发则再次发起解析，如果解析成功则进行转发，否则仍然产生一个黑洞路由将去往该地址的报文丢弃。这种方式能够有效地防止IP报文的攻击，减轻CPU的负担。
· # 开启ARP源抑制功能，并指定ARP源抑制的阈值为100（100仅为示例）。
<Sysname> system-view
[Sysname] arp source-suppression enable
[Sysname] arp source-suppression limit 100
· # 开启ARP黑洞路由功能，并配置发送ARP探测报文个数为5，发送ARP探测报文的时间间隔为3秒。（各参数仅为示例）
<Sysname> system-view
[Sysname] arp resolving-route enable
[Sysname] arp resolving-route probe-count 5
[Sysname] arp resolving-route probe-interval 3
如果攻击源向设备发送大量的源MAC地址固定的ARP攻击报文，会导致设备表项被占满，无法学习合法的ARP表项。
开启源MAC地址固定的ARP攻击检测功能后，设备会根据ARP报文的源MAC地址对上送CPU的ARP报文进行统计，在5秒内，如果收到同一源MAC地址（源MAC地址固定）的ARP报文超过一定的阈值，则认为存在攻击，系统会将此MAC地址添加到攻击检测表项中。
当开启了ARP日志信息功能，且在该攻击检测表项老化之前，如果设置的检查模式为过滤模式，则会打印日志信息并且将该源MAC地址发送的ARP报文过滤掉；如果设置的检查模式为监控模式，则只打印日志信息，不会将该源MAC地址发送的ARP报文过滤掉。
切换源MAC地址固定的ARP攻击检查模式时，如果从监控模式切换到过滤模式，过滤模式马上生效；如果从过滤模式切换到监控模式，已生成的攻击检测表项，到表项老化前还会继续按照过滤模式处理。
对于网关或一些重要的服务器，可能会发送大量ARP报文，为了使这些ARP报文不被过滤掉，可以将这类设备的MAC地址配置成保护MAC地址，这样，即使该设备存在攻击也不会被检测或过滤。
# 开启源MAC地址固定的ARP攻击检测功能，并选择过滤模式。
<Sysname> system-view
[Sysname] arp source-mac filter
如果选择监控模式，则需要执行arp source-mac monitor命令。
# 配置源MAC地址固定的ARP报文攻击检测的阈值为30个（30仅为示例）。
[Sysname] arp source-mac threshold 30
# 配置源MAC地址固定的ARP攻击检测表项的老化时间为60秒（60仅为示例）。
[Sysname] arp source-mac aging-time 60
# 配置保护MAC地址为001e-1200-0213（001e-1200-0213仅为示例）。
[Sysname] arp source-mac exclude-mac 001e-1200-0213
# 开启源MAC地址固定的ARP攻击检测日志信息功能。
[Sysname] arp source-mac log enable
攻击源向设备发送大量的ARP攻击报文，导致设备表项被占满，无法学习合法的ARP表项。同时，会导致设备的CPU负担过重，造成其他功能无法正常运行甚至设备瘫痪。
接口上开启ARP报文限速功能后，如果单位时间接口收到的ARP报文数量超过用户设定的限速值，则有如下处理机制：
· 当开启了ARP模块的告警功能后，设备将这个时间间隔内的超速峰值作为告警信息发送出去，生成的告警信息将发送到设备的SNMP模块，通过设置SNMP中告警信息的发送参数，来决定告警信息输出的相关特性。有关告警信息的详细介绍请参见“网络管理和监控命令参考”中的SNMP。
· 当开启了ARP限速日志功能后，设备将这个时间间隔内的超速峰值作为日志的速率值发送到设备的信息中心，通过设置信息中心的参数，最终决定日志报文的输出规则（即是否允许输出以及输出方向）有关信息中心参数的配置请参见“网络管理和监控配置指导”中的“信息中心”。
# 开启ARP报文限速的告警功能。
<Sysname> system-view
[Sysname] snmp-agent trap enable arp rate-limit
# 开启ARP报文限速日志功能。
[Sysname] arp rate-limit log enable
# 配置当设备收到的ARP报文速率超过用户设定的限速值时，设备发送告警或日志的时间间隔为120秒（120仅为示例）。
[Sysname] arp rate-limit log interval 120
# 在接口GigabitEthernet1/0/1上开启ARP报文限速功能，并设置ARP报文限速速率为50pps（50仅为示例）。
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] arp rate-limit 50
开启本功能后，ARP模块收到非免费ARP报文时，会将ARP报文中的发送端IP地址和已有ARP表项中的IP地址进行比较。如果发现发送端IP地址和某条ARP表项中的IP地址相同，但MAC地址不同，则认为网络中存在终端用户间的IP地址冲突。此时，ARP模块会生成终端用户间IP地址冲突表项，同时生成对应的IP地址冲突日志。生成的IP地址冲突日志将被发送给信息中心模块处理，信息中心模块的配置将决定日志信息的发送规则和发送方向。本功能可以防御仿冒用户类攻击行为。
# 开启ARP记录终端用户间源IP地址冲突功能。
<Sysname> system-view
[Sysname] arp user-ip-conflict record enable
攻击者仿冒网关，发送错误的网关IP地址和MAC地址对应关系给合法客户端，导致合法客户端不能正常访问网关。
开启源地址冲突提示功能后，设备接收到其它设备发送的ARP报文后，如果发现报文中的源IP地址和自己的IP地址相同，该设备会根据当前源IP地址冲突提示功能的状态，进行如下处理：
· 如果源IP地址冲突提示功能处于关闭状态时，设备发送一个免费ARP报文确认是否冲突，只有收到对应的ARP应答后才提示存在IP地址冲突。
· 如果源IP地址冲突提示功能处于开启状态时，设备立刻提示存在IP地址冲突。
# 开启源IP地址冲突提示功能。
<Sysname> system-view
[Sysname] arp ip-conflict log prompt
开启 ARP报文源MAC地址一致性检查功能后，网关设备在进行ARP学习前将对ARP报文进行检查。如果以太网数据帧首部中的源MAC地址和ARP报文中的源MAC地址不同，则认为是攻击报文，将其丢弃；否则，继续进行ARP学习。
# 开启ARP报文源MAC地址一致性检查功能。
<Sysname> system-view
[Sysname] arp valid-check enable
攻击者仿冒用户的IP地址发送ARP请求给网关，网关收到ARP表项后，新建了错误的ARP表项或更新已有ARP表项的MAC地址，则合法用户无法收到报文。
配置ARP主动确认功能后，设备在新建或更新ARP表项前需进行主动确认，防止产生错误的ARP表项。
为了对ARP表项的学习执行更严格的检查，可以开启严格模式的ARP主动确认功能，具体机制如下：
· 收到目标IP地址为自己的ARP请求报文时，设备会发送ARP应答报文，但不建立ARP表项；
· 收到ARP应答报文时，需要确认本设备是否对该报文中的源IP地址发起过ARP解析：若发起过解析，解析成功后则设备启动主动确认功能，主动确认流程成功完成后，设备可以建立该表项；若未发起过解析，则设备丢弃该报文。
# 开启严格模式的ARP主动确认功能。
<Sysname> system-view
[Sysname] arp active-ack strict enable
开启授权ARP（Authorized ARP）功能后，在动态学习ARP的过程中，只有和DHCP服务器生成的租约或DHCP中继生成的安全表项一致的ARP报文才能够被学习。配置接口的授权ARP功能后，可以防止用户仿冒其他用户的IP地址或MAC地址对网络进行攻击，保证只有合法的用户才能使用网络资源，增加了网络的安全性。关于DHCP服务器和DHCP中继的介绍，请参见“网络互通配置指导”中的“DHCP服务器”和“DHCP中继”。
# 在GigabitEthernet1/0/1上开启授权ARP功能。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] arp authorized enable
· 用户合法性检查：对于ARP信任接口，不进行用户合法性检查；对于ARP非信任接口，进行包括基于用户合法性规则检查、IP Source Guard静态绑定表项的检查、基于DHCP Snooping表项的检查和基于802.1X安全表项来检查ARP报文的发送端IP地址和发送端MAC地址。只要符合三者中的任何一个，就认为该ARP报文合法，进行转发。如果所有检查都没有找到匹配的表项，则认为是非法报文，直接丢弃。
· 报文有效性检查：对于ARP信任接口，不进行报文有效性检查；对于ARP非信任接口，需要根据配置对MAC地址和IP地址不合法的报文进行过滤。可以选择配置源MAC地址、目的MAC地址或IP地址检查模式。
¡ 源MAC地址的检查模式：会检查ARP报文中的源MAC地址和以太网报文头中的源MAC地址是否一致，一致则认为有效，否则丢弃报文；
¡ 目的MAC地址的检查模式（只针对ARP应答报文）：会检查ARP应答报文中的目的MAC地址是否为全0或者全1，是否和以太网报文头中的目的MAC地址一致。全0、全1、不一致的报文都是无效的，需要被丢弃；
¡ IP地址检查模式：会检查ARP报文中的源IP或目的IP地址，如全1、或者组播IP地址都是不合法的，需要被丢弃。对于ARP应答报文，源IP和目的IP地址都进行检查；对于ARP请求报文，只检查源IP地址。
· ARP报文强制转发：对于从ARP信任接口接收到的ARP报文不受此功能影响，按照正常流程进行转发；对于从ARP非信任接口接收到的并且已经通过用户合法性检查的ARP报文的处理过程如下：
¡ 对于ARP请求报文，通过信任接口进行转发；
¡ 对于ARP应答报文，首先按照报文中的以太网目的MAC地址进行转发，若在MAC地址表中没有查到目的MAC地址对应的表项，则将此ARP应答报文通过信任接口进行转发。
· # 配置用户合法性规则，规则编号为0，规则内容为转发源地址为10.1.1.1，掩码为255.255.0.0，源MAC地址为0001-0203-0405，掩码为ffff-ffff-0000的ARP报文。（各参数仅为示例）
<Sysname> system-view
[Sysname] arp detection rule 0 permit ip 10.1.1.1 255.255.0.0 mac 0001-0203-0405 ffff-ffff-0000
# 在VLAN10内开启ARP Detection功能。
[Sysname] vlan 10
[Sysname-vlan10] arp detection enable
[Sysname-vlan10] quit
# 配置二层以太网接口GigabitEthernet1/0/1为ARP信任接口。
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] arp detection trust
· # 开启对ARP报文的MAC地址和IP地址的有效性检查。
<Sysname> system-view
[Sysname] arp detection validate dst-mac ip src-mac
# 在VLAN10内开启ARP Detection功能。
[Sysname] vlan 10
[Sysname-vlan10] arp detection enable
[Sysname-vlan10] quit
# 配置二层以太网接口GigabitEthernet1/0/1为ARP信任接口。
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] arp detection trust
· # 开启VLAN 2的ARP报文强制转发功能。
<Sysname> system-view
[Sysname] vlan 2
[Sysname-vlan2] arp restricted-forwarding enable
ARP自动扫描功能一般与ARP固化功能配合使用，用来防御局域网内的ARP欺骗行为：
· 开启ARP自动扫描功能后，设备会对局域网内的邻居自动进行扫描（向邻居发送ARP请求报文，获取邻居的MAC地址，建立动态ARP表项）。
· 开启固化功能后，设备会将当 前的ARP动态表项（包括ARP自动扫描生成的动态ARP表项）转换为静态ARP表项。通过对动态ARP表项的固化，可以有效防止攻击者修改ARP表项。
接口上开启了ARP自动扫描功能后，会向扫描区间的所有IP地址同时发送ARP请求报文，这会造成设备瞬间CPU利用率过高、网络负载过大的问题。您可以通过设置接口发送ARP报文的速率解决此问题。
固化生成的静态ARP表项数量同样受到设备可以支持的静态ARP表项数目的限制，由于静态ARP表项数量的限制可能导致只有部分动态ARP表项被固化。
# 对接口GigabitEthernet1/0/1上的主IP地址网段内的邻居进行ARP自动扫描。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] arp scan
[Sysname-GigabitEthernet1/0/1] quit
# 将设备上的动态ARP表项转化成静态ARP表项。
[Sysname] arp fixup
攻击者发送错误的网关IP地址和MAC地址对应关系给合法客户端，导致合法客户端不能正常访问网关。
在设备上不与网关相连的接口上开启ARP网关保护功能后，当接口收到ARP报文时，将检查ARP报文的源IP地址是否和配置的被保护网关的IP地址相同。如果相同，则认为此报文非法，将其丢弃；否则，认为此报文合法，继续进行后续处理。
不能在同一个接口上配置ARP网关保护功能和ARP过滤保护功能。
# 在GigabitEthernet1/0/1下开启ARP网关保护功能，受保护的网关IP地址为1.1.1.1。（各参数仅为示例）
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] arp filter source 1.1.1.1
· 攻击者发送错误的网关IP地址和MAC地址对应关系给合法客户端，导致合法客户端不能正常访问网关。
· 攻击者发送伪造的合法客户端的IP地址和MAC地址的对应关系给网关或其他客户端，导致网关或其他客户端无法与合法客户端正常通信。
在接口上开启ARP过滤保护功能后，当接口收到ARP报文时，将检查ARP报文的源IP地址和源MAC地址是否和允许通过的IP地址和MAC地址相同：
· 如果相同，则认为此报文合法，继续进行后续处理；
· 如果不相同，则认为此报文非法，将其丢弃。
不能在同一个接口上配置ARP网关保护功能和ARP过滤保护功能。
# 在GigabitEthernet1/0/1下开启ARP过滤保护功能，允许源IP地址为1.1.1.1、源MAC地址为0e10-0213-1023的ARP报文通过。（各参数仅为示例）
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] arp filter binding 1.1.1.1 0e10-0213-1023
配置ARP报文发送端IP地址检查功能后，网关设备在进行ARP学习前将对ARP报文进行检查。如果指定VLAN内的ARP报文的发送端IP地址不在指定源IP地址范围内，则认为是攻击报文，将其丢弃；否则，继续进行ARP学习。
# 在VLAN 2内配置可接受的ARP报文中sender IP的地址范围为1.1.1.1～1.1.1.20。（各参数仅为示例）
<Sysname> system-view
[Sysname] vlan 2
[Sysname–vlan2] arp sender-ip-range 1.1.1.1 1.1.1.20
ND Snooping功能用于二层交换网络环境，设备通过侦听ND或者数据报文来创建ND Snooping表项，该表项内容包括报文的源IPv6地址、源MAC地址、所属VLAN和报文入端口等信息。
ND Snooping表项可以配合ND Detection和IPv6 Source Guard功能使用，以防止网络中的攻击源发送非法ND报文攻击网关等行为。
# 在VLAN 10内开启学习ND Snooping表项的功能。
<Sysname> system-view
[Sysname] vlan 10
[Sysname-vlan10] ipv6 nd snooping enable global
[Sysname-vlan10] ipv6 nd snooping enable link-local
[Sysname-vlan10] quit
# 配置接口GigabitEthernet1/0/1学习ND Snooping表项的最大个数为64（本例中的参数仅为示例）。
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] ipv6 nd snooping max-learning-num 64
[Sysname-GigabitEthernet1/0/1] quit
# 配置表项的VALID状态的超时时间为250秒（本例中的参数仅为示例）。
[Sysname] ipv6 nd snooping lifetime valid 250
# 配置发送两次DAD NS报文进行探测的时间间隔为200毫秒（本例中的参数仅为示例）。
[Sysname] ipv6 nd snooping dad retrans-timer 200
如果网络中存在攻击源向设备发送大量ND报文，则会造成设备需要处理大量的ND报文，增加了CPU的负担。
当攻击报文的源MAC地址和以太网数据帧首部中的源MAC地址不一致时，可以通过ND协议报文源MAC地址一致性检查功能避免此类攻击。开启本特性后，网关设备会对接收的ND协议报文进行检查。如果ND报文中的源MAC地址和以太网数据帧首部中的源MAC地址不一致，则认为是攻击报文，将其丢弃；否则，继续进行ND学习。
若开启ND日志信息功能，当ND报文中的源MAC地址和以太网数据帧首部中的源MAC地址不同时，会打印相关的日志信息。设备生成的ND日志信息会交给信息中心模块处理，信息中心模块的配置将决定日志信息的发送规则和发送方向。关于信息中心的详细描述请参见“网络管理和监控配置指导”中的“信息中心。
# 开启ND协议报文源MAC地址一致性检查功能。
<Sysname> system-view
[Sysname] ipv6 nd mac-check enable
# 开启ND日志信息功能。
[Sysname] ipv6 nd check log enable
ND Detection功能主要用来在接入设备上检查收到的ND报文是否合法。对于合法用户的ND报文进行正常转发，否则直接丢弃，从而防止仿冒用户、仿冒网关的攻击。
用户合法性检查将从非信任端口接收到的ND报文中的源IPv6地址和源MAC地址与设备上保存的表项进行比较，以便检查用户是否合法。用户合法性检查使用的表项包括IPv6 Source Guard静态绑定表项、ND Snooping表项和DHCPv6 Snooping安全表项的检查。只要ND报文中的信息与任意一条表项相同，就认为该ND报文合法。
配置ND Detection功能时，必须至少配置IPv6 Source Guard静态绑定表项、DHCPv6 Snooping功能和ND Snooping功能三者之一，否则所有从ND非信任接口收到的ND报文都将被丢弃。
# 在VLAN10内开启ND Detection功能。
<Sysname> system-view
[Sysname] vlan 10
[Sysname-vlan10] ipv6 nd detection enable
[Sysname-vlan10] quit
# 配置二层以太网接口GigabitEthernet1/0/1为ND信任接口。
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] ipv6 nd detection trust
# 开启ND Detection日志功能。
[Sysname] ipv6 nd detection log enable
通过与AAA的配合，L2TP提供了对用户进行安全认证的手段，具体包括以下几种方式。
· LAC端的AAA认证
用户身份认证通过后，LAC才能发起建立隧道的请求，否则不会为用户建立隧道。
若采用本地AAA认证，则必须为L2TP用户配置本地用户的用户名和密码；若采用远程AAA认证，则必须为L2TP用户配置远程用户的用户名和密码。
· LNS端的AAA认证
用户身份认证通过后，远端系统才可以通过LNS访问企业内部网络。
若采用本地AAA认证，则必须为L2TP用户配置本地用户的用户名和密码；若采用远程AAA认证，则必须为L2TP用户配置远程用户的用户名和密码。
在LAC端对用户进行验证后，为了增强安全性，可在LNS端再次对用户进行验证。在这种情况下，将对用户进行两次验证，第一次发生在LAC端，第二次发生在LNS端，只有两次验证全部成功后，L2TP隧道才能建立。
目前，LNS端对用户的验证方式按优先级从高到底依次为强制LCP重协商、强制CHAP验证和代理验证三种。
¡ 强制LCP重协商：在L2TP客户端对用户进行验证后，再由L2TP服务器端采用强制LCP重协商方式对用户进行二次LCP协商及认证，增强安全性。
¡ 强制CHAP验证：在L2TP客户端对用户进行验证后，再由L2TP服务器端采用CHAP方式对用户进行二次认证，增强安全性。
¡ 代理验证：由LAC代替LNS对用户进行验证，并将用户的所有验证信息及LAC端本身配置的验证方式发送给LNS。LNS根据接收到的信息及本端配置的验证方式，判断用户是否合法。
LNS端的AAA认证：
· 强制LCP重协商和强制CHAP验证两种验证方式仅适用于NAS-Initiated模式的L2TP组网。
· 如果同时配置了强制LCP重协商和强制CHAP验证两种验证方式，则仅强制LCP重协商生效。
· 如果未配置强制LCP重协商和强制CHAP验证，则对用户进行代理验证。
· 强制CHAP验证
¡ 配置强制CHAP验证时，在LNS的VT接口下必须且只能配置PPP用户的验证方式为CHAP认证。
¡ 对于不支持进行第二次验证的用户，不建议配置本功能，否则将因LNS端的CHAP重新验证失败而导致L2TP隧道无法建立。
· 强制LCP重新协商
启用强制LCP重协商后，如果相应的虚拟模板接口上没有配置验证，则LNS将不对用户进行二次验证（这时用户只在LAC端接受一次验证）。
· 配置LAC端的AAA认证
AAA相关的配置请参见“用户接入与认证配置指导”中的“AAA”。
配置LAC端的AAA认证时，接入用户的接口上需要配置PPP用户的验证方式为PAP或CHAP。
· 配置LNS端的AAA认证
AAA相关的配置请参见“用户接入与认证配置指导”中的“AAA”。
¡ 配置强制LCP重新协商
# 强制LNS与用户进行LCP协商。
<Sysname> system-view
[Sysname] l2tp-group 1 mode lns
¡ 配置强制CHAP验证
# 强制LNS对用户进行CHAP验证。
<Sysname> system-view
[Sysname] l2tp-group 1 mode lns
[Sysname-l2tp1] mandatory-chap
# 进入VT接口并在该接口下配置PPP用户的验证方式为CHAP认证。
在安全性要求较高的L2TP网络中，除了用户名/密码验证外，还需要对用户的其它信息做进一步检查，例如用户是否安装防病毒软件、是否更新病毒库、是否安装了非法软件、是否更新操作系统补丁等。配置基于L2TP接入的EAD功能后，L2TP可以通过和安全策略服务器配合对认证通过的用户做进一步的安全性检查。只有通过安全检查的用户才可以正常访问网络资源，未通过安全检查的用户将只能访问隔离区的资源。
如果LNS设备上开启了基于L2TP接入的EAD功能，但未配置认证服务器下发的ACL号或未准确配置ACL规则，会导致认证不通过。
不同的主机用户ACL可以不同，设备根据不同的ACL对不同的用户进行报文过滤。
建议只在跨越Internet的远端客户端使用此功能，局域网用户不建议使用此功能。
本命令对于虚拟模板接口下已经存在的PPP会话不生效，仅对新创建的PPP会话生效。
# 开启基于L2TP接入的EAD功能。
<Sysname> system-view
[Sysname] interface virtual-template 10
[Sysname-Virtual-Template10] ppp access-control enable
# 配置Portal。
具体配置请参见“安全配置指导”中的“Portal”。
# 配置AAA。
具体配置请参见“用户接入与认证配置指导”中的“AAA”。
# 配置安全策略服务器。
具体配置请参见“CAMS EAD安全策略组件联机帮助”和“iMC EAD安全策略组件联机帮助”。
在L2TP网络中将会面临以下安全威胁：
· 非法对端和本端建立L2TP隧道，窃取本端内部数据。
· 非法用户窃取采用明文方式传输AVP数据（例如隧道协商参数、会话协商参数和用户认证信息）。
针对以上安全威胁，可以在设备上配置如下安全功能：
· L2TP隧道验证
利用隧道验证判断对端的合法性。配置L2TP隧道验证后，仅在两端隧道验证通过后，二者之间才能成功建立L2TP隧道，增强网络的安全性。
· AVP数据的隐藏传输
利用隧道验证密码对AVP数据进行加密传输。配置AVP数据的隐藏传输功能后，L2TP利用隧道验证密码对AVP数据（例如隧道协商参数、会话协商参数和用户认证信息）进行加密传输，增强数据传输的安全性。
· 配置隧道验证
隧道建立成功后，修改隧道验证的密钥不影响当前隧道的正常通信；当隧道断开后重新建立时使用修改后的密钥进行隧道验证。
· 配置AVP数据的隐藏传输
只有使能了隧道验证功能，AVP数据的隐藏传输配置后才会生效。
· 配置隧道验证
# 开启L2TP隧道验证功能。
<Sysname> system-view
[Sysname] l2tp-group 1 mode lns
[Sysname-l2tp1] tunnel authentication
# 以明文方式配置隧道验证密钥为&569pass1（&569pass1仅为示例）。
[Sysname-l2tp1] tunnel password simple &569pass1
· 配置AVP数据的隐藏传输
# 开启L2TP隧道验证功能。
<Sysname> system-view
[Sysname] l2tp-group 1 mode lac
[Sysname-l2tp1] tunnel authentication
# 以明文方式配置隧道验证密钥为&569pass1（&569pass1仅为示例）。
[Sysname-l2tp1] tunnel password simple &569pass1
# 配置AVP数据采用隐藏方式传输。
[Sysname-l2tp1] tunnel avp-hidden
在L2TP网络中，LNS设备可能会面临以下性能安全威胁：
· 用户上线时LNS端需要为其创建VA接口，用于和LAC交换数据；在用户下线后需要删除VA接口。创建/删除VA接口需要消耗一定的系统资源，如果遭受攻击（例如大量用户频繁上下线），易出现处理能力不足，产生拒绝服务，成为攻击者的目标。
· 大量L2TP用户的突发上线请求对设备性能造成影响。
· 乱序报文过多对设备性能造成影响。
· 本端收到的报文超出本端处理报文的能力范围，导致部分用户上线失败。
针对以上安全威胁，可以在设备上配置如下安全功能，减少对设备性能的影响，确保L2TP用户能够平稳上下线：
· 配置VA池
利用VA池减少临时创建/删除VA接口对设备性能的影响。VA池是在建立L2TP连接前事先创建的VA接口的集合。创建VA池后，当有用户上线时，直接从VA池中获取一个VA接口，当用户下线后，直接把VA接口放入VA池中，无需删除VA接口，这样不仅可以提高L2TP连接的建立和拆除速度，还可以一定程度上缓解大量用户突发或频繁上下线对设备性能造成的冲击。
· 配置LNS端每秒能处理ICRQ报文的最大数目
通过配置LNS端每秒能处理ICRQ报文的最大数目来限制设备接收处理ICRQ报文的速率。配置LNS端每秒能处理ICRQ报文的最大数目后，当LNS端每秒收到的ICRQ报文数大于配置值时，丢弃超出的部分，从而避免大量L2TP用户的突发上线请求对设备性能造成影响，同时又确保L2TP用户能够平稳上线。
· 配置L2TP隧道接收窗口的大小
利用隧道接收窗口优化提高对乱序报文的处理效率。如果乱序报文过多，可以通过调整L2TP接收窗口的大小进行缓解。当出现乱序报文的时候，如果乱序报文NS（L2TP报文中用于标识当前报文序列号的字段）在接收窗范围内，设备会先将报文缓存起来，等待NS等于接收窗下沿的报文到达。当收到NS等于接收窗下沿的报文时，则对其（NS等于接收窗下沿的报文）进行处理，处理完该报文后，接收窗下沿加1；如果此时缓存中存在NS等于接收窗下沿的报文，则继续处理；如不存在，则继续等待NS等于接收窗下沿的报文到达；依次类推。对于超过接收窗范围的报文进行丢弃。
· 配置L2TP隧道发送窗口的大小
利用隧道发送窗口平衡隧道两端的报文收发处理能力，优化提高报文处理效率。
在某些组网中可能出现对端的报文接收处理能力和对端接收窗口的大小不匹配的情况（例如：对端实际的报文接收处理能力为10，但接收窗口的大小为20），此时可以通过本特性调整本端L2TP隧道发送窗口的大小来适配对端的实际报文接收处理能力，以保证L2TP用户平稳上线。
· 配置VA池
每个虚拟模板接口只能关联一个VA池。如果想要修改使用的VA池的大小，只能先删除原来的配置，然后重新配置VA池。
创建/删除VA池需要花费一定的时间，请用户耐心等待。在VA池创建/删除过程中（还没创建/删除完成）允许用户上线/下线，但正在创建/删除的VA池不生效。
系统可能由于资源不足不能创建用户指定容量的VA池，用户可以通过display l2tp va-pool命令查看实际可用的VA池的容量以及VA池的状态。
VA池会占用较多的系统内存，请用户根据实际情况创建大小合适的VA池。
删除VA池时，如果已有在线用户使用该VA池中的VA接口，不会导致这些用户下线。
· 配置L2TP隧道接收窗口的大小
在L2TP隧道建立时，接收窗口大小以L2TP组视图下配置的接收窗口大小为准。隧道建立完成后通过本特性修改L2TP隧道接收窗口的大小对已经建立的隧道接收窗口的大小无影响。
· 配置L2TP隧道发送窗口的大小
在L2TP隧道建立时会获取L2TP组视图下配置的发送窗口大小。如果配置的发送窗口大小为0，则按缺省情况处理；如果配置的发送窗口大小非0，则以配置的发送窗口大小为准。隧道建立完成后通过本配置修改L2TP隧道发送窗口的大小对已经建立的隧道发送窗口的大小无影响。
· 配置VA池
# 为虚拟模板2创建容量为1000的VA池（1000仅为示例）。
<Sysname> system-view
[Sysname] l2tp virtual-template 2 va-pool 1000
· 配置LNS端每秒能处理ICRQ报文的最大数目
# 配置LNS端每秒最多能处理200个ICRQ报文（200仅为示例）。
<Sysname> system-view
[Sysname] l2tp icrq-limit 200
· 配置L2TP隧道接收窗口的大小
# 配置隧道的接收窗口大小为128（128仅为示例）。
<Sysname> system-view
[Sysname] l2tp-group 1 mode lac
[Sysname-l2tp1] tunnel window receive 128
· 配置L2TP隧道发送窗口的大小
# 配置隧道的发送窗口大小为128（128仅为示例）。
<Sysname> system-view
[Sysname] l2tp-group 1 mode lac
[Sysname-l2tp1] tunnel window send 128
当认证失败的802.1X用户再次发起认证时，设备会对其进行认证处理。如果大量含有错误认证信息（例如错误用户名或错误的密码等）的802.1X用户频繁发起认证，会导致设备处理用户认证信息时占用大量资源，从而无法处理正常用户的认证信息。
开启静默定时器功能后，当802.1X用户认证失败以后，设备静默一段时间，在静默期间，设备不对802.1X认证失败的用户进行认证处理。
在网络处在风险位置，容易受攻击的情况下，可以适当地将静默定时器值调大一些，反之，可以将其调小一些来提高对用户认证请求的响应速度。
# 开启静默定时器功能，并配置静默定时器的值为100秒（100仅为示例）。
<Sysname> system-view
[Sysname] dot1x quiet-period
[Sysname] dot1x timer quiet-period 100
如果在线的802.1X认证用户使用非法的客户端与设备交互，会逃过代理检测、双网卡检测等iNode客户端的安全检查功能，存在安全隐患。
开启在线用户握手安全功能后，设备会通过检验客户端上传的握手报文中携带的验证信息，来确认用户是否使用iNode客户端进行握手报文的交互。如果握手检验不通过，则会将用户置为下线状态。
只有设备上的在线用户握手功能处于开启状态时，安全握手功能才会生效。
在线用户握手安全功能仅能在iNode客户端和iMC服务器配合使用的组网环境中生效。
# 在端口GigabitEthernet1/0/1上开启在线用户握手安全功能。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] dot1x handshake
[Sysname-GigabitEthernet1/0/1] dot1x handshake secure
在Portal组网环境中，设备将会面临以下安全威胁：
· 攻击者发起大量HTTP/HTTPS请求，造成Portal服务器资源耗尽，无法响应正常认证请求。
· 非法用户使用穷举法试探合法用户的密码。
· 非法用户接入网络。
针对以上安全威胁，可以在设备上配置如下安全功能：
· Portal HTTP/HTTPS防攻击功能
¡ 限制单用户Portal重定向的最大会话数
限制设备上单个Portal用户的HTTP和HTTPS重定向的最大会话数后，如果单个Portal用户的HTTP重定向的最大会话数或HTTPS重定向会话数超出设置值，设备将拒绝新的重定向请求。
¡ Portal安全重定向功能
根据HTTP和HTTPS报文的请求方法、产生HTTP和HTTPS报文的浏览器类型和访问网络的目的URL这些特征，有针对性的将一些HTTP和HTTPS请求报文丢弃，不再重定向到Portal Web服务器，从而有效的减轻了Portal Web服务器的负担。
· Portal认证失败后的用户阻塞功能
如果在指定时间内用户进行Portal认证失败的次数达到指定值，该用户将被阻塞一段时间，即在此时间段内来自该用户的认证请求报文将被丢弃。
· Portal仅允许DHCP用户上线
通常，攻击者的IP地址为静态配置的，因此通过禁止IP地址为静态配置的Portal认证用户上线可以一定程度上避免被攻击的风险。
Portal仅允许DHCP用户上线功能，仅在采用接入设备作为DHCP服务器的组网中生效，且不会影响已经在线的用户。
在IPv6网络中，开启Portal仅允许DHCP用户上线功能后，终端仍会使用临时IPv6地址进行Portal认证，从而导致认证失败，所以终端必须关闭临时IPv6地址。
Portal认证前域中的用户在指定时间内认证失败达到限定次数后不会被阻塞。
对于无线应用，单用户Portal重定向的最大会话数功能仅在集中转发模式生效。
· Portal HTTP/HTTPS防攻击功能
¡ 单用户Portal重定向的最大会话数
# 配置单用户Portal重定向的最大会话数为128。
<Sysname> system-view
[Sysname] portal redirect max-session per-user 128
¡ Portal安全重定向功能
# 开启Portal安全重定向功能。
<Sysname> system-view
[Sysname] portal safe-redirect enable
# 配置Portal安全重定向允许的HTTP协议的请求方法为GET。
[Sysname] portal safe-redirect method get
# 配置匹配Portal安全重定向允许的HTTP User Agent中的浏览器类型为Chrome和Safari。
[Sysname] portal safe-redirect user-agent Chrome
[Sysname] portal safe-redirect user-agent Safari
# 配置Portal安全重定向禁止的URL地址为http://www.abc.com。
[Sysname] portal safe-redirect forbidden-url http://www.abc.com
# 配置Portal安全重定向禁止URL携带扩展名为.jpg的文件。
[Sysname] portal safe-redirect forbidden-file .jpg
# 配置Portal安全重定向URL地址匹配的缺省动作为放行报文。
[Sysname] portal safe-redirect default-action permit
# 配置Portal安全重定向允许的URL地址为http://www.abc.com。
[Sysname] portal safe-redirect permit-url http://www.abc.com
· Portal认证失败后的用户阻塞功能
# 配置在100分钟内用户进行Portal认证失败次数达到2次时被阻塞。
<Sysname> system-view
[Sysname] portal user-block failed-times 2 period 100
# 配置被阻塞用户重新进行Portal认证的时间间隔为20分钟。
[Sysname] portal user-block reactive 20
· Portal仅允许DHCP用户上线
# 在接口GigabitEthernet1/0/1上配置仅允许通过DHCP获取IP地址的客户端上线功能。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] portal user-dhcp-only
缺省情况下，设备仅根据ARP表项对无线Portal客户端进行合法性检查。在采用本地转发模式的无线组网环境中，AC上没有Portal客户端的ARP表项，为了保证合法用户可以进行Portal认证，需要开启无线Portal客户端合法性检查功能。本功能开启后，当设备收到未认证Portal用户的认证报文后，将使用WLAN Snooping表、DHCP Snooping表和ARP表对其进行合法性检查。只有在这三个表中查询到该Portal客户端信息，才认为其合法并允许进行Portal认证。
# 开启无线Portal客户端合法性检查功能。
<Sysname> system-view
[Sysname] portal host-check enable
在线Portal用户数过多，会导致系统资源不足。为解决这个问题，可以限制在线Portal用户数，当在线Portal用户数超过设定的最大值时，系统会拒绝新的Portal用户接入。
建议将全局最大Portal用户数配置为所有开启Portal的接口或无线服务模板上的最大IPv4 Portal用户数和最大IPv6 Portal用户数之和，但不超过整机最大Portal用户数，否则会有部分Portal用户因为整机最大用户数已达到而无法上线。
· 配置全局Portal最大用户数
# 配置全局Portal最大用户数为100。
<Sysname> system-view
[Sysname] portal max-user 100
· 配置接口上的Portal最大用户数
¡ （IPv4网络）
# 在接口GigabitEthernet1/0/1上配置IPv4 Portal最大用户数为100。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] portal ipv4-max-user 100
¡ （IPv6网络）
# 在接口GigabitEthernet1/0/1上配置IPv6 Portal最大用户数为100。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] portal ipv6-max-user 100
· 配置无线服务模板上的Portal最大用户数
¡ （IPv4网络）
# 在无线服务模板上配置IPv4 Portal最大用户数为100。
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] portal ipv4-max-user 100
¡ （IPv6网络）
# 在无线服务模板上配置IPv6 Portal最大用户数为100。
<Sysname> system-view
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] portal ipv6-max-user 100
严格检查模式用于配合服务器上的用户授权控制策略，它仅允许接口上成功下发了授权信息的用户在线。开启Portal授权信息的严格检查模式后，当认证服务器下发的授权ACL、User Profile在设备上不存在或者设备下发ACL、User Profile失败时，设备将强制Portal用户下线。若同时开启了对授权ACL和对授权User Profile的严格检查模式，则只要其中任意一个授权属性未通过严格授权检查，则用户就会下线。
# 在接口GigabitEthernet1/0/1上开启对授权ACL的严格检查模式。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname–GigabitEthernet1/0/1] portal authorization acl strict-checking
SSL VPN以SSL（Secure Sockets Layer，安全套接字层）为基础提供远程的安全连接服务：
· 用户可通过互联网，使用内嵌SSL协议的浏览器或客户端与远端的资源服务器建立安全的连接，访问内部资源。
· 企业或机构可通过SSL VPN来为移动用户或者外部客户提供访问内部资源的服务并保证安全性。
设备作为SSL VPN网关位于远端接入用户和企业内部网络之间，负责在二者之间转发报文，并为对端提供SSL VPN服务，具体过程如下：
(1) 管理员在SSL VPN网关上创建与企业网内服务器对应的资源。
(2) 远程接入用户与SSL VPN网关建立HTTPS连接，通过SSL提供的基于证书的身份验证功能，SSL VPN网关和远程接入用户可以验证彼此的身份。
(3) 远程接入用户输入用户名、密码等身份信息，SSL VPN网关对用户的身份进行认证，并对用户可以访问的资源进行授权。
(4) 用户获取到可以访问的资源，通过SSL连接将访问请求发送给SSL VPN网关。
(5) SSL VPN网关将资源访问请求转发给企业网内的服务器。
(6) SSL VPN网关接收到服务器的应答后，通过SSL连接将其转发给用户。
关于SSL VPN的详细信息，请参见“IP隧道及安全VPN配置指导”中的“SSL VPN”。
缺省情况下，HTTPS重定向服务使用设备自签名的证书，SSL参数均为缺省值。这种方式简化了配置，但是存在安全隐患。
可以通过配置SSL服务器端策略，并将其与HTTPS重定向服务进行关联，来增强HTTPS重定向服务的安全性。
如果关联的SSL服务器端策略不存在，则无法完成HTTPS报文的重定向。允许用户先关联一个不存在的SSL服务器端策略，再对该策略进行相关配置。
# 指定HTTPS重定向服务关联的SSL服务器端策略为policy1。
<Sysname> system-view
[Sysname] http-redirect ssl-server-policy policy1
DHCP饿死攻击是指攻击者伪造chaddr字段各不相同的DHCP请求报文，向DHCP服务器申请大量的IP地址，导致DHCP服务器地址池中的地址耗尽，无法为合法的DHCP客户端分配IP地址，或导致DHCP服务器消耗过多的系统资源，无法处理正常业务。
如果封装DHCP请求报文的数据帧的源MAC地址各不相同，则通过限制端口可以学习到的MAC地址数，并配置学习到的MAC地址数达到最大值时，丢弃源MAC地址不在MAC地址表里的报文，能够避免攻击者申请过多的IP地址，在一定程度上阻止了DHCP饿死攻击。此时，不存在DHCP饿死攻击的端口下的DHCP客户端可以正常获取IP地址，但存在DHCP饿死攻击的端口下的DHCP客户端仍可能无法获取IP地址。
如果封装DHCP请求报文的数据帧的MAC地址都相同，则通过上述方法无法防止DHCP饿死攻击。在这种情况下，需要开启DHCP服务器/DHCP中继的MAC地址检查功能。开启该功能后，DHCP服务器/DHCP中继检查接收到的DHCP请求报文中的chaddr字段和数据帧的源MAC地址字段是否一致。如果一致，则认为该报文合法，进行后续处理；如果不一致，则丢弃该报文。
# 在接口GigabitEthernet1/0/1上开启DHCP服务器的MAC地址检查功能。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] dhcp server check mac-address
# 在接口GigabitEthernet1/0/1上开启DHCP中继的MAC地址检查功能。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] dhcp relay check mac-address
DHCP支持按照用户类分配IP地址。DHCP服务器会根据用户所在的用户类，从对应的地址空间中选择地址分给用户。当某些用户类中存在攻击源时，攻击源获取到地址后，就能在网络中发起攻击行为。
为了避免上述问题，用户可以将不存在攻击源的用户类加入白名单。DHCP服务器只有收到属于用户类白名单的DHCP客户端发送的请求报文，才会进行处理。
· 如果某个用户类未加入白名单，则该用户类对应的所有DHCP客户端都无法获取到IP地址。
· 如果DHCP客户端请求的是静态绑定租约，则DHCP服务器不进行白名单检查直接处理。
# 在DHCP地址池0中开启DHCP用户类白名单功能（本例中的参数仅为示例）。
<Sysname> syatem-view
[Sysname] dhcp server ip-pool 0
[Sysname-dhcp-pool-0] verify class
# 在DHCP地址池0中配置DHCP白名单包括的用户类名为test1和test2。
[Sysname-dhcp-pool-0] valid class test1 test2
在通过DHCP获取地址的组网环境中，所有合法客户端都通过DHCP方式获取到IP地址。某些非法主机使用自身伪造的IP地址发送攻击报文攻击网关，影响网关设备的正常工作。
· DHCP中继用户地址表项记录功能
开启本功能后，当客户端通过DHCP中继从DHCP服务器获取到IP地址时，DHCP中继可以自动记录客户端IP地址与硬件地址的绑定关系，生成DHCP中继的用户地址表项。
本功能与其他IP地址安全功能（如ARP地址检查、授权ARP和IP Source Guard）配合，可以实现只允许匹配用户地址表项中绑定关系的报文通过DHCP中继。从而，保证非法主机不能通过DHCP中继与外部网络通信。
· DHCP中继动态用户地址表项定时刷新功能
DHCP中继动态用户地址表项定时刷新功能开启时，DHCP中继每隔指定时间采用客户端获取到的IP地址向DHCP服务器发送DHCP-REQUEST报文：
¡ 如果DHCP中继接收到DHCP服务器响应的DHCP-ACK报文或在指定时间内未接收到DHCP服务器的响应报文，则表明这个IP地址已经可以进行分配，DHCP中继会删除动态用户地址表中对应的表项。为了避免地址浪费，DHCP中继收到DHCP-ACK报文后，会发送DHCP-RELEASE报文释放申请到的IP地址。
¡ 如果DHCP中继接收到DHCP服务器响应的DHCP-NAK报文，则表示该IP地址的租约仍然存在，DHCP中继不会删除该IP地址对应的表项。
· DHCP中继的用户下线探测功能
如果在接口上配置了DHCP中继的用户下线检测功能，则当ARP表项老化时，DHCP中继认为该表项对应的用户已经下线，删除对应的用户地址表项，并通过发送Release报文通知DHCP服务器删除下线用户的IP地址租约。
手工删除ARP表项，不会触发DHCP中继删除对应的用户地址表项。
# 开启DHCP中继用户地址表项记录功能。
<Sysname> system-view
[Sysname] dhcp relay client-information record
# 开启DHCP中继动态用户地址表项定时刷新功能。
[Sysname] dhcp relay client-information refresh enable
# 配置DHCP中继动态用户地址表项的刷新时间间隔为100秒（本例中的参数仅为示例）。
[Sysname] dhcp relay client-information refresh interval 100
# 开启用户下线探测功能。
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] dhcp client-detect
非法用户向DHCP服务器发送攻击报文后，影响DHCP服务器正常工作。
开启DHCP中继支持代理功能后，DHCP中继收到DHCP服务器的应答报文，会把报文中的DHCP服务器地址修改为中继的接口地址，并转发给DHCP客户端。当DHCP客户端通过DHCP中继从DHCP服务器获取到IP地址等网络参数后，DHCP客户端会把DHCP中继当作自己的服务器，来进行后续的DHCP功能的报文交互。从而达到了把真正的DHCP服务器和DHCP客户端隔离开，保护DHCP服务器的目的。
# 配置接口GigabitEthernet1/0/1工作在DHCP代理模式。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] dhcp select relay proxy
DHCP Snooping是DHCP的一种安全特性。DHCP Snooping设备位于DHCP客户端与DHCP服务器之间，或DHCP客户端与DHCP中继之间。DHCP Snooping的作用是：
· 保证客户端从合法的服务器获取IP地址
为了使DHCP客户端能通过合法的DHCP服务器获取IP地址，DHCP Snooping安全机制允许将端口设置为信任端口和不信任端口：
¡ 信任端口正常转发接收到的DHCP报文。
¡ 不信任端口接收到DHCP服务器响应的DHCP-ACK和DHCP-OFFER报文后，丢弃该报文。
· 记录DHCP客户端IP地址与MAC地址的对应关系
DHCP Snooping通过监听DHCP-REQUEST报文和信任端口收到的DHCP-ACK报文，记录DHCP Snooping表项，其中包括客户端的MAC地址、DHCP服务器为DHCP客户端分配的IP地址、与DHCP客户端连接的端口及VLAN等信息。DHCP Snooping表项可以供ARP Detection和IP Source Guard等安全功能使用。
关于DHCP Snooping的详细信息，请参见“网络互通配置指导”中的“DHCP Snooping”。关于DHCPv6 Snooping的详细信息，请参见“网络互通配置指导”中的“DHCPv6 Snooping”。
网络攻击者通过DHCP服务器为设备分配错误的域名后缀和域名服务器地址，会导致设备域名解析失败，或解析到错误的结果。
在设备上指定DNS信任接口后，域名解析时只采用信任接口动态获得的域名后缀和域名服务器信息，非信任接口获得的信息不能用于域名解析，从而在一定程度上避免这类攻击。
# 指定接口GigabitEthernet1/0/1为DNS信任接口（本例中的参数仅为示例）。
<Sysname> system-view
[Sysname] dns trust-interface gigabitethernet 1/0/1
ICMP差错报文通常被网络层或传输层协议用来在异常情况发生时通知相应设备，以便进行控制和管理。当网络攻击源发送ICMP差错报文进行恶意攻击时，会改变设备的报文转发路径，影响报文的正常发送。
常见的ICMP差错报文包括ICMP重定向报文、ICMP超时报文和ICMP目的不可达报文。为了防止攻击，建议关闭这些ICMP报文发送功能。
· 配置ICMPv4安全功能。
# 关闭设备的ICMP重定向报文发送功能。
<Sysname> system-view
[Sysname] undo ip redirects enable
# 关闭设备的ICMP超时报文发送功能。
[Sysname] undo ip ttl-expires enable
# 关闭设备的ICMP目的不可达报文发送功能。
[Sysname] undo ip unreachables enable
· 配置ICMPv6安全功能。
# 关闭设备的ICMPv6目的不可达报文发送功能。
<Sysname> system-view
[Sysname] undo ipv6 unreachables enable
# 关闭设备的ICMPv6超时报文发送功能。
[Sysname] undo ipv6 hoplimit-expires enable
# 关闭设备的ICMPv6重定向报文发送功能。
[Sysname] undo ipv6 redirects enable
SYN Flood攻击是指攻击者向设备发送大量请求建立TCP连接的SYN报文，而不回应设备的SYN ACK报文，导致设备上建立了大量的TCP半连接，从而达到耗费设备资源，使设备无法处理正常业务的目的。
SYN Cookie功能用来防止SYN Flood攻击。配置SYN Cookie功能后，当设备收到TCP连接请求时，不建立TCP半连接，而直接向发起者回复SYN ACK报文。设备接收到发起者回应的ACK报文后，建立连接，并进入ESTABLISHED状态。通过这种方式，可以避免在设备上建立大量的TCP半连接。
# 开启SYN Cookie功能。
<Sysname> system-view
[Sysname] tcp syn-cookie enable
攻击者仿冒RIP邻居或修改RIP路由信息，可能会使设备学习到错误的路由或引发网络中断。
RIP和RIPng提供了如下几种安全策略：
· 对RIP-1和RIPng报文的零域检查
RIP-1和RIPng报文中的有些字段必须为零，称之为零域。用户可配置RIP-1在接收报文时对零域进行检查，零域值不为零的RIP-1报文将不被处理。
· 对接收到的RIP路由更新报文进行源IP地址检查
RIP在接收报文时进行源IP地址检查，即检查发送报文的接口IP地址与接收报文接口的IP地址是否处于同一网段。如果没有通过检查，则该RIP报文将不被处理。
· RIPv2的报文认证机制
设备在发送报文时携带验证信息，在接收报文时对验证信息进行校验，如果报文校验失败，则该报文将被丢弃。这样可以避免设备接收无法信任的设备的RIPv2报文。
· RIPng基于IPsec安全框架的认证方式
设备在发送的报文中会携带配置好的IPsec安全框架的SPI（Security Parameter Index，安全参数索引）值，接收报文时通过SPI值进行IPsec安全框架匹配：仅接收安全框架匹配的报文；否则该报文将被丢弃，无法正常建立邻居和学习路由。IPsec安全框架的具体情况请参见“安全配置指导”中的“IPsec”。
# 开启进程号为1的RIP进程对RIP-1报文的零域检查功能。
<Sysname> system-view
[Sysname] rip
[Sysname-rip-1] checkzero
# 开启对接收到的RIP路由更新报文进行源IP地址检查的功能。
<Sysname> system-view
[Sysname-rip] rip 100
[Sysname-rip-100] validate-source-address
# 在接口GigabitEthernet1/0/1上配置RFC 2453格式的MD5明文验证，密钥为154&rose（154&rose仅为示例）。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] rip version 2
[Sysname-GigabitEthernet1/0/1] rip authentication-mode md5 rfc2453 plain 154&rose
# 开启进程号为100的RIPng进程对RIPng报文的零域检查功能。
<Sysname> system-view
[Sysname] ripng 100
[Sysname-ripng-100] checkzero
# 配置接口GigabitEthernet1/0/1应用的IPsec安全框架为profile001（profile001仅为示例）。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] ripng ipsec-profile profile001
OSPF报文验证功能可避免路由信息外泄或者OSPF路由器受到恶意攻击。建立OSPF邻居关系时，在发送的报文中携带配置的验证信息；接收报文时对验证信息进行校验。只有通过校验的报文才能接收，否则将不会接收报文，无法建立邻居。
GTSM（Generalized TTL Security Mechanism，通用TTL安全保护机制）功能可避免设备受到CPU利用（CPU-utilization）等类型的攻击（如CPU过载）。当设备收到来自OSPF普通邻居或虚连接邻居的报文时，会判断报文的TTL是否在255-“hop-count”+1到255之间。如果在，就上送报文；如果不在，则直接丢弃报文。
# 配置OSPF区域0使用MD5明文验证模式，验证字标识符为15，验证密钥为abc。（各参数仅为示例）
<Sysname> system-view
[Sysname] ospf 100
[Sysname-ospf-100] area 0
[Sysname-ospf-100-area-0.0.0.0] authentication-mode md5 15 plain abc
# 配置接口GigabitEthernet1/0/1采用MD5明文验证模式，验证字标识符为15，验证密钥为Ab&123456。（各参数仅为示例）
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] ospf authentication-mode md5 15 plain Ab&123456
# 开启接口GigabitEthernet1/0/1的GTSM功能，并指定最大跳数为254（254仅为示例）。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] ospf ttl-security hops 254
恶意用户通过变换组地址，使用一些无效组播组频道加入，造成设备上建立大量无效表项，占用大量系统资源，导致正常用户的点播无法成功。
在使能了IGMP Snooping/MLD Snooping的二层设备上，通过配置组播组过滤器，可以限制用户对组播节目的点播。当用户点播某个组播节目时，主机会发起一个IGMP/MLD成员关系报告报文，该报文将在二层设备上接受组播组过滤器的检查，只有通过了检查，二层设备才会将该主机所属的端口加入到出端口列表中，从而达到控制用户点播组播节目的目的。
# 全局配置组播组过滤器，以限定VLAN 2内的主机只能加入组播组225.1.1.1。（各参数仅为示例）
<Sysname> system-view
[Sysname] acl basic 2000
[Sysname-acl-ipv4-basic-2000] rule permit source 225.1.1.1 0
[Sysname-acl-ipv4-basic-2000] quit
[Sysname] igmp-snooping
[Sysname-igmp-snooping] group-policy 2000 vlan 2
# 全局配置IPv6组播组过滤器，以限定VLAN 2内的主机只能加入IPv6组播组FF03::101。（各参数仅为示例）
<Sysname> system-view
[Sysname] acl ipv6 basic 2000
[Sysname-acl-ipv6-basic-2000] rule permit source ff03::101 128
[Sysname-acl-ipv6-basic-2000] quit
[Sysname] mld-snooping
[Sysname-mld-snooping] group-policy 2000 vlan 2
# 在端口GigabitEthernet1/0/1上配置组播组过滤器，以限定端口GigabitEthernet1/0/1下VLAN 2内的主机只能加入组播组225.1.1.1。（各参数仅为示例）
<Sysname> system-view
[Sysname] acl basic 2000
[Sysname-acl-ipv4-basic-2000] rule permit source 225.1.1.1 0
[Sysname-acl-ipv4-basic-2000] quit
[Sysname] interface gigabitethernet1/0/1
[Sysname-GigabitEthernet1/0/1] igmp-snooping group-policy 2000 vlan 2
# 在端口GigabitEthernet1/0/1上配置IPv6组播组过滤器，以限定端口GigabitEthernet1/0/1下VLAN 2内的主机只能加入IPv6组播组FF03::101。（各参数仅为示例）
<Sysname> system-view
[Sysname] acl ipv6 basic 2000
[Sysname-acl-ipv6-basic-2000] rule permit source ff03::101 128
[Sysname-acl-ipv6-basic-2000] quit
[Sysname] interface gigabitethernet1/0/1
[Sysname-GigabitEthernet1/0/1] mld-snooping group-policy 2000 vlan 2
在组播用户接入网络中，用户主机在某些情况下（比如测试）发出IGMP/MLD普遍组查询报文或IPv4/IPv6 PIM Hello报文，此时存在如下安全威胁：
· 如果二层设备收到了某用户主机发来的IGMP/MLD普遍组查询报文或IPv4/IPv6 PIM Hello报文，那么接收报文的端口就将成为动态路由器端口，从而使VLAN内的所有组播报文都会向该端口转发，导致该主机收到大量无用的组播报文。
· 用户主机发送IGMP/MLD普遍组查询报文或IPv4/IPv6 PIM Hello报文，也会影响该接入网络中三层设备上的组播路由协议状态（如影响IGMP/MLD查询器或DR的选举），严重时可能导致网络中断。
当配置了禁止端口成为动态路由器端口功能后，即使该端口收到了IGMP/MLD普遍组查询报文或IPv4/IPv6 PIM Hello报文，该端口也不会成为动态路由器端口，从而能够有效解决上述问题，提高网络的安全性和对组播用户的控制能力。
# 禁止端口GigabitEthernet1/0/1在VLAN 2内成为动态路由器端口。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] igmp-snooping router-port-deny vlan 2
# 禁止端口GigabitEthernet1/0/1在VLAN 2内成为动态路由器端口。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] mld-snooping router-port-deny vlan 2
设备上的控制平面是指运行大部分路由交换协议进程的处理单元，它的主要工作是进行协议报文的解析和协议的运行。与之相对应的核心物理实体是CPU，它具备灵活的报文处理能力，但数据吞吐能力有限。如果大量协议报文同时上送CPU，会使CPU一直忙于处理协议报文而无法顾及其它任务，最终导致过载甚至设备瘫痪。
可以通过QoS策略实现协议报文限速：在流分类中配置匹配指定协议报文的规则，在流行为中配置限速动作，最后将QoS策略应用在控制平面上，达到对上送CPU的协议报文速率进行限制的目的，保证CPU的正常运转。
# 定义流分类c，配置匹配控制平面DHCP协议报文的规则（DHCP仅为示例）。
<Sysname> system-view
[Sysname] traffic classifier c
[Sysname-classifier-c] if-match control-plane protocol dhcp
[Sysname-classifier-c] quit
# 定义流行为b，动作为报文限速，速率为500个报文每秒（500仅为示例）。
[Sysname] traffic behavior b
[Sysname-behavior-b] packet-rate 500
[Sysname-behavior-b] quit
# 定义策略p，并为流分类c指定流行为b。
[Sysname] qos policy p
[Sysname-qospolicy-p] classifier c behavior b
[Sysname-qospolicy-p] quit
# 将策略p应用到控制平面（集中式设备）。
[Sysname] control-plane
[Sysname-cp] qos apply policy p inbound
# 将策略p应用到指定slot的控制平面（分布式设备－独立运行模式）（集中式IRF设备）。
[Sysname] control-plane slot 1
[Sysname-cp-slot1] qos apply policy p inbound
# 将策略p应用到指定成员设备指定slot的控制平面（分布式设备－IRF模式）。
[Sysname] control-plane chassis 1 slot 1
[Sysname-cp-chassis1-slot1] qos apply policy p inbound
当设备受到非法攻击时，会导致某类协议报文过多，占用设备过多的CPU资源，并导致合法服务请求得不到及时处理。
可以通过开启协议报文限速功能，对上送CPU的报文基于协议进行分类并加以限速处理，超过指定传输速率的协议报文会被丢弃。在协议报文限速功能基础之上，还可以开启基于流的协议报文限速功能，通过源IP或者源MAC来区分不同的用户流并进行限速，该方式下设备还会记录用户的指定协议报文的流量统计情况，为网络管理者判断该用户是否存在流量异常行为提供依据。
开启基于流的协议报文限速功能后，设备首先对报文按照流速率进行限制，然后再按照协议报文速率阈值进行限制。
在任意视图下执行display anti-attack protocol命令，可以查看设备支持限速的所有协议报文。
# 开启全局报文限速功能。（集中式设备）
<Sysname> system-view
[Sysname] anti-attack enable
# 开启指定slot上的全局报文限速功能。（集中式IRF设备）
[Sysname] anti-attack enable slot 1
# 开启ARP协议报文的限速功能。（集中式设备）
[Sysname] anti-attack protocol arp enable
# 开启指定slot上的ARP协议报文的限速功能。（集中式IRF设备）
[Sysname] anti-attack protocol arp enable slot 1
# 配置ARP协议的限速速率为1000包每秒（1000仅为示例）。（集中式设备）
[Sysname] anti-attack protocol arp threshold 1000
# 配置指定slot上的ARP协议的限速速率为1000包每秒（1000仅为示例）。（集中式IRF设备）
[Sysname] anti-attack protocol arp threshold 1000 slot 1
# 开启ARP基于流的协议报文限速功能，并设置ARP协议的流限速速率为50包每秒（50仅为示例）。（集中式设备）
[Sysname] anti-attack protocol arp flow-threshold 50
# 开启指定slot上的ARP基于流的协议报文限速功能，并设置ARP协议的流限速速率为50包每秒（50仅为示例）。（集中式IRF设备）
[Sysname] anti-attack protocol arp flow-threshold 50 slot 1
设备上的控制平面是指运行大部分路由交换协议进程的处理单元，它的主要工作是进行协议报文的解析和协议的运行。与之相对应的核心物理实体是CPU，它具备灵活的报文处理能力，但数据吞吐能力有限。如果同一时刻上送控制平面的报文过多，则有可能在上送过程中被控制平面限速策略丢弃。丢包将严重影响协议的正常运行，所以需及时记录并以合适的方式发出警示。
用户可以通过开启控制平面协议丢包告警日志信息记录功能，使得设备周期性将丢包信息以日志的方式发送到信息中心，并通过设置信息中心的参数，决定日志信息的输出规则（即是否允许输出以及输出方向）。
# 开启所有控制平面协议丢包告警日志功能（all仅为示例）。
<Sysname> system-view
[Sysname] qos control-plane logging protocol all enable
# 配置控制平面协议丢包告警日志信息的生成与发送周期为60秒（60仅为示例）。
[Sysname] qos control-plane logging interval 60
CAPWAP隧道中传输报文，可能会被外部网络恶意攻击、截获报文，然后对报文内容进行更改或者伪造报文，攻击网络环境中的AC等设备。
CAPWAP隧道加密功能使用DTLS（Datagram Transport Layer Security，数据包传输层安全性协议）协议对CAPWAP控制隧道和数据隧道中交互的隧道报文进行加密处理，从而保障了CAPWAP隧道报文的安全性。
开启CAPWAP隧道加密功能后：
· AC回复AP的Discovery Response报文中将携带加密标志位，AP接收到Discovery Response报文后将与该AC进行DTLS握手，然后完成CAPWAP隧道的建立。在AP与AC完成DTLS握手后交互的CAPWAP控制隧道报文将被加密传输。
· AP在收到AC回复的第一个数据隧道保活报文（keepalive报文）后，将与AC通过控制隧道交换包括密钥在内的加密信息，交换完成后再对CAPWAP数据隧道报文进行加密传输（不加密Keepalive报文）。
# 在AP1上开启AP的CAPWAP控制隧道加密功能。
<Sysname> system-view
[Sysname] wlan ap ap1 model WA4320i-ACN
[Sysname-wlan-ap-ap1] tunnel encryption enable
This operation will restart the AP. Continue? [Y/N]
# 在AP1上开启AP的CAPWAP数据隧道加密功能。
<Sysname> system-view
[Sysname] wlan ap ap1 model WA4320i-ACN
[Sysname-wlan-ap-ap1] data-tunnel encryption enable
This operation will restart the AP. Continue? [Y/N]
在实际WLAN网络应用中，若非法客户端接入无线服务，会泄露无线用户的个人信息并向设备发起一系列安全攻击，比如对AP发起泛洪报文攻击，使AP不能正常工作，对无线网络的安全造成威胁。
通过配置客户端接入控制功能，使用黑白名单和ACL规则限制接入无线网络的客户端，可以过滤非法客户端，确保无线网络的安全。
当配置了客户端二次接入认证的时间间隔或者AP收到客户端的攻击报文时，AC才会将该客户端的MAC地址添加到动态黑名单中：
· 配置动态黑名单基于AP生效，AP将拒绝该客户端的接入，但仍可以从AC下的其他AP接入。
· 配置动态黑名单基于AC生效，AC下相连的所有AP都将拒绝该客户端接入。
动态黑名单表项具有一定的老化时间。当到达老化时间时，AC会将MAC地址从动态黑名单中删除。
在AP部署较密集的无线网络环境下，建议用户配置动态黑名单基于AC生效。
新配置的动态黑名单老化时间只对新加入动态黑名单的客户端生效。
若客户端同时存在于白名单和动态黑名单中时，则白名单生效。
· 配置使用黑白名单限制接入WLAN网络的客户端
# 配置允许接入WLAN网络的白名单表项为001c-f0bf-9c92（001c-f0bf-9c92仅为示例）。
<Sysname> system-view
[Sysname] wlan whitelist mac-address 001c-f0bf-9c92
# 配置禁止接入WLAN网络的静态黑名单表项为001c-f0bf-9c92（001c-f0bf-9c92仅为示例）。
<Sysname> system-view
[Sysname] wlan static-blacklist mac-address 001c-f0bf-9c92
# 配置动态黑名单基于AC生效。（仅以基于AC生效为例）（无线AC应用）
<Sysname> system-view
[Sysname] undo wlan dynamic-blacklist active-on-ap
# 配置客户端二次接入认证的时间间隔为100秒。
[Sysname] wlan client reauthentication-period 100
# 配置动态黑名单表项的老化时间为3600秒（3600仅为示例）。
[Sysname] wlan dynamic-blacklist lifetime 3600
· 配置使用ACL规则限制接入WLAN网络的客户端
# 配置ACL 4000（仅以基于接入的ACL规则为例）（各参数仅为示例）。
<Sysname> system-view
[Syname] acl mac 4000
[Syname-acl-mac-4000] rule 0 permit source-mac 001e-35b2-000e ffff-ffff-ffff
[Syname-acl-mac-4000] rule 1 permit source-mac 000e-35b2-000f ffff-ff00-0000
[Syname-acl-mac-4000] rule 2 deny
[Syname-acl-mac-4000] quit
# 在AP下，配置基于ACL的接入控制为4000，仅允许MAC地址为001e-35b2-000e以及匹配OUI（Organizationally unique identifier，组织唯一标识符）值为000e-35的无线客户端接入（各参数仅为示例）。（无线AC应用）
[Sysname] wlan ap ap1 model WA4320i-ACN
[Sysname-wlan-ap-ap1] access-control acl 4000
# 在无线服务模板下，配置基于ACL的接入控制为4000，仅允许MAC地址为001e-35b2-000e以及匹配OUI控制方式的无线客户端接入（各参数仅为示例）。（无线FAT AP应用）
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] access-control acl 4000
WLAN用户接入认证是一种基于用户的安全接入管理机制，根据用户MAC地址来进行访问控制。如果不对接入WLAN网络的用户进行身份认证，则任何用户都可以随意接入，会对无线网络安全造成严重威胁。
WLAN用户接入认证主要包括802.1X和MAC地址认证两种认证方式：
· 802.1X认证系统使用EAP（Extensible Authentication Protocol，可扩展认证协议）来实现客户端、设备端和认证服务器之间认证信息的交换。
· MAC地址认证不需要用户安装任何客户端软件。设备在检测到用户的MAC地址以后，对该用户进行认证操作。认证过程中，不需要用户手动输入用户名或者密码，若该用户认证成功，则允许其访问网络资源，否则该用户则无法访问网络资源。
WLAN用户接入认证支持以下几种认证模式：
表4-2 WLAN用户接入认证模式描述表
|
认证模式 |
工作机制 |
|
|
缺省情况 |
bypass |
不对用户进行认证 |
|
采用802.1X认证 |
dot1x |
只进行802.1X认证 |
|
采用MAC地址认证 |
mac |
只进行MAC地址认证 |
|
采用802.1X和MAC地址认证组合认证 |
mac-then-dot1x |
先进行MAC地址认证，如果失败，再进行802.1X认证，如果认证成功，则不进行802.1X认证 |
|
dot1x-then-mac |
先进行802.1X认证，如果失败，再进行MAC地址认证，如果认证成功，则不进行MAC地址认证 |
|
关于WLAN用户接入认证的详细介绍，请参见“用户接入与认证配置指导”中的“WLAN用户接入认证”。
如果无线网络未采取任何安全措施，则任何用户都可以接入，既占用大量网络资源，又容易使无线网络遭受攻击和窃听。通过配置WLAN用户安全可以对用户进行链路层认证并对数据进行加密保护。
配置WLAN用户安全协议后，客户端发现周围的无线网络，需要通过链路层认证、链路服务协商和用户接入认证，才能安全地访问无线网络。WLAN用户安全协议提供的服务主要包括：
· 链路认证服务
· 数据加密服务
· 用户接入认证服务
WLAN用户安全协议主要包括Pre-RSNA、802.11i和802.11w。其中，Pre-RSNA机制最早出现，安全机制不太完善；802.11i协议是对Pre-RSNA的增强，但仅对无线网络的数据报文进行了加密保护；802.11w建立在802.11i框架上，对无线网络的管理帧进行保护，进一步增强了无线网络的安全性。
· Pre-RSNA安全机制采用开放式系统认证（Open system authentication）和共享密钥认证（Shared key authentication）两种认证模式来进行客户端认证，并且采用WEP加密方式对数据进行加密来保护数据机密性，以对抗窃听。
· 802.11i安全机制又被称为RSNA（Robust Security Network Association，健壮安全网络连接）安全机制，包括WPA（Wi-Fi Protected Access，Wi-Fi保护访问）和RSN（Robust Security Network，健壮安全网络）两种安全模式：
¡ WPA是一种比WEP加密性能更强的安全机制。在802.11i协议完善前，采用WPA为用户提供一个临时性的WLAN安全增强解决方案。
¡ RSN是按照802.11i协议为用户提供的一种WLAN安全解决方案。
· 保护管理帧功能通过保护无线网络中的管理帧来完善无线网络的安全性。802.11w保护的管理帧包括解除认证帧，解除关联帧和部分强壮Action帧。
关于WLAN用户安全的详细信息，请参见“WLAN安全配置指导”中的“WLAN用户安全”。
目前，针对无线网络的安全协议都是由国外提出的，例如Pre-RSNA、802.11i和802.11w，也即WEP、WPA/WPA2和保护管理帧功能。而WAPI（WLAN Authentication and Privacy Infrastructure，无线局域网鉴别与保密基础结构）是中国提出的以802.11无线协议为基础的无线安全标准，它能提供比WEP和WPA/WPA2更强的安全性，对于增强中国的实力和维护国家安全具有重要意义。
WAPI采用证书认证方式和预共享密钥认证方式对客户端身份的合法性进行认证，并且采用单播密钥协商和组播密钥通告对客户端和与AC之间交互的单播/组播数据进行保护。
WAPI协议由以下两部分构成：
· WAI（WLAN Authentication Infrastructure，无线局域网鉴别基础结构）：用于实现身份认证和密钥管理的安全方案。
· WPI（WLAN Privacy Infrastructure，无线局域网保密基础结构）：用于对传输数据进行保护的安全方案，包括数据加解密和重放保护等功能。
关于WAPI的详细信息，请参见“WLAN安全配置指导”中的“WAPI”。
在WLAN组网环境中，非法设备可能存在安全漏洞或被攻击者操纵，对无线网络的安全造成严重危害。WIPS（Wireless Intrusion Prevention System，无线入侵防御系统）是针对802.11协议开发的二层协议检测和防护功能。WIPS通过对信道进行监听及分析处理，从中检测出威胁网络安全、干扰网络服务、影响网络性能的无线行为或设备，并能够对非法设备进行反制使其它无线终端无法与其关联。
关于WIPS的详细信息，请参见“WLAN安全配置指导”中的“WIPS”。
非法用户构造VRRP通告报文攻击VRRP备份组，导致VRRP备份组无法正常运行。
VRRP通过在VRRP报文中增加认证字的方式，验证接收到的VRRP报文。VRRP提供了两种认证方式：
· simple：简单字符认证。发送VRRP报文的路由器将认证字填入到VRRP报文中，而收到VRRP报文的路由器会将收到的VRRP报文中的认证字和本地配置的认证字进行比较。如果认证字相同，则认为接收到的报文是真实、合法的VRRP报文；否则认为接收到的报文是一个非法报文。
· md5：MD5认证。发送VRRP报文的路由器利用认证字和MD5算法对VRRP报文进行摘要运算，运算结果保存在Authentication Header（认证头）中。收到VRRP报文的路由器会利用认证字和MD5算法进行同样的运算，并将运算结果与认证头的内容进行比较。如果相同，则认为接收到的报文是真实、合法的VRRP报文；否则认为接收到的报文是一个非法报文。
MD5认证比简单字符认证更安全，但是MD5认证需要进行额外的运算，占用的系统资源较多。
一个接口上的不同备份组可以设置不同的认证方式和认证字；加入同一备份组的成员需要设置相同的认证方式和认证字。
使用VRRPv3版本的IPv4 VRRP不支持认证。使用VRRPv3版本时，此配置不会生效。
# 设置接口GigabitEthernet1/0/1上备份组1发送和接收IPv4 VRRP报文的认证方式为simple，认证字为Sysname。（各参数仅为示例）
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] vrrp vrid 1 authentication-mode simple plain Sysname
一个使用NTP协议同步时间的网络中，如果没有配置NTP验证，非法的时间服务器就可以随意向网络中的设备发送时间同步信息，可能导致设备同步到错误的时间。
可以通过关联ACL来限制对端设备对本地设备上NTP服务的访问控制权限。
NTP服务的访问控制权限从高到低依次为peer、server、synchronization、query。
· peer：完全访问权限。该权限既允许对端设备向本地设备的时间同步，对本地设备进行控制查询（查询NTP的一些状态，比如告警信息、验证状态、时间服务器信息等），同时本地设备也可以向对端设备的时间同步。
· server：服务器访问与查询权限。该权限允许对端设备向本地设备的时间同步，对本地设备进行控制查询，但本地设备不会向对端设备的时间同步。
· synchronization：仅具有访问服务器的权限。该权限只允许对端设备向本地设备的时间同步，但不能进行控制查询。
· query：仅具有控制查询的权限。该权限只允许对端设备对本地设备的NTP服务进行控制查询，但是不能向本地设备的时间同步。
以上定义的访问控制权限都可以关联ACL，由ntp-service { peer | query | server | synchronization } acl命令配置。设备一旦收到NTP服务请求时，会先对其执行ACL规则匹配再为其分配ACL关联的访问控制权限。具体匹配规则如下：
当设备接收到NTP服务请求时，会按照权限从高到低的顺序依次进行匹配。匹配原则为：
· 如果没有指定权限应用的ACL或权限应用的ACL尚未创建，则继续匹配下一个权限。
· 如果所有的权限都没有应用ACL或权限应用的ACL尚未创建，则所有对端设备对本地设备NTP服务的访问控制权限均为peer。
· 如果存在应用了ACL的权限，且该ACL已经创建，则只有NTP服务请求匹配了某个权限应用的ACL中的permit规则，发送该NTP服务请求的对端设备才会具有该访问控制权限。其他情况下（NTP服务请求匹配某个权限应用的ACL中的deny规则或没有匹配任何权限的任何规则），发送该NTP服务请求的对端设备不具有任何权限。
配置NTP服务的访问控制权限，仅提供了一种最小限度的安全措施，更安全的方法是使用NTP验证功能。
# 创建并配置与访问权限关联的ACL。
具体配置请参见“ACL和QoS配置指导”中的“ACL”
# 配置对端设备对本地设备NTP服务的访问控制权限（2001仅为示例）。
<Sysname> system-view
[Sysname] ntp-service peer acl 2001
网络上大多数信息都需要记录时间，如果设备从非法的时间服务器上获取了时间信息，则会导致设备同步到错误的时间。
NTP通过验证功能来对接收到的NTP报文进行合法性验证。只有报文通过验证后，设备才会接收该报文，并从中获取时间同步信息；否则，设备会丢弃该报文。从而，保证设备不会与非法的时间服务器进行时间同步，避免时间同步错误。
图4-1 NTP验证功能示意图
如图4-1所示，NTP验证功能的工作过程为：
(1) NTP报文发送者利用密钥ID标识的密钥对NTP报文进行加密运算，并将计算出来的摘要信息连同NTP报文和密钥ID一起发送给接收者。
(2) 接收者接收到该NTP报文后，根据报文中的密钥ID找到对应的密钥，并利用该密钥对报文进行相同的加密运算。接收者将运算结果与报文中的摘要信息比较，依据比较结果，有以下两种情况：
¡ 比较结果不相同，则丢弃该报文。
¡ 比较结果相同，则检查NTP报文发送者是否有权在本端使用该密钥ID，检查通过，则接收该报文；否则，丢弃该报文。
客户端和服务器、主动对等体和被动对等体、广播客户端和广播服务器、组播客户端和组播服务器上进行不同的配置时，NTP验证结果有所不同，详细介绍请参见表4-3、表4-4、表4-5、表4-6。其中，表格中的“-”表示不管此项是否配置。
|
客户端 |
服务器 |
结果 |
|||
|
身份验证 |
关联密钥 |
关联密钥存在且为可信密钥 |
身份验证 |
关联密钥存在且为可信密钥 |
|
|
是 |
是 |
是 |
是 |
是 |
身份验证成功 |
|
是 |
是 |
是 |
是 |
否 |
身份验证失败 |
|
是 |
是 |
是 |
否 |
- |
身份验证失败 |
|
是 |
是 |
否 |
- |
- |
身份验证失败 |
|
是 |
否 |
- |
- |
- |
不进行身份验证 |
|
否 |
- |
- |
- |
- |
不进行身份验证 |
表4-4 主动对等体和被动对等体上进行不同配置时的NTP验证结果
|
主动对等体 |
被动对等体 |
结果 |
||||
|
身份验证 |
关联密钥 |
关联密钥存在且为可信密钥 |
时钟层数 |
身份验证 |
关联密钥存在且为可信密钥 |
|
|
是 |
是 |
是 |
- |
是 |
是 |
身份验证成功 |
|
是 |
是 |
是 |
- |
是 |
否 |
身份验证失败 |
|
是 |
是 |
是 |
- |
否 |
- |
身份验证失败 |
|
是 |
否 |
- |
- |
是 |
- |
身份验证失败 |
|
是 |
否 |
- |
- |
否 |
- |
不进行身份验证 |
|
否 |
- |
- |
- |
是 |
- |
身份验证失败 |
|
否 |
- |
- |
- |
否 |
- |
不进行身份验证 |
|
是 |
是 |
否 |
大于被动对等体 |
- |
- |
身份验证失败 |
|
是 |
是 |
否 |
小于被动对等体 |
是 |
- |
身份验证失败 |
|
是 |
是 |
否 |
小于被动对等体 |
否 |
- |
不进行身份验证 |
表4-5 广播客户端和广播服务器上进行不同配置时的NTP验证结果
|
广播服务器 |
广播客户端 |
结果 |
|||
|
身份验证 |
关联密钥 |
关联密钥存在且为可信密钥 |
身份验证 |
关联密钥存在且为可信密钥 |
|
|
是 |
是 |
是 |
是 |
是 |
身份验证成功 |
|
是 |
是 |
是 |
是 |
否 |
身份验证失败 |
|
是 |
是 |
是 |
否 |
- |
身份验证失败 |
|
是 |
是 |
否 |
是 |
- |
身份验证失败 |
|
是 |
是 |
否 |
否 |
- |
不进行身份验证 |
|
是 |
否 |
- |
是 |
- |
身份验证失败 |
|
是 |
否 |
- |
否 |
- |
不进行身份验证 |
|
否 |
- |
- |
是 |
- |
身份验证失败 |
|
否 |
- |
- |
否 |
- |
不进行身份验证 |
表4-6 组播客户端和组播服务器上进行不同配置时的NTP验证结果
|
组播服务器 |
组播客户端 |
结果 |
|||
|
身份验证 |
关联密钥 |
关联密钥存在且为可信密钥 |
身份验证 |
关联密钥存在且为可信密钥 |
|
|
是 |
是 |
是 |
是 |
是 |
身份验证成功 |
|
是 |
是 |
是 |
是 |
否 |
身份验证失败 |
|
是 |
是 |
是 |
否 |
- |
身份验证失败 |
|
是 |
是 |
否 |
是 |
- |
身份验证失败 |
|
是 |
是 |
否 |
否 |
- |
不进行身份验证 |
|
是 |
否 |
- |
是 |
- |
身份验证失败 |
|
是 |
否 |
- |
否 |
- |
不进行身份验证 |
|
否 |
- |
- |
是 |
- |
身份验证失败 |
|
否 |
- |
- |
否 |
- |
不进行身份验证 |
· 配置客户端/服务器模式的NTP验证功能。
# 开启客户端的NTP验证功能。
<DeviceA> system-view
[DeviceA] ntp-service authentication enable
# 在NTP客户端创建编号为42的NTP验证密钥，密钥值为aNiceKey，以明文形式输入。（各参数仅为示例）
[DeviceA] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# 在NTP客户端配置编号为42的密钥为可信密钥（42仅为示例）。
[DeviceA] ntp-service reliable authentication-keyid 42
# 在NTP客户端指定与编号42密钥关联的NTP服务器。
[DeviceA] ntp-service unicast-server 1.1.1.1 authentication-keyid 42
# 开启服务器端的NTP验证功能。
<DeviceB> system-view
[DeviceB] ntp-service authentication enable
# 在NTP服务器端创建编号为42的NTP验证密钥，密钥值为aNiceKey，以明文形式输入。（各参数仅为示例）
[DeviceB] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# 在NTP服务器端配置编号为42的密钥为可信密钥（42仅为示例）。
[DeviceB] ntp-service reliable authentication-keyid 42
· 配置对等体模式的NTP验证功能。
# 开启主动对等体的NTP验证功能。
<DeviceA> system-view
[DeviceA] ntp-service authentication enable
# 在NTP主动对等体创建编号为42的NTP验证密钥，密钥值为aNiceKey，以明文形式输入。（各参数仅为示例）
[DeviceA] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# 在NTP主动对等体配置编号为42的密钥为可信密钥（42仅为示例）。
[DeviceA] ntp-service reliable authentication-keyid 42
# 在NTP主动对等体指定与编号42密钥关联的NTP被动对等体。
[DeviceA] ntp-service unicast-peer 1.1.1.1 authentication-keyid 42
# 开启被动对等体的NTP验证功能。
<DeviceB> system-view
[DeviceB] ntp-service authentication enable
# 在NTP被动对等体创建编号为42的NTP验证密钥，密钥值为aNiceKey，以明文形式输入。（各参数仅为示例）
[DeviceB] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# 在NTP被动对等体配置编号为42的密钥为可信密钥（42仅为示例）。
[DeviceB] ntp-service reliable authentication-keyid 42
· 配置广播模式的NTP验证功能。
# 开启广播客户端的NTP验证功能。
<DeviceA> system-view
[DeviceA] ntp-service authentication enable
# 在NTP广播客户端创建编号为42的NTP验证密钥，密钥值为aNiceKey，以明文形式输入。（各参数仅为示例）
[DeviceA] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# 在NTP广播客户端配置编号为42的密钥为可信密钥（42仅为示例）。
[DeviceA] ntp-service reliable authentication-keyid 42
# 开启广播服务器端的NTP验证功能。
<DeviceB> system-view
[DeviceB] ntp-service authentication enable
# 在NTP广播服务器端创建编号为42的NTP验证密钥，密钥值为aNiceKey，以明文形式输入。（各参数仅为示例）
[DeviceB] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# 在NTP广播服务器端配置编号为42的密钥为可信密钥（42仅为示例）。
[DeviceB] ntp-service reliable authentication-keyid 42
# 将NTP广播服务器与编号42密钥关联。
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] ntp-service broadcast-server authentication-keyid 42
· 配置组播模式的NTP验证功能。
# 开启组播客户端的NTP验证功能。
<DeviceA> system-view
[DeviceA] ntp-service authentication enable
# 在NTP组播客户端创建编号为42的NTP验证密钥，密钥值为aNiceKey，以明文形式输入。（各参数仅为示例）
[DeviceA] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# 在NTP组播客户端配置编号为42的密钥为可信密钥（42仅为示例）。
[DeviceA] ntp-service reliable authentication-keyid 42
# 开启组播服务器端的NTP验证功能。
<DeviceB> system-view
[DeviceB] ntp-service authentication enable
# 在NTP组播服务器端创建编号为42的NTP验证密钥，密钥值为aNiceKey，以明文形式输入。（各参数仅为示例）
[DeviceB] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# 在NTP组播服务器端配置编号为42的密钥为可信密钥（42仅为示例）。
[DeviceB] ntp-service reliable authentication-keyid 42
# 将NTP组播服务器与编号42密钥关联。
[DeviceB] interface gigabitethernet 1/0/1
[DeviceB-GigabitEthernet1/0/1] ntp-service multicast-server 224.0.1.1 authentication-keyid 42
网络上大多数信息都需要记录时间，如果设备从非法的时间服务器上获取了时间信息，则会导致设备同步到错误的时间。
SNTP通过验证功能来对接收到的SNTP报文进行合法性验证。只有报文通过验证后，设备才会接收该报文，并从中获取时间同步信息；否则，设备会丢弃该报文。从而，保证设备不会与非法的时间服务器进行时间同步，避免时间同步错误。
图4-2 SNTP验证功能示意图
如图4-2所示，SNTP验证功能的工作过程为：
(1) SNTP报文发送者利用密钥ID标识的密钥对SNTP报文进行加密运算，并将计算出来的摘要信息连同SNTP报文和密钥ID一起发送给接收者。
(2) 接收者接收到该SNTP报文后，根据报文中的密钥ID找到对应的密钥，并利用该密钥对报文进行相同的加密运算。接收者将运算结果与报文中的摘要信息比较，依据比较结果，有以下两种情况：
¡ 比较结果不相同，则丢弃该报文。
¡ 比较结果相同，则检查SNTP报文发送者是否有权在本端使用该密钥ID，检查通过，则接收该报文；否则，丢弃该报文。
客户端需要将指定密钥与对应的NTP服务器关联，并保证服务端有权在本端使用该密钥ID进行验证。
如果客户端没有成功启用SNTP验证功能，不论服务器端是否开启验证功能，客户端均可以与服务器端同步。
· 配置客户端。
# 开启SNTP客户端的身份验证功能。
<DeviceA> system-view
[DeviceA] sntp authentication enable
# 在SNTP客户端创建编号为42的NTP验证密钥，密钥值为aNiceKey，以明文形式输入。（各参数仅为示例）
[DeviceA] sntp authentication-keyid 42 authentication-mode md5 simple aNiceKey
# 在SNTP客户端配置编号为42的密钥为可信密钥（42仅为示例）。
[DeviceA] sntp reliable authentication-keyid 42
# 在SNTP客户端指定与编号42密钥关联的NTP服务器。
[DeviceA] sntp unicast-server 1.1.1.1 authentication-keyid 42
· 配置服务器端。
# 开启服务器端的NTP验证功能。
<DeviceB> system-view
[DeviceB] ntp-service authentication enable
# 在NTP服务器端创建编号为42的NTP验证密钥，密钥值为aNiceKey，以明文形式输入。（各参数仅为示例）
[DeviceB] ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# 在NTP服务器端配置编号为42的密钥为可信密钥（42仅为示例）。
[DeviceB] ntp-service reliable authentication-keyid 42
接入同一个设备不同接口的多台主机中，若某台主机存在安全隐患，受到攻击后向同一VLAN内的其他主机发送大量单播、组播或广播报文，甚至传播病毒，会影响其他主机、占用网络带宽。通过端口隔离功能，将需要隔离的端口加入到同一个隔离组中，实现隔离组中端口之间的二层隔离，尽可能的将受到攻击时波及的范围控制在一个端口内，提高了网络的安全性。
关于端口隔离的详细信息，请参见“二层技术-以太网交换”中的“端口隔离”。
对使用同一无线服务或在同一VLAN进行通信的用户报文进行隔离，可达到提高用户安全性、缓解设备转发压力和减少射频资源消耗的目的。
用户隔离包括基于SSID的用户隔离和基于VLAN的用户隔离：
· 基于SSID的用户隔离：用于隔离同一SSID下的无线用户。
· 基于VLAN的用户隔离：用于隔离同一VLAN内的有线用户和无线用户。
关于用户隔离的详细信息，请参见“WLAN流量优化配置指导”中的“用户隔离”。
未知组播数据报文是指在IGMP Snooping/MLD Snooping转发表中不存在对应转发表项的组播数据报文，若未开启丢弃未知组播数据报文功能，二层设备将在未知组播数据报文所属的VLAN内广播该报文。这样可能导致广播风暴，降低设备转发性能。
开启了丢弃未知组播数据报文功能后，二层设备只向其路由器端口转发未知组播数据报文，不在VLAN内广播；如果二层设备没有路由器端口，未知组播数据报文报文会被丢弃，不再转发。相对于广播处理，这种方式可以降低瞬时带宽占用率。
# 全局开启丢弃未知组播数据报文功能。
<Sysname> system-view
[Sysname] igmp-snooping
[Sysname-igmp-snooping] drop-unknown
# 全局开启丢弃未知IPv6组播数据报文功能。
<Sysname> system-view
[Sysname] mld-snooping
[Sysname-mld-snooping] drop-unknown
# 在VLAN 2内使能IGMP Snooping，并开启丢弃未知组播数据报文功能。
<Sysname> system-view
[Sysname] igmp-snooping
[Sysname-igmp-snooping] quit
[Sysname] vlan 2
[Sysname-vlan2] igmp-snooping enable
[Sysname-vlan2] igmp-snooping drop-unknown
# 在VLAN 2内使能MLD Snooping，并开启丢弃未知IPv6组播数据报文功能。
<Sysname> system-view
[Sysname] mld-snooping
[Sysname-mld-snooping] quit
[Sysname] vlan 2
[Sysname-vlan2] mld-snooping enable
[Sysname-vlan2] mld-snooping drop-unknown
设备的MAC地址学习功能通常处于开启状态。有时为了保证设备的安全，需要关闭MAC地址学习功能。例如，非法用户使用大量源MAC地址不同的报文攻击设备，导致设备MAC地址表资源耗尽，造成设备无法根据网络的变化更新MAC地址表。关闭MAC地址学习功能可以有效防止这种攻击。
# 关闭全局MAC地址学习功能。
<Sysname> system-view
[Sysname] undo mac-address mac-learning enable
# 关闭VLAN 10的MAC地址学习功能。
<Sysname> system-view
[Sysname] vlan 10
[Sysname-vlan10] undo mac-address mac-learning enable
# 关闭端口GigabitEthernet1/0/1的MAC地址学习功能。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] undo mac-address mac-learning enable
当非法用户使用大量源MAC地址不同的报文攻击设备时，会导致设备的MAC地址表变得庞大，可能引起设备转发性能下降的问题。为了避免网络受到冲击，可以配置MAC地址数学习上限功能。当MAC地址的学习数量达到上限时，则不再对MAC地址进行学习。同时还可以通过配置达到上限后的转发规则来控制是否允许系统转发源MAC不在MAC地址表中的报文。也可以开启告警功能在MAC地址数目达到最大值时、达到最大值后MAC地址数降低到最大值的90%以下时生成日志信息。
# 配置端口GigabitEthernet1/0/1的MAC地址数学习上限为600，当端口学习的MAC地址数达到600时，禁止转发源MAC地址不在MAC地址表里的报文。（600仅为示例）
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] mac-address max-mac-count 600
[Sysname-GigabitEthernet1/0/1] undo mac-address max-mac-count enable-forwarding
# 配置VLAN 10的MAC地址数学习上限为600，当VLAN 10学习的MAC地址数达到600时，禁止转发源MAC地址不在MAC地址表里的报文。（600仅为示例）
<Sysname> system-view
[Sysname] vlan 10
[Sysname-vlan10] mac-address max-mac-count 600
[Sysname-vlan10] undo mac-address max-mac-count enable-forwarding
基于MAC地址转发报文的网络中，有时会因为下行接口的攻击行为或者环路，使得下行接口学习到网关等上层设备的MAC地址。例如，非法用户伪装成上层设备的MAC地址从下行接口入侵，干扰上层设备与其他设备的正常通信
为了避免这种情况，将接口的MAC地址学习功能分为两个优先级：高优先级和低优先级。对于高优先级的接口，可以学习任何MAC地址；对于低优先级的接口，在学习MAC地址时需要查看高优先级接口是否已经学到该MAC地址，如果已经学到，则不允许学习该MAC地址。比如，可以将上行接口的MAC地址学习优先级配置为高优先级，下行接口的MAC地址学习优先级配置为低优先级，那么，下行接口就不会学到网关等上层设备的MAC地址，避免了攻击。
# 配置端口GigabitEthernet1/0/1的MAC地址学习优先级为高优先级。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] mac-address mac-learning priority high
MAC地址迁移是指：设备从某接口（假设接口A）学习到某MAC地址，之后从另一接口（假设接口B）接收到了以该MAC地址为源MAC地址的报文，且接口B与接口A所属的VLAN相同，则该MAC地址表项的出接口改为接口B，此时认为该MAC地址从接口A迁移到接口B。
如果MAC地址迁移频繁出现，且同一MAC地址总是在特定的两个接口之间迁移，那么网络中可能存在二层环路或存在非法用户将攻击报文的源MAC伪装成了合法用户的MAC地址。
当监测到某端口频繁迁移时，用户可以通过配置MAC地址迁移抑制功能，使频繁迁移的端口down，一定时间后该端口将自行恢复up，或者用户通过手动方式将该端口up。
# 开启MAC地址迁移上报功能。
<Sysname> system-view
[Sysname] mac-address notification mac-move
# 在端口GigabitEthernet1/0/1上开启MAC地址迁移抑制功能。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] mac-address notification mac-move suppression
IPsec是一组安全协议集合，能够为承载于IP协议上的数据提供包括发送方认证、完整性验证和机密性保证等一整套安全服务，其包括AH（Authentication Header，认证头）、ESP（Encapsulating Security Payload，封装安全载荷）、IKE（Internet Key Exchange，互联网密钥交换）和IKEv2（Internet Key Exchange Version 2，互联网密钥交换第2版）等协议。其中，AH协议和ESP协议用于提供安全服务，IKE协议和IKEv2协议用于密钥交换。
关于Ipsec、IKE和IKEv2的详细信息，请参见“IP隧道及安全VPN配置指导”中的“IPsec”、“IKE”和“IKEv2”。
如果设备收到被篡改的GRE数据报文或非法客户端伪造的GRE报文，会遭受到不可预知的攻击。
GRE支持GRE Key验证、校验和验证两种安全机制。
· GRE Key验证
通过GRE Key验证可以检查报文的合法性。
发送方在发送的报文中携带本地配置的GRE Key。接收方收到报文后，将报文中的GRE Key与接收方本地配置的GRE Key进行比较，如果一致则对报文进行进一步处理，否则丢弃该报文。
· GRE校验和验证
通过GRE校验和验证可以检查报文的完整性。
发送方根据GRE头及Payload信息计算校验和，并将包含校验和信息的报文发送给对端。接收方对接收到的报文计算校验和，并与报文中的校验和比较，如果一致则对报文进行进一步处理，否则丢弃该报文。
· # 在隧道模式为GRE的Tunnel接口上开启GRE报文校验和功能。
<Sysname> system-view
[Sysname] interface tunnel 2 mode gre
[Sysname-Tunnel2] gre checksum
· # 设置GRE类型Tunnel接口的GRE Key为@bd123（@bd123仅为示例）。
<Sysname> system-view
[Sysname] interface tunnel 2 mode gre
[Sysname-Tunnel2] gre key @bd123
ACL（Access Control List，访问控制列表）是一系列用于识别报文流的规则的集合。ACL需要与其他功能配合使用，例如报文过滤、QoS策略和策略路由等。这些功能通过引用ACL对收发报文进行精确识别，并对命中ACL规则的报文执行预先设定的策略，达到控制网络访问行为和提高网络带宽利用率等目的。
根据规则制订依据的不同，可以将ACL分为如表5-1所示的几种类型。
表5-1 ACL的分类
|
ACL类型 |
编号范围 |
适用的IP版本 |
规则制订依据 |
|
基本ACL |
2000～2999 |
IPv4 |
报文的源IPv4地址 |
|
IPv6 |
报文的源IPv6地址 |
||
|
高级ACL |
3000～3999 |
IPv4 |
报文的源IPv4地址、目的IPv4地址、报文优先级、IPv4承载的协议类型及特性等三、四层信息 |
|
IPv6 |
报文的源IPv6地址、目的IPv6地址、报文优先级、IPv6承载的协议类型及特性等三、四层信息 |
||
|
二层ACL |
4000～4999 |
IPv4和IPv6 |
报文的源MAC地址、目的MAC地址、802.1p优先级、链路层协议类型等二层信息 |
|
用户自定义ACL |
5000～5999 |
IPv4和IPv6 |
以报文头为基准，指定从报文的第几个字节开始与掩码进行“与”操作，并将提取出的字符串与用户定义的字符串进行比较，从而找出相匹配的报文 |
关于ACL的详细信息，请参见“ACL和QoS配置指导”中的“ACL”。
网络和设备在运行过程中，业务系统可能会因为外部的攻击流量引发系统过载或异常，最终导致业务不可用。通过流量过滤功能可以禁止某些流量特征的报文通过，保护网络和设备的正常运行，保证合法流量的正常转发。
流量过滤功能通过QoS策略实现。将配置了流量过滤动作的QoS策略应用在指定位置（接口、全局或VLAN等），对符合流分类的流执行过滤动作（允许或禁止通过）。例如，可以根据网络的实际情况禁止从某个源IP地址发送过来的报文通过。
# 定义高级ACL 3000，匹配源IP地址为10.0.0.2的数据流。（各参数仅为示例）
<Device> system-view
[Device] acl advanced 3000
[Device-acl-ipv4-adv-3000] rule permit ip source 10.0.0.2 0
[Device-acl-ipv4-adv-3000] quit
# 定义类classifier_1，匹配高级ACL 3000。
[Device] traffic classifier classifier_1
[Device-classifier-classifier_1] if-match acl 3000
[Device-classifier-classifier_1] quit
# 定义流行为behavior_1，动作为流量过滤（deny），对数据包进行丢弃。
[Device] traffic behavior behavior_1
[Device-behavior-behavior_1] filter deny
[Device-behavior-behavior_1] quit
# 定义策略policy，为类classifier_1指定流行为behavior_1。
[Device] qos policy policy
[Device-qospolicy-policy] classifier classifier_1 behavior behavior_1
[Device-qospolicy-policy] quit
# 将策略policy应用到端口GigabitEthernet1/0/1的入方向上。
[Device] interface gigabitethernet 1/0/1
[Device-GigabitEthernet1/0/1] qos apply policy policy inbound
IP Source Guard功能用于对AP收到的上行数据报文进行过滤控制，以防止非法客户端的报文通过，比如非法客户端仿冒合法客户端IP接入网络，提高无线网络的安全性。
IP Source Guard的具体工作机制如下：
(1) 生成绑定表项
· 对于使用IPv4地址的客户端，AP会截获客户端发送的ARP报文或者与DHCP服务器间交互的DHCPv4报文，从报文中获取到客户端的IP地址，并与客户端的MAC地址形成绑定表项。
· 对于使用IPv6地址的客户端，有以下两种方式生成绑定表项。
¡ DHCPv6方式：AP会截获客户端与DHCPv6服务器间交互的DHCPv6报文，从报文中获取到DHCPv6服务器为客户端分配的完整的IPv6地址，并与客户端的MAC地址形成绑定表项。
¡ ND方式：AP监听网络中的NS和NA报文，从报文中获取IPv6地址，并与客户端的MAC地址形成绑定表项。
(2) 匹配绑定表项，过滤报文
AP在收到客户端报文时，查找绑定表项，如果客户端发送报文的特征项（源MAC地址+源IP地址）与某个绑定表项匹配，则转发该报文，否则做丢弃处理。
对于IPv4报文，不仅要地址匹配绑定表项，还要求客户端使用的IP地址是通过DHCP方式获取的，才转发报文，否则做丢弃处理。
关于IP Source Guard的详细信息，请参见“安全配置指导”中的“IP Source Guard”。
包过滤防火墙可以对匹配的数据流进行转发限制，仅放行信任的报文。但为了保证设备发起的请求能够正常收到应答报文，包过滤防火墙必须双向放行。这种情况下则无法限制不受信任的网络对设备发起威胁攻击或非法请求。
为了解决包过滤防火墙存在的问题，提出了状态防火墙——ASPF（Advanced Stateful Packet Filter，高级状态包过滤）的概念。ASPF和包过滤防火墙协同工作，包过滤防火墙负责按照ACL规则进行报文过滤（阻断或放行），ASPF负责对已放行报文进行信息记录，使已放行的报文的回应报文可以正常通过配置了包过滤防火墙的接口。这样既可保证设备发起的请求能够正常收到应答报文，又能阻断不信任网络主动对设备发起的攻击。
关于ASPF的详细信息，请参见“安全配置指导”中的“ASPF”。
网络连接通常由报文五元组（源IP地址、源端口号、目的IP地址、目的端口号和协议类型）表示，用于标识一条端到端的数据流。在以下场景中，有必要对流经设备的特定数据流进行限制：
· 外网主机与内网服务器建立大量连接，消耗服务器的连接资源，影响其处理性能，使其不能为其他用户提供正常服务。
· 外网主机直接与设备建立大量连接，挤占设备的处理资源，降低其服务性能。
· 内网主机与外网服务器建立大量连接，消耗网关设备的表项资源（如NAT表项），使其他内网用户无法与外网进行正常通信。
设备提供多粒度阈值方式限制匹配指定ACL的新建连接的数量，管理员可基于报文源IP地址、目的IP地址和服务（目的端口号与协议类型）等粒度的不同组合来配置阈值，并可同时限制新建连接的速率。
关于连接数限制的详细信息，请参见“安全配置指导”中的“连接数限制”。
部署于公网的网关设备，以及位于网关设备下游的主机或服务器容易受到各类单包攻击、扫描攻击和泛洪攻击等DoS（Denial of Service，拒绝服务）攻击的侵害。受到DoS攻击的设备往往无法对正常用户的请求作出响应。
设备支持对如下DoS攻击进行有效防范：
· 单包攻击：ICMP redirect、ICMP unreachable、ICMP type、ICMPv6 type、Land、Large ICMP、Large ICMPv6、IP option、IP option abnormal、Fragment、Impossible、Tiny fragment、Smurf、TCP Flag、Traceroute、Winnuke、UDP Bomb、UDP Snork、UDP Fraggle、Teardrop、Ping of death、IPv6 ext-header
· 扫描攻击：IP Sweep、Port scan、分布式Port scan
· 泛洪攻击：SYN flood、ACK flood、SYN-ACK flood、FIN flood、RST flood、DNS flood、DNS reply flood、HTTP flood、SIP flood、ICMP flood、ICMPv6 flood、UDP flood
关于DoS攻击检测与防范的详细信息，请参见“安全配置指导”中的“攻击检测与防范”。
Naptha属于DDoS（Distributed Denial of Service，分布式拒绝服务）攻击方式，主要利用操作系统TCP/IP栈和网络应用程序需要使用一定的资源来控制TCP连接的特点，在短时间内不断地建立大量的TCP连接，并且使其保持在某个特定的状态（CLOSING、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2和LAST_ACK五种状态中的一种），而不请求任何数据，那么被攻击设备会因消耗大量的系统资源而陷入瘫痪。
防止Naptha攻击功能通过加速TCP状态的老化，来降低设备遭受Naptha攻击的风险。开启防止Naptha攻击功能后，设备周期性地对各状态的TCP连接数进行检测。当某状态的最大TCP连接数超过指定的最大连接数后，将加速该状态下TCP连接的老化。
关于Naptha攻击防范的详细信息，请参见“安全”中的“基于IP的攻击防御”。
传统的包过滤设备仅可以基于五元组对报文进行控制，但无法对具有攻击特征的报文进行深度识别，一旦设备遭到黑客攻击、病毒入侵，则可能导致设备瘫痪，无法正常转发数据。
安全策略是一种基于安全域的高级包过滤技术。安全策略不仅包含包过滤防火墙对匹配流量进行放行或丢弃的功能，还融合了应用识别以及报文深度检测功能。通过在不同的源安全域与目的安全域Local之间应用安全策略规则，并引用DPI业务（入侵防御系统），可有效防范病毒、黑客对设备的攻击行为，全方位保护设备。
关于安全策略的详细信息，请参见“安全配置指导”中的“安全策略”。
支持
