去年某地一家医院的网络HIS系统被攻破，攻击者用的系统账号是"admin"，密码是存弱"admin123"。这不是口令段子，是漏洞真实的通报案例。弱口令漏洞的置措危险性在于：它不需要攻击者掌握任何高级技术，一个脚本跑几分钟就能撞开几百台设备。网络更麻烦的系统是，很多运维人员觉得"内网的存弱东西没人看得到"，这种侥幸心理恰恰是口令最大的隐患。

弱口令的漏洞问题根源往往不在技术层面。我见过一家企业，置措安全制度写得漂漂亮亮，网络密码复杂度要求12位以上、系统含大小写和特殊字符，存弱结果机房里的交换机密码是"123456"。问起来，运维的说法是"方便记，反正外网访问不到"。这种认知偏差非常普遍——把"不容易被发现"等同于"安全"。实际上，攻击者一旦通过钓鱼邮件或VPN漏洞进入内网，第一件事就是扫弱口令，横向移动的速度远超你的想象。

先摸清家底，别急着改密码

发现弱口令之后，最容易犯的错误是立刻批量强制改密码。这么做看起来雷厉风行，实际上可能把业务系统改崩——某些老旧系统把密码硬编码在配置文件或数据库连接串里，你一改，服务直接起不来。正确做法是先梳理：哪些设备用了弱口令？是默认口令还是人为设置的简单密码？这些设备分别承载什么业务？影响范围有多大？

具体操作上，可以用Nmap配合弱口令检测脚本做一次内网扫描，也可以直接用Hydra对已知服务做定向测试。但注意，扫描行为本身要先获得授权，别自己把自己搞成"违规操作"。梳理完之后，列一张表：设备IP、服务类型、账号、口令强度、业务重要性、是否可停机。这张表决定了后续处置的优先级和方式。

处置要分场景，不能一刀切

能停机的设备，直接改密码，改完验证业务正常。不能停机的，走变更窗口，提前和业务方确认时间。对于那些密码写死在代码里的老系统，硬改密码行不通，得在网络层做访问控制——用防火墙策略或ACL限制只有特定IP能访问该服务，把暴露面缩到最小。

还有一种情况：设备本身不支持复杂密码，比如某些工业控制系统的PLC，密码位数上限就是8位纯数字。这种没法从密码强度上做文章，只能靠网络隔离。把它放到独立的VLAN里，和办公网之间加一道防火墙，只放行必要的端口和协议。说白了，密码改不了，那就让它"够不着"。

改完之后的事才是关键

很多单位的做法是：改完密码，写个报告，归档，完事。过半年一查，密码又变回"admin123"了。为什么？因为运维人员记不住那么多复杂密码，又没有一个好用的密码管理工具，最后只能怎么方便怎么来。

解决这个问题，技术上可以上堡垒机或密码管理系统，让运维人员不需要知道真实密码就能登录设备。管理上得有定期审计机制——不是一年查一次，是每个月自动跑一次弱口令扫描，发现一个处理一个。另外，新设备上线前必须过一道安全检查，默认口令必须改，这条规则要写进上线流程里，不然永远是"边改边冒"。

弱口令这事，技术含量不高，但考验的是管理的细致程度。它不像0day漏洞那样引人注目，可偏偏是攻防演练里得分最高的突破口。把它当回事，比买再多安全设备都管用。