上周帮一位朋友做安全巡检登录他们单位那台用了五年的防火墙时我手一快输入了admin/admin结果直接进去了。朋友当时脸都绿了因为这台设备的位置在边界理论上承载着整张网的访问控制策略。这个场景我见过不止一次很多企业在安全设备的管理上有个共同的盲区安全产品出厂密码管理。这篇文章就想聊聊“安全厂商部分的默认产品密码”这件事。它不是什么高深技术但直接关系到网络边界、审计数据、终端管控这些核心资产的底线。适合安全运维、IT管理员、等保测评人员以及安全服务工程师阅读。我会把默认产品密码为什么存在、分布在哪里、怎么排查、怎么整改以及如何避免整改时把业务搞挂全部拆开讲清楚。1. 为什么“卖安全的厂商”自己成了弱口令重灾区1.1 安全设备的“沉默属性”决定了它容易被遗忘很多人有个直觉误区安全设备既然是做防护的那它的管理口令肯定比其他系统更安全。实际情况恰好相反。防火墙、入侵检测、堡垒机这类设备有个共同特点——部署完就沉在网络里平时根本没人登录。业务系统天天有人访问出了问题会立刻暴露安全设备只要不报警、不宕机运维人员一年半载都不会碰一次管理界面。账号密码就这么静静地躺在那里保存着出厂状态。我在巡检中统计过一个大概比例业务服务器的弱口令率其实低于安全设备。原因是业务服务器至少还有开发、运维偶尔登录密码忘了马上会发现而安全设备的管理账号往往只有一两个人知道甚至这个人离职了都没人接手。设备没人登录默认口令就一直保留着直到某次被扫描器扫出来或者被攻击者撞库撞开。还有一个容易被忽视的点中大型企业的安全设备数量并不少。边界防火墙、Web应用防火墙、日志审计、运维审计、终端管理控制中心再加上各个分支机构的同类设备轻松能凑出几十台。资产一分散管理就稀薄默认口令的存活率自然高。1.2 攻击者为什么优先盯上安全设备从攻防视角看安全设备被控制后的价值非常高仅次于域控。防火墙在边界控制一台就等于拿到了整个内网的流量出入口日志审计和堡垒机保存着大量敏感凭据和操作记录攻击者拿到后可以删日志、拿账号、摸清全网拓扑终端管理控制中心更夸张一旦被控制攻击者可以直接向全网终端下发指令。所以这不是危言耸听而是攻击者的优先级排序先打边缘设备再打审计系统最后才是业务系统。很多攻防演练中默认口令就是突破口只要设备还留着出厂密码基本等于给攻击者留了一扇门。安全设备本身是防御体系的重要组成部分但它同时也是最容易被反制的目标因为运维人员往往默认它是安全的天然缺少对它的监控。1.3 厂商不强制改密的历史问题这里面也有厂商的责任。早年很多安全设备出厂时并没有强制修改初始密码的机制设备装机后直接用默认口令就能进。有些产品为了让实施人员上手快把初始口令统一设计成极其简单的组合甚至不同型号之间通用。厂商的考虑是降低部署成本但这等于把风险留给了最终用户。这几年新出的设备好一些了很多厂商开始要求首次登录必须修改密码部分产品还会校验密码复杂度。但存量设备依然是个大问题尤其是那些固件长期不升级的老设备出厂逻辑就是默认口令永久有效你拿它一点办法都没有只能靠管理手段去补。1.4 一段巡检中的真实见闻回到开头那个巡检场景。那台边界防火墙的管理地址本来只允许从内网访问但配置里有一条临时的远程运维策略没删除导致管理界面暴露在外网。叠加默认口令这台设备实际上已经可以被任何人接管了。我查了一下会话记录发现近三个月有多次来自外部的登录尝试密码一批一批地撞只是那时设备口令还是默认的理论上早该被撞开了。好在攻击者没能完成全部连接就被ISP侧的流量清洗给拦了算是运气好。这类情况最大的问题在于修改默认口令的成本极低却总是被忽略。很多单位把精力放在部署新的安全产品上对已经上线的设备反而疏于管理用一句话总结就是重采购、轻维护。2. 安全设备默认口令的典型分布与管理暴露面2.1 安全设备分类与默认口令常见模式不同类别的安全设备默认口令的规律差别挺大。我按实际使用场景把常见设备分了五类并整理出每类设备的典型口令模式方便对照自查。设备类型常见默认口令模式主要风险防火墙/上网行为管理admin/admin、admin/123456、admin/空口令边界被接管访问控制策略被篡改WAF/抗D设备admin/admin、admin/Admin123防护规则被关闭攻击流量直达源站堡垒机/运维审计admin/admin、admin/123456审计数据泄露纳管资产账号密码被获取日志审计/数据库审计admin/admin、admin/123456日志被删除溯源线索中断终端管控/EDR控制中心admin/admin、admin/123456全网终端可被下发恶意指令需要说明的是这只是长期巡检中的一个统计性观察不能当作某厂商某型号的完整对照表。不同批次、不同固件版本都有差异实际排查要以自家设备的实际情况为准。从模式上能看出一个明显规律绝大多数默认口令集中在admin加简单数字或者干脆复用用户名的组合。这类口令的特点是实施人员容易记但也意味着攻击者用最小的字典就能扫开。2.2 除了Web登录还有哪些“隐形默认口令”除了管理后台的Web登录安全设备还有几个经常被忽略的暴露面。第一个是SSH/Telnet远程命令行。一些设备的Web管理界面做了密码强度控制但命令行通道却保留着另外一个账号。命令行拿到手之后权限比Web管理页面还高可以直接看配置、改路由、导数据。排查时不能只盯Web后台要检查所有开放的服务端口。第二个是SNMP默认团体名。很多网络设备默认public只读、private可写安全设备里也有类似情况。攻击者如果能通过SNMP读写设备流量统计、接口配置都可能被改动。SNMP团体名严格来说不算账号密码但从风险角度看它就是一类隐性的默认口令。第三个是设备内置数据库的默认口令。堡垒机、日志审计这类设备通常内嵌了数据库来存审计数据这些数据库很多时候也有默认账号。之前有案例就是Web后台改了强口令但数据库还是默认的攻击者直接从数据库里把用户口令和审计记录全拖走了。第四个是厂商预留的调试维护通道。部分设备出厂时会有调试账号用于厂商远程排障平时隐藏在后端。这类通道一旦被利用影响面非常大而且普通运维人员不一定知道它的存在。排查时可以通过查看运行进程、监听端口以及配置文件来确认这类通道是否开放如果是非必要端口建议直接关闭或在边界上做严格限制。2.3 互联网上流通的“默认口令文档”说明了什么在攻防圈里安全设备的默认口令清单属于流传度很高的资料几乎每个拿了授权做渗透测试的工程师手里都有一份。这些文档内容详细到品牌、型号、版本、初始账号、初始密码、端口有些甚至标注了恢复出厂的方法。之所以流传广根本原因是设备存量太大、默认口令太普遍验证成本极低。这给我们防守方提了个醒不要心存侥幸认为自家设备的默认口令没人会知道。攻击者手里的字典远远比我们想象的全而且随着自动化扫描工具的普及撞默认口令已经是完全自动化的过程不需要人工参与。只要设备暴露在可达的网络范围它就时刻处于被尝试登录的状态。3. 一次真实的企业默认口令排查过程与脚本实践3.1 第一步把家底摸清楚——先有资产清单排查默认口令的第一个拦路虎不是技术而是很多单位根本不知道自己有哪些安全设备。管理网段里跑着什么系统、哪个IP开着 80/443/22 端口一概不清楚。没有资产清单后面所有的检测都是空谈。我当时的方法是先拉网络拓扑再结合CMDB和流量审计平台的数据把可能出现安全设备的网段圈出来。然后用nmap做一次快速扫描识别开放了管理端口的主机。这一步建议在业务低峰期做避免扫描流量被IPS误报为攻击行为。nmap -sS -p 22,80,443,8443,8080 192.168.100.0/24 -oG security_assets.txt扫描结果里凡是开放这些端口的主机都逐台登录确认设备类型。确认的工作量确实不小但没有捷径因为默认口令排查必须建立在准确的资产台账之上。3.2 第二步探测管理端口与登录接口资产清单有了之后下一步是确认登录接口。绝大多数安全设备的Web管理界面在/或/login路径下但也有部分设备把管理界面放在非标准端口比如 8443、9443、10000 这类端口。还有些设备支持API管理默认开启了某个API端口这也算管理面的一部分。我通常会结合nmap的服务识别结果再手工访问一遍确认。遇到HTTPS证书自签名的设备要单独记录因为自签名证书本身就是设备尚未纳入正规管理的信号之一。nmap -sV -p 22,80,443,8443,8080,9090 192.168.100.0/24这一步不需要太快稳扎稳打把每一台设备的开放端口、服务版本、证书信息记录下来后面改密时这些都是重要依据。3.3 第三步用脚本验证弱口令附示例代码资产和接口确认后就可以做默认口令验证了。注意前提条件仅限授权范围内针对自有资产做安全排查不要对非授权目标做任何测试。以SSH服务为例我写过一个简单的Python脚本用paramiko做弱口令检测。核心逻辑就是循环尝试常见默认口令组合命中后自动退出避免过多无效连接。import paramiko import sys TARGETS [192.168.100.11, 192.168.100.22] USERNAMES [admin] PASSWORDS [admin, 123456, Admin123, ] def check_ssh(host, username, password): try: client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(host, port22, usernameusername, passwordpassword, timeout5) print(f[高危] {host} 使用默认口令 {username}/{password}) client.close() return True except paramiko.AuthenticationException: return False except Exception as exc: print(f[异常] {host} 连接失败: {exc}) return False if __name__ __main__: for host in TARGETS: found False for user in USERNAMES: for pwd in PASSWORDS: if check_ssh(host, user, pwd): found True break # 控制连接频率避免触发锁定策略 time.sleep(0.5) if found: break if not found: print(f[通过] {host} 未发现常见默认口令)脚本本身不复杂关键是执行时机的选择和控制速率。安全设备普遍有登录失败锁定机制短时间大量失败尝试会把检测源IP直接封掉甚至影响运维人员的正常登录。我一般把尝试间隔设在 0.5 秒以上并且单台设备的总尝试次数控制在十次以内只试最常见的组合不做大规模字典爆破。Web管理界面的检测类似通常带验证码和CSRF Token脚本处理起来更麻烦。如果确认设备有验证码机制我不会强行写脚本硬撞而是人工确认一次配合指纹信息做风险判断。自动化工具的作用是提高效率不是制造新的封禁风险。3.4 排查中的三个典型“坑”排查过程中我踩过几个坑写出来供参考。第一个坑是验证码和锁定策略。Web管理界面的默认口令验证脚本跑得太快很容易触发锁定把设备锁到连正常管理员都登不进去。建议对Web类接口优先做指纹识别判断设备是否可能有默认口令而不是直接尝试登录。第二个坑是固件升级后默认口令复现。有些设备之前已经改过密码了但某次固件升级之后部分配置文件被重置某些隐藏账号恢复成出厂口令。这意味着默认口令排查不能只做一次要纳入定期巡检。第三个坑是绕过管理界面的其他通道。有些设备虽然Web后台改了密码但SNMP团体名、数据库账号、厂商调试端口还是默认的。排查单一口令没有意义得把所有管理入口都覆盖到否则就是拆东墙补西墙。4. 统一改密为什么容易翻车我的排雷记录4.1 改密不是“改密码”那么简单的变更前置动作发现默认口令后整改动作就是改密码。但改密这个动作看起来简单实际上翻车概率非常高。我在一家制造企业的整改中就遇到过安全团队一口气把核心防火墙密码全改了结果第二天业务部门报障说打通了经销商系统的订单接口不通了。排查到最后发现是ERP系统里配置了固定账号连接防火墙做流量统计改密前没人通知业务侧更新配置。密码一改外部对接直接失效。这是一个非常典型的教训必须在改密前确认有没有系统、脚本、第三方集成写死了设备账号。改密前应该做的第一件事是梳理设备账号的使用方。谁会登录这台设备有没有监控系统在拉数据有没有自动化脚本在用设备API这些信息花半小时整理清楚远好过改完后加班救火。4.2 分批改密与验证节奏我的习惯是按设备重要性排序分三批执行。第一批改最核心的边界设备和管理平台第二批改分支机构和中等风险设备第三批改外围和边缘设备。核心设备出问题影响最大所以优先处理而且要给足验证时间。每台设备改完密码后至少要验证三件事第一新密码能正常登录第二设备内的策略和配置没丢第三和设备相关的业务链路抽样确认正常。验证通过后再改下一台不要图省事并发操作。多线程改密的效率确实高但一旦出错定位问题的成本远高于节省下来的时间。改密后的密码记录也要同步更新。很多单位改完密码就完了密码随手写在Excel里放在网盘上安全性堪忧。有条件的话应该在改密后第一时间把新密码录入密码保险箱或者PAM系统同时更新CMDB台账保证人找得到密码但密码不落地。4.3 复盘一次双机热备改密翻车事件我印象最深的翻车事件是关于双机热备。一次给某单位的双机防火墙做统一改密改完主设备的密码后发现主备设备的心跳同步中断了业务出现秒级抖动。当时第一反应是网络问题排查了半天才发现是备设备还在用旧密码与主设备做认证两边配置里的认证密钥不一致导致状态同步失败。这类问题的根源在于双机热备环境里设备之间往往存在独立的认证凭据它不等同于管理员登录密码。改密时只改了管理账号没有同步更新设备间认证配置主备就失联了。所以处理双机环境时改密前必须先把设备间认证机制查清楚确认改动范围改完再检查主备同步状态。另一个常见的翻车点是堡垒机。堡垒机纳管了大量设备的账号如果直接在目标设备上改了密码而没有在堡垒机里同步更新所有通过堡垒机访问资源的入口都会失效。特别是某些老版本堡垒机纳管凭据更新不及时批量改密后运维人员连服务器都登不进去。做这类整改时建议先在测试设备上完整走一遍流程确认堡垒机和目标设备的联动逻辑没有障碍再推广到全量设备。4.4 管理接口收敛比改密更重要的加固改完密码并不代表万事大吉还需要做接口收敛。很多安全设备默认开启了所有网络接口上的管理服务也就是说只要某个业务接口被人访问到管理页面也跟着暴露。正确的做法是限定管理接口只允许管理网段访问让业务流量和管理流量分开。我在排查时经常看到的情况是设备改了强口令但管理端口依然全网可达。这种情况下即使口令再复杂也架不住长时间的暴力破解和0day利用。管理接口收敛的成本很低只需要在设备上配置严格的访问控制策略把管理服务的源地址限制为运维网段即可。有条件的环境建议再加一层双因子认证特别是边界防火墙、堡垒机、终端管理控制中心这类高价值设备。现在很多主流安全设备都支持OTP或者短信认证打开之后默认口令即使泄露攻击者也很难直接利用。不过双因子在老设备上兼容性一般建议先在测试设备验证再决定是否全量启用。5. 把默认口令治理变成常态化安全运营闭环5.1 把排查动作固化到巡检计划默认口令排查如果只是运动式的专项行动效果很难持久。正确的做法是把它固化成常态化的巡检项按固定周期执行。我建议至少每季度做一次全网安全设备默认口令专项检查包括登录口令、SNMP团体名、内置数据库口令、隐藏调试接口。检查的方法不一定要多高级复用第3章里的流程就行更新资产清单、扫描管理端口、验证弱口令、输出报告、整改验证。关键是要让这个流程跑起来每次巡检留痕整改项闭环。半年之后回看弱口令数量一定会明显下降。考虑到人的惰性最好把检查动作尽量自动化。可以用定时任务定期扫描再结合人工确认结果。工具不是万能的但至少能保证持续在看这个动作本身不会中断。5.2 有条件的企业建议上PAM在设备数量多、运维人员分工细的环境里靠手工维护密码早晚会出问题。这时候可以考虑上PAM特权账号管理平台。PAM的核心价值不是帮人记密码而是让密码不落地、定期自动改密、账号权限可审批、操作行为可审计。PAM上线后运维人员登录设备不需要知道真实密码而是通过PAM发起会话由PAM完成身份认证并代填密码。这样即使某台设备的密码泄露了只要PAM侧及时改密风险也能快速收敛。更重要的是所有运维操作都会被记录出问题时审计追踪非常方便。不过PAM不是银弹老设备的协议兼容性、双机热备场景下的联动、改密失败后的自动回滚机制都要在选型和实施时充分考虑。步子不要迈太大先纳管核心设备跑一段时间稳定后再扩大范围。5.3 用等保基线给自己定一个及格线对于大多数企业来说等保合规要求是一个可量化的参考标准。在等保测评中身份鉴别是必查项核心要求包括用户身份标识和鉴别、密码复杂度、登录失败处理、远程管理时的传输加密等。默认口令问题直接对应这些要求中的身份鉴别条款很多测评单位第一次拿整改报告问题清单里就写着设备存在默认口令。所以可以把等保基线的检查项当成内部治理清单逐条对照。比如是否存在默认口令、密码策略是否满足要求、登录失败是否有锁定、管理通道是否加密、是否启用了双因子认证。逐项过一遍大概率就能找到自己环境的短板然后按优先级整改。5.4 一个可持续运转的默认口令治理闭环最后聊聊治理闭环。默认口令问题的本质是资产管理和生命周期管理问题不是一次性修复。我习惯用一个四步环来运转盘点、检测、整改、监控。盘点阶段持续更新资产台账确保每一台安全设备都被记录在案检测阶段定期扫描默认口令、弱口令和暴露面整改阶段发现问题后立即改密并同步更新台账监控阶段通过日志和告警持续观察设备的登录行为发现异常登录及时处置。四个环节缺一不可。很多团队只做到前两步发现一堆默认口令改完就结束了没把整改结果纳入监控结果没过多久又恢复原样。真正让治理效果持续的是最后一环——让设备登录行为处于可观测状态任何异常都逃不过告警。做安全运维这么多年我最大的体会是安全设备本身也是资产而且是高价值资产。默认口令的整改成本极低收益却极高几乎可以说是安全投入中性价比最高的动作之一。最后分享一个小技巧把默认口令检查脚本放进每个月的例行巡检计划不用追求复杂的系统哪怕只是一个定时跑批加一个结果邮件也能让所有相关人员持续保持警觉这比任何一次运动式整改都管用。