企业官网建设流程全解析

等保三级，这个词对搞网络运维的人来说，既是绕不开的坎，也是每年都得认真对待的硬任务。我手上管着好几台锐捷的核心交换机、出口路由器和无线控制器，前前后后配合测评机构做了三轮等保整改，从最开始被揪出一堆“高风险”项，到后面基本一次通过，踩过的坑、试对的路都不少。这篇就把锐捷设备在等保三级测评里的实战配置思路、命令细节和排错经验一次性说清楚，希望能帮正准备做等保或者正在整改的朋友少走弯路。

先说一个最基本的认知：等保三级不是让你买一堆盒子堆在机房里，等保测评的很大一部分分数，其实落在网络设备自身的加固配置上。锐捷的设备无论交换机、路由器还是防火墙，系统都基于类似的思想，很多命令风格和华为、H3C接近，会一种之后迁移起来并不难。下面我按等保测评实际检查的顺序，把配置逐项拆开讲。

1. 等保三级对网络设备的要求逐条拆解

1.1 先搞清楚等保三级到底考什么

很多刚接触等保的兄弟，第一反应是“等保就是装个安全设备”。这个理解太片面了。等保三级依据的是GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》，其中对网络设备的要求分散在“安全通信网络”“安全区域边界”“安全计算环境”几个章节里。我总结下来，跟设备配置直接相关的核心就四类：身份鉴别、访问控制、安全审计、入侵防范。

我之前第一次做等保时，以为测评就是走个过场，结果测评老师拿着检查表一项项核对，就连我交换机上开着Telnet、密码明文存储这种“老毛病”都记成了高风险。那一刻我才意识到，等保测评对设备自身安全性的检查是非常细致的，不是靠一两台安全设备就能糊弄过去的。

等保三级和二级最大的区别在于：三级要求有“审计记录留存”和“可信验证”，你不仅要能做安全审计，日志还得能留存至少6个月；管理员的登录行为、设备的配置变更记录都得有据可查。这就意味着，光在设备上看看日志是不够的，必须把日志外发到syslog服务器统一留存。

1.2 设备测评中最容易丢分的三个控制点

测评机构的检查表里，针对网络设备常考的控制点主要有三个，每一个都对应着具体的技术要求。

第一个是身份鉴别。测评老师会看你的设备是否采用了密码登录，密码是否有复杂度要求，是否定期更换，是否存在默认口令，是否具备登录失败处理功能（比如连续输错几次锁定账号）。锐捷设备默认支持这些能力，但很多环境里都没启用，密码还是初始的admin/admin，这种一查一个准。

第二个是访问控制。这块主要看管理员的登录入口是否受限，是否遵循最小权限原则。具体来说，管理网段应该和业务网段隔离，只有运维人员所在网段能登录设备；不同角色（比如配置管理员和审计管理员）的权限要分开，不能所有人都是超级管理员。

第三个是安全审计。测评老师会查看设备的安全审计日志是否开启，日志是否包含事件发生的日期时间、用户、事件类型、结果等字段，审计记录是否保护，是否定期备份。这块也是锐捷设备配置里最容易忽略的部分，后面我会详细讲syslog的配置方法。

1.3 测评中常见的“一票否决”项

还有几个问题，一旦出现基本就是整改项甚至高风险，需要提前自查。

一是存在弱口令或默认口令，这在任何测评里都是绕不过去的问题，属于基础却致命。二是开放了不必要的服务，比如设备还开着Telnet、SNMP默认团体名public/private，这些在等保三级里直接被定义为高风险。三是管理通道明文传输，只要还能用Telnet或者HTTP登录设备，测评老师基本都会判定为高风险，要求改成SSH和HTTPS。四是没有日志留存，设备日志没有外发到集中日志平台，连登录记录都查不到，这在三级里面也是不符合项。

我自己经历过的真实案例：有一台老款锐捷交换机，因为某些历史原因一直开着Telnet，整改时我把服务关掉换成SSH，结果业务部门说某个采集系统连不上设备了——后来一查，那套系统用的正是Telnet协议。所以整改之前一定要先摸清楚有哪些业务系统在用老协议，不能想关就关。

2. 配置前的准备工作

2.1 资产梳理与等级判定

动手配之前，第一步一定是资产梳理。不要觉得只有核心交换机才需要加固，出口路由器、防火墙、无线控制器，只要承载了等级保护对象的业务，都在测评范围内。我见过最典型的遗漏是机房里那台老旧接入交换机，因为没人管它，结果测评时发现它连着核心设备的管理口，存在严重的管理通道暴露风险，最后也成了整改项。

梳理资产的时候，建议做一张清单，明确每一台设备的型号、软件版本、承载业务、管理方式、管理IP、物理位置。特别是软件版本，我强烈建议你在规划前先确认一下：锐捷不同版本的软件，命令细节是有差异的，部分老版本对某些特性（比如密码复杂度策略）支持不完整，可能需要升级到指定版本才能满足等保要求。

2.2 软件版本与特性核对

锐捷的设备软件一般分为经典版和云教版（部分型号），命令体系有差异。我在配置前会做一次show version，确认当前运行的版本，然后去官网看该版本的特性支持列表，重点确认这几项能力：

• 是否支持SSH v2（v1安全性不足，不建议使用）
• 是否支持RADIUS或TACACS+认证
• 密码策略是否支持复杂度配置（长度下限、字符种类等）
• 登录失败锁定策略是否支持
• 是否支持syslog外发和NTP

如果设备版本太老，建议先升级再做配置，否则后续配置做了半天，特性不生效，反而浪费精力。我之前就遇到过一台老设备不支持登录失败锁定策略，最后只能通过反复尝试别的方式替代，费了不少周折。

2.3 配置基线模板设计

等保整改最忌讳“东一榔头西一棒子”，建议一次性整理出一份设备安全配置基线模板，再逐台套用。模板里至少包含以下配置块：

• 管理账号与认证策略（本地密码策略、登录锁定、AAA认证）
• 远程管理加固（关闭Telnet，开启SSH v2）
• 访问控制列表（管理源地址限制、SNMP源地址限制）
• 日志配置（时间戳、syslog服务器、审计内容）
• 服务最小化（关闭不必要的HTTP服务、SNMP默认团体、不用的端口）
• 时间同步（NTP配置）

有了模板之后，每台设备只需替换IP、接口等个性化参数即可，效率会高很多，也能避免漏配。

3. 身份鉴别与访问控制实战

3.1 本地密码策略与登录锁定

锐捷设备本地账号的密码策略，主要通过password-policy相关命令配置。不同版本的命令略有差异，我以比较通用的配置为例：

Ruijie(config)# password-policy enable Ruijie(config)# password-policy min-length 8 Ruijie(config)# password-policy complexity require-all Ruijie(config)# password-policy expire 90

上面这几条的意思是：启用密码策略，密码最短8位，必须包含大小写字母、数字和特殊字符，密码90天过期。这里有个细节：min-length在不同版本上支持的下限可能不一样，一些老版本只支持到6位，测评方面要求密码长度一般不少于8位，所以如果设备版本不支持8位，就得先升级版本。

登录失败锁定策略也同样重要。等保三级要求“具应对登录失败的处理功能”，一般配置为连续失败5次锁定账号10分钟，防止暴力破解：

Ruijie(config)# login Authentication failure retry 5 lock 10

有的版本命令是login lock-times之类的，配置前最好用?查看一下当前版本的完整命令。这条命令我建议尽量配上，因为测评老师会人工检查这个参数的配置情况，哪怕设备默认开启了，最好也在配置里显式体现，方便评审人员核对。

3.2 集中认证：RADIUS/TACACS+对接

等保三级要求应对登录的用户进行身份标识和鉴别，且推荐采用双因素认证或集中认证。在实际测评中，虽然本地密码也算一种鉴别方式，但如果有堡垒机或认证服务器，建议把设备接入RADIUS或TACACS+，能明显提高测评通过率。

锐捷设备配置RADIUS认证的大致逻辑如下：

Ruijie(config)# radius-server host 192.168.10.10 key Ruijie@2024 Ruijie(config)# aaa new-model Ruijie(config)# aaa authentication login default group radius local

第一行指定RADIUS服务器的IP和共享密钥，第二行开启AAA模型，第三行配置登录认证优先用RADIUS，如果RADIUS不可用则回退到本地认证。

这里有个容易踩坑的地方：一旦RADIUS服务器宕机或者网络不通，如果配置成“只走RADIUS不回退本地”，会导致管理员被锁在设备外面。所以建议一定要带上local作为兜底。我实际配置时，还会先在一台非核心设备上测试认证链路，确认OK后再批量下发，避免因为共享密钥错误导致所有设备都登录不进去。

另外，如果公司用了堡垒机，测评时可以把“运维人员通过堡垒机统一登录设备”作为加分项写在整改说明里，这就等同于有了集中的身份认证和操作审计，能有效降低身份鉴别和审计两个维度的风险项。

3.3 管理通道加固：SSH配置

锐捷设备默认可能开放了Telnet，测评中Telnet属于明文传输，基本必被记为高风险。所以第一步是关闭Telnet服务，启用SSH v2：

Ruijie(config)# enable service ssh-server Ruijie(config)# ip ssh version 2 Ruijie(config)# crypto key generate rsa Ruijie(config)# line vty 0 4 Ruijie(config-line)# transport input ssh Ruijie(config-line)# login local

如果设备上还有HTTP/TLS的Web管理服务，建议同样只开启HTTPS，或者干脆关掉Web管理，只保留命令行SSH。等保评审喜欢“最小化”，端口多开一个就是多一个暴露面。我之前见过有同行的设备开着HTTP Web管理界面，测了一圈发现还有默认口令，直接被列为高风险，所以管理面一定要收敛。

实际操作中还有个需要注意的地方：开启SSH后要确认管理终端能正常连接，尤其是如果你当前是Telnet连上去配置的，改完线路配置不要立刻断开，先新开一个SSH会话测试通了再断开旧连接，防止“改配置把自己关在门外”。

4. 安全审计与日志管理

4.1 时间同步：审计日志的前提

安全审计的日志必须包含准确的日期时间，所以设备的时间同步是前置条件。很多测评老师会看设备时间与标准时间是否一致，不一致的话会记一个“审计记录时间不准确”的隐患。

锐捷设备的NTP配置比较简单：

Ruijie(config)# ntp server 192.168.10.20 Ruijie(config)# ntp enable

配置完成后用show ntp status确认状态是否同步。这里有些细节经验：第一，NTP服务器最好指向公司内部的时钟源服务器，而不是直接指向公网NTP（一是安全策略可能不允许设备直接访问外网，二是测评环境往往要求内网通信）；第二，如果有多台设备，建议核心交换机作为NTP server，接入交换机作为client同步核心交换机，避免所有设备直接请求同一台NTP服务器导致负载集中。

4.2 Syslog日志外发配置

三级等保明确要求“审计记录应至少保存6个月”，靠设备本地存储的日志无法满足要求，所以一定要把日志外发到统一的syslog服务器或者日志审计平台。锐捷设备配置syslog外发的命令是这样：

Ruijie(config)# logging host 192.168.10.30 Ruijie(config)# logging on Ruijie(config)# logging source-interface loopback 0 Ruijie(config)# logging trap informational

logging source-interface指的是以哪个接口的IP作为日志源地址，建议手工指定为loopback地址，避免由于物理接口down掉导致日志源IP变化，给后端日志平台的分析带来困扰。

还需要注意日志级别。logging trap informational表示发送所有级别的日志，包含debug级别的信息。在某些高流量环境下这样会产生大量日志，容易把日志服务器“灌爆”，这时可以适当调节为notice或warning级别，但至少要保证登录成功/失败、配置变更等关键事件能记录到。我个人的习惯是：先开informational观察几天日志量，如果日均量太大再降级，同时在后端对日志量做过滤。

4.3 配置变更审计与本地日志保留

除了syslog外发，设备本地的日志缓冲也要保留足够空间。锐捷交换机在系统内存里保存的日志是易失的，重启就没了，所以不能过度依赖设备本地日志。条件允许的话，建议在日志平台侧配置接收来自设备的日志，并设置对应的存储策略，至少保存6个月以上。

同时，等保还要求对设备配置的变更进行审计。锐捷设备可以通过开启配置变更日志来记录配置被更改的事件：

Ruijie(config)# archive log enable Ruijie(config)# archive log size 200

这条命令会把配置变更记录保存在设备flash中，相当于本地配置审计日志。在测评时，这一项可以作为“配置变更可追踪”的证明。注意archive log也有容量上限，不要设得过大导致flash空间耗尽，200条左右是比较合适的值。

5. 访问控制与边界防护命令

5.1 管理源地址限制（ACL）

三级等保要求“应对登录的用户进行源地址限制”，换句话说，不是谁都能在任意IP上访问你的设备管理口。最常见的做法是通过ACL限制SSH、SNMP等管理协议的源地址，只允许运维网段的IP访问。

举个例子，运维网段是192.168.10.0/24，只允许这个网段SSH登录设备，可以这样写：

Ruijie(config)# ip access-list standard permit-mgmt Ruijie(config-std-nacl)# permit 192.168.10.0 0.0.0.255 Ruijie(config-std-nacl)# deny any Ruijie(config)# line vty 0 4 Ruijie(config-line)# access-class permit-mgmt in

这里ACL的deny any很重要，如果不加这一条，前面permit就形同虚设。同时，line vty下的access-class是控制入方向SSH访问的，别写到了出方向。

SNMP的源地址限制也同理，在snmp-server community配置中加上ACL调用，防止外部扫描器用默认团体名探测设备信息。

5.2 关闭不必要的服务与端口

锐捷设备默认开启的服务里，有些在等保三级环境下属于“多余服务”，测评老师看到就记风险点。比如：

• HTTP服务（如果不需要Web管理，建议直接关闭）
• SNMP v1/v2c（如确需使用，建议配置团体名复杂化并限制源地址；能上v3就上v3）
• 设备发现协议（某些私有协议，如无需求可关闭）

关闭HTTP服务的命令举例：

Ruijie(config)# no ip http server Ruijie(config)# no ip http secure-server

如果业务确实需要Web管理接口，至少也要开启HTTPS，并限制管理源地址。我见过不少设备开了HTTPS却用的是默认自签名证书，测评对证书本身一般不深究，但管理者是谁、是否可信，偶尔也会问，所以如果设备支持导入CA证书，建议把公司内部的证书导进去。

5.3 访问控制列表与最小权限

对于出口路由器和核心交换机，ACL不仅要管管理通道，还要在业务vlan之间做访问控制。等保三级强调“区域边界访问控制”，禁止非授权访问。最简单的做法是在三层接口或VLAN接口上应用ACL，仅放行业务需要的互访流量。

Ruijie(config)# ip access-list extended vlan10-20 Ruijie(config-ext-nacl)# permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 Ruijie(config-ext-nacl)# deny ip any any Ruijie(config)# interface vlan 10 Ruijie(config-if-VLAN10)# ip access-group vlan10-20 in

这里一定要理清楚：ACL是应用在源VLAN的入方向，还是目的VLAN的入方向。我犯过的错误是在源VLAN上写了permit到目的网段的规则，但忘了应用了deny any，导致VLAN间互访全部放开，等于ACL白写了。最好的做法是先在模拟环境（比如用EVENG或者锐捷的模拟平台）里把ACL行为测明白，再上现网。

等保里还有个“最小权限”的评估维度，落到网络设备上，就是账号角色权限分离。锐捷设备支持通过privilege level或者自定义command authorization来限制不同账号的权限。比如审计账号只能看配置，不能改配置：

Ruijie(config)# username auditor privilege 1 password xxxxxx Ruijie(config)# username admin privilege 15 password xxxxxx

privilege 1是查看权限，15是管理员权限。测评老师看到账号权限分级别配置，会比较认可“权限分离”这一条。

6. 常见问题与排查技巧实录

6.1 改完SSH配置，管理员被拒之门外

这类问题我碰到过不止一次，而且每次都发生在最紧张的整改时间窗口。典型场景：在Telnet会话里配置完SSH，又顺手在vty下设置了transport input ssh，然后Telnet会话一断，发现SSH连不上，排查发现是ACL把源地址deny了，或者SSH的rsa key没生成成功。

排查思路：先确认设备IP能不能ping通，如果能ping通就说明网络通，再检查SSH端口是否开放（可以用show ip ssh确认状态），再看vty下的ACL是否放行了当前源IP。如果这些都对，就检查认证配置，是不是RADIUS服务器没通导致认证失败。

关键预防手段是：在线配置时，先新开一个会话验证，再改全局配置和vty配置。给核心设备加配置，千万别把自己的老连接关掉，否则一出问题就只能跑机房了。

6.2 日志服务器收不到设备日志

syslog配好后，最常见的故障是日志服务器收不到任何消息。排查思路依次是：

• 用show logging看设备是否产生了日志，排除设备本身没有日志的情况
• 确认日志服务器IP和端口（默认UDP 514）是否可达，可以用ping测试网络连通
• 确认服务器上是否配置了允许接收来自该设备IP的syslog消息，很多syslog服务器默认不记录来自未知源的日志
• 确认防火墙或ACL没有阻隔UDP 514端口的流量，这一点最容易忽视，因为UDP是无连接的，ping通不代表UDP 514通

这里有一个实用小技巧：锐捷设备可以用logging host 192.168.10.30 transport udp port 514指定端口，如果服务器使用非514端口接收，比如9000，需要同步修改。另外如果设备日志量太大，先检查是不是有接口频繁up/down刷日志，这种噪音会干扰真实审计日志的查看。

6.3 测评前自检清单

我每次测评前都会花半小时做一次全面自检，确认所有等保要求项都对应有配置。分享一份可以直接拿去用的自检清单：

这个清单不一定100%覆盖每一家测评机构的检查项，但覆盖了绝大多数常见的检查点。每次整改或变更配置之后，我都会重新对照清单过一遍，避免改完ACL把其他配置带崩了。

6.4 锐捷平台对配置工作流的支持

最后再强调一下工作流层面的经验。锐捷设备本身的命令行体系和华为、H3C相似，命令风格差异不大，但也需要特别注意命令细节差异，特别是ACL编号、syslog参数等。如果团队里同时管着华为和锐捷设备，建议两份配置基线分开维护，不要直接套用。我习惯在锐捷设备上配置好一套模板后，先用show running-config导出配置，做成标准化配置文件存档，后续新设备上线或等保整改时直接改改IP就能用，省时省力还不容易漏配。

另外，锐捷有官方的模拟平台可以在电脑上搭建虚拟环境，我建议你在上现网之前，先把这些配置在模拟器里跑一遍。特别是ACL应用方向、密码策略是否生效这类问题，模拟环境验证能帮你提前发现错误，避免在现网上来回调试。我自己每次配置大改，都会先模拟验证再上真机，这个习惯帮我躲过不少坑。

等保三级不是一次性工作，而是一个持续的过程。等保测评过了，不代表可以放松，设备密码要定期换、日志要定期检查、管理员账号变更要定期清理。我个人的体会是：把安全基线做成标准化模板，每次新设备上线直接套用，再通过定期的自检清单核对，比等测评前临时抱佛脚要轻松得多。这篇内容基本覆盖了我在锐捷设备上做等保三级整改的核心经验，如果你正在做整改，建议先把自检清单过一遍，再对照着逐步加固，稳扎稳打，测评通过没那么玄乎。