1. 先搞懂等保2.0的“计算环境”里为什么把网络设备安全单拎出来做了几年等保测评每次拿到测评项目最容易被忽视的往往是“计算环境之网络设备安全”这一块。业务侧的服务器有专业的加固基线中间件有版本检查、漏洞扫描但网络设备经常是一放好几年不动登录口令、远程管理方式、日志备份这些细节别说整改很多单位连设备上有多少个账户都没数过。这篇就以实际测评视角把等保测评中“计算环境之网络设备安全”从标准条款、现场核查、常见问题到整改手段完整拆一遍。先看等保2.0的技术类安全通用要求框架它把测评对象分成了五个技术层面安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心。前四个是技术控制最后一个是管理支撑。其中安全计算环境这一层覆盖的测评对象最杂服务器、终端、数据库、中间件以及网络设备和安全设备。很多运维人员一听到“计算环境”潜意识里只想到主机和数据库但标准里的“计算环境”并不只是计算资源网络设备也被纳入其中作为支撑整个业务区域运行的基础网络设施它的身份鉴别、访问控制、安全审计、入侵防范等安全属性直接决定了主机侧那些安全机制能不能真正起作用。1.1 网络设备安全和“安全区域边界”的区别不少刚入行的测评人员或者运维同学容易把“计算环境之网络设备安全”和“安全区域边界”混在一起。安全区域边界关注的是数据跨边界流动时怎么控制比如防火墙的策略、边界入侵防范、恶意代码防范、边界安全审计它在网络拓扑上属于“门卫”的角色。而计算环境下的网络设备安全关注的是网络设备本体谁在登录它、登录之后有什么权限、登录过程是否加密、有没有审计日志、设备上开了哪些多余服务。一个管“门前”一个管“屋里”虽然测评表里都要检查网络设备但关注点完全不同。举个例子某单位在边界防火墙上部署了非常严格的安全策略所有跨区访问都被ACL限制得死死的防火墙审计日志也很完整这是“安全区域边界”做得好。但如果核心交换机的远程管理还开着Telnet密码还是出厂默认的admin登录失败不锁定、超时不断开那不管边界防火墙多强攻击者只要进了内网拿到设备管理权限也就是分分钟的事。这一块就是安全计算环境里网络设备的测评范围。1.2 测评对象的识别方法实操时怎么确定哪些网络设备要纳入“计算环境之网络设备安全”的测评对象一般按三步走。第一步从定级备案表、网络拓扑图、设备台账里梳理出被测系统涉及的网络设备第二步按承载业务重要性和网络层级筛出重点对象通常核心交换机、汇聚交换机、路由器、无线控制器这几类优先纳入接入交换机如果数量很大、型号配置一致按照抽样原则选取有代表性的对象即可第三步在访谈时和网络管理员确认是否有近期变更、新增设备避免测评范围外漏。这里容易出现一个偏差把边界防火墙、入侵检测系统、WAF这些安全设备也一股脑写进“网络设备安全”的测评项里。安全设备有它自己的测评控制点虽然要求和网络设备类似但归类上更倾向于安全计算环境里的“安全设备”。测评报告里网络设备和安全设备通常会分开列核查时不要混填否则被测对象覆盖不清晰专家评审环节会被打回。2. 测评项逐条拆解身份鉴别、访问控制、安全审计、入侵防范、可信验证等保2.0中安全计算环境下的网络设备安全大方向可以归纳为五个板块身份鉴别、访问控制、安全审计、入侵防范、可信验证。下面按测评表里的实际核查逻辑把每个板块的核心要求讲透顺便把测评师在现场最常看的证据点列出来。2.1 身份鉴别账号唯一、密码复杂、远程防窃听身份鉴别是网络设备安全里权重很高的一块也是现场最容易发现问题的地方。标准要求并不复杂登录用户要有唯一身份标识不能谁都用一个共享账号身份鉴别信息要有复杂度要求并定期更换系统要具备登录失败处理功能包括结束会话、限制非法登录次数、登录超时自动退出远程管理时必须防止鉴别信息在网络传输中被窃听。前两点对应到设备配置上就是要建立独立的本地用户表或集中认证体系每个管理员有自己的账号密码策略上要设置最小长度、复杂度要求比如大写、小写、数字、特殊字符中至少三种组合并定期强制更换。第三点对应登录失败锁定策略和空闲超时配置连续输入错误密码达到一定次数账号锁定一段时间管理连接超过设定空闲时间后自动断开。第四点就是赫赫有名的“关闭Telnet、启用SSH”只要远程管理还在用明文协议这一项几乎必然判不符合。现场核查时测评师会登录设备查看运行配置重点找这几处用户配置、密码策略相关命令、VTY或Line登录配置以及SSH服务状态。有的设备支持show ssh或display ssh server能直接看到SSH版本和端口如果version显示是1.x隐患也很大SSHv1本身就有安全缺陷必须升级到SSHv2。见过一个比较典型的现场设备上确实配了SSH但同时Telnet也开着说是因为部分老运维不会用SSH客户端结果Telnet就成了最大的突破口这种配置在现场整改时很常见。2.2 访问控制权限分级、默认账户要处理访问控制这一板块核心要求是对登录用户分配不同账户和权限重命名或删除默认账户修改默认口令及时删除或停用多余的、过期的账户避免共享账户。翻译成大白话就是不同人有不同权限默认的admin这类账户别再用离职或长期不用的账户要及时清理。测评时怎么查先拉出设备上的用户列表看是否存在权限大小完全一样的管理员账户有没有不该存在的额外账户。网络设备的账户权限一般分为管理员、操作员、只读用户等层级比较规范的配置是日常监控人员只有只读权限只有网络运维的核心人员才有配置权限。凡是所有账户都是管理员权限的访问控制基本这段就不达标。默认账户和默认口令的问题更加普遍。很多单位买了设备开机初始化时把初始密码改了但账户名还叫admin有些设备出厂会有多个默认账户比如有些设备的debug账户、访客账户平时根本不用却一直留在配置里。测评表里“重命名或删除默认账户”这一项看的就是账户名是否有默认痕迹。整改时建议把admin这种账户改名或禁用然后新建带业务特征的管理员账户并为每个管理员单独建号避免多人共用一个管理员。另外共享账户和临时账户是很多单位容易忽略的坑。有些小团队为了图省事几个人共用一个管理员账户登录出了问题根本查不到是谁操作的这和身份鉴别里的“身份标识唯一性”是冲突的。测评时访谈人员如果承认存在共享账户即使设备配置看起来没什么问题这一项也保不住。2.3 安全审计记录完整、日志能追溯安全审计的要求也比较直白启用审计功能审计覆盖到每个用户对重要的用户行为和重要安全事件进行审计审计记录要包含事件的日期时间、用户、事件类型、事件结果、具体描述等要素审计记录要保护起来定期备份防止被未预期删除、修改或覆盖。这里最关键的是“审计日志落地”。不少网络设备出厂默认只把日志输出到console口人在现场能看到但平时没人盯着有些设备日志buffer很小几天就被覆盖了。测评时如果发现设备没有配置日志主机也没配log buffer日志随用随丢安全审计直接判不符合。审计记录要素的核查要看日志内容和格式。比如某设备上有用户远程登录、配置变更的记录日志里能看到时间、来源IP、操作账号和操作内容这才算完整。见过一个情况设备日志里全是系统重启、链路状态变化的记录但没有任何登录和配置操作记录这说明管理员把审计级别配错了只记录了info级事件没有记录用户行为和配置变更。这种属于“有审计功能但审计不到关键内容”测评结果通常判定为部分符合。时间同步也是审计里容易被忽略但很要命的细节。如果设备没有配置NTP同步日志时间漂移事后追溯攻击行为时会发现时间线对不上。现场测评时如果发现设备时间和日志服务器时间差了好几个小时审计记录即使保留了也失去严谨性测试项照样扣分。2.4 入侵防范最小化安装、限制管理来源入侵防范板块的核心逻辑就一句话攻击面越小越好。标准要求遵循最小安装原则只安装需要的组件和应用程序关闭不需要的系统服务、默认共享和高危端口通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制。对应到网络设备上常见问题包括SNMP服务对外开放且用的是v1/v2c弱版本管理口IP暴露在多个VLAN里HTTP管理服务开启设备上跑着与业务无关的服务或协议管理端口没有用ACL限制来源。这些都是在现场测评时会实际检查的内容。“管理终端限制”这一项值得单独说。测评师会看设备上有没有配置管理ACL限制了登录设备的管理源地址范围。比较稳妥的做法是单独规划一个管理VLAN把所有网络设备的管理地址都规划在这个VLAN里再配合ACL只允许运维终端所在网段访问设备管理地址。如果设备对全网开放管理任何一台终端都能通过SSH尝试连接设备配合弱口令就是极大的隐患。“高危端口”在等保计算环境网络设备里通常指设备对外开启的管理类端口和服务。有些设备还会开一些调试端口或未使用的逻辑接口现场看配置时可以通过interface状态和端口统计来核对。测评评分时不会因为一个接口开着就判为高风险但如果大量无用途接口处于up状态且没有对应的访问控制入侵防范这一项也会被扣分。2.5 可信验证关键设备上的新增要求可信验证在等保2.0里是一个相对新的提法核心是基于可信根对计算设备的系统引导程序、系统程序等进行可信验证并在检测到可信性受到破坏时可进行报警。对网络设备来说这个要求不是所有设备都能满足主要看设备是不是具备可信计算相关能力。低级别系统里这一项一般不是测评重点但三级及以上系统测评时会看设备是否具备可信根芯片或其他可信验证机制比如安全启动、固件校验功能是否开启。很多传统交换机根本不支持这类功能测评时通常填写“不适用”或“部分符合”然后看厂商后续型号是否支持。不过随着设备国产化替代步伐加快新采购的设备和操作系统逐渐在加入可信启动能力未来这项要求会越来越常见。3. 测评实操过程从访谈、配置核查到结果判定光会读标准条文还不够关键是怎么在现场把“符合/不符合”的证据捞出来。这里从实操流程的角度把网络设备安全测评的完整路径讲一遍方便测评人员对照执行也方便被测评单位的运维人员准备材料。3.1 测评前的信息收集与对象确认测评进场前我会先让对接人员提供几份基础材料系统定级备案表、网络拓扑图、设备配置清单、设备版本信息汇总。拿到拓扑和清单后先圈定哪些属于计算环境网络设备的测评对象。如果被测系统规模大网络设备数量多通常按“核心设备全测、同类型接入设备抽样测”的原则进行抽样时要记录抽样的型号和数量报告里要能说得清覆盖范围。有个容易被遗漏的环节是版本核对。不同软件版本的设备命令行和功能支持差异很大比如某些设备老版本根本不支持SSHv2也不支持更细粒度的密码策略。提前把版本信息整理出来可以预判哪些设备整改起来可能需要升级系统给后续整改方案留足时间。如果等测评现场才发现版本老旧整改窗口往往就很紧张。3.2 现场访谈与配置核查的关键动作现场访谈时问题要问得具体不能只问“你们设备安全吗”这种空话。我常用的问题清单大致是设备运维由谁负责有几个人远程管理用什么协议有没有限制管理来源地址密码多久换一次复杂度要求是什么设备日志存在哪是否备份是否做过NTP同步有没有做过账号权限梳理有没有临时账号访谈记录要留档测评报告的符合性判定需要访谈记录做支撑。配置核查是核心环节。登录设备后按“用户与认证—远程管理协议—登录策略—审计配置—服务端口—ACL限制—SNMP状态”这个顺序查看运行配置。不同厂商设备命令差别明显但核查逻辑一致主要提取的信息包括本地用户表、AAA配置、enable密码或特权密码判断身份标识和权限分配。SSH服务是否启用、Telnet是否关闭SSH版本是否为v2。VTY或远程登录的接入限制是否有ACL调用。登录失败锁定策略、空闲超时参数。日志输出配置是否指向日志服务器本地日志buffer大小。SNMP配置community字符串复杂度SNMP版本。设备NTP配置确认日志时间准确性。配置核查的同时还要做验证性测试不是光看配置就够了。比如尝试连续输入错误密码看设备是否触发锁定模拟一次远程登录观察超时是否生效如果设备支持SSH用抓包方式或查看会话信息确认当前没有明文管理连接。验证性测试的结果要记录在现场记录表中作为测评证据。3.3 符合性判定与高风险逻辑测评结果的判定一般分为符合、部分符合、不符合、不适用四类。判定“部分符合”的场景很常见比如密码策略设置了复杂度但设备不强制定期更换日志功能开着但没有外送日志服务器SSH启用了但Telnet没完全关闭。测评师的判定要严谨不能凭感觉每条记录后面要跟证据描述写清楚配置核查和测试验证的具体结果。关于高风险判定虽然最终高风险项要和测评项目整体情况结合来看但网络设备安全里有几类是极其容易触发高风险的默认口令或空口令直接登录几乎必判高风险远程管理使用明文协议且设备暴露在非可信网络有较大概率判高风险未启用任何审计功能无法追溯安全事件也可能判高风险多因素叠加时风险等级还会继续发酵比如“默认口令全网可管理无审计日志”这种组合在风险分析里属于非常严重的情况。这里要提醒一句风险判定不是机械套公式测评师要结合设备在网络架构中的位置、管理网络的可信程度、设备的实际暴露面综合判断。同样是管理终端没有限制如果管理地址只在内网VLAN里且内网有严格的准入控制风险相对可控如果设备管理口直接暴露在对外服务网段风险就会显著上升。报告里写风险分析时要把这些客观条件写清楚不能只给一个结论。4. 高频问题与整改手段可以直接照抄的解决方案网络设备安全测评中高频问题翻来覆去就那么几类。把这些问题的整改手段提前准备好后面做等保整改会省很多事。下面按问题场景给出配置层面的解决思路具体命令以设备实际版本为准。4.1 弱口令、默认账户与共享账户问题表现设备管理员密码长期未更换初始密码仍在用管理员账户名还是admin或root多人共享同一个管理账号。整改思路先把设备上所有默认账户和无关账户禁用或删除再为每个网络管理员建立独立账号按职责分成管理员和只读用户。密码策略上开启复杂度检查和最小长度限制设置定期更换周期。登录失败锁定和超时策略也在这一轮一起配置。以一台常见的企业级交换机为例配置逻辑大致如下# 开启密码复杂度检查 password complexity enable password min-length 8 # 为本地用户设置登录失败锁定策略 local-user admin class manage login fail-count 5 lock-time 10 # 配置远端登录会话空闲超时 user-interface vty 0 4 idle-timeout 5 0注意配置完账号策略后逐个确认管理员是否还记得自己的密码。整改过程中经常发生改完密码管理员自己也登录不进去的情况建议先在一个管理账号上测试通过后再批量应用。4.2 远程管理明文传输与全网可管理问题表现Telnet未关闭管理端口对全网开放没有限制管理终端来源地址。整改思路优先关闭Telnet服务启用SSH并强制使用SSHv2。如果单位有堡垒机或跳板机还应把管理地址限制为堡垒机地址。ACL限制管理来源是性价比最高的一步做法是创建一个管理ACL只允许运维网段访问设备管理地址然后在远程管理协议上引用这个ACL。# 启用SSH ssh server enable # 关闭Telnet telnet server disable # 创建管理ACL仅允许运维网段管理设备 acl number 2001 rule 5 permit source 192.168.10.0 0.0.0.255 # 在VTY调用ACL user-interface vty 0 4 acl 2001 inbound这里有一个特别重要的实操提醒关闭Telnet之前一定要确认有可用的带外管理通道或本地console访问能力。如果设备在远端机房又没有带外管理系统Telnet一关SSH配置又因为某台终端没放行而连不上运维可能直接面临设备失联。我在一个项目里就碰到过这种事本来只是想顺手关掉Telnet结果SSH的ACL地址段写错了一个网段管理连接全断最后只能安排人员去机房现场处理。关远程明文协议前先在当前会话里把SSH和ACL验证通了再来关Telnet顺序不要反。4.3 审计日志缺失、不完整与时间不同步问题表现设备没有配置日志外发本地日志容量有限且经常覆盖日志时间不准确审计范围不完整。整改思路搭一台统一的日志服务器或接入单位已有的集中日志平台网络设备通过syslog把日志外发出去。同时保持本地日志不要关作为日志链路异常的兜底。关键配置项包括日志主机地址、日志级别、NTP时间同步以及确认日志内容包含了用户登录和配置变更事件。# 配置NTP时间同步 ntp-service enable ntp-service unicast-server 192.168.100.1 # 配置日志输出到日志服务器 info-center enable info-center loghost 192.168.100.50 # 调整日志级别确保记录用户行为和配置操作 info-center source default log level informational整改后记得验证一下在设备上做一些配置变更类操作再登录日志服务器查看是否能收到对应的日志记录。如果日志服务器收不到优先排查网络连通、防火墙阻断和日志级别配置不要等测评人员到场了才发现日志管道是断的。NTP同步这件事在整改时很容易被忽略但审计时间不一致会导致日志在司法追溯、事件回溯时失去效力所以一定要纳入整改清单。4.4 多余服务与高风险端口未收敛问题表现SNMP v1/v2c服务对外开放且community弱口令设备的HTTP管理功能开启未使用的接口大量处于up状态CDP/LLDP等邻居发现协议未关闭。整改思路按最小化原则清理服务。SNMP如果业务确实需要监控尽量升级到SNMPv3配置认证和加密参数如果监控系统只支持v2c至少要修改默认community字符串并用ACL限制监控服务器的来源。设备管理不建议使用HTTP如果某些场景必须用要评估是否需要通过HTTPS替代。关闭不使用的物理接口配置为shutdown状态。从测评经验看设备开放SNMP且community是public/private这类默认字符串的案例非常多尤其是一些老设备放了好多年没动过。这个问题的风险不仅在于信息泄露攻击者通过SNMP可以读取大量设备信息甚至配合写入权限修改设备配置。整改优先级上SNMP弱community应当和弱口令一样放在最前面处理。4.5 权限不分级与操作无留痕问题表现所有管理员账户都是最高权限没有只读账号设备上也没有对配置变更做操作前确认、操作后复核的机制。整改思路建立分级账户体系管理员、操作员、维护人员、审计人员分开。网络设备上尽量给日常巡检人员配置只读权限需要变更配置的人员才使用管理员权限。考虑到账号复用的问题建议管理员账户一人一号专人专用。很多单位会问设备能不能支持这么多账户其实多数企业级设备在本地用户管理上完全支持多账户和不同权限级别之前没做往往只是嫌麻烦。整改时可以把账户重新设计一遍再配合堡垒机做统一认证和操作审计。如果单位有堡垒机设备的本地账号可以设置为只读或者对接AAA集中认证由堡垒机系统做精细授权和操作录屏这样审计证据会比设备本地日志更加完整。5. 测评现场的一些真实经验与建议网络设备安全测评做了很多项目之后有些体会是通用的。设备配置这些技术检查项本身并不复杂真正难的是如何保证测评证据有效如何让整改方案既能满足合规要求又不影响业务可用性。5.1 测评取证时要留好证据链现场测评时配置核查的所有关键输出都建议保留截图或文本记录。截图里要能看到设备主机名和当前时间避免后续说不清是哪台设备、什么时候截的图。访谈记录、测试记录、配置备份要成套归档测评报告的风险判定、问题描述都必须能从这些原始证据里反推出来。有个细节登录设备执行核查命令时不要用修改类命令只做查看性操作。虽然测评人员在现场有访谈测试的需求但误操作导致业务受影响是绝对的红线。查看性命令和修改性命令边界一定要分清楚动作要保守遇到不熟悉的命令宁可跳过也不要盲目执行。5.2 给被测评单位的整改优先级建议如果整改时间有限建议按这个优先级走第一梯队修改默认口令、关闭Telnet、开启SSH、配置日志外发这几项都是高风险项也是测评专家比较敏感的点第二梯队配置登录失败锁定、空闲超时、密码复杂度、账户权限分级这些是标准里明确要求且容易被抽查到的点第三梯队NTP同步、SNMP升级或收紧、管理ACL限制、服务端口收敛属于提升项但很影响整体评分。整改过程中最忌讳的是大范围改设备配置而不做验证。每次变更后先在一台备用设备或非核心设备上验证命令效果再推广到核心设备。核心交换机、路由器这类设备上动配置一定要提前备份配置、准备回滚方案变更窗口尽量安排在业务低峰期。曾经有个项目运维人员在核心交换机上增加管理ACL时不小心把设备管理地址所在的网段过滤掉了结果管理断连最后靠console接入才恢复。这种事故其实完全可以避免ACL生效前先模拟计算一下源地址匹配关系或者采用逐步收紧的方式先加白名单观察一段时间再关闭其他来源。5.3 建立设备安全配置基线比测评前突击更有效根据我个人经验网络设备安全做得好的单位不是测评前突击整改出来的而是形成了一套设备安全配置基线。新设备到货、新系统上线时运维人员按基线模板完成初始配置再通过运维流程审核把关。做等保测评时只需要把存量设备和基线的差异梳理出来针对性整改即可。这套基线建议包含哪些内容可以参考前面几章里提到过的核心项账号策略、远程管理协议、审计日志、NTP、SNMP版本、管理ACL、服务端口收敛、密码复杂度与登录失败策略。每台设备上线后把配置备份存档后续测评或巡检时通过对比上次备份和当前配置能快速发现安全配置被改动或回退的情况。最后再分享一个小技巧每次整改完成后把设备的当前配置全量导出一份和整改前的配置做一次diff对比。这样既能直观看到整改覆盖了哪些检查项也能发现有没有误改的业务配置。这个方法在配合测评复核时非常实用很多想不起来改过哪里的历史遗留问题都能顺着diff记录找到线索。