简介《网络设备安全加固方案1.0版》是一份面向网络管理员与运维工程师的Word文档针对内网设备缺乏登录限制、Con口未加密、任意终端可telnet等隐患给出从现状分析到安全加固的完整落地思路。资源仅1个Word文件压缩包大小约9KB内容精炼便于快速查阅和参照配置。目前已有156人学习下载。方案核心包括通过控制台接口配合加密密码实现本地登录身份认证借助访问控制列表限制telnet登录来源确保只有明确许可的终端才能接入通过本地用户创建与分级权限设置实现账户管理和最小权限原则同时推荐使用SSH替代telnet并借助系统日志与命令权限控制强化审计与防误操作。读者可直接依据其中的操作命令对照设备逐条实施既能快速弥补基础安全短板也能为后续网络设备合规加固提供可复用的执行框架。1. 网络设备安全加固方案先从一份文档说到它背后要落地的动作拿到《网络设备安全加固方案1.0.docx》这类文档时最常见的处理方式是把几十页的风险描述、整改清单和配置模板读完标记“已阅”然后不知道下一步该敲什么命令。实际上这份文档真正值钱的不是“方案”两个字而是背后的一批可执行动作哪些设备先动、哪些服务先关、哪些端口要收敛、账号和日志怎么管。这篇就来拆解这些动作。读者如果是网络运维工程师、等保整改执行者或者刚接手一批设备想系统做一遍安全加固的同学可以照着这篇的思路把文档变成命令、脚本和可验证的结果。2. 加固对象与优先级先看清四个风险面再动手2.1 网络设备风险面拆解管理面、协议面、服务面、运维面设备安全加固不能“拿着文档逐条套”要先搞清楚设备的攻击面到底在哪。我一般把它拆成四个面来看。管理面是指登录设备和操作设备的所有通道。Telnet明文传输、SSH未启用的老设备、Web管理接口直接暴露在业务网、默认口令没改、闲置账号没删都属于管理面问题。攻击者抓包看Telnet流量能直接拿到口令这是最容易被利用的短板。很多设备默认还开着HTTP的Web管理页面这类页面往往带着历史漏洞扫描器扫到管理端口基本一打一个准。协议面指设备上运行的各种网络协议路由协议、SNMP、NTP、LLDP都算。常见问题包括OSPF或BGP没启用邻居认证、SNMP还在用v1或v2c团体字、NTP没做认证导致系统时间可被篡改。时间被改的隐患很隐蔽日志审计的时序对不上取证时非常被动。路由协议不发认证的风险更直接——攻击者可以在链路上伪造邻居把流量引到自己的设备上做中间人这个面平时看不见出了事才觉得它像个黑匣子。服务面指设备上默认开放的各种服务TFTP、FTP、HTTP、DNS小服务、不必要的SNMP端口。这些服务平时没人用却占着监听端口成为扫描器眼中的攻击面。很多设备出厂默认开了一堆服务加固方案的很大一部分工作就是把这些监听端口一个个关掉。运维面最容易被忽略。账号权限没有分级、审计日志不往syslog送、配置变更没有记录、备份策略缺失这些都是运维面的问题。四类风险面不是孤立的管理面漏洞是最常用的入口协议面和服务面的问题则是后续横向移动的跳板运维面缺失导致你根本说不清设备被改过什么。2.2 加固优先级按“可被利用的入口”排序优先级排序我一般按“攻击者最容易摸到的入口”来排而不是按文档里风险条目的编号顺序。第一优先级是管理面的远程访问通道。Telnet能关就关SSH能开就开管理口能用ACL限制来源就用ACL限制。原因是这个面直接暴露在网络上不需要先攻破其他环节就能尝试登录。第二优先级是SNMP和路由协议认证。SNMP v2c的团体字符串在链路上就是明文抓包直接能看到改成v3需要网管平台配合所以要在方案里预留过渡期。第三优先级才是关服务、收端口。第四优先级是账号和日志这部分工作量大、见效慢但决定了后面能不能追溯。举个例子一台接入交换机如果同时开着Telnet和SNMP v2c而管理网段又跟业务网段没有隔离那加固方案里最该先做的事就是把Telnet换成SSH、给SNMP换版本而不是先去调什么转发参数。顺序反了可能出现“折腾半天最危险的口子还开着”的情况。2.3 参考基准确认等保2.0与CIS基准怎么选动手前先定基准不然加固项写到一半会开始纠结“到底加固到什么程度算合格”。常见的做法是参考等保2.0通用安全要求里关于网络设备的部分再叠加厂商发布的CIS Benchmarks。等保给出的是合规骨架CIS给出的是具体到某条配置命令的检查项。我给设备做加固时会把每个加固项写成三行现状是什么、期望是什么、用什么命令验证。例如“现状VTY支持Telnet期望仅支持SSH验证display user-interface vty 0 4”。这样写的好处是执行完不用猜有没有生效。方案文档里如果只写了“加强远程管理安全”这种话落地时基本没法验收。3. 设备级加固落地交换机、防火墙、Nginx 的分场景配置3.1 交换机与路由器SSH替代Telnet、ACL收紧与SNMP v3交换机是数量最多、最容易漏配的一类设备。下面这组配置以华为Comware风格为例Cisco设备把protocol inbound ssh换成transport input ssh即可。先关Telnet、开SSH# 关闭Telnet启用SSH undo telnet server enable ssh server enable ssh server authentication-type password # 只允许管理网段访问设备 acl number 2001 rule 5 permit source 192.168.10.0 0.0.0.255 rule 10 deny # VTY只能走SSH且来源被ACL限制 user-interface vty 0 4 acl 2001 inbound protocol inbound ssh idle-timeout 10 0逻辑说明undo telnet server enable直接关掉Telnet监听端口ssh server enable开启SSH服务。ACL 2001里先写permit放行管理网段再写deny拒绝其他来源顺序不能反——华为ACL匹配到第一条就停止如果deny写在前面管理网段也会被拦掉。user-interface vty 0 4下的protocol inbound ssh限定远程登录只能走SSHidle-timeout 10 0是10分钟无操作自动断开。参数说明192.168.10.0 0.0.0.255是华为风格的反掩码写法等价于/24。Cisco设备需要把protocol inbound ssh改成transport input ssh。这里要特别提醒如果你的管理网段不是192.168.10.0/24ACL里的permit条目必须改成你实际能登录的那个网段否则命令敲完当前会话直接断掉而且重连不上。SNMP部分从v2c切换到v3# 只启用SNMP v3 snmp-agent sys-info version v3 snmp-agent group v3 grp_privacy privacy snmp-agent usm-user v3 snmp_user grp_privacy snmp-agent usm-user v3 snmp_user authentication-mode sha snmp-agent usm-user v3 snmp_user privacy-mode aes256逻辑说明group v3 grp_privacy privacy定义了一个带加密权限的组usm-user v3 snmp_user创建用户并绑定到该组。认证方式用SHA加密用AES256这样在链路上抓包只能看到密文。参数说明privacy关键字决定这个组是否启用加密没有它就只能认证不能加密。网管平台侧要同步把读团体字改成v3用户和密码否则平台会失联。账号策略同样要动。默认的admin账号如果还在用弱口令加固方案等同没做# 修改管理账号口令并限定用途 local-user admin class manage password cipher 加密后的口令 service-type ssh authorization-attribute user-role network-admin逻辑说明password cipher后面的字符串在脚本里应该填设备生成的密文而不是明文。直接把明文口令写进命令会留在命令行历史里这是个很容易被忽略的泄露点。service-type ssh限定了这个账号只能通过SSH登录user-role network-admin给的是管理权限。如果只给监控用途可以建一个network-operator只读账号。3.2 防火墙管理接口隔离与区域策略最小化防火墙是安全设备但它自己也需要被加固。最常见的两个问题管理口跟业务口混在一起、管理服务对所有区域开放。管理接口单独划区是第一步interface GigabitEthernet1/0/0 ip address 192.168.10.254 255.255.255.0 firewall zone management逻辑说明把管理口放进management区域业务区域的流量默认不允许进入管理区域。参数说明firewall zone management是华为/USG系列的命令H3C设备用port-link-mode route加安全域绑定Cisco ASA把管理口放management子接口。地区设备型号不同命令差异比较大但思路一致——管理口必须跟业务口不在一个安全域。再配一条安全策略限制谁能访问管理口security-policy rule name deny_untrust_to_admin source-zone untrust destination-zone management action deny rule name permit_admin_net source-address 192.168.10.0 mask 255.255.255.0 destination-zone management action permit逻辑说明先deny掉所有从untrust区域到管理区域的访问再放行管理网段。这两条规则的顺序也是先deny后permit跟交换机ACL正好相反原因是防火墙策略一般按序号从上到下匹配第一条deny会拦掉大部分非法来源第二条permit精确放行。参数说明如果管理网段跨了多个地址段需要按实际地址段拆成多条permit。防火墙的会话老化时间也值得顺手调一下。默认的TCP会话老化时间可能长达几个小时半开会话会占满会话表firewall session aging-time tcp 1800逻辑说明把TCP会话老化时间从默认值缩短到30分钟减少无效会话占用的资源。参数说明这个值不是越小越好如果业务本身有长时间不活跃的TCP连接比如数据库连接池调太短会导致连接被中途切断。生产环境建议先看会话表再动这个参数。3.3 Nginx安全加固像做CTF加固题一样逐项排查默认配置很多网络设备前面还挂着一层Nginx做反向代理或者Web管理入口。Nginx的加固思路跟设备命令行不一样它更接近做CTF的nginx安全加固题——拿到默认配置一项项找设置点确认每一项都收敛到最小暴露面。# 隐藏版本号 server_tokens off; # 限制请求体大小 client_max_body_size 10m; # 只启用TLS 1.2以上 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5:!3DES; # 关闭目录浏览 autoindex off; # 安全响应头 add_header X-Content-Type-Options nosniff; add_header X-Frame-Options SAMEORIGIN;逻辑说明server_tokens off最直观响应头里的Server字段不再带具体版本号攻击者少了一个指纹信息。client_max_body_size限制上传请求体大小防止通过大体积POST请求打资源。ssl_protocols只留TLS 1.2和1.3TLS 1.0和1.1的协议漏洞不需要再讨论。autoindex off关闭目录列表防止Web目录被直接浏览。两个响应头是防御基础攻击的标配。参数说明ssl_ciphers的写法是OpenSSL风格HIGH:!aNULL:!MD5:!3DES表示用高强度套件、排除匿名套件和弱哈希。如果设备上跑的Nginx版本较老可能不支持TLS 1.3需要先确认版本再改否则Nginx直接起不来。改完Nginx配置后记得执行nginx -t验证语法再reload生效不要直接重启——重启会断开所有正在处理的连接生产环境容易引发事故。3.4 无线设备隐藏SSID不等于安全加密与VLAN隔离才是重点无线AP和无线控制器也要进加固方案。很多人以为隐藏SSID就算加固了实际上抓包工具分分钟能拿到隐藏的SSID这就是个心理安慰。无线设备加固的核心是认证和隔离。首先认证方式要改成WPA2企业版或WPA3而不是WPA-PSK共享口令。共享口令意味着一个人知道全公司都知道离职员工手里还捏着旧口令。企业版认证走802.1X加RADIUS每个人的凭证独立离职后单独吊销就行。其次管理VLAN和业务VLAN必须分开AP的管理地址不能跟终端在同一网段否则终端通过ARP欺骗就能摸到AP管理面。再次如果控制器支持Rogue AP检测打开它能自动发现私接的非法AP。最后把WPS功能关掉WPS的PIN码爆破是出了名的好打。这些配置项在不同厂商的控制器上位置差异很大但你在方案文档里只需要把“启用WPA2企业版、关闭WPS、管理VLAN独立、开启非法AP检测”这四件事写清楚具体命令按实际设备型号补。4. 批量执行网络设备自动化运维脚本把方案变成可交付结果4.1 为什么方案文档必须配自动化脚本人肉逐台配置的三大问题设备数量一多人肉逐台配置就会出现三个问题。第一个问题是漏配。网络设备安全加固方案里的条目有几十项两台设备做完可能还记得做到第十台就开始跳项回头检查时根本对不上哪台做了哪台没做。第二个问题是误配。在命令行窗口里复制粘贴长配置块很容易把某条命令贴错行比如把ACL的deny规则提前导致业务流量被切断。第三个问题是没有任何审计。谁在什么时候改了哪台设备的哪条配置全凭记忆。出了事想追溯连个日志都拿不出来。网络设备自动化运维脚本解决的就是这三件事。脚本可以重复执行同样的命令输出统一的结果文件可以在执行前自动备份配置失败时按回滚清单恢复可以把每一台设备的执行输出存档事后对账。它不是把“人工”换成“程序”这么简单而是让整个加固过程从不可验证变成可验证。4.2 用PythonNetmiko批量下发加固配置一个最小可跑脚本我常用的自动化方案是Python加Netmiko库。Netmiko封装了SSH登录、命令下发、配置保存的细节不需要自己处理enable模式和分页符。安装就是一条命令pip install netmiko然后看这个最小可跑脚本import os import time from netmiko import ConnectHandler # 设备清单按实际IP和管理账号填写 DEVICES [ {host: 192.168.10.11, username: ops_admin, device_type: huawei}, {host: 192.168.10.12, username: ops_admin, device_type: huawei}, ] # 加固命令清单对应交换机SSH和ACL部分 HARDEN_COMMANDS [ undo telnet server enable, ssh server enable, ssh server authentication-type password, acl number 2001, rule 5 permit source 192.168.10.0 0.0.0.255, rule 10 deny, user-interface vty 0 4, acl 2001 inbound, protocol inbound ssh, idle-timeout 10 0, ] def backup_config(conn, hostname): 下发配置前先把当前配置备份到本地文件 output conn.send_command(display current-configuration) filename fbackup_{hostname}_{time.strftime(%Y%m%d_%H%M%S)}.txt with open(filename, w, encodingutf-8) as f: f.write(output) print(f配置已备份到 {filename}) def harden_device(device): 连接单台设备执行加固命令保存配置 password os.environ.get(NET_DEVICE_PASSWORD, ) if not password: raise SystemExit(请先设置环境变量 NET_DEVICE_PASSWORD) device[password] password conn None try: conn ConnectHandler(**device) hostname conn.send_command(display current-configuration | include sysname) backup_config(conn, hostname) output conn.send_config_set(HARDEN_COMMANDS) print(output) conn.save_config() finally: if conn: conn.disconnect() if __name__ __main__: for dev in DEVICES: harden_device(dev)逻辑说明脚本先备份当前配置再进入配置模式逐条执行HARDEN_COMMANDS执行完保存配置最后断开连接。备份放在执行命令之前顺序不能换——先改配置再备份就没有意义了。try...finally结构保证即使中间某条命令执行报错SSH连接也会正常断开。参数说明device_type是关键参数Netmiko用它选择命令解析方式。huawei对应华为Comwarehp_comware对应华三cisco_ios对应Cisco IOS。填错了会导致命令发送格式不对登录后无法正确识别enable模式。密码通过环境变量NET_DEVICE_PASSWORD传入避免了把明文口令写进脚本文件。命令清单里的每条命令跟手工配置模式下一模一样你可以按自己设备的实际加固项增删。4.3 脚本执行前的检查清单与失败回滚策略脚本不是写好就能全量跑的。我先列一个执行前检查清单照着走能避开大部分问题。先在测试设备上跑一遍脚本确认没有报错。不要拿生产设备当试验场。然后确认设备清单里的IP、账号、设备类型全部正确尤其注意有没有把测试设备的IP混进生产清单——这种事发生过不止一次。接下来确认备份目录有写入权限脚本执行前会自动生成备份文件如果目录不可写会在备份那一步直接报错。最后准备回滚命令清单把HARDEN_COMMANDS逐条翻译成对应的undo命令比如undo protocol inbound ssh、undo acl number 2001放在另一个列表里备用。回滚策略其实很简单脚本里的命令自适应设备状态如果某台设备执行到一半失败先用备份文件确认当前配置再用回滚命令恢复原状。如果备份文件本身没生成那只能手工逐条回滚非常痛苦。批量执行时不要一次扫几十台先挑5台跑一遍确认没有问题再扩大到全量。全量执行时把脚本输出重定向到日志文件每台设备的执行结果都留档后面验收时直接翻日志对比。5. 网络设备安全加固避坑与常见问题排查5.1 加固把自己锁在设备外管理ACL拦住了自己现象在VTY下应用ACL后当前SSH会话立刻断开重连时直接超时或被拒绝。这是最经典的翻车瞬间几乎是每个做过设备加固的人都经历过的。原因ACL里的规则顺序不对。最常见的情况是把rule 10 deny写在了rule 5 permit前面华为ACL匹配到第一条就停止当前管理IP被deny规则命中等于自己把自己拉黑了。还有一种原因是在ACL里忘了放行当前管理网段只写了一个deny all应用后所有来源都被拒。解决在配置ACL时先把当前登录IP所在网段写成permitdeny规则放在permit后面。下发前执行display acl 2001确认规则顺序和执行次数。如果已经断开了只能通过console口登录把VTY下的acl 2001 inbound去掉再重新调整ACL规则。血泪经验是任何涉及VTY、SSH、管理口的改动都必须先确认当前管理IP在permit范围内。5.2 ACL顺序导致业务中断先写permit还是先写deny现象加固完成后业务部门报部分网段不通但设备本身没有告警网络拓扑看起来也正常。原因ACL的匹配顺序和预期不符。华为设备ACL默认按规则编号从小到大匹配匹配即停止。如果一个ACL同时被应用在VTY和业务接口上或者你顺手把业务口的访问控制也收紧了一下业务流量可能在permit规则之前就被deny规则匹配了。尤其当ACL被多个接口复用时规则顺序的影响会放大。解决ACL在设计时先梳理业务放行规则把所有permit写在前deny写在后。应用范围要克制——管理ACL只应用到VTY或管理口不要顺手挂到业务接口上。如果确实需要做业务访问控制单独建一条ACL不要跟管理ACL混用。改完配置后用display acl all看匹配次数确认放行规则有命中、deny规则只拦掉了该拦的流量。5.3 SNMP v3切换后网管平台失联没做双版本过渡现象把交换机SNMP从v2c切换到v3后网管平台上的所有设备状态变成离线监控告警响成一片。原因网管平台还在用v2c的团体字符串读取设备信息设备端只启用了v3双方握手失败。这种情况在加固方案里很常见——方案写了“升级到SNMP v3”但没有同步考虑网管平台的适配进度。设备侧的切换是即时的平台侧的改造往往要滞后一期。解决加固时不要直接把v2c关掉先让v2c和v3双版本并存。操作是snmp-agent sys-info version v3改成snmp-agent sys-info version v2c v3确认网管平台能通过v3读到数据后再下线v2c。整个过程留一个观察窗口至少跑一个监控周期。另外切v3时不要只改版本认证密码和加密密码要提前在网管平台配置好否则v3用户建了也是白建。5.4 老设备CPU飙升SSH加密算法引发的软件转发现象SSH加固后设备CPU占用率从个位数飙到百分之七八十操作延迟明显业务转发也受影响。原因老款设备的主控板没有加密硬件加速SSH的加密解密全部走CPU软处理。加固方案里如果启用了强加密套件比如AES256老设备每处理一个SSH会话都要消耗大量CPU资源。并发会话一多CPU直接被打满。解决加固前先查设备型号和CPU基线确认是否支持硬件加密。如果设备确实很老SSH加密套件可以适当降级到设备支持的级别优先保证管理通道可用而不是一味追求最强算法。同时限制并发SSH会话数把VTY数量从5个缩到2个减少资源消耗。最重要的经验是加固方案里要有“设备型号适配”这一列不同代际的设备用不同的参数组合。5.5 没有备份的后悔药配置回退的基本功现象某台设备加固后出现异常需要回退到加固前状态结果发现当时没有备份配置只能看着命令行历史手工恢复恢复出来的配置还不完整。原因加固执行时图省事直接进配置模式改动没有先保存running-config。设备只要没有重启running-config还在但一旦有人顺手reload或者设备断电重启改动全部丢失连回退的基准都没了。解决把备份写进加固流程的第一步用脚本自动执行。备份文件按设备名加时间戳命名存到独立的备份服务器或目录。更稳妥的做法是同时备份startup-config和running-config两份回退时直接用startup-config恢复。我做设备操作的习惯是“不改不备想改先备”这条习惯救过我好几次。6. 加固效果验证三条快速检测路径与一个巡检习惯6.1 基线校验把加固项转成自动化复核脚本加固做没做、做对了没有不能靠“我记得改了”。我习惯写一个基线校验脚本批量检查每台设备的关键配置项是否存在for ip in 192.168.10.11 192.168.10.12; do echo $ip ssh -o ConnectTimeout5 ops_admin$ip \ display current-configuration | include ssh server enable|acl number 2001|protocol inbound ssh done逻辑说明用SSH登录设备执行display current-configuration过滤出加固项对应的关键字。设备会回显当前配置中匹配到的行。你在输出里确认ssh server enable存在、protocol inbound ssh在VTY下生效就说明SSH相关的加固项落地了。参数说明include是华为过滤命令的关键字Cisco用show run | include。如果设备启用了SSH密钥登录ssh命令需要换成密钥文件参数否则会提示输入密码。6.2 攻击面验证从外部视角确认端口与服务状态配置层面的校验只能说明“命令下了”外部视角的扫描才能说明“攻击面收敛了”。用一个轻量端口扫描命令扫管理网段nmap -sT -Pn -p 22,23,80,443,161,162 192.168.10.0/24逻辑说明这个命令扫描管理网段所有设备上的六个端口按加固目标来看23端口Telnet不应该有响应80端口HTTP管理页面不应该存在161/162是SNMP端口应该只看到v3对应的UDP端口状态。参数说明-sT走TCP全连接扫描准确率高但速度慢-Pn跳过主机发现阶段因为很多设备默认不响应ICMP。如果发现23端口还开着说明Telnet下发失败或者没有生效回去查那台设备的配置。6.3 周期性巡检把加固项变成月度复核清单加固不是一次性项目设备配置过了三个月可能被某次变更覆盖掉。我把加固项整理成一张月度巡检表每月花半天时间过一遍。检查项验证方式合格线远程管理通道扫描管理网段端口仅SSH监听Telnet无响应账号权限导出本地用户列表无默认账号、无长期闲置账号登录日志查看syslog服务器有第三方登录审计记录ACL命中统计查看ACL匹配次数放行规则有命中deny规则只拦异常来源配置备份比对备份文件时间戳一个月内有最新备份SNMP版本查询协议状态v2c已关闭仅v3这张表不用做得很重关键是每个检查项都有明确的验证命令和及格线。巡检时照着表逐台执行发现问题当场标记月底统一复查。之前接手过一台核心交换机前任运维说“加固都做过了”结果我扫描一看Telnet端口还开着一问才知道当时只是改了VTY的传输协议系统级的Telnet服务没有关。从那以后我养成了一个习惯方案文档写得好不好不重要重要的是每一条加固项都能用一条具体的命令去验证它。这个习惯帮我省掉了后面很多的返工。网络设备安全加固这事儿理论说得再漂亮最后还是要落到“设备上确实没有开着多余的口子、没有留着能登录的弱账号、没有裸奔的明文协议”这三件事上希望帮到你。本文还有配套的精品资源点击获取