拓冰网站定制 
简介《网络设备安全加固方案1.0》docx文档是一份面向网络管理员、运维及安全人员的实操型加固指南旨在解决内网设备长期存在“任意终端可Telnet登录、Con口未加密、登录过程无身份认证、命令权限未分级”等突出问题。方案围绕本地控制台身份认证、Telnet访问控制列表ACL、用户账户与权限管理、日志管理与命令分级四条主线展开并通过具体命令行示例演示user-interface con 0、set authentication password cipher、acl rule、local-user、command-privilege level以及syslog等配置方法同时强调用SSH替代Telnet降低密码嗅探与中间人攻击风险。内容直接对应真实网络设备加固场景从现状分析、解决思路到操作命令层层推进可帮助读者快速理解安全基线建设全流程并可直接作为日常设备加固与审计的参考模板文档末尾的配置片段也可供现网环境对照验证。资源包仅含1个docx文件压缩包大小约9KB便于查阅与分发。目前已有156人学习下载适合需要为内网设备快速建立访问控制与审计机制的中高级网络工程师。1. 网络设备安全加固这份方案解决的不只是 Telnet 漏洞先说结论这份《网络设备安全加固方案1.0》解决的并不是「防外部黑客」的问题而是「防内网任意终端横移」的问题。方案原文篇幅不大但把 H3C 设备上最常见的三类漏洞——Telnet 无限制访问、Con 口明文直登、用户权限不分级——逐一给出了可复现的配置命令。现状是内网任何一台终端都能 telnet 上设备敲命令等于把核心设备的控制权暴露给了全网这比外网攻击更棘手因为攻击者不需要突破边界他已经在网内了。适合谁用刚接手内网运维、设备密码还没分级管理的网络工程师或者正在准备等保整改、需要一份可落地的设备基线配置的从业者。方案不长但每个命令都能直接粘进设备。2. 三个隐患拆解为什么 Con 口加密和 Telnet ACL 必须一起做2.1 内网安全现状所有人都能登设备问题出在哪方案开头点出的现状很直白——内网所有网络设备未做登录安全限制。这里说的「安全限制」不是指设备没有密码而是指没有任何基于身份的认证和基于来源的访问控制。安全隐患可以拆成三层来看。第一层是 Telnet 明文协议本身。Telnet 的数据包在网络上以明文传输用户名和密码可以被抓包工具直接读取。第二层是没有来源限制。任何内网 IP 都能发起 Telnet 连接攻击者不需要拿到什么特殊权限只要在内网有一台终端就能直连设备。第三层是 Con 口未加密。Con 口是设备的物理控制台接口如果有人能物理接触到设备插上 console 线就能直接进入命令行连密码都不用猜。这三层隐患叠加在一起意味着设备的管理面完全裸露。方案针对这三层分别下了药Con 口加本地密码认证Telnet 走 AAA 认证加 ACL 过滤来源同时配合用户分级控制命令权限。这是一套组合拳缺一个都不完整。2.2 从物理口到虚拟口认证体系如何分层H3C 设备上用户访问设备命令行有两条路径。一条是物理的 Con 口也就是 console 口本地直连另一条是虚拟的 VTY 口也就是 telnet 或 SSH 建立的远程会话。这两条路径的认证方式是独立配置的这也是方案里分开处理的根本原因。Con 口的配置逻辑很简单user-interface con 0 authentication-mode password user privilege level 15 set authentication password cipher *******逻辑说明先进入 con 0 接口视图把认证模式设置为密码认证然后给这个接口设置一个加密存储的密码。user privilege level 15表示通过 Con 口登录的用户默认拥有最高权限级别。参数说明con 0是固定编号一台设备只有一个物理控制台口。cipher关键字表示密码以密文形式存储在配置文件中而不是明文。需要注意即使配了密码Con 口默认的权限级别也建议显式指定否则不同型号默认值可能不同。VTY 口的配置则复杂一些因为要同时处理认证方式、来源限制和权限级别三个维度user-interface vty 0 4 authentication-mode aaa acl 2000 inbound user privilege level 15逻辑说明vty 0 4表示同时配置 5 个虚拟终端接口编号 0 到 4对应 5 个并发的 Telnet 会话。认证模式设为 AAA意味着用户名密码校验交给 AAA 模块处理而不是固定的本地密码。acl 2000 inbound在入方向上应用 ACL只允许 ACL 中匹配的源 IP 建立 Telnet 连接。user privilege level 15是默认权限如果启用了 AAA 认证实际权限以 AAA 下发的权限为准。参数说明如果设备同时有 Telnet 和 SSH 需求vty 0 4是共用的。也就是说ACL 2000 同时过滤 Telnet 和 SSH 的接入来源。2.3 AAA 与本地用户认证和授权为什么要分开管方案里创建了三个用户admin、jsftp、jssipo。这个设计值得仔细看它体现了权限分级的思想。aaa local-user admin password cipher ******* local-user admin privilege level 15 local-user admin service-type telnet local-user jsftp password cipher ******* local-user jsftp privilege level 15 local-user jsftp ftp-directory flash:/syslogfile/ local-user jsftp service-type ftp local-user jssipo password cipher ******* local-user jssipo privilege level 1 local-user jssipo service-type telnet逻辑说明AAA 是认证、授权、计费三个英文单词的缩写。这里用的是本地认证也就是用户名密码存放在设备本地。每个用户通过local-user命令创建然后分别指定密码、权限级别和服务类型。参数说明privilege level是权限级别的核心参数范围是 0 到 15。级别 15 是最高权限能执行所有命令级别 1 只能执行基本查询命令。service-type限制了用户能使用的服务类型admin 只能用 Telnetjsftp 只能用 FTPjssipo 只能用 Telnet。这个设计把 FTP 和 Telnet 的用户体系拆开了避免一个账号同时暴露多条攻击路径。这里有一个容易被忽略的细节jsftp 的权限级别虽然也是 15但它只能走 FTP 且目录被限制在flash:/syslogfile/。这意味着即使账号泄露攻击者也只拿到一个被限制在日志目录下的 FTP 权限无法通过 FTP 上传文件到系统目录。另一个值得注意的点是 command-privilege 的配置command-privilege level 1 view shell display current-configuration command-privilege level 1 view shell display environment逻辑说明这两条命令把display current-configuration和display environment两个查看命令的权限降到了级别 1。默认情况下级别 1 的用户看不到当前配置和设备的运行环境信息这属于敏感信息。降权之后低权限用户比如 jssipo也能查看这些内容。参数说明view shell指的是 shell 视图下的命令。如果低权限用户被分配了查看配置的需求或者运维团队需要让一线人员查状态但不改配置这个配置就能派上用场。3. 配置落地全流程从 Con 口到 Telnet ACL 的完整操作3.1 配置前的准备明确管理网段和设备角色在动手敲命令之前务必先做一件关键的事情梳理哪些终端需要管理设备。方案里的 ACL 规则很典型只放行了三个特定 IP10.85.59.31、10.85.39.10、10.85.60.137。实际落地的思路是按照「管理终端清单」来规划。我的习惯是先画一张表。这台设备由谁管他的办公 IP 是什么备用管理终端是哪台有没有跳板机需要放行。把这些信息整理成一张表再转成 ACL 规则才不容易漏放或错放。终端角色IP 地址ACL 规则运维主终端10.85.59.31rule 5 permit运维备终端10.85.39.10rule 10 permit管理跳板机10.85.60.137rule 5 permitACL 2000其他终端任意rule 15 deny需要注意方案里出现了两个 ACLACL 2001 和 ACL 2000。从配置内容判断ACL 2001 用于控制 FTP 访问ACL 2000 用于控制 Telnet 访问两者独立生效。3.2 分步配置控制台加密、ACL 规则、VTY 调用进入系统视图后先处理 FTP 服务器的来源限制system-view ftp server enable ftp acl 2001逻辑说明ftp server enable打开设备的 FTP 服务。ftp acl 2001给 FTP 服务绑定 ACL 2001只有 ACL 里允许的源 IP 能访问 FTP。这里是先绑 ACL 再配置 ACL 规则还是先配 ACL 再绑操作顺序不影响结果但建议先创建 ACL再绑定服务避免设备在配置间隙暴露 FTP 服务。参数说明如果不需要 FTP 功能可以直接不执行ftp server enable整体减少暴露面。但方案里特意配置了 FTP一般是为了让运维人员能往flash:/syslogfile/目录上传或下载日志文件。接着创建 ACLacl number 2000 rule 5 permit source 10.85.60.137 0 rule 10 permit source 10.85.39.10 0 rule 15 deny逻辑说明ACL 2000 放行了两个管理终端的 IP最后一条rule 15 deny拒绝所有其他来源。这里deny没有跟source参数表示默认拒绝一切未匹配的流量。ACL 的逻辑是从上到下逐条匹配rule 5、rule 10命中后立即放行不再往下匹配所有 IP 都没命中最后被rule 15拒绝。参数说明source 10.85.60.137 0中的0是通配符掩码等价于 255.255.255.255表示精确匹配这个 IP。如果要放行一个网段比如 10.85.60.0 网段写法是source 10.85.60.0 0.0.0.255。ACL 2001 的配置逻辑相同放行 10.85.59.31 和 10.85.39.10acl number 2001 rule 5 permit source 10.85.59.31 0 rule 10 permit source 10.85.39.10 0 rule 15 deny逻辑说明ACL 2001 用于 FTP 控制对比 ACL 2000 的放行列表FTP 额外放行了 10.85.59.31但没有放行 10.85.60.137。这说明在方案的设计语境里这台 FTP 只对特定运维人员开放另一个人只被允许 Telnet。然后在用户接口下调用 ACLuser-interface vty 0 acl 2000 inbound authentication-mode aaa user privilege level 15逻辑说明注意这里单独配置了vty 0而不是vty 0 4。在 H3C 设备上vty 0和vty 1 4可以分别配置不同的认证方式。方案的做法是第一个 VTY 口走 ACL 2000 加 AAA 认证其余四个 VTY 口走 AAA 认证但不加 ACL。这样做的实际效果是主管理终端走第一个虚拟终端其他终端虽然能听到 Telnet 端口但会被 ACL 挡住。参数说明inbound方向表示过滤进入设备的 Telnet 流量。如果在没有配置acl前先开启了authentication-mode aaa那么在 ACL 和用户配置完成前设备会短暂处于「仅靠 AAA 认证但无来源限制」的状态风险窗口虽然短但对安全整改来说不够严谨。用户口的认证方式配置完整后验证 Telnet 登录是否正常工作。验证方式不复杂在放行清单内的终端上执行 telnet 命令对照下方表格确认行为测试内容预期行为放行 IP 的终端 telnet 设备弹出用户名密码提示认证通过后进入命令行非放行 IP 的终端 telnet 设备连接被拒绝不出现登录提示未配置密码的用户尝试登录认证失败提示密码错误3.3 配置固化确认后必须保存H3C 设备上配置修改后如果不保存重启后所有改动会丢失。这是新手最容易踩的坑。save force逻辑说明save命令将当前运行配置写入下次启动配置文件。force参数跳过交互确认直接覆盖保存。在整改测试阶段建议先不执行save force等所有功能验证通过后再固化。参数说明save不加force时会询问是否覆盖现有配置文件输入 Y 确认即可。对于关键设备我习惯先display current-configuration确认配置没有遗漏然后再保存。4. 加固方案避坑清单这些坑我踩过的希望你别踩4.1 坑一ACL 规则没刷新运维自己先被锁在门外现象ACL 配置完成后运维自己的终端 Telnet 设备失败连接直接被拒绝。原因ACL 规则是倒序检查的配置时先写了 permit 规则、再写 deny 规则还好如果先写了 deny 再写 permit后面的 permit 永远不会被匹配因为 deny 已经把所有流量都拦住了。另一个常见原因是 IP 写错比如把 10.85.60.137 写成了 10.85.60.137 0.0.0.0导致精确匹配失败。解决在任何 ACL 修改前先检查自己终端当前的出口 IP。修改 ACL 时先添加 permit 规则测试连接正常后再添加 deny 规则。如果已经被锁在外面有两个后悔药用 Con 口本地登录设备删除或修改 ACL或者让管理跳板机先放行。4.2 坑二Con 口密码设了但用户权限没限制现象设置authentication-mode password后任何拿到 Con 口密码的人都能直接进入系统不需要用户名而且默认拿到最高权限。原因Con 口密码认证模式下设备只校验密码、不校验身份更不存在多用户体系。密码本身只是一个门槛门槛后面所有用户共享同一权限。解决建议把 Con 口的认证模式改成分级管控。如果设备不支持 Con 口走 AAA至少要把user privilege level 15这一条去掉或降级避免默认满权限。物理安全也很重要——Con 口是本地接口如果有人能物理接触设备密码再复杂也防不住暴力重置。4.3 坑三Telnet 口令在网络里裸奔抓包工具直接能看到现象配置了 AAA 和 ACL 后用 Wireshark 抓包仍然能看到 Telnet 会话里的明文密码。原因这是 Telnet 协议本身的设计缺陷不是配置问题。ACL 和 AAA 解决的是「谁能登」和「怎么验身份」不解决「传输过程是否加密」。即使所有安全策略都配到位Telnet 的流量仍然以明文形式在二层网络中传输。解决判断网络是否具备升级到 SSH 的条件逐步用 SSH 替代 Telnet。H3C 设备通常支持 SSH 服务配置方式是在 VTY 接口下新增protocol inbound ssh同时在 AAA 用户下添加service-type ssh。在 SSH 全面启用之前尽量避免在 Telnet 会话中输入高权限账号的密码。4.4 坑四账号权限不收敛低权限账号自带了查看配置的能力现象按方案配置了 jssipo 的 privilege level 1但通过该账号登录后仍能执行display current-configuration。原因H3C 设备上display current-configuration这类查看命令的权限级别低于 1默认情况下 level 1 的用户就可以执行。也就是说如果只设置权限级别不修改命令本身的权限低权限账号实际可用的命令比预想的多。解决方案里已经带了针对这个问题的答案——command-privilege level 1 view shell display current-configuration。这条命令把查看配置的操作降权到 level 1于是 jssipo 这类 level 1 用户就能看到配置。注意这样改完之后level 0 的用户仍然看不到配置相当于给只读用户开了个窗口。如果不需要让低权限用户看配置就不要加这条命令。4.5 坑五认证模式混用导致用户登录不了现象VTY 口配置了authentication-mode aaa但 Telnet 登录时提示认证失败即使输入了正确的用户名密码。原因AAA 认证模式下设备只会校验 AAA 模块里定义的用户。如果设备的 AAA 视图里没有配置任何 local-user或者 local-user 的service-type没有包含telnet那么认证必然失败。还有一种情况是设备上配置了多个认证方案本地认证优先级低于远端认证导致本地用户被跳过。解决检查 AAA 视图下的authentication-scheme确认默认方案使用的是local认证。然后核对 local-user 里的service-type是否包含telnet。admin 用户的 service-type 是 telnet但如果想用同一个用户名走 SSH必须把 service-type 加上 ssh。5. 升级方向从 Telnet 加固到 SSH 替代的渐进式改造5.1 手动加固做完以后下一步要做什么方案 1.0 的核心是「让不该进来的人进不来」解决的是内网横向攻击路径的问题。但 Telnet 本身是明文协议这意味着即使 ACL 和 AAA 全部到位会话中的数据仍然可以被抓包分析。更合理的演进路径是在保留 ACL 和 AAA 的基础上把远程管理协议从 Telnet 切到 SSH。H3C 设备上启用 SSH 并不复杂核心步骤如下rsa local-key-pair create ssh server enable user-interface vty 0 4 protocol inbound ssh authentication-mode aaa逻辑说明首先生成设备的 RSA 密钥对这是 SSH 服务开启的前提。ssh server enable打开 SSH 服务。VTY 接口下protocol inbound ssh限制只能通过 SSH 建立远程会话Telnet 直接失效。AAA 认证方式不变继续复用本地用户体系。参数说明rsa local-key-pair create执行后会要求输入密钥长度通常选 2048 位。生成密钥后可以display rsa local-key-pair public查看公钥信息用于客户端指纹校验。切换 SSH 之后之前所有 Telnet 相关的安全隐患就不存在了ACL 和 AAA 继续保留。如果还需要临时开启 Telnet 做紧急排障可以临时改protocol inbound all但排障完必须切回。5.2 批量设备加固操作命令与注意事项如果内网设备数量多逐台登录配置会明显拉长整改周期。这个场景下可以先在一台设备上把配置跑通导出配置文件作为基线再通过批量运维工具统一下发。常见的做法是先在这台设备上执行display current-configuration导出完整配置剥离设备专属信息设备名、管理 IP、ACL 里的放行 IP保留 ACL 模板、AAA 配置、VTY 配置和 Con 口加密配置这几段做成标准化配置段。下发时每台设备只需要替换管理 IP 和 ACL 放行 IP。注意每台设备的 VTY 编号数量未必完全一致下发前先确认。习惯是先将批量模板在一台测试设备上跑一次确认无报错后再扩大到其余设备避免批量翻车。从那以后我每次做设备加固都强制自己把「Con 口加密 VTY 的 ACL AAA 用户 命令权限收敛」这四件套完整走一遍而不是只处理其中一项。这套做法不一定是最短的路径但能覆盖掉我踩过的所有坑希望帮到你。本文还有配套的精品资源点击获取 H3C网络设备安全加固：Telnet漏洞、Con口加密与权限分级实战
简介《网络设备安全加固方案1.0》docx文档是一份面向网络管理员、运维及安全人员的实操型加固指南旨在解决内网设备长期存在“任意终端可Telnet登录、Con口未加密、登录过程无身份认证、命令权限未分级”等突出问题。方案围绕本地控制台身份认证、Telnet访问控制列表ACL、用户账户与权限管理、日志管理与命令分级四条主线展开并通过具体命令行示例演示user-interface con 0、set authentication password cipher、acl rule、local-user、command-privilege level以及syslog等配置方法同时强调用SSH替代Telnet降低密码嗅探与中间人攻击风险。内容直接对应真实网络设备加固场景从现状分析、解决思路到操作命令层层推进可帮助读者快速理解安全基线建设全流程并可直接作为日常设备加固与审计的参考模板文档末尾的配置片段也可供现网环境对照验证。资源包仅含1个docx文件压缩包大小约9KB便于查阅与分发。目前已有156人学习下载适合需要为内网设备快速建立访问控制与审计机制的中高级网络工程师。1. 网络设备安全加固这份方案解决的不只是 Telnet 漏洞先说结论这份《网络设备安全加固方案1.0》解决的并不是「防外部黑客」的问题而是「防内网任意终端横移」的问题。方案原文篇幅不大但把 H3C 设备上最常见的三类漏洞——Telnet 无限制访问、Con 口明文直登、用户权限不分级——逐一给出了可复现的配置命令。现状是内网任何一台终端都能 telnet 上设备敲命令等于把核心设备的控制权暴露给了全网这比外网攻击更棘手因为攻击者不需要突破边界他已经在网内了。适合谁用刚接手内网运维、设备密码还没分级管理的网络工程师或者正在准备等保整改、需要一份可落地的设备基线配置的从业者。方案不长但每个命令都能直接粘进设备。2. 三个隐患拆解为什么 Con 口加密和 Telnet ACL 必须一起做2.1 内网安全现状所有人都能登设备问题出在哪方案开头点出的现状很直白——内网所有网络设备未做登录安全限制。这里说的「安全限制」不是指设备没有密码而是指没有任何基于身份的认证和基于来源的访问控制。安全隐患可以拆成三层来看。第一层是 Telnet 明文协议本身。Telnet 的数据包在网络上以明文传输用户名和密码可以被抓包工具直接读取。第二层是没有来源限制。任何内网 IP 都能发起 Telnet 连接攻击者不需要拿到什么特殊权限只要在内网有一台终端就能直连设备。第三层是 Con 口未加密。Con 口是设备的物理控制台接口如果有人能物理接触到设备插上 console 线就能直接进入命令行连密码都不用猜。这三层隐患叠加在一起意味着设备的管理面完全裸露。方案针对这三层分别下了药Con 口加本地密码认证Telnet 走 AAA 认证加 ACL 过滤来源同时配合用户分级控制命令权限。这是一套组合拳缺一个都不完整。2.2 从物理口到虚拟口认证体系如何分层H3C 设备上用户访问设备命令行有两条路径。一条是物理的 Con 口也就是 console 口本地直连另一条是虚拟的 VTY 口也就是 telnet 或 SSH 建立的远程会话。这两条路径的认证方式是独立配置的这也是方案里分开处理的根本原因。Con 口的配置逻辑很简单user-interface con 0 authentication-mode password user privilege level 15 set authentication password cipher *******逻辑说明先进入 con 0 接口视图把认证模式设置为密码认证然后给这个接口设置一个加密存储的密码。user privilege level 15表示通过 Con 口登录的用户默认拥有最高权限级别。参数说明con 0是固定编号一台设备只有一个物理控制台口。cipher关键字表示密码以密文形式存储在配置文件中而不是明文。需要注意即使配了密码Con 口默认的权限级别也建议显式指定否则不同型号默认值可能不同。VTY 口的配置则复杂一些因为要同时处理认证方式、来源限制和权限级别三个维度user-interface vty 0 4 authentication-mode aaa acl 2000 inbound user privilege level 15逻辑说明vty 0 4表示同时配置 5 个虚拟终端接口编号 0 到 4对应 5 个并发的 Telnet 会话。认证模式设为 AAA意味着用户名密码校验交给 AAA 模块处理而不是固定的本地密码。acl 2000 inbound在入方向上应用 ACL只允许 ACL 中匹配的源 IP 建立 Telnet 连接。user privilege level 15是默认权限如果启用了 AAA 认证实际权限以 AAA 下发的权限为准。参数说明如果设备同时有 Telnet 和 SSH 需求vty 0 4是共用的。也就是说ACL 2000 同时过滤 Telnet 和 SSH 的接入来源。2.3 AAA 与本地用户认证和授权为什么要分开管方案里创建了三个用户admin、jsftp、jssipo。这个设计值得仔细看它体现了权限分级的思想。aaa local-user admin password cipher ******* local-user admin privilege level 15 local-user admin service-type telnet local-user jsftp password cipher ******* local-user jsftp privilege level 15 local-user jsftp ftp-directory flash:/syslogfile/ local-user jsftp service-type ftp local-user jssipo password cipher ******* local-user jssipo privilege level 1 local-user jssipo service-type telnet逻辑说明AAA 是认证、授权、计费三个英文单词的缩写。这里用的是本地认证也就是用户名密码存放在设备本地。每个用户通过local-user命令创建然后分别指定密码、权限级别和服务类型。参数说明privilege level是权限级别的核心参数范围是 0 到 15。级别 15 是最高权限能执行所有命令级别 1 只能执行基本查询命令。service-type限制了用户能使用的服务类型admin 只能用 Telnetjsftp 只能用 FTPjssipo 只能用 Telnet。这个设计把 FTP 和 Telnet 的用户体系拆开了避免一个账号同时暴露多条攻击路径。这里有一个容易被忽略的细节jsftp 的权限级别虽然也是 15但它只能走 FTP 且目录被限制在flash:/syslogfile/。这意味着即使账号泄露攻击者也只拿到一个被限制在日志目录下的 FTP 权限无法通过 FTP 上传文件到系统目录。另一个值得注意的点是 command-privilege 的配置command-privilege level 1 view shell display current-configuration command-privilege level 1 view shell display environment逻辑说明这两条命令把display current-configuration和display environment两个查看命令的权限降到了级别 1。默认情况下级别 1 的用户看不到当前配置和设备的运行环境信息这属于敏感信息。降权之后低权限用户比如 jssipo也能查看这些内容。参数说明view shell指的是 shell 视图下的命令。如果低权限用户被分配了查看配置的需求或者运维团队需要让一线人员查状态但不改配置这个配置就能派上用场。3. 配置落地全流程从 Con 口到 Telnet ACL 的完整操作3.1 配置前的准备明确管理网段和设备角色在动手敲命令之前务必先做一件关键的事情梳理哪些终端需要管理设备。方案里的 ACL 规则很典型只放行了三个特定 IP10.85.59.31、10.85.39.10、10.85.60.137。实际落地的思路是按照「管理终端清单」来规划。我的习惯是先画一张表。这台设备由谁管他的办公 IP 是什么备用管理终端是哪台有没有跳板机需要放行。把这些信息整理成一张表再转成 ACL 规则才不容易漏放或错放。终端角色IP 地址ACL 规则运维主终端10.85.59.31rule 5 permit运维备终端10.85.39.10rule 10 permit管理跳板机10.85.60.137rule 5 permitACL 2000其他终端任意rule 15 deny需要注意方案里出现了两个 ACLACL 2001 和 ACL 2000。从配置内容判断ACL 2001 用于控制 FTP 访问ACL 2000 用于控制 Telnet 访问两者独立生效。3.2 分步配置控制台加密、ACL 规则、VTY 调用进入系统视图后先处理 FTP 服务器的来源限制system-view ftp server enable ftp acl 2001逻辑说明ftp server enable打开设备的 FTP 服务。ftp acl 2001给 FTP 服务绑定 ACL 2001只有 ACL 里允许的源 IP 能访问 FTP。这里是先绑 ACL 再配置 ACL 规则还是先配 ACL 再绑操作顺序不影响结果但建议先创建 ACL再绑定服务避免设备在配置间隙暴露 FTP 服务。参数说明如果不需要 FTP 功能可以直接不执行ftp server enable整体减少暴露面。但方案里特意配置了 FTP一般是为了让运维人员能往flash:/syslogfile/目录上传或下载日志文件。接着创建 ACLacl number 2000 rule 5 permit source 10.85.60.137 0 rule 10 permit source 10.85.39.10 0 rule 15 deny逻辑说明ACL 2000 放行了两个管理终端的 IP最后一条rule 15 deny拒绝所有其他来源。这里deny没有跟source参数表示默认拒绝一切未匹配的流量。ACL 的逻辑是从上到下逐条匹配rule 5、rule 10命中后立即放行不再往下匹配所有 IP 都没命中最后被rule 15拒绝。参数说明source 10.85.60.137 0中的0是通配符掩码等价于 255.255.255.255表示精确匹配这个 IP。如果要放行一个网段比如 10.85.60.0 网段写法是source 10.85.60.0 0.0.0.255。ACL 2001 的配置逻辑相同放行 10.85.59.31 和 10.85.39.10acl number 2001 rule 5 permit source 10.85.59.31 0 rule 10 permit source 10.85.39.10 0 rule 15 deny逻辑说明ACL 2001 用于 FTP 控制对比 ACL 2000 的放行列表FTP 额外放行了 10.85.59.31但没有放行 10.85.60.137。这说明在方案的设计语境里这台 FTP 只对特定运维人员开放另一个人只被允许 Telnet。然后在用户接口下调用 ACLuser-interface vty 0 acl 2000 inbound authentication-mode aaa user privilege level 15逻辑说明注意这里单独配置了vty 0而不是vty 0 4。在 H3C 设备上vty 0和vty 1 4可以分别配置不同的认证方式。方案的做法是第一个 VTY 口走 ACL 2000 加 AAA 认证其余四个 VTY 口走 AAA 认证但不加 ACL。这样做的实际效果是主管理终端走第一个虚拟终端其他终端虽然能听到 Telnet 端口但会被 ACL 挡住。参数说明inbound方向表示过滤进入设备的 Telnet 流量。如果在没有配置acl前先开启了authentication-mode aaa那么在 ACL 和用户配置完成前设备会短暂处于「仅靠 AAA 认证但无来源限制」的状态风险窗口虽然短但对安全整改来说不够严谨。用户口的认证方式配置完整后验证 Telnet 登录是否正常工作。验证方式不复杂在放行清单内的终端上执行 telnet 命令对照下方表格确认行为测试内容预期行为放行 IP 的终端 telnet 设备弹出用户名密码提示认证通过后进入命令行非放行 IP 的终端 telnet 设备连接被拒绝不出现登录提示未配置密码的用户尝试登录认证失败提示密码错误3.3 配置固化确认后必须保存H3C 设备上配置修改后如果不保存重启后所有改动会丢失。这是新手最容易踩的坑。save force逻辑说明save命令将当前运行配置写入下次启动配置文件。force参数跳过交互确认直接覆盖保存。在整改测试阶段建议先不执行save force等所有功能验证通过后再固化。参数说明save不加force时会询问是否覆盖现有配置文件输入 Y 确认即可。对于关键设备我习惯先display current-configuration确认配置没有遗漏然后再保存。4. 加固方案避坑清单这些坑我踩过的希望你别踩4.1 坑一ACL 规则没刷新运维自己先被锁在门外现象ACL 配置完成后运维自己的终端 Telnet 设备失败连接直接被拒绝。原因ACL 规则是倒序检查的配置时先写了 permit 规则、再写 deny 规则还好如果先写了 deny 再写 permit后面的 permit 永远不会被匹配因为 deny 已经把所有流量都拦住了。另一个常见原因是 IP 写错比如把 10.85.60.137 写成了 10.85.60.137 0.0.0.0导致精确匹配失败。解决在任何 ACL 修改前先检查自己终端当前的出口 IP。修改 ACL 时先添加 permit 规则测试连接正常后再添加 deny 规则。如果已经被锁在外面有两个后悔药用 Con 口本地登录设备删除或修改 ACL或者让管理跳板机先放行。4.2 坑二Con 口密码设了但用户权限没限制现象设置authentication-mode password后任何拿到 Con 口密码的人都能直接进入系统不需要用户名而且默认拿到最高权限。原因Con 口密码认证模式下设备只校验密码、不校验身份更不存在多用户体系。密码本身只是一个门槛门槛后面所有用户共享同一权限。解决建议把 Con 口的认证模式改成分级管控。如果设备不支持 Con 口走 AAA至少要把user privilege level 15这一条去掉或降级避免默认满权限。物理安全也很重要——Con 口是本地接口如果有人能物理接触设备密码再复杂也防不住暴力重置。4.3 坑三Telnet 口令在网络里裸奔抓包工具直接能看到现象配置了 AAA 和 ACL 后用 Wireshark 抓包仍然能看到 Telnet 会话里的明文密码。原因这是 Telnet 协议本身的设计缺陷不是配置问题。ACL 和 AAA 解决的是「谁能登」和「怎么验身份」不解决「传输过程是否加密」。即使所有安全策略都配到位Telnet 的流量仍然以明文形式在二层网络中传输。解决判断网络是否具备升级到 SSH 的条件逐步用 SSH 替代 Telnet。H3C 设备通常支持 SSH 服务配置方式是在 VTY 接口下新增protocol inbound ssh同时在 AAA 用户下添加service-type ssh。在 SSH 全面启用之前尽量避免在 Telnet 会话中输入高权限账号的密码。4.4 坑四账号权限不收敛低权限账号自带了查看配置的能力现象按方案配置了 jssipo 的 privilege level 1但通过该账号登录后仍能执行display current-configuration。原因H3C 设备上display current-configuration这类查看命令的权限级别低于 1默认情况下 level 1 的用户就可以执行。也就是说如果只设置权限级别不修改命令本身的权限低权限账号实际可用的命令比预想的多。解决方案里已经带了针对这个问题的答案——command-privilege level 1 view shell display current-configuration。这条命令把查看配置的操作降权到 level 1于是 jssipo 这类 level 1 用户就能看到配置。注意这样改完之后level 0 的用户仍然看不到配置相当于给只读用户开了个窗口。如果不需要让低权限用户看配置就不要加这条命令。4.5 坑五认证模式混用导致用户登录不了现象VTY 口配置了authentication-mode aaa但 Telnet 登录时提示认证失败即使输入了正确的用户名密码。原因AAA 认证模式下设备只会校验 AAA 模块里定义的用户。如果设备的 AAA 视图里没有配置任何 local-user或者 local-user 的service-type没有包含telnet那么认证必然失败。还有一种情况是设备上配置了多个认证方案本地认证优先级低于远端认证导致本地用户被跳过。解决检查 AAA 视图下的authentication-scheme确认默认方案使用的是local认证。然后核对 local-user 里的service-type是否包含telnet。admin 用户的 service-type 是 telnet但如果想用同一个用户名走 SSH必须把 service-type 加上 ssh。5. 升级方向从 Telnet 加固到 SSH 替代的渐进式改造5.1 手动加固做完以后下一步要做什么方案 1.0 的核心是「让不该进来的人进不来」解决的是内网横向攻击路径的问题。但 Telnet 本身是明文协议这意味着即使 ACL 和 AAA 全部到位会话中的数据仍然可以被抓包分析。更合理的演进路径是在保留 ACL 和 AAA 的基础上把远程管理协议从 Telnet 切到 SSH。H3C 设备上启用 SSH 并不复杂核心步骤如下rsa local-key-pair create ssh server enable user-interface vty 0 4 protocol inbound ssh authentication-mode aaa逻辑说明首先生成设备的 RSA 密钥对这是 SSH 服务开启的前提。ssh server enable打开 SSH 服务。VTY 接口下protocol inbound ssh限制只能通过 SSH 建立远程会话Telnet 直接失效。AAA 认证方式不变继续复用本地用户体系。参数说明rsa local-key-pair create执行后会要求输入密钥长度通常选 2048 位。生成密钥后可以display rsa local-key-pair public查看公钥信息用于客户端指纹校验。切换 SSH 之后之前所有 Telnet 相关的安全隐患就不存在了ACL 和 AAA 继续保留。如果还需要临时开启 Telnet 做紧急排障可以临时改protocol inbound all但排障完必须切回。5.2 批量设备加固操作命令与注意事项如果内网设备数量多逐台登录配置会明显拉长整改周期。这个场景下可以先在一台设备上把配置跑通导出配置文件作为基线再通过批量运维工具统一下发。常见的做法是先在这台设备上执行display current-configuration导出完整配置剥离设备专属信息设备名、管理 IP、ACL 里的放行 IP保留 ACL 模板、AAA 配置、VTY 配置和 Con 口加密配置这几段做成标准化配置段。下发时每台设备只需要替换管理 IP 和 ACL 放行 IP。注意每台设备的 VTY 编号数量未必完全一致下发前先确认。习惯是先将批量模板在一台测试设备上跑一次确认无报错后再扩大到其余设备避免批量翻车。从那以后我每次做设备加固都强制自己把「Con 口加密 VTY 的 ACL AAA 用户 命令权限收敛」这四件套完整走一遍而不是只处理其中一项。这套做法不一定是最短的路径但能覆盖掉我踩过的所有坑希望帮到你。本文还有配套的精品资源点击获取