等保三级整改指南：锐捷设备安全加固配置实战

等保三级整改这几年几乎成了网络运维的年度规定动作。只要机房里有锐捷设备，这份工作就会变得具体又琐碎：交换机要逐个做登录加固，管理ACL要按区域重新梳理，日志要能推到统一的审计平台，SNMP不能再用public裸奔，无线控制器和出口防火墙的会话超时、账号锁定这些细节也得逐台核对。这篇文章把我多次参与锐捷设备等保三级整改和测评配合的现场经验整理成一份可以直接照做的配置指南，覆盖身份鉴别、访问控制、安全审计、入侵防范、备份恢复和常见排错。适合刚接手安全整改的网络运维、想了解设备侧如何配合测评的同行，以及准备做等保三级复评的IT人员参考。

1. 等保三级到底要对锐捷设备做哪些事

1.1 先给设备分类和定边界

很多整改项目上手就想改配置，这是最容易踩坑的开局。等保三级测评的网络部分，不是把所有锐捷设备都纳入同一套标准，而是要先确定测评对象和范围。入门先做下面三件事：

• 盘点现有设备清单，包含交换机、路由器、防火墙、无线控制器这几个大类，把型号、软件版本、管理IP、作用区域列出来；
• 区分哪些是核心业务设备，哪些是终端接入设备，哪些只是链路透传，不同角色的整改力度完全不一样；
• 和测评机构确认边界：通常边界防火墙、核心交换机、带外管理设备、无线控制器是必查对象，二层接入交换机不一定逐个查，但审计日志往往需要覆盖。

这里有个实操技巧：如果你对某些配置命令没把握，先在锐捷模拟器或官方虚拟化平台把配置调通，再往真机上推。不要直接在生产设备上边猜边敲，等保整改窗口本来就紧，设备因为配置错误离线，比整改没完成更麻烦。

1.2 等保三级对网络设备的硬性要求

围绕合规要求，结合锐捷设备能实现的能力，我把对照关系整理成了一张表。做整改前先把这张表打印出来，逐台设备核对现状，比漫无目的地看running-config高效得多。

这张表里的每一项，后面都会有对应的配置段。一个常见的误判是以为“防火墙开了，交换机不用管”，实际上测评抽测交换机时，检查的就是登录、VTY、SNMP和管理ACL。设备层面的小问题反而最容易扣分。

1.3 网络侧整改的常见缺口

我见过很多网络第一次参与等保整改，问题高度集中在一块：

• 设备默认密码没改，或者所有设备用一个统一密码，密码策略形同虚设。
• 远程管理直接用Telnet，抓包能看到密码明文，测评抓这个几乎是必抓项。
• SNMP团体字符串还是public/private，等于把设备状态和管理权限“公示”了。
• 管理VLAN和业务VLAN共用，任何一台终端都可能跳到管理网段。
• 日志只存在设备本地buffer里，设备重启日志全没，没有远程日志服务器。
• 设备时间不准，日志时间戳和实际时间偏差好几个小时，审计记录根本没法溯源。

这些问题不涉及特别高深的技术，但整改起来很花时间，尤其是老网络、设备数量又多的时候。下面的章节就直接进入配置，先讲最容易被查到的身份鉴别。

2. 核心加固第一步：身份鉴别配置

2.1 上线AAA统一认证，别再让每个设备单独管密码

等保三级要求用户的身份标识应具有唯一性，并且应该采用两种或以上组合的鉴别技术。落到设备侧，最有效的方案就是对接AAA服务器，用RADIUS或TACACS+做统一认证。锐捷的交换机、路由器和防火墙对这两种协议都支持，运维账号统一在认证服务器上管理，设备本地只保留逃生账号。

RADIUS和TACACS+怎么选？我的建议是：只做设备登录认证，两者都行；需要做细粒度命令授权，优先选TACACS+，因为它能把认证、授权、记账分开处理；如果公司已经有RADIUS平台（比如和Wi-Fi认证共用），那就直接复用，减少运维成本。锐捷设备配置RADIUS的典型写法如下：

code复制enable
configure terminal
!
radius-server host 10.10.20.5 auth-port 1812 acct-port 1813 key Rad@2024
!
aaa authentication login default group radius local
aaa authentication enable default group radius enable
aaa accounting exec default start-stop group radius

local关键字很关键，它表示RADIUS不可达时回落到本地账号。否则服务器一挂，全公司运维都登不进设备，只能去机房插console线，这个教训我在现场吃过。

我还建议开exec记账，这样运维人员每次登录和退出都会在RADIUS服务器上留下记录，测评需要调取登录审计时，这份数据可以直接拿来用。

2.2 本地密码策略和账号加固

即使上了AAA，设备本地也必须有一个带权限的逃生账号，并且这个账号的密码策略不能是“随便设一个就算了”。锐捷较新的RGOS版本支持密码策略配置，我一般会在核心设备上全部开启：

code复制enable service password-encryption
!
username admin privilege 15 secret Ruijie@Admin2024
username ops privilege 1 secret Ruijie@Ops2024
!
password-policy enable
password-policy minimum-length 8
password-policy complexity require-digit
password-policy complexity require-letter
password-policy complexity require-special
password-policy history-limit 5
password-policy lockout-threshold 3
password-policy lockout-time 15

注意几点：service password-encryption是对配置里的密码做加密显示，能防止别人看配置直接抄走密码；privilege 15是最高权限，privilege 1只读，运维账号尽量用低权限，管理操作通过enable再提权。设备默认密码哪怕只是临时上架，也要在上线当天改掉，不要寄托于“反正是内网，没人知道”。

如果你发现设备的命令提示里没有password-policy，说明版本太老，那就只能靠流程约束：密码长度至少8位、定期更换、不同设备不要复用。我在测评现场见过最头疼的情况，就是几十台锐捷交换机密码全部一样，最后只能在规定时间内逐台重设，工作量大到怀疑人生。

2.3 SSH、登录锁定和会话超时的完整配置

远程管理协议必须用SSH，这是等保测评的必查项。Telnet和HTTP管理端口一律关闭。配置SSH前要先确认设备有RSA密钥，没有的话先执行密钥生成，否则ssh-server起来也连不上：

code复制enable ssh-server
crypto key generate rsa 2048
ip ssh version 2
ip ssh authentication-retries 3

登录会话超时同样重要。很多人配完SSH就收工，结果审计发现运维连接的会话可以挂机一整天，这等于给攻击者留了一个“已认证闲置窗口”。VTY和Console都要加超时和登录源限制：

code复制ip access-list standard MGMT-ACL
 permit host 192.168.100.10
 permit host 192.168.100.11
 deny   any
!
line vty 0 4
 login local
 transport input ssh
 access-class MGMT-ACL in
 exec-timeout 5 0
!
line console 0
 exec-timeout 5 0
 login local

这段配置做完，效果是：只有192.168.100.10和192.168.100.11这两台运维终端能SSH登录交换机的VTY口，其他地址全部拒绝；会话5分钟无操作自动断开；Console也一样5分钟超时。ip ssh authentication-retries 3限制了密码尝试次数，再配合前面密码策略里的锁定时长，就能满足“登录失败处理功能”的检查项。

有个细节提醒一下：在改VTY里的transport input ssh和access-class之前，先确认你当前这条管理连接不会被ACL挡掉。现场经常有人在机房以外远程把VTY ACL加上去，结果ACL把当前IP也拒了，等保整改没完成，人先被锁在设备门外。

3. 访问控制：隔离和管理权限收敛

3.1 管理面与业务面分离

访问控制是等保三级网络部分的大头，而最难的往往不是技术实现，而是改变历史遗留的架构。理想状态是专门划一个管理VLAN，把所有网络设备的管理IP放进去，业务流量走业务VLAN，两者之间用防火墙或ACL隔离。

在锐捷交换机上，管理VLAN的配置不复杂：

code复制vlan 100
 name MGMT
!
interface vlan 100
 ip address 10.100.0.2 255.255.255.0
 no shutdown
!
interface GigabitEthernet 0/24
 switchport mode access
 switchport access vlan 100

上联口进管理VLAN，业务口进业务VLAN，然后在核心交换机或防火墙上把管理VLAN与外部网络的互访策略关掉。管理IP不暴露在业务网里，测评审计时这一项就很稳。如果预算和拓扑允许，带外管理网（独立物理链路）效果更好，但多数企业没有这个条件，管理VLAN已经是性价比最高的方案。

3.2 用ACL把管理入口精确到“白名单”

管理入口的白名单化是访问控制最容易提分的一项。除了在VTY口做ACL，我还会在三层接口和SSH服务入口做双保险。比如在核心交换机上，只允许运维子网访问各个设备的管理地址，业务子网之间如果需要互访，按策略单独开：

code复制ip access-list extended CORE-TO-MGMT
 permit tcp 192.168.100.0 0.0.0.255 host 10.100.0.2 eq 22
 permit icmp 192.168.100.0 0.0.0.255 host 10.100.0.2
 deny ip any any log
!
interface vlan 100
 ip access-group CORE-TO-MGMT in

重点说下最后一行deny ip any any log。很多人的ACL只写permit，不写deny，导致规则语义不明确；加上log之后，不符合白名单的访问会在日志里留痕，审计时可以直接展示“有哪些陌生地址试图访问管理口”，这是测评专家很喜欢的证据。

3.3 接入层防伪造：端口安全、DHCP Snooping与DAI

终端接入区域的ARP欺骗、DHCP仿冒是等保三级重点关注的网络攻击类型。锐捷交换机的接入端口要开启端口安全，控制端口的MAC学习数量；同时开启DHCP Snooping和DAI（动态ARP检测），阻断伪造DHCP服务响应和虚假ARP报文。

典型配置如下：

code复制ip dhcp snooping enable
ip dhcp snooping vlan 10,20
!
interface GigabitEthernet 0/1
 switchport mode access
 switchport access vlan 10
 port-security enable
 port-security max-mac-count 1
 port-security violation restrict
 spanning-tree portfast
 spanning-tree bpduguard enable
!
interface GigabitEthernet 0/24
 ip dhcp snooping trust
 ip arp inspection trust
!
ip arp inspection enable
ip arp inspection vlan 10,20

这里容易出问题的是“信任口”的概念：连接DHCP服务器、汇聚交换机上联口要配置成trust，连接终端的口是untrust。如果全交换机没设trust口，DHCP Snooping会把所有DHCP响应都当成非法丢弃，终端拿不到地址，这就是典型的“开了安全反而断网”事故。我后面在常见问题部分会再展开讲。

4. 安全审计：日志和时间戳一个都不能少

4.1 远程syslog和NTP时间同步

等保三级要求重要行为产生审计记录，而且审计记录不能被随意删除，所以日志必须远程推送和留存。锐捷设备的日志配置比较直接：

code复制logging on
logging buffered 16384
!
logging host 10.10.20.7
logging facility local6
service timestamps log datetime localtime show-timezone
!
ntp server 10.10.20.1
clock timezone CST +8 8

logging host指定远程日志服务器；logging facility设置日志设施值，方便日志服务器区分设备来源；service timestamps给每条日志打上可读的时间戳。NTP的重要性经常被忽略，但时间戳不准的日志在审计里等于废数据。尤其是日志服务器上聚合多台设备时，设备间时间偏差超过一分钟，事件还原就会变得非常混乱。我建议所有整改设备全部对到同一个NTP服务器，并且每周核对一次状态。

4.2 日志里必须有哪些内容

审计日志不能只看“有没有”，还要看“够不够”。测评翻日志时，会关注下面几类事件的覆盖情况：

实操经验是：在整改期间把设备上能开的关键日志都开着，尤其是日志级别设为informational级别观察一段时间，确认关键事件能上报，再调回合理级别。别为了省事把日志级别开太高，导致日志服务器一天几个GB的垃圾数据，真正要查的时候反而沉底了。

4.3 流量审计日志，用端口镜像来补

设备自身的syslog只能覆盖设备行为，但“谁访问了哪个业务系统、流量是否异常”这类审计证据，设备日志是给不出来的。流量层面的审计，通常靠把交换机、防火墙的镜像流量送给旁路审计设备或IDS/IPS。

锐捷交换机端口镜像的配置：

code复制monitor session 1 source interface Gi0/1-24 both
monitor session 1 destination interface Gi0/25

镜像会话的源可以是端口、VLAN甚至单方向流量，目的地接审计探针。这里要提醒的是：镜像口本身不要再跑业务流量，而且镜像目的是“单向被动接收”，不要把它当成普通转发端口去配置ACL，否则可能影响镜像数据的完整性。如果审计设备要同时接收多个核心上联口的流量，可以用远程镜像（RSPAN）把流量跨设备传送，具体配置不同型号略有差异，建会话时留意一下目的VLAN的规划。

4.4 日志留存和定期归档

等保三级对日志留存时间有明确要求，本地日志能力有限，必须依赖远程日志服务器和定期归档。设备本地buffer一般只有几MB，重启即失，远程服务器才是主力。我在配合测评时，还会按月导出核心设备配置和日志目录到归档存储，形成一条“设备日志、AAA记账、配置备份”三条证据链。

这条工作看着简单，但很影响测评结果。日志服务器上的索引没有按设备和时间做目录，调取半年内的登录记录现场翻了十几分钟，测评专家直接就记了一个瑕疵。建议每台设备在日志服务器上单独建目录，目录命名带上设备名，归档文件同步打时间戳。

5. 设备加固与入侵防范

5.1 关闭不必要服务，收敛攻击面

入侵防范的第一步，是减少能被攻击的面。锐捷设备如果出厂或历史配置里开着HTTP管理服务、FTP服务、无用的SNMP、不必要的协议隧道，先关掉。常见关闭项目：

• 关闭Web管理（HTTP/HTTPS），统一走SSH或带外管理；
• 关闭不必要的FTP/TFTP服务，需要传输配置文件也建议临时开、用完即关；
• 关闭网络设备上无用的echo、discard、daytime之类的小服务；
• 不用的物理端口统统shutdown；
• 不跑业务就关闭LLDP、CDP这类邻居发现协议。

配置时按设备实际情况逐项关闭即可，没有统一命令。比如关闭HTTP服务在不同型号上命令可能不同，常见的写法是no enable service web-server。这里先强调一个原则：任何“看起来方便”的服务开关，都要先确认没有业务依赖，再关闭。很多老业务在使用设备的内置DHCP、NTP、DNS转发这些功能，贸然关闭会引发业务中断。

5.2 SNMP不裸奔：从v2c升级到v3

SNMP是网络管理绕不开的协议，但很多设备默认的SNMP v2c配置存在非常大的风险。v2c通过团体字符串认证，团体字符串一旦泄露，相当于把设备的读写权限交给对方。等保整改阶段，我的标准动作是把SNMP全部收敛：

code复制snmp-server group RG-MONITOR v3 priv
snmp-server user monitor RG-MONITOR v3 auth sha Monitor@2024 priv aes 128 Monitor@2024
snmp-server host 10.10.20.7 version 3 priv monitor
snmp-server enable traps
!
no snmp-server community public
no snmp-server community private

如果监控平台暂时不支持v3，退而求其次的做法是：把v2c的团体字符串改成强随机字符串，并使用ACL限制管理服务器IP访问SNMP端口。注意这里有个测评细节：设备必须没有默认团体字符串。有些设备上no snmp-server community public之后居然还存在隐藏默认配置，测评发现后就是安全漏洞，所以改完要重启验证或查看具体running-config确认。

5.3 边界防火墙与攻击防护策略

出口和区域的边界攻击防护，主要由下一代防火墙承担。锐捷防火墙（比如RG-WALL系列）完成等保整改时，我会关注几个点：

• 开启攻击防护特征库，并保证升级到最新版本；
• 配置区域间策略按白名单模型，默认拒绝未放行的流量；
• 开启防扫描检测，限制单IP并发会话数和新建连接速率；
• 针对常见攻击类型，开启畸形报文检测和异常流量日志。

区域间策略的检查项，测评会用“源、目的、端口、动作”的四元组是否明确来判断。如果防火墙里还留着一堆any to any，虽然业务跑得通，但测评这一项直接不合格，这是很多单位第一次测评被扣分的重灾区。

5.4 二层环路防护和广播风暴防护

交换网络里的环路和广播风暴，在等保要求中属于网络可用性和入侵防范的范畴。接入端口开启PortFast + BPDU Guard，能防止用户私接交换机形成环路；对上联口配置根保护（Root Guard），防止非法设备抢占根桥。

code复制interface GigabitEthernet 0/1
 spanning-tree portfast
 spanning-tree bpduguard enable
!
interface GigabitEthernet 0/48
 spanning-tree guard root
!
storm-control broadcast level 60

storm-control的阈值要根据业务实际情况调。阈值太低，正常视频会议或广播流量就可能被误删；阈值太高，等保的“防洪泛攻击”要求又形同虚设。我一般会先观察一周正常业务的峰值流量，再按峰值上浮30%作为阈值，完成后持续看日志，确认没有被反复触发的误报。

6. 配置备份与应急恢复

6.1 配置定期备份，别等设备宕机才想起

等保三级对数据备份有明确要求，网络设备的配置也属于需要保护的“数据”。配置备份最稳妥的组合是：本地设备保存一份startup-config，远程服务器定期抓取全量配置，运维平台再保留历史版本。

锐捷交换机手动备份命令：

code复制copy running-config startup-config
copy running-config tftp://10.10.20.8/backup/ruijie-core-20241201.cfg

注意TFTP是明文传输，如果远程备份链路不过加密要求，建议用支持加密传输的方式，或者对远程备份服务器做网络隔离。如果设备支持SCP，优先用SCP，避免配置文件里包含密码密文和ACL规则等敏感信息被中间设备截获。备份文件的命名带上设备名和日期，否则半年后你根本分不清哪份配置是新哪份是旧。

设备升级同样需要备份：升级前保存当前配置和当前软件镜像，避免升级失败后连回滚的资本都没有。很多项目上线时忽略这一步，结果新版本有问题，旧镜像又没留存，只能干等着厂商重新提供。

6.2 应急恢复通道的准备

设备配置万一被改坏、或者ACL把自己锁死，应急通道就是Console口。等保整改期间，我要求在每次配置变更前，至少确保有一个Console接入终端放在可到达的机房位置，并且手头保存所有设备的管理账号、enable密码、Console登录方式。

通过Console登录后，恢复操作的思路很简单：

code复制enable
configure terminal
no ip access-group MGMT-ACL in

锁死的原因大多是ACL把远程管理地址挡了，Console登录后清掉ACL或改管理地址即可。平时一定要测试一次从Console进入设备的完整流程，不要等到现场才拆包装找console线。我在一个项目中见过，设备在弱电井里，Console线被压在机柜最下面，等保整改不但没完成，还多花了半天在找线上。

6.3 测评现场配合的经验

配合测评专家做技术验证，答辩和配合方式也很重要。防护措施做完了，不会展示等于白做。我会在测评前整理好一份“设备安全配置自查表”，包含每台设备的主机名、管理IP、SSH状态、SNMP版本、ACL规则、日志服务器地址，测评时直接对照表给专家看配置输出。

测评专家问“这个设备有没有启用HTTP管理”时，不要只说“关掉了”，直接展示show running-config | include http/server/web的返回结果。问“密码策略怎么设置的”，就展示show password-policy。这种“以证据回应”的方式，能让测评过程顺利很多。

7. 实际整改中的常见问题与排错实录

7.1 配置完登录锁定，运维自己失联了

这是出现频率最高的问题。原理很简单：登录失败次数阈值设置过小，或者测试时反复输错密码，设备把运维账号锁定了。更严重的是，如果锁定策略同时作用于所有登录通道，连SSH都进不来。

处理方式分两层：第一层，任何锁定策略都建议对Console口放开，或者设置Console口不带锁，保证机房本地永远能进；第二层，真被锁定后，通过Console登录，用clear login lockout或等锁定期结束后再试。不同版本命令有差异，现场用?查。

这里想多说一句：别在正式设备上边敲边测试密码策略，先观察锁定的提示和恢复时间，确认无误再推广。网管室几个人同时登录测试，设备反而先被自己人锁死，这种事在测评准备期非常常见。

7.2 SSH明明开了，就是连不上

排查顺序一般是：先确认SSH服务状态和版本，再确认VTY的transport input ssh没有漏配，再看ACL是否放行了你的管理地址。如果开了crypto key generate rsa之后仍然不行，检查密钥长度和设备时间，部分型号在密钥生成后需要保存配置并重启SSH服务才生效。

还要检查一个隐藏项：有些设备默认允许的SSH认证次数很少，如果VTY执行了login local但本地账号权限不足，也会被拒。用管理员账号测试一次，如果没问题，再逐步收回权限。

7.3 syslog日志服务器收不到日志

日志收不到，我通常按下面这个顺序排查：

最容易被忽视的是中间防火墙拦截UDP 514。设备上和服务器上看都是通的，但中间有访问控制策略把日志流量丢了。现场排查时需要把日志服务器到设备管理段的UDP 514放行，并确认设备日志源地址确实是管理IP。

7.4 开了端口安全和DAI，终端大量掉线

这类问题不一定是配置写错，更多是“信任口”和“阈值”设置与实际环境不匹配。开了DHCP Snooping后终端获取不到地址，大概率是DHCP服务器上联口没配置ip dhcp snooping trust。终端掉线，大概率是端口MAC学习数量设为1，但终端实际有多个MAC（比如语音电话+PC共用），或者DAI误判了合法ARP报文。

解决办法是把端口改为max-mac-count 2或更灵活的模式，并且把合法的DHCP服务器和网关接口全部设为trust。这里的判断标准是：信任该端口的报文，能显著降低误杀率，同时不破坏防伪造的目标。安全配置讲究“精准”而不是“全关”，一上来就全防全堵，往往适得其反。

7.5 多厂商设备混用，命令记混

锐捷、华为、H3C、思科等主流厂商的基础巡检命令相似，能直观感受到“我会的都能用”，但细节差异很多。比如查看配置，思科和锐捷是show running-config，华为和H3C是display current-configuration。ACL的写法、VLAN命名、SSH配置语法都有差异。同一套等保配置思路，换一个品牌就得调整命令格式。

我的做法是从一开始就建一个“三栏对照表”：锐捷、华为、H3C在相同功能下的对应命令。整改时按设备类型分批推进，不要今天改两台锐捷明天改两台华为，思维切换容易漏配置。对锐捷设备尤其要小心不同软件版本（RGNOS和RGOS）的命令差异，拿不准就先用?查看在线帮助。

8. 写在后面的一点经验

最后说一点我自己实际干活后的体会。等保三级整改，技术配置是一部分，更考验的是“把合规要求和设备能力一一对上”的梳理能力。锐捷设备在身份鉴别、ACL、日志审计这些方面能力很完整，但如果不做版本确认、不做整改前现状盘点、不给设备分类定级，很容易出现“配了很多但测评不认”的尴尬局面。

如果你手头正在做这类整改，我建议从今天开始做一个动作：把所有设备的管理账号、enable密码、SSH状态、SNMP配置、日志服务器信息整理成一份清单，并且找出其中还在用Telnet、public团体字符串、默认密码的设备。先解决这三类问题，等保三级整改最容易被扣分的部分就已经消掉了一大半。后续再按这份指南把身份鉴别、访问控制、安全审计、入侵防范逐项落实，哪怕设备再多，也能有条不紊地推进到位。