H3C 无线接入点安全加固手册
Copyright © 2019 新华三技术有限公司 版权所有，保留一切权利。
非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。
除新华三技术有限公司的商标外，本手册中出现的其它公司的商标、产品标识及商品名称，由各自权利人拥有。
本文档中的信息可能变动，恕不另行通知。
本手册主要适用于如下工程师：
· 网络规划人员
· 现场技术支持与维护人员
· 负责网络配置和维护的网络管理员
本手册中出现的接口编号仅作示例，并不代表设备上的实际接口编号。实际使用过程中，请以设备上存在的接口编号为准。
本文档不严格与具体软、硬件版本对应，如果使用过程中与产品实际情况有差异，请以设备实际情况为准。
本文档中的配置均是在实验室环境下进行的配置和验证，配置前设备的所有参数均采用出厂时的缺省配置。如果您已经对设备进行了配置，为了保证配置效果，请确认现有配置和以下举例中的配置不冲突。
本文中的内容为通用性技术信息，某些信息可能不适用于您所购买的产品。
本文档针对基于Comware系统的设备，指导用户从管理平面、控制平面和转发平面对设备进行加固维护。
设备的管理平面给网络管理人员提供Telnet、SSH、Web、SNMP等方式来管理设备；设备的控制平面用于控制和管理所有网络协议的运行，为转发平面提供数据转发所必须的各种网络信息和转发查询表项。
由于网络设备之间或网络设备与其它网络实体之间的通信可能会穿过各种各样的中间系统，而中间系统的可信性以及对端身份的真实性会给设备的管理平面和控制平面带来各种安全威胁。另外，如果设备上的安全策略配置不当，也会威胁到设备的安全。
设备的管理平面和控制平面常见的安全威胁主要包括以下几类：
· 非授权的访问
攻击者通过伪装身份、重放管理会话或者中间人攻击来获取管理员权限，这会危害到设备的安全以及设备所处网络的安全。建议管理员使用强身份认证，以及支持防重放、信息完整性验证的安全通道来访问设备。同时，建议在设备上启用操作日志、安全日志功能对管理行为进行记录和审计。
· 弱密钥
弱密钥很容易被破解。设备上支持启用密码策略来防止用户配置弱密钥。
· 敏感信息泄漏
由于网络节点间的通信所经过的中间系统的可信性无法保障，通信内容可能会被窥探；设备存储介质中的信息也可能在介质转移、替换的过程中存在信息泄露的风险。为了防止信息泄露，设备的管理通道需要使用安全协议保护，例如SSH、IPsec、SFTP、HTTPS等，禁止使用Telnet、FTP、TFTP、HTTP等没有保护的通道进行通信。另外，建议使用配置文件加密功能，以及对从现网替换下来且不再使用的存储介质进行格式化。
· 消息篡改和伪造
报文在网络中传输的过程中，可能会被恶意篡改，或者被攻击者捕获之后重放，攻击者借此向设备中注入恶意的数据，或直接破坏设备的合法数据。例如，通过更改路由协议报文的数据来破坏或改变设备的路由表，使用户的流量无法正常转发。为防止该类型攻击，可使用带完整性验证，防重放等功能的安全协议对数据进行保护。
· DDoS
DDoS（Distributed Denial of Service，分布式拒绝服务）是指攻击者利用大流量来消耗设备的CPU、内存、连接数、带宽等资源，使合法用户无法使用网络。可使用白名单，黑名单，以及限制未识别流量上送控制平面的速率来防止此类攻击。
· 管理员配置失误
管理员配置失误会造成设备的访问控制策略、权限控制策略的配置错误，或者造成授权不当的结果。为了及早发现此类问题，可以通过实施前对配置进行审核，实施后定期观察实施效果、查看操作日志和系统运行日志来发现配置中的错误。
设备的转发平面需要处理各端口上大量不同类型数据流量的转发任务。如果数据流量不合法，或者转发平面处理资源被挤占，将会影响设备对正常数据流量的处理效率，甚至导致非法流量向网络中扩散。常见的转发平面威胁如下：
· 畸形报文攻击
畸形报文攻击利用网络设备处理报文的漏洞使设备出现异常，使设备无法提供正常服务。可以打开攻击检测与防范中相应攻击的开关来防止此类攻击。
· DDoS攻击
攻击者使用大流量对设备进行攻击，消耗设备的CPU、内存、连接、带宽等资源。对于这类威胁，可以通过限制设备资源占用以及识别合法用户等措施，尽量保证已识别的合法用户对网络的使用，并对未识别的用户的流量进行一定限制。
· 身份仿冒
网络中的很多攻击行为都伴随着身份仿冒，而网络的开放性给身份识别带来了困难，尤其是在转发平面。转发平面提供了一些基本的方法可在一定程度上防止身份仿冒，比如ARP/ND检测等。
· 消息篡改和伪造
消息的完整性至关重要，虚假的数据会使网络故障、甚至瘫痪。可以使用IPsec等安全协议来保护网络数据，提供完整性、私密性、身份验证等功能。
Comware系统的安全体系架构如图2-1所示：
图2-1 Comware系统安全体系架构图
设备基于以上安全体系架构在不同层面实施相应的安全防护，具体过程如下：
(1) 对于硬件转发类设备，收到目的地址为本机的报文并上送CPU处理前，会通过以下两种通道机制来保证上层的控制平面/管理平面不会受到DoS/DDoS等大流量的攻击：
¡ 白名单：对于已经建立连接，并确认来源是可靠的报文，设备会下发白名单保证其优先上送CPU。
¡ 优先级队列：对于由控制平面、管理平面处理的应用流量，在设备没有与其建立连接之前，因不能匹配到白名单，会进入优先级队列，根据不同的应用优先级处理。
(2) 对于由转发平面转发的报文，设备提供了一系列的措施来保证设备的安全和网络用户的安全：
¡ 畸形报文检测
¡ 包过滤
¡ 防仿冒
¡ DDoS攻击防范
¡ 资源占用限制：包括连接数限制、ARP/ND表项限制等等，防止DDoS等恶意流量攻击。
¡ 数据保护协议：IPsec等，为本机和用户数据提供数据私密性、完整性、防重放等安全保护。
(3) 对于目的地址为本机的业务报文，可以采用以下安全加固策略：
a. 通过控制平面的QoS策略对上送控制平面/管理平面的流量进行限制，例如限制带宽等。另外，各协议本身（TCP、ICMP/ICMPv6、ARP/ND）也有相应的防护措施。
b. 在控制平面/管理平面，各业务模块采用相应的安全协议或安全选项，对业务报文提供更好的安全服务。
虽然设备可提供丰富的安全加固策略，但对于设备而言，并不是实施的安全加固策略越多效果越好。每一项安全加固措施对网络、业务都有或多或少的影响，比如会影响设备性能、内存资源、部署成本、用户使用习惯。所以，需要根据网络和业务的特点来综合评估可能存在的风险和威胁，并在充分了解到各类安全加固策略可能对网络和业务产生的影响后作出恰当的选择。
安全加固策略选择的普遍原则如下：
· 根据安全风险和威胁发生的可能性由大到小的顺序，依次考虑相应的安全加固策略；
· 按照安全加固策略对网络和业务影响程度由小到大的顺序，逐步实施各策略，并观察效果；
· 每一次安全加固策略实施后要观察效果，并根据效果调整当前策略以及选择后续的加固策略；
· 遵循业务优先原则，将安全加固策略对业务的影响降到最低，或者将其控制在可接受的范围内。
Console口属于物理接口，通过它进行登录是登录设备的基本方式之一。
缺省情况下，通过Console口登录时认证方式为none，可直接登录，登录成功之后用户角色为network-admin。
如果攻击者获取了Console口的使用权限，在缺省情况下可以非常容易登录到设备上，获取到设备的管理权限。
可以在用户线/用户线类视图下配置以下两种认证方式，提高通过Console口登录设备的安全性：
· password方式：表示下次使用该用户线登录时，需要输入密码。只有密码正确，用户才能登录到设备上。配置认证方式为password后，请妥善保存密码。
· scheme方式：表示下次使用该用户线登录设备时需要进行用户名和密码认证，用户名或密码错误，均会导致登录失败。配置认证方式为scheme后，请妥善保存用户名及密码。
改变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”。
在使用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协议。
虽然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”。
设备提供如下几种密码（或密钥）设置方式：
· 明文方式：用户以明文方式输入密码，设备以密文或哈希方式存储该密码（具体以各业务模块实现为准）。
· 密文方式：用户以密文方式输入密码，设备以密文方式存储该密码。
· 哈希方式：用户以密文方式输入密码，设备以哈希方式存储该密码。
为了提高系统的安全性和可维护性，对密码的设置有以下建议：
· 提高密码的长度和复杂度，不要使用弱密码。
· 不同特性的密码不要重复使用，避免攻击者非法获取了某业务的密码后，对其它业务的安全性造成威胁。
· 以密文或哈希方式设置的密码必须可被设备解析，否则无法成功设置。这两种密码设置方式通常用于测试或配置恢复。正常业务需求下，请不要尝试自行构造密文密码或哈希密码用于设置业务密码。
缺省情况下，设备上的密码恢复功能处于开启状态。当用户忘记Console口认证密码或者登录认证失败时，可通过Console口连接设备，并在硬件重启设备过程中根据提示按组合键<Ctrl+B>进入BootWare菜单，再选择对应的BootWare菜单选项来修复这个问题。这会给非法用户访问设备带来便利，非法用户可通过Console口访问设备。
关闭密码恢复功能后，设备将处于一个安全性更高的状态，即当出现上述情况时，若想继续使用Console口登录设备，只能通过BootWare菜单选择将设备恢复为出厂配置之后方可继续操作，这样可以有效地防止非法用户获取启动配置文件。
# 关闭密码恢复功能。
<Sysname> system-view
[Sysname] undo password-recovery enable
缺省情况下，在系统启动过程中，用户在指定时间内按组合键<Ctrl+B>可以进入BootWare菜单，以便完成系统软件的加载和对存储介质的管理等操作。
为防止非法用户访问BootWare菜单，可以配置禁止访问BootWare菜单。配置禁止访问BootWare菜单后，在系统启动过程中按组合键<Ctrl+B>不会进入BootWare菜单，而直接进入命令行配置界面。
# 禁止访问BootWare菜单。
<Sysname> undo bootrom-access enable
如果设备的空闲内存不够，会导致业务模块的表项无法下发，设备的重要数据无法保存，影响设备的正常运行。
使用内存告警门限功能后，系统会实时监控剩余空闲内存大小，当条件达到一级、二级、三级告警门限或者恢复正常状态门限时，就产生相应的告警/告警解除通知，通知关联的业务模块/进程采取相应的措施，以便最大限度的利用内存，又能保证设备的正常运行。
一级（minor）、二级（severe）和三级（critical）门限，对应的剩余空闲内存越来越少，紧急程度越来越严重。
· 当剩余空闲内存值从大于等于变成小于一级告警门限时，产生一级告警。
· 当剩余空闲内存值从大于等于变成小于二级告警门限时，产生二级告警。
· 当剩余空闲内存值从大于等于变成小于三级告警门限时，产生三级告警。
· 当剩余空闲内存值从小于等于变成大于二级告警门限时，产生三级告警解除通知。
· 当剩余空闲内存值从小于等于变成大于一级告警门限时，产生二级告警解除通知。
· 当剩余空闲内存值小于等于变成大于正常内存大小时，产生一级告警解除通知。
同一级别的告警/告警解除通知是交替进行的：当剩余空闲内存值小于某级告警门限，设备产生相应级别的告警，后续只有该告警解除了，剩余空闲内存值再次小于某级告警门限时，才会再次生成该级别的告警。
当剩余空闲内存大小如图3-1中曲线所示时，会生成如图3-1所示的告警和解除告警通知。
当设备出现内存告警时，可删除暂时不用的配置或关闭部分功能来释放内存。但因为内存不足，部分配置可能删除失败。
# 配置一级、二级、三级告警门限分别为64MB、48MB、32MB，当系统剩余空闲内存大于96MB时，恢复到正常状态。
<Sysname> system-view
[Sysname] memory-threshold minor 64 severe 48 critical 32 normal 96
开启配置文件加密功能后，管理员每次执行save命令，设备都会先将当前生效的配置进行加密，再保存。配置文件加密功能支持使用公钥和私钥两种方式进行加密，由于所有运行Comware V7平台软件的设备拥有相同的公钥和私钥，因此加密后的文件只能被所有运行Comware V7平台软件的设备识别和解析。为了防止非法用户对加密后配置文件的解析，需确保只有合法用户才能获取加密后的配置文件，进一步提高配置文件的安全性。
开启配置文件加密功能后，将不能使用more命令查看加密配置文件（后缀名为“.cfg”的配置文件）的内容，加密配置文件不可以作为display diff命令的参数，进行两份配置文件之间的差异比较，可以使用display saved-configuration命令查看加密的下次启动配置文件内容。
· # 设置保存配置文件时使用公钥进行加密。
<Sysname> system-view
[Sysname] configuration encrypt public-key
· # 设置保存配置文件时使用私钥进行加密。
<Sysname> system-view
[Sysname] configuration encrypt private-key
· 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
· 配置根保护
# 开启端口的根保护功能。
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] stp root-protection
· 配置TC-BPDU攻击保护
# 配置在单位时间（固定为十秒）内，设备收到TC-BPDU后一定时间内，允许收到TC-BPDU后立即刷新转发地址表项的最高次数为10（10仅为示例）。
<Sysname> system-view
[Sysname] stp tc-protection threshold 10
合法的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
攻击者仿冒网关，发送错误的网关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中继”。
# 在VLAN接口2上开启授权ARP功能。
<Sysname> system-view
[Sysname] interface vlan-interface 2
[Sysname-Vlan-interface2] arp authorized enable
· 用户合法性检查：对于ARP信任接口，不进行用户合法性检查；对于ARP非信任接口，进行包括基于用户合法性规则检查、基于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表项被固化。
# 对VLAN接口2上的主IP地址网段内的邻居进行ARP自动扫描。
<Sysname> system-view
[Sysname] interface vlan-interface 2
[Sysname-Vlan-interface2] arp scan
[Sysname-Vlan-interface2] quit
# 将设备上的动态ARP表项转化成静态ARP表项。
[Sysname] arp fixup
如果网络中存在攻击源向设备发送大量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
通过与AAA的配合，PPP提供了在其链路上对对端进行安全认证的手段，具体包括以下几种方式。
· PAP认证
PAP为两次握手协议，它通过用户名和密码来对用户进行认证。
PAP在网络上以明文的方式传递用户名和密码，认证报文如果在传输过程中被截获，便有可能对网络安全造成威胁。因此，它适用于对网络安全要求相对较低的环境。
· CHAP认证
CHAP为三次握手协议。
CHAP认证过程分为两种方式：认证方配置了用户名、认证方未配置用户名。推荐使用认证方配置用户名的方式，这样被认证方可以对认证方的身份进行确认。
CHAP只在网络上传输用户名，并不传输用户密码（准确的讲，它不直接传输用户密码，传输的是用MD5算法将用户密码与一个随机报文ID一起计算的结果），因此它的安全性要比PAP高。
· MSCHAP认证
MSCHAP为三次握手协议，认证过程与CHAP类似，MSCHAP与CHAP的不同之处在于：MSCHAP支持重传机制。在被认证方认证失败的情况下，如果认证方允许被认证方进行重传，被认证方会将认证相关信息重新发回认证方，认证方根据此信息重新对被认证方进行认证。认证方最多允许被认证方重传3次。
· MSCHAPv2认证
MSCHAPv2为三次握手协议，认证过程与CHAP类似，MSCHAPv2与CHAP的不同之处在于：
¡ MSCHAPv2通过报文捎带的方式实现了认证方和被认证方的双向认证。
¡ MSCHAPv2支持重传机制。在被认证方认证失败的情况下，如果认证方允许被认证方进行重传，被认证方会将认证相关信息重新发回认证方，认证方根据此信息重新对被认证方进行认证。认证方最多允许被认证方重传3次。
¡ MSCHAPv2支持修改密码机制。被认证方由于密码过期导致认证失败时，被认证方会将用户输入的新密码信息发回认证方，认证方根据新密码信息重新进行认证。
若认证方采用本地AAA认证，则必须为被认证方配置本地用户的用户名和密码；若认证方采用远程AAA认证，则必须为被认证方配置远程用户的用户名和密码。
· 采用PAP认证方式
在认证方上为被认证方配置的用户名和密码必须与被认证方上通过ppp pap local-user命令配置的用户名和密码相同。
· 采用CHAP认证方式（认证方配置了用户名）
在认证方上为被认证方配置的用户名和密码必须满足如下要求：
¡ 用户名必须与被认证方上通过ppp chap user命令配置的被认证方的用户名相同。
¡ 密码必须与被认证方上为认证方配置的用户名的密码相同。
在被认证方上为认证方配置的用户名和密码必须满足如下要求：
¡ 用户名必须与认证方上通过ppp chap user命令配置的认证方的用户名相同。
¡ 密码必须与认证方上为被认证方配置的用户名的密码相同。
在被认证方上不能通过ppp chap password命令配置进行CHAP认证时采用的密码，否则即使认证方配置了用户名，CHAP仍将按照认证方未配置用户名的情况进行认证。
· 采用CHAP认证方式（认证方未配置用户名）
在认证方上为被认证方配置的用户名和密码必须满足如下要求：
¡ 用户名必须与被认证方上通过ppp chap user命令配置的被认证方的用户名相同。
¡ 密码必须与被认证方上通过ppp chap password命令配置的密码相同。
· 采用MSCHAP和MSCHAPv2认证方式
¡ 设备只能作为MSCHAP和MSCHAPv2的认证方来对其它设备进行认证。
¡ L2TP环境下仅支持MSCHAP认证，不支持MSCHAPv2认证。
¡ MSCHAPv2认证只有在RADIUS认证的方式下，才能支持修改密码机制。
¡ MSCHAPv2认证时不支持为PPP用户配置认证方式为none。
¡ 为被认证方配置的用户名和密码必须与被认证方上的配置相同。
¡ 若认证方配置了用户名，则在被认证方上为认证方配置的用户名必须与认证方上ppp chap user命令配置的用户名相同。
· 配置PAP认证
¡ 配置认证方
# 配置认证方采用PAP方式认证被认证方。
<Sysname> system-view
[Sysname] interface dialer 1
[Sysname-Dialer1] ppp authentication-mode pap domain system
# 配置认证方采用本地或远程AAA认证方式对被认证方进行认证。
具体配置请参见“用户接入与认证配置指导”中的“AAA”。
¡ 配置被认证方
# 配置采用PAP方式时被认证方的用户名和密码。
<Sysname> system-view
[Sysname] interface dialer 1
[Sysname-Dialer1] ppp pap local-user userb password simple passb&289
· 配置CHAP认证（认证方配置了用户名）
¡ 配置认证方
# 配置认证方采用CHAP方式认证被认证方。
<Sysname> system-view
[Sysname] interface dialer 1
[Sysname-Dialer1] ppp authentication-mode chap domain system
# 配置采用CHAP认证时认证方的用户名。
[Sysname-Dialer1] ppp chap user usera
# 配置认证方采用本地或远程AAA认证方式对被认证方进行认证。
具体配置请参见“用户接入与认证配置指导”中的“AAA”。
¡ 配置被认证方
# 配置采用CHAP认证时被认证方的用户名。
<Sysname> system-view
[Sysname] interface dialer 1
[Sysname-Dialer1] ppp chap user userb
# 配置被认证方采用本地或远程AAA认证方式对认证方进行认证。
具体配置请参见“用户接入与认证配置指导”中的“AAA”。
· 配置CHAP认证（认证方未配置用户名）
¡ 配置认证方
# 配置认证方采用CHAP方式认证被认证方。
<Sysname> system-view
[Sysname] interface dialer 1
[Sysname-Dialer1] ppp authentication-mode chap domain system
# 配置认证方采用本地或远程AAA认证方式对被认证方进行认证。
具体配置请参见“用户接入与认证配置指导”中的“AAA”。
¡ 配置被认证方
# 配置采用CHAP认证时被认证方的用户名。
<Sysname> system-view
[Sysname] interface dialer 1
[Sysname-Dialer1] ppp chap user userb
# 配置采用CHAP认证时被认证方的认证密码。
[Sysname-Dialer1] ppp chap password simple hello&358
· 配置MSCHAP或MSCHAPv2认证（认证方配置了用户名）
¡ 配置认证方
# 配置认证方采用MSCHAP或MSCHAPv2方式认证被认证方。
<Sysname> system-view
[Sysname] interface dialer 1
（MSCHAP方式）
[Sysname-Dialer1] ppp authentication-mode ms-chap domain system
（MSCHAPv2方式）
[Sysname-Dialer1] ppp authentication-mode ms-chap-v2 domain system
# 配置采用MSCHAP或MSCHAPv2认证时认证方的用户名。
[Sysname-Dialer1] ppp chap user usera
# 配置认证方采用本地或远程AAA认证方式对被认证方进行认证。
具体配置请参见“用户接入与认证配置指导”中的“AAA”。
· 配置MSCHAP或MSCHAPv2认证（认证方未配置用户名）
¡ 配置认证方
# 配置认证方采用MSCHAP或MSCHAPv2方式认证被认证方。
<Sysname> system-view
[Sysname] interface dialer 1
（MSCHAP方式）
[Sysname-Dialer1] ppp authentication-mode ms-chap domain system
（MSCHAPv2方式）
[Sysname-Dialer1] ppp authentication-mode ms-chap-v2 domain system
# 配置认证方采用本地或远程AAA认证方式对被认证方进行认证。
具体配置请参见“用户接入与认证配置指导”中的“AAA”。
在PPP网络中将会面临用户使用非法IP地址访问网络资源的安全威胁。
针对以上安全威胁，可以在设备上配置PPP用户IP网段检查功能，增强对PPP用户的管理和控制，开启PPP用户IP网段检查功能后，当IPCP协商时，设备会检查PPP用户的IP地址与上线接口的IP地址是否在同一网段，如果不在同一网段，则IPCP协商失败，不允许用户上线。
# 在Dialer1接口上使能接口的IP网段检查功能。
<Sysname> system-view
[Sysname] interface dialer 1
[Sysname-Dialer1] ppp ipcp remote-address match
当认证失败的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
端口安全用于在端口上提供基于MAC地址的网络接入控制，它提供了以下安全特性：
· Need To Know特性（NTK）
Need To Know特性通过检测从端口发出的数据帧的目的MAC地址，保证数据帧只能被发送到已经通过认证或被端口学习到的MAC所属的设备或主机上，从而防止非法设备窃听网络数据。
· 入侵检测（Intrusion Protection）特性
入侵检测特性对端口接收到的数据帧进行检测，源MAC地址未被端口学习到的报文或未通过认证的报文，被认为是非法报文，如果发现非法报文，则对接收非法报文的端口采取相应的安全策略，包括端口被暂时断开连接、永久断开连接或MAC地址被阻塞一段时间，以保证端口的安全性。
· 控制MAC地址学习和用户认证
通过定义不同的端口安全模式来实现：
¡ 控制MAC学习类：无需认证，包括端口自动学习MAC地址和禁止MAC地址学习两种模式。
¡ 认证类：利用MAC地址认证和802.1X认证机制来实现，包括单独认证和组合认证等多种模式。
配置了安全模式的端口上收到用户报文后，首先查找MAC地址表，如果该报文的源MAC地址已经存在于MAC地址表中，则端口转发该报文，否则根据端口所采用的安全模式进行MAC地址学习或者触发相应的认证，并在发现非法报文后触发端口执行相应的安全防护措施（Need To Know、入侵检测）或发送Trap告警。缺省情况下，端口出方向的报文转发不受端口安全限制，若触发了端口Need To Know，则才受相应限制。关于各模式的具体工作机制，以及是否触发Need To Know、入侵检测的具体情况请参见表4-1。
|
端口安全采用方式 |
安全模式 |
触发的安全防护措施 |
|
|
端口控制MAC地址学习 |
autoLearn |
NTK/入侵检测 |
|
|
secure |
|||
|
端口采用802.1X认证 |
userLogin |
无 |
|
|
userLoginSecure |
NTK/入侵检测 |
||
|
userLoginSecureExt |
|||
|
userLoginWithOUI |
|||
|
端口采用MAC地址认证 |
macAddressWithRadius |
NTK/入侵检测 |
|
|
端口采用802.1X和MAC地址认证组合认证 |
Or |
macAddressOrUserLoginSecure |
NTK/入侵检测 |
|
macAddressOrUserLoginSecureExt |
|||
|
Else |
macAddressElseUserLoginSecure |
||
|
macAddressElseUserLoginSecureExt |
|||
关于端口安全的详细信息，请参见“用户接入与认证配置指导”中的“端口安全”。
在Portal组网环境中，设备将会面临以下安全威胁：
· 攻击者频繁发起HTTP/HTTPS请求，会产生大量匹配Portal重定向规则的HTTP/HTTPS报文，从而导致设备资源不足。
· 攻击者发起大量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仅允许DHCP用户上线
通常，攻击者的IP地址为静态配置的，因此通过禁止IP地址为静态配置的Portal认证用户上线可以一定程度上避免被攻击的风险。
Portal仅允许DHCP用户上线功能，仅在采用接入设备作为DHCP服务器的组网中生效，且不会影响已经在线的用户。
在IPv6网络中，开启Portal仅允许DHCP用户上线功能后，终端仍会使用临时IPv6地址进行Portal认证，从而导致认证失败，所以终端必须关闭临时IPv6地址。
· 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仅允许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网络）
# 在VLAN接口2上配置IPv4 Portal最大用户数为100。
<Sysname> system-view
[Sysname] interface vlan-interface 2
[Sysname-Vlan-interface2] portal ipv4-max-user 100
¡ （IPv6网络）
# 在VLAN接口2上配置IPv6 Portal最大用户数为100。
<Sysname> system-view
[Sysname] interface vlan-interface 2
[Sysname-Vlan-interface2] 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的严格检查模式，则只要其中任意一个授权属性未通过严格授权检查，则用户就会下线。
# 在VLAN接口2上开启对授权ACL的严格检查模式。
<Sysname> system-view
[Sysname] interface vlan-interface 2
[Sysname–Vlan-interface2] portal authorization acl strict-checking
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地址检查）配合，可以实现只允许匹配用户地址表项中绑定关系的报文通过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 vlan-interface 2
[Sysname-Vlan-interface2] dhcp client-detect
非法用户向DHCP服务器发送攻击报文后，影响DHCP服务器正常工作。
开启DHCP中继支持代理功能后，DHCP中继收到DHCP服务器的应答报文，会把报文中的DHCP服务器地址修改为中继的接口地址，并转发给DHCP客户端。当DHCP客户端通过DHCP中继从DHCP服务器获取到IP地址等网络参数后，DHCP客户端会把DHCP中继当作自己的服务器，来进行后续的DHCP功能的报文交互。从而达到了把真正的DHCP服务器和DHCP客户端隔离开，保护DHCP服务器的目的。
# 配置VLAN接口2工作在DHCP代理模式。
<Sysname> system-view
[Sysname] interface vlan-interface 2
[Sysname-Vlan-interface2] dhcp select relay proxy
网络攻击者通过DHCP服务器为设备分配错误的域名后缀和域名服务器地址，会导致设备域名解析失败，或解析到错误的结果。
在设备上指定DNS信任接口后，域名解析时只采用信任接口动态获得的域名后缀和域名服务器信息，非信任接口获得的信息不能用于域名解析，从而在一定程度上避免这类攻击。
# 指定VLAN接口2为DNS信任接口（本例中的参数仅为示例）。
<Sysname> system-view
[Sysname] dns trust-interface vlan-interface 2
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
恶意用户通过变换组地址，使用一些无效组播组频道加入，造成设备上建立大量无效表项，占用大量系统资源，导致正常用户的点播无法成功。
在使能了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
如果未对网络中的组播用户配置用户控制策略，会造成组播源数据可以被任意组播用户点播，无法实现对组播用户访问组播组权限的控制。
通过配置组播用户控制策略，设备可以对组播用户发送的IGMP/MLD成员关系报文和IGMP/MLD离开报文进行过滤，从而实现对组播用户访问组播组权限的控制。
# 在名为abc的User Profile下配置只允许组播用户加入/离开组播组225.1.1.1。（各参数仅为示例）
[Sysname-acl-ipv4-basic-2001] rule permit source 225.1.1.1 0
[Sysname-acl-ipv4-basic-2001] quit
[Sysname-user-profile-abc] igmp-snooping access-policy 2001
# 在名为abc的User Profile下配置只允许IPv6组播用户加入/离开IPv6组播组FF03::101。（各参数仅为示例）
[Sysname-acl6-basic-2001] rule permit source ff03::101 16
[Sysname-acl6-basic-2001] quit
[Sysname-user-profile-abc] mld-snooping access-policy 2001
在实际WLAN网络应用中，若非法客户端接入无线服务，会泄露无线用户的个人信息并向设备发起一系列安全攻击，比如对AP发起泛洪报文攻击，使AP不能正常工作，对无线网络的安全造成威胁。
通过配置客户端接入控制功能，使用黑白名单和ACL规则限制接入无线网络的客户端，可以过滤非法客户端，确保无线网络的安全。
当配置了客户端二次接入认证的时间间隔或者AP收到客户端的攻击报文时，AP才会将该客户端的MAC地址添加到动态黑名单中。
动态黑名单表项具有一定的老化时间。当到达老化时间时，AP会将MAC地址从动态黑名单中删除。
新配置的动态黑名单老化时间只对新加入动态黑名单的客户端生效。
若客户端同时存在于白名单和动态黑名单中时，则白名单生效。
· 配置使用黑白名单限制接入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
# 配置客户端二次接入认证的时间间隔为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
# 在无线服务模板下，配置基于ACL的接入控制为4000，仅允许MAC地址为001e-35b2-000e以及匹配OUI控制方式的无线客户端接入（各参数仅为示例）。
[Sysname] wlan service-template service1
[Sysname-wlan-st-service1] access-control acl 4000
WLAN用户接入认证是一种基于用户的安全接入管理机制，根据用户MAC地址来进行访问控制。如果不对接入WLAN网络的用户进行身份认证，则任何用户都可以随意接入，会对无线网络安全造成严重威胁。
WLAN用户接入认证主要包括802.1X、MAC地址认证和OUI认证三种认证方式：
· 802.1X认证系统使用EAP（Extensible Authentication Protocol，可扩展认证协议）来实现客户端、设备端和认证服务器之间认证信息的交换。
· MAC地址认证不需要用户安装任何客户端软件。设备在检测到用户的MAC地址以后，对该用户进行认证操作。认证过程中，不需要用户手动输入用户名或者密码，若该用户认证成功，则允许其访问网络资源，否则该用户则无法访问网络资源。
· OUI（Organizationally Unique Identifier，全球统一标识符）是MAC地址的前24位（二进制），是IEEE为不同设备供应商分配的一个全球唯一的标识符。采用OUI认证方式后，如果用户的MAC地址与设备配置的OUI能匹配上，则认证成功，否则认证失败。
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地址认证 |
||
|
oui-then-dot1x |
先进行OUI认证，如果失败，再进行802.1X认证，如果认证成功，则不进行802.1X认证 |
||
关于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用户安全”。
在WLAN组网环境中，非法设备可能存在安全漏洞或被攻击者操纵，对无线网络的安全造成严重危害。WIPS（Wireless Intrusion Prevention System，无线入侵防御系统）是针对802.11协议开发的二层协议检测和防护功能。WIPS通过对信道进行监听及分析处理，从中检测出威胁网络安全、干扰网络服务、影响网络性能的无线行为或设备，并能够对非法设备进行反制使其它无线终端无法与其关联。
关于WIPS的详细信息，请参见“WLAN安全配置指导”中的“WIPS”。
一个使用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”
# 配置对端设备对本地设备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 vlan-interface 1
[DeviceB-Vlan-interface1] 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 vlan-interface 2
[DeviceB-Vlan-interface2] ntp-service multicast-server 224.0.1.1 authentication-keyid 42
接入同一个设备不同接口的多台主机中，若某台主机存在安全隐患，受到攻击后向同一VLAN内的其他主机发送大量单播、组播或广播报文，甚至传播病毒，会影响其他主机、占用网络带宽。通过端口隔离功能，将需要隔离的端口加入到同一个隔离组中，实现隔离组中端口之间的二层隔离，尽可能的将受到攻击时波及的范围控制在一个端口内，提高了网络的安全性。
关于端口隔离的详细信息，请参见“网络互通配置指导”中的“端口隔离”。
对使用同一无线服务或在同一VLAN进行通信的用户报文进行隔离，可达到提高用户安全性、缓解设备转发压力和减少射频资源消耗的目的。
用户隔离包括基于SSID的用户隔离和基于VLAN的用户隔离：
· 基于SSID的用户隔离：用于隔离同一SSID下的无线用户。
· 基于VLAN的用户隔离：用于隔离同一VLAN内的有线用户和无线用户。
关于用户隔离的详细信息，请参见“安全配置指导”中的“用户隔离”。
未知组播数据报文是指在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地址表项匹配时，该报文被丢弃。
# 将000f-e201-0101配置为黑洞MAC地址表项（000f-e201-0101仅为示例）。
<Sysname> system-view
[Sysname] mac-address blackhole 000f-e201-0101 vlan 2
设备的MAC地址学习功能通常处于开启状态。有时为了保证设备的安全，需要关闭MAC地址学习功能。例如，非法用户使用大量源MAC地址不同的报文攻击设备，导致设备MAC地址表资源耗尽，造成设备无法根据网络的变化更新MAC地址表。关闭MAC地址学习功能可以有效防止这种攻击。
# 关闭全局MAC地址学习功能。
<Sysname> system-view
[Sysname] 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地址数学习上限为200，当端口学习的MAC地址数达到200时，禁止转发源MAC地址不在MAC地址表里的报文。（200仅为示例）
<Sysname> system-view
[Sysname] interface gigabitethernet 1/0/1
[Sysname-GigabitEthernet1/0/1] mac-address max-mac-count 200
[Sysname-GigabitEthernet1/0/1] 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的详细信息，请参见“安全配置指导”中的“IPsec”。
ACL（Access Control List，访问控制列表）是一系列用于识别报文流的规则的集合。ACL需要与其他功能配合使用，例如报文过滤、QoS策略和策略路由等。这些功能通过引用ACL对收发报文进行精确识别，并对命中ACL规则的报文执行预先设定的策略，达到控制网络访问行为和提高网络带宽利用率等目的。
根据规则制订依据的不同，可以将ACL分为如表5-1所示的几种类型。
表5-1 ACL的分类
|
ACL类型 |
编号范围 |
适用的IP版本 |
规则制订依据 |
|
无线客户端ACL |
100～199 |
IPv4和IPv6 |
无线客户端连接的SSID（Service Set Identifier，服务集标识符） |
|
基本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的详细信息，请参见“安全配置指导”中的“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
部署于公网的设备容易受到各类单包攻击、扫描攻击和泛洪攻击等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攻击检测与防范的详细信息，请参见“安全配置指导”中的“攻击检测与防范”。
