做了几年等保测评，最常被网络管理员追着问的一句话就是：“你这套测评到底要在设备上敲哪些命令？”华为、H3C的命令资料网上随手一搜就有一堆，但换成信锐的无线控制器和安视交换机，不管是测评同行还是运维人员，普遍都会懵一下——资料少、命令体系不熟，偏偏等保测评的所有网络设备核查项又绕不开它。这篇文章我就把信锐网络设备做等保测评时常用的核查命令、判断标准和整改思路完整梳理一遍，帮正在搞等保整改的运维少走弯路，也帮刚入行的测评同行快速上手。
1. 信锐设备在等保测评中的定位与常见失分点分布
1.1 网络设备测评指标到底落在哪些层面
等保测评很少把“网络设备”单独列成一个测评层面，它的核查项是散落在几个技术层面里的。对网络设备来说，主要集中在这几块：安全通信网络、安全区域边界、安全计算环境，以及安全管理中心里跟审计相关的部分。也就是说，一台信锐无线控制器不只是“能上网”的设备，它既要满足通信网络层面的结构安全要求，又要在边界层面承担访问控制和入侵防范职责，到了计算环境层面，还得跟服务器、终端一样过一遍身份鉴别、访问控制、安全审计、入侵防范、资源控制这些通用指标。
所以测评师打开测评作业指导书之后，信锐设备涉及的控制点往往比表面上看起来多得多。比如无线控制器如果接了核心交换机，那么交换机上的VLAN划分、ACL策略、端口安全都要查；AC本身的口令策略、登录限制、管理协议、日志审计也要查；AP侧还要看无线加密方式、用户隔离、访客网络隔离。很多单位以为买了信锐的设备就“等保合规”了，实际上设备在测评里往往是被发现问题最多的对象之一。
1.2 信锐AC、安视交换机、AP最容易丢分的区域
信锐的产品线在测评现场出现频率最高的就是无线控制器（NAC系列）、安视交换机、无线AP这三类。以我这几年的测评经验，问题集中在下面几个点上：
| 设备类型 | 典型测评发现 | 对应核查项 |
|---|---|---|
| 信锐NAC控制器 | 默认管理员口令未改、登录失败无锁定、管理端未限制 | 身份鉴别、访问控制 |
| 信锐控制器/交换机 | telnet开启、SSH未启用、Web管理走HTTP | 身份鉴别 |
| 安视交换机 | 未配置ACL、管理VLAN与业务VLAN混跑、端口隔离缺失 | 访问控制 |
| 信锐无线AP | 加密方式弱、未开启无线用户隔离、访客网与办公网互通 | 访问控制、边界防护 |
| 全系列 | 日志只停留在Web页面展示、未外送syslog、无NTP对时 | 安全审计 |
为什么失分这么集中？核心原因有两个：一是设备上线时只求“网络能通”，默认配置保留得多，管理员根本没想到这些配置将来会在等保测评里被逐项翻出来；二是信锐设备的命令行资料相对少，运维平时习惯用Web管理，CLI下很多安全选项从来没碰过。等测评师拿着核查表过来，一条条对下来，整改项自然一大片。
2. 入场摸底：先用一类命令把设备“底细”摸清
2.1 系统信息与版本核对
测评连上信锐设备之后，第一步一定不是急着一顿敲配置，而是先确认设备的基本信息和版本。等保测评里，如果设备固件版本过旧、存在公开漏洞，是要作为隐患记录的。而且后续很多配置项在不同版本里命令名称和开关位置都不一样，先摸清版本能省掉后面大量折腾。
以我现场用得比较多的命令形态为例，信锐设备登录后可以先用这些命令打底：
show version show cpu utilization show memory show system-status show clock show ntp status不同固件版本之间命令差异不小，但大体上都是以show开头的查看类命令，配合Tab补全和?帮助就能找到自己要的。我习惯先看版本、再看CPU内存（顺带判断设备负载是否健康），然后把时钟和NTP状态一起查了。为什么把时钟放这么靠前？因为接下来查日志审计时，时间不同步会让所有日志记录失去证据价值，这是后面会重点说的问题。
补充一个实用习惯：连上设备先敲一个?或help，把当前模式下的命令列表拉出来扫一遍。信锐设备提示符形态比较接近“类Linux+网络命令混合”的风格，多花两分钟看命令提示，比拿着别家设备的命令硬套要靠谱得多。
2.2 时钟与NTP同步检查
时间问题在等保测评里太容易翻车了。很多单位的信锐设备从来没配过NTP，设备时间要么是出厂时间，要么是某次人工设置后就没再管过。等到测评师去抽查日志，发现设备上的登录记录、配置变更记录跟后端安全设备的日志对不上时间轴，整个审计项都受影响。
show clock show ntp status show ntp server核查标准很直接：设备时间与标准时间相差超过5分钟，就要列为整改项；NTP源至少配置一个可用地址，最好是两台以上，并明确指定同步源。有些单位确实配了NTP，但填的是境外时间服务器，解析不通，设备获取不到时间就默默回退成本地时间。这种情况测评时不算合规。
去年测评一家企业，信锐AC上所有日志时间都比标准时间慢8个小时。查了半天发现NTP服务器地址写了一个根本不可达的IP，设备同步失败后一直用着旧时钟。后来改成国内可用的NTP源，时钟恢复正常，日志外送服务器上的记录才终于能跟防火墙日志对上。这种“看起来配了、实际是假的”的情况，在测评现场相当常见。
2.3 管理服务面：telnet、SSH、HTTP、SNMP的暴露面排查
等保测评对远程管理有很明确的要求：远程管理必须使用加密协议。这条规则直接把telnet和HTTP推到了对立面。我在测评时必查的就是这四个服务：
show telnet status show ssh status show http server show https server show snmp community show management access判断标准一句话就能概括：
- telnet开启：不合规。远程管理未加密，抓包就能拿到明文口令。
- SSH开启且版本不低于2.0：合规。
- HTTP的Web管理开启：有风险，通常会建议关闭，只保留HTTPS。
- SNMP的community字符串是public、private或设备默认值：不合规，必须修改为复杂字符串，并限定可管理的源地址。
顺带说一句，总有人搜“telnet命令怎么用”，测评整改场景里telnet命令的最终答案是：把它关掉，改用SSH。SSH的登录方式跟telnet几乎一样，只是加密通道更安全，替换成本很低。运维如果只会telnet连设备，改成SSH后只需要在终端工具里换一个协议，不影响平时的排障操作。
管理服务面排查还有一个容易被忽略的点：管理VLAN的访问范围。设备的管理接口默认允许所有IP访问，或者只靠VLAN隔离但VLAN内所有主机都能访问，这在等保里都算不合规。正确做法是管理口ACL只放行运维网段，其他来源一律拒绝，测评时这条一般是必查项。
3. 身份鉴别与访问控制：整改最集中的两座山头
3.1 本地账号、口令复杂度与登录失败锁定
等保对网络设备的身份鉴别要求很具体：身份标识必须唯一，不能几个人共用一个账号；口令要有复杂度要求并定期更换；连续登录失败要有处理措施，比如结束会话、限制非法登录次数；网络登录连接超时后要自动退出。信锐设备上对应的核查命令大概是这么个形态：
show local-users show password policy show login failure-limit show idle-timeout show user authentication逐条对照下来：
- 账号唯一性：不能存在共享账号；默认admin账号要修改口令，如果可能直接停用或者改名。测评时发现设备上还留着出厂默认口令，这是最严重的问题之一，直接判不符合。
- 口令复杂度：建议口令长度不少于8位，包含大小写字母、数字、特殊字符中至少两类。有些测评机构尺度偏严，会按“三类以上”来掌握，我建议运维直接按最高标准配置，免得整改来回折腾。
- 登录失败处理：连续失败5次左右锁定账号，锁定时间不少于15分钟。设备上如果没有这个功能，就需要靠AAA服务器或堡垒机补偿。
- 会话超时：配置空闲超时自动退出，建议15分钟以内，最长不要超过30分钟。有些管理员为了自己方便把超时设成“永不”，测评人员一旦看到这种配置，铁定写进整改项。
这里必须说实话：信锐的部分入门型号在本地口令策略上能配置的项有限，比如有的设备只支持口令长度限制，不支持复杂度和失败锁定。这种情况下不要硬怼设备，正确思路是组合整改——把认证外包给AAA/RADIUS服务器，由服务器统一执行口令复杂度和锁定策略；运维登录走堡垒机，让堡垒机完成账号管理和双因素认证。这种“设备+周边组件”的组合方案，等保测评里是认的。
3.2 VLAN隔离、ACL与无线接入安全策略
访问控制这块，信锐设备在网络层面要查的内容比普通交换机多一些，因为还牵扯到无线接入侧。我常用的核查命令如下：
show vlan show interface trunk show access-list show port-security show mac-address-table show wlan security show wlan isolation show ap database核心关注点就三个方向：
第一，管理VLAN和业务VLAN必须分离。有些单位图省事，AC的管理地址跟业务地址在同一个VLAN里，终端连上无线之后可以直达AC管理口。测评看到这种拓扑，访问控制项直接扣分。正确做法是管理VLAN独立，并通过ACL把管理口限制为仅运维网段可访问。
第二，无线接入策略。WEP这种老古董加密方式是绝对不能出现的，现在最低标准是WPA2，能用WPA3更好。访客网络要跟办公网络隔离，最稳妥的方案是独立的访客VLAN，并且在防火墙上限制访客VLAN只能访问外网，不能触碰内网资源。无线用户之间的隔离也要开启，否则连上同一个AP的终端可以直接互访，这对办公网来说是很严重的安全隐患。
第三，交换机的端口安全。服务器区或办公网接入交换机上，端口安全、MAC地址绑定、BPDU保护这些功能能开就开。实际测评中，很多安视交换机的端口安全配置完全是空的，接口下的默认配置一放到底，这在等保里属于“网络设备访问控制措施缺失”。
4. 安全审计：日志不记录，测评直接零分
4.1 本机日志、日志级别与buffer容量
安全审计是所有测评项里最容易被忽视、也最致命的。等保要求网络设备启用安全审计功能，记录覆盖设备登录、配置变更、用户增删、认证事件等关键行为。但实际测评中，相当多信锐设备连日志记录功能都没完整打开，或者日志级别设置得太低，只留下了告警级别的信息，正常登录和配置操作根本没有记录。
show logging show logging buffered show logging level show log这里有个很关键的问题：本机日志如果只写到内存buffer里，设备一重启日志就全没了。测评时见到设备上能看到日志，先查一下它到底存在哪里。如果日志只停留在内存暂存区，没有持久化存储，那“日志留存6个月”这条等保要求基本没法证明。判定结果几乎只能是“不符合”。
日志级别建议设置在informational级别以上，这样登录成功、登录失败、配置变更、接口状态变化这些关键事件才不会被过滤掉。
4.2 syslog外送与日志留存周期
等保要求审计记录至少保存6个月。网络设备本地存储空间本来就有限，而且像AC这种设备，如果AP数量多、终端连入频繁，日志量是很大的。正确做法是配置syslog外送，把设备日志实时转发到集中的日志服务器。
logging on logging server 192.168.x.x port 514 logging level informational logging facility local5配置完之后不能只看设备端，还得到日志服务器上验证。我测评时会抽查三个时间点的日志：设备启动记录、某次登录事件、某次认证成功或失败记录，确认日志确实到达了服务器，且已经连续留存了足够长时间。如果日志服务器上只能查到最近两三天的数据，那留存要求就是不达标。
顺带提一句：日志服务器本身也要做等保测评，它的时间也必须同步，否则设备日志过来了、时间戳是乱的，依然不算有效审计数据。
4.3 审计数据的时间关联性
前面花了篇幅讲NTP，就是为了这块。日志外送解决的是“有没有”的问题，时间同步解决的是“对不对得上”的问题。一个完整的审计证据链，需要交换机、AC、防火墙、日志服务器、堡垒机全部在同一个时间基准下工作。
做测评这几年，最让我抓狂的情况不是设备没有日志功能，而是设备明明有日志，但时间错位得离谱。有一次客户的核心AC上登录记录显示凌晨3点有人改了配置，但堡垒机日志里同一时间段根本没有任何操作记录——后来发现是AC的时钟快了40分钟，加上时区配置不对，整改方案其实就是修好NTP。这种问题看似小，但到了安全事件回溯的时候，时间对不上的日志等于废纸。
所以自查时别只看“日志有没有”，还要看“日志的时间准不准”。把设备时钟、时区、夏令时处理都确认一遍，再抽查几条日志跟标准时间对比，这一步省不了。
5. 信锐设备等保测评实操中容易踩的坑与补救思路
5.1 设备功能缺位时的“组合整改”思路
前面提过，信锐部分型号在身份鉴别的本地策略上功能有限。不光身份鉴别，有些中低端型号在ACL、端口安全上也不支持太细的配置。测评遇到这种情况，不要直接写“设备不支持”然后放弃，等保测评本身是允许组合整改的。
举个例子：一台入门级信锐AC不支持登录失败锁定，但单位已经部署了堡垒机，所有运维登录必须经过堡垒机，堡垒机上配置了失败锁定策略，同时设备侧管理口只对堡垒机IP开放。这种情况下，身份鉴别项可以按“补偿措施到位”来评判，不一定非要设备本身具备完整功能。
组合整改的核心逻辑是：一个控制点的安全目标没变，只是实现目标的载体从单一设备分散到了多个设备上。运维人员要做的不是把功能硬塞进设备，而是把整个运维链路梳理清楚，让测评师看到安全能力是由哪几台设备共同兜住的。
5.2 运维侧常见的“假整改”问题
测评机构发整改通知之后，运维最常见的回应就是“改了啊”。但我在复测时经常发现三类假整改：
第一类是改了没生效。管理员在运行态把密码策略改了，但没保存配置，设备一重启又回到旧策略。信锐设备保存配置的命令在不同型号上叫法不同，有save、有write、也有copy running-config startup-config，拿不准就敲?看提示。改完配置后一定要执行保存，并且最好重启验证一次。
show running-config save write copy running-config startup-config第二类是改了一半。比如SNMP community字符串确实从public改掉了，但只改了只读字符串，读写字符串还是弱口令；或者ACL加上了，但没应用到管理接口，实际访问还是不受限制。测评复测时不会只看配置里“有没有”，还会拿真实访问来验证“通不通”。
第三类是表面整改。日志服务器配上了，但设备日志级别没调高，服务器上半天收不到一条有效日志；NTP地址填了，但根本不可达。这类问题在复测现场一查一个准。
5.3 测评过程中的授权边界与信息保护
这条虽然不是命令，但比命令更重要。测评人员连接信锐设备、执行命令之前，必须有书面授权，且授权范围要明确到哪台设备、什么时间段、允许执行哪些操作。特别要提醒的是：show startup-config这类命令会把完整配置包括口令信息打印出来，结果一定不能直接外发。
我在测评中一般只将必需的命令输出截图或保存，涉及口令、密钥的字段当场脱敏。运维人员在配合测评时，也不要图方便把生产环境完整配置直接甩到微信群里，建议先把敏感信息替换掉再传递。这个环节出了问题，不只是测评流程违规的问题，弄不好会造成实际的安全生产事故。
另外，测评时尽量避开业务高峰窗口。show类命令基本没有风险，但像save、write、copy running-config startup-config这类写操作，以及任何调试类命令，一定要在工作量可控的窗口执行，并且操作前备份一份配置，防止意外。
6. 测评前自查清单：运维人员可以照单核查
最后这部分是给运维人员的自查清单。测评前自己先过一遍，比等测评师上门再整改要主动得多。我按测评核查的顺序整理成一张表，运维可以照着敲一遍命令，看结果是否符合要求。
| 核查项目 | 建议命令 | 合格标志 |
|---|---|---|
| 系统时钟 | show clock | 与标准时间误差小于5分钟 |
| NTP同步 | show ntp status/show ntp server | 有可用NTP源且同步成功 |
| 远程管理协议 | show ssh status/show telnet status | SSH开启、telnet关闭 |
| Web管理 | show http server/show https server | 仅HTTPS开启或管理源受限 |
| SNMP安全 | show snmp community | 无public/private，字符串非默认 |
| 口令复杂度 | show password policy | 长度≥8位，含至少两类字符 |
| 本地账号 | show local-users | 无共享账号、无默认口令 |
| 登录失败处理 | show login failure-limit | 连续失败后有锁定动作 |
| 会话超时 | show idle-timeout | 空闲超时15分钟以内 |
| 管理源ACL | show access-list | 管理口仅允许运维网段访问 |
| VLAN隔离 | show vlan | 管理、业务、访客VLAN相互隔离 |
| 无线加密 | show wlan security | 使用WPA2/WPA3 |
| 无线用户隔离 | show wlan isolation | 用户间隔离已开启 |
| 本机日志 | show logging | 日志记录开启，级别达到informational |
| 日志外送 | show logging syslog | syslog服务器可达，留存6个月以上 |
| 配置保存 | show running-config+ save | 修改后的配置已保存到启动配置 |
这张表不是用来背的，是用来逐项验证的。每敲一条命令都顺便看一眼输出内容是否符合预期，不符合就进入整改流程。真正把自查做到位之后，测评师上门时你反而可以把沟通过程变成一次免费的配置体检，而不是被动地收一摞整改通知单。
做了这么多测评项目，我的体会是：信锐设备的等保测评，难点从来不在命令本身，命令一年多变、不同版本之间差异也大，真到现场靠Tab补全和问号帮助都能摸出个大概；难的是一开始就想清楚“测评项要什么、设备能提供什么、缺口怎么补”。先梳理核查项，再上设备敲命令，最后逐条对照标准出结论——这套流程走熟了，信锐设备也就是一台普通的网络设备而已。
