★ FEATURED ARTICLE 干等保测评这一行最怕的不是读不懂报告而是拿到设备不知道敲什么命令。国产网络设备的命令行体系五花八门尤其做接入和园区网的设备跟华为、H3C、锐捷这些主流厂商的命令风格差别很大经常是登录进去之后先翻一遍help才能找到入口。我最近连续做了几个项目被测对象都是同一类设备——某厂商的羚羊系列网络设备就是大家在机房常见到的那种接入交换机、汇聚交换机偶尔也会在边界上碰到它。第一次测的时候对着命令行一层层翻效率很低而且容易漏掉等保要求里的关键证据。后来我把等级保护2.0里跟网络设备相关的控制点逐条跟设备实际能查的信息做了映射整理出一套可以直接上手的命令清单和核查思路现在分享出来。这篇文章覆盖身份鉴别、访问控制、安全审计、入侵防范四条线适合刚入行的测评工程师也适合驻场运维自己按合规要求做自查。1. 等保测评网络设备测评先想清楚查什么再动手敲命令1.1 测评项与设备命令的映射关系等保测评不是把设备所有配置都翻一遍而是按控制点来取证。网络设备这边的核心控制点就是身份鉴别、访问控制、安全审计、入侵防范再加上一部分网络架构和边界防护的内容。拿到一台羚羊系列设备别急着show run先在脑子里把控制点和设备功能对应起来身份鉴别对应本地用户、AAA、登录超时访问控制对应ACL、VLAN、路由策略、端口安全安全审计对应日志开关、syslog服务器、NTP入侵防范对应防攻击策略、CPU内存监控、危险服务加固。我自己的工作习惯是带一张对照表左边写控制点中间写要查的命令关键词右边写预期结果。到了现场逐行打勾。这样看起来笨但最稳尤其连续测七八台设备的时候不会漏项。很多刚入行的同事容易陷入一个误区抱着设备命令手册从头看到尾看的时候觉得都涉及写报告的时候却对应不上等保条款。原因就是缺了这层“控制点到命令”的映射。其实测评命令采集的本质是证据链。测评师要的从来不是所有配置而是能支撑“符合、部分符合、不符合”结论的关键证据。对于羚羊系列这种命令体系不算主流的设备更需要提前把证据点列清楚。比如“身份鉴别”里有一条要求是“登录失败后应有处理措施”如果你连这个设备支持不支持登录失败锁定都不知道现场临时去找命令大概率要翻半天。1.2 设备登录与基础信息收集开始测之前先把登录方式确认好。羚羊系列默认可以通过console口登录部分型号支持SSH和TelnetWeb管理一般也有但通常不是默认开启。按等保要求远程管理必须加密所以现场如果发现Telnet开着这个点先记下来后面核查远程管理协议时大概率要判不合规。远程登录尽可能用SSH不要图方便用Telnet测完之后也要提醒运维把Telnet关掉。设备登录进去以后第一件事是固定设备身份信息。羚羊系列常见的查看命令是show version、show device-info或者部分版本支持display version。命令名有差异不要紧关键是拿到这几样设备型号、软件版本、运行时间、序列号、配置文件名称。这些信息要原样写进测评记录尤其是软件版本后面核查补丁更新情况时要用。基础信息这块还有个容易忽略的动作确认设备当前时间和时区。后面做安全审计核查如果设备时间跟标准时间偏差太大日志时间轴就是乱的审计证据直接打折扣。我一般会顺手敲一下show clock或者display time再跟本机时间对一下偏差超过五分钟就记录下来作为后续整改项。提示羚羊系列不同软件版本的命令差异不小我下面列的命令以该系列常见的命令行风格为准。现场如果敲不下去就用“?”或help逐级找千万不要靠记忆硬敲设备命令失效是小误操作影响业务是大。2. 四大控制点的核心核查命令与判定标准2.1 身份鉴别口令策略、登录失败处理与会话超时网络设备的身份鉴别主要看三个方向口令策略、登录失败处理、会话超时顺带还要看远程管理协议是不是加密。先查本地用户和口令策略羚羊系列一般在show running-config里过滤user、password、authentication这几个关键字也可以进到配置视图后逐行看。部分版本支持display local-user或show users能看到用户列表和对应权限。看口令策略时重点盯五个点第一口令策略里有没有最小长度和字符类型要求比如至少8位且包含字母和数字第二口令在配置里是不是加密存储明文密码直接算高风险项第三有没有登录失败锁定机制比如连续失败5次锁定5分钟第四有没有无操作自动退出一般5分钟以上应该强制下线第五远程管理走的是SSH还是Telnet。这五个点里前面两个是设备侧配置后面两个往往在line配置或用户界面配置里。羚羊系列部分版本支持login retry、login auto-lock、idle-timeout这类命令如果命令不存在就去查line vty下的exec-timeout和logging synchronous。判定的时候有一点要特别注意设备支持并不等于现场已经配置。很多交换机默认不开口令复杂度也不做登录失败锁定这种情况就要判“部分符合”或“不符合”整改建议里写清楚具体要补哪条配置。另外如果设备开了Web管理还要看Web登录是否同样受口令策略约束这个点测评要求里经常被忽略但检查时很多设备Web管理是独立一套配置需要单独确认。2.2 访问控制ACL、VLAN隔离与路由策略核查访问控制这块等保的核心是看不同安全区域之间有没有隔离流量有没有按策略放行以及管理通道有没有被限制。羚羊系列交换机和接入设备一般都有ACL能力查看配置常用show access-list或display acl重点看里面有没有实际生效的规则而不是只看有没有建ACL。现场经常遇到的情况是ACL建了一大堆但没有绑定到端口或VLAN上这种等于白建不能作为“已实现访问控制”的证据。ACL是否生效要看绑定位置。在端口下查show interface status或display interface看端口有没有引用ACL。二层交换机更多是把ACL绑到VLAN或物理端口上三层设备则可能绑到接口的inbound/outbound方向。另一个重点是VLAN划分用show vlan或display vlan查看VLAN表确认办公网、管理网、服务器区是不是做了二层隔离。很多等保测评项目里管理VLAN和业务VLAN混在一个广播域里这是比较典型的隐患。路由策略核查也不能省。用show ip route或display ip routing-table查看路由表确认设备是否存在指向敏感网段的默认路由或者有不合理的策略路由。边界设备上要关注有没有NAT、路由过滤这类手段至少确认不该通的网段没有可达路径。管理口方面还要看SSH、HTTP、SNMP这些管理服务是不是限制在管理网段。SNMP这块我建议单独查一下show snmp看版本和community值public/private这种默认值一旦出现基本可以直接判不符合。2.3 安全审计日志开关、日志服务器与时间同步安全审计是整个网络设备测评里最容易踩坑的环节。很多设备默认只在console上打日志不写本地缓冲区也不外发到syslog服务器这种情况单看设备自身很难满足“审计记录留存”的要求。按等保2.0的思路网络设备的审计日志至少应该覆盖用户登录、配置变更、重要操作等事件并保留一定周期所以测评时重点要看三块日志开没开、日志往哪发、时间准不准。羚羊系列的日志配置一般分三步。第一步开启日志开关常见命令是logging on第二步设置日志级别比如logging buffered informational或logging console warning第三步指定日志服务器常见命令是logging host x.x.x.x或syslog server。现场核查不能只看配置在不在还要确认日志真的能发出去。我遇到过一次设备上配置了logging host但syslog服务器一台设备的消息都收不到后来排查发现中间防火墙把UDP 514端口给拦了。所以光看设备配置不验证实际收发很容易误判。时间同步要单独看。用show ntp status或display ntp-status查NTP同步状态同时用show clock或display time看当前时间。如果设备没有配置NTP只靠手工校时一般判“部分符合”整改建议是统一接入NTP服务器。另外日志时区也要看有些设备默认记录UTC时间跟本地时间差了好几个小时这种日志作为审计证据时时间线会很难对齐报告里最好能说明设备使用的时间标准。2.4 入侵防范防攻击策略、资源监控与危险服务加固网络设备的入侵防范经常被误以为是防火墙专属实际等级保护里交换机、路由器同样要核查。第一项是防攻击策略比如广播风暴抑制、ICMP速率限制、畸形报文丢弃。羚羊系列一般在配置视图下有storm-control、broadcast-suppression、multicast-suppression这类命令执行show running-config时过滤storm或suppression关键字就能看到。如果设备不支持这类命令至少要有端口广播抑制之类的替代手段一项都没有的话边界或接入侧的风险就会放大。第二项是资源监控。网络设备有没有CPU利用率、内存利用率的监控手段是判断“能否发现异常攻击”的重要依据。用show cpu、show memory或display cpu-usage、display memory查看当前资源占用同时查设备有没有开启告警阈值。这里要说明一下等保测评不是性能测试CPU高不高本身不是判定项判定的是“设备是否有监控手段能不能及时发现被攻击或异常消耗”如果现场连查看资源占用的途径都没有那就属于入侵防范能力缺失。第三项是危险服务和弱算法加固。远程管理协议优先只保留SSH并关闭TelnetSNMP尽量用v3如果只能用SNMPv2c要确认community不是默认值且只读还要看Web管理、FTP、TFTP这类服务有没有不必要的开放。用show service、display tcp brief或show tcp status能看到当前监听的端口逐个确认用途。常见的问题是Talent服务没关干净或者SNMP写权限开着这些在报告里都属于需要整改的高风险点。3. 实操过程从登录设备到输出测评结论3.1 测评前信息收集与测评方案定制到现场之后不要急着连设备先做环境观察。确定被测设备在网络里是什么角色是核心交换机、汇聚交换机还是边界路由器。这个信息决定了哪些控制点适用。边界设备重点看边界防护、访问控制、入侵防范核心交换机重点看网络架构、VLAN隔离、安全审计接入交换机则要更多关注端口安全、广播抑制和访问控制。同时确认设备部署的物理位置和连接区域比如是否直接连着服务器区、办公区、互联网出口。连接关系不同ACL策略核查的侧重点也不同。比如办公网到服务器区的流量至少要看到明确的放行策略互联网出口设备则要确认是否做了必要的访问限制和攻击防护。测评工具箱也要提前准备好console线、串口转USB线、SSH客户端、终端日志记录工具、命令记录模板。羚羊系列有些型号的console口是RJ45有些是串口最好两种转接头都带上。另外提前跟运维确认登录账号和权限。曾遇到过现场账号只能执行部分命令进不了配置视图结果只能临时找运维重新开权限白白浪费半天时间这些沟通一定要前置。3.2 命令执行规范与记录要点测评过程中要遵循“最小影响原则”。我们执行的大多是查看类命令对业务影响很小但反复登录设备本身也是会产生日志的如果设备配置了登录告警运维侧可能会收到一堆告警消息。所以在生产设备上执行命令前最好跟运维打个招呼约定时间窗口。不要在同一终端一次性粘贴一大串命令万一某条命令在当前版本上不支持或触发了交互提示后面所有命令都会乱掉。记录建议用终端日志功能把每次登录到退出之间的完整回显保存成文本。这样比手工抄命令快得多也避免抄错。保存完成后给文本做分区标注哪些是身份鉴别证据哪些是访问控制证据哪些是审计和入侵防范证据方便后面直接引用到报告里。敏感信息的处理要格外小心。配置回显里可能包含口令、SNMP community、密钥等原始记录不要随便发到群里或放到共享目录测评报告输出前要做脱敏。虽然等保测评本来就是合规工作但保护被测系统的敏感配置是测评人员的基本职业习惯也是对客户负责。还有一个细节容易被忽略命令执行时间点的记录。每条命令大概什么时间跑的哪个账号执行的这些要随手记。后续如果客户对测评结论有疑问需要还原当时的操作过程这些时间点就是证据链的一部分。我一般会在终端日志里加上时间戳这样回显本身就能证明操作顺序。3.3 测评结果判定与整改建议组织整理测评结果时把证据和结论严格对应起来。每个不符合项都要写清楚证据是什么、对应哪个要求项、风险说明、整改建议。建议一定要具体到设备和命令级别。比如发现设备没有配置登录失败锁定整改建议不要写“请完善身份鉴别策略”而要写“在配置视图下配置连续5次失败锁定5分钟可通过login retry和login auto-lock命令实现”。客户拿到报告后可以直接照着操作这才是有效的整改建议。同一台设备上的多个问题可能是同一个根因导致的比如软件版本太旧很多安全功能根本不支持这时候可以将身份鉴别、入侵防范相关的几个问题合并成一条整改建议“升级设备软件版本并重新进行安全配置基线核查”。合并的好处是避免整改建议过于碎片化客户也更容易落地。判定时要注意区分“设备支持但未启用”和“设备本身不支持”。这两种情况在测评结论和风险等级上是有差别的。如果设备本身不支持某项功能但通过其他补偿措施达到了类似效果比如没有登录失败锁定但通过AAA服务器实现了统一认证和账号锁定那可以考虑判部分符合而不是直接判不符合。这种判断需要测评师结合现场实际情况做综合评估不能机械地套条款。4. 常见问题与排查技巧实录4.1 登录不上设备、命令权限不够怎么办羚羊系列设备测评时最常遇到的问题就是登录账号权限不足。有的账号能执行show命令但进不了配置视图导致查不到完整配置。这时先看当前用户权限常见命令是show privilege或display privilege。如果权限确实不够让运维临时开一个具备查看配置权限的只读账号或者由运维人员代为执行命令后转发回显给你转发时注意先做脱敏。千万不要为了让测评方便临时把设备口令改成弱口令这是帮倒忙测评完还要留下一个安全漏洞。连接不上设备的问题也经常发生。SSH连不上时先确认远程管理服务是否开启、是否在管理网段内。Telnet没开、SSH又不通就只能走console。console登录时要注意串口参数绝大多数网络设备默认9600,8,n,1但部分羚羊系列型号默认波特率可能是115200如果屏幕上全是乱码先调波特率再试。4.2 日志审计配置看起来正常但日志没外发现场经常遇到这样的情况设备上logging host配置了syslog服务器地址也写了但服务器上就是收不到消息。排查思路分三步。第一步在设备上ping日志服务器确认三层连通性第二步检查中间防火墙或安全策略很多网络设备的syslog默认走UDP 514端口边界策略没放行日志就出不去第三步查日志级别如果配的是emergencies这种极端级别正常操作日志根本发不出来至少要调到informational或notice级别。判断日志是否真正合格的标准只有一个日志服务器上有没有持续增长的实际日志。光看设备配置界面上“日志功能已开启”不算数。测评时最好直接登录syslog服务器查一下最近的日志记录截图作为审计证据。如果服务器上啥也没有那不管设备配置多完整这个点都只能判部分符合或不符合。4.3 多台设备批量采集命令的经验同一个项目里往往有一批同型号设备逐台登录执行命令效率很低。可以先在一台设备上把命令清单全部跑通整理成脚本再用SSH批量执行。批量采集工具可以选择常见的自动化运维工具也可以用脚本语言自己编写关键是控制好节奏。每台设备单独建一个输出文件文件名带上设备IP和业务名称避免结果混淆。批量执行时命令间隔不要太短有些老设备并发SSH连接多了会卡顿甚至丢配置建议同一时刻只测一台或者每台设备间隔3到5秒。采集完成后先抽查两台设备的输出格式确认命令在当前软件版本下正常执行再继续后续分析。不同型号的设备、不同软件版本命令支持程度不一样脚本里要有异常处理逻辑命令不存在时记录到单独的日志文件不要中断整个流程。4.4 容易误判的几个点与边界问题口令复杂度判定时要区分“设备支持”和“现场启用”这两个概念。有些老版本设备本身支持口令策略配置但默认没有开启这种情况下不能直接判不符合要看现场有没有通过其他方式补偿比如认证走AAA服务器由服务器侧统一执行口令复杂度策略。若真有补偿措施可判部分符合整改建议里写清楚“建议在设备侧或认证服务器侧启用口令复杂度要求”。远程管理问题也容易被机械判定。有些测评人员看到Telnet开着就直接判高风险但现场往往端口已经做了ACL限制只允许管理网段访问这种情况风险等级可以适当下调为“中”报告里要把ACL限制措施写清楚。同样SNMP如果配的是SNMPv2c但community是复杂字符串且只读也不能直接按不符合处理要结合实际管理用途来判。关于可信验证等级保护里对计算环境有明确要求但并不是所有网络设备都具备可信根校验能力。羚羊系列这类设备能不能满足取决于硬件和软件是否支持可信启动、完整性校验等特性。测评时先确认设备能力再决定这一条是判不适用还是判不符合不能拿服务器的标准硬套交换机。很多刚入行的测评师在这个点上栽过跟头写报告前一定要查清楚设备型号的技术规格。写到这里算是把羚羊系列网络设备在等保测评中要走的命令路子捋了一遍。我个人在实际项目里最大的体会是设备命令可以记不全但测评思路一定要清晰先想清楚每个控制点要什么证据再去找对应的命令远比你抱着一本命令手册现场翻要有效率得多。另外每次测完记得把设备型号、软件版本、命令差异点记进自己的知识库下次遇到同一厂商的新设备能省很多事。如果你也在用这款设备做合规自查建议先拿测试环境跑一遍上面的命令确认版本支持情况再上生产别在业务高峰期折腾设备。后续我再遇到这个厂商其他产品线会继续把命令和踩过的坑补进来。
阅读完成 · 觉得有帮助？
