内容摘要：凌晨三点，安全扫描器弹出一条告警：某台数据库服务器SSH端口对外开放，账号root密码是“123456”。这不是段子，是上个月我在客户内网真实撞见的场景。那台机器跑着生产环境的订单库，运维图省事，从装

凌晨三点，服务安全扫描器弹出一条告警：某台数据库服务器SSH端口对外开放，器弱账号root密码是口令“123456”。这不是处理段子，是办法上个月我在客户内网真实撞见的场景。那台机器跑着生产环境的服务订单库，运维图省事，器弱从装机那天起就没改过默认口令。口令弱口令这事，处理说小了是办法懒，说大了就是服务给入侵者留门。

什么叫弱口令？器弱别只盯着“123456”“admin”“password”这种。真正的口令弱口令是一组有规律的字符——公司名拼音加年份，像“huaxin2023”；或者键盘上随手一划，处理“qwerty”“1qaz2wsx”；再或者用员工工号、办法手机尾号做密码。攻击者手里的字典早就把这些模式收录了。我见过一个案例，某企业内网两百多台服务器，密码全是“企业简称+@+月份”，比如“abc@0315”。结果一台被爆破，整个内网三天内全沦陷。

处理弱口令，第一步不是改密码，是盘点。你得先知道哪些机器存在弱口令。别指望人工登录每台服务器去试，那得干到明年。用工具批量扫。Linux下可以用Hydra配合常见密码字典对SSH、FTP、RDP做探测，但注意别把生产环境扫挂了——并发调低，比如每秒5个请求。Windows域环境更简单，用NetExec或者CrackMapExec跑一遍SMB协议，几分钟就能拉出列表。扫出来的结果按危险等级分：能直接拿root或管理员权限的标红，普通用户权限的标黄。

改密码这事，很多人改完就完事了，其实坑在后面。你改了服务器密码，但应用配置文件里还写着旧密码，服务起不来；或者定时任务里嵌了密码，半夜批量失败。我习惯的做法是：先改一台，跑一遍全链路验证。确认没问题了，再批量推。批量推也别用脚本硬怼，用Ansible的user模块或者expect脚本，每改完一台就自动测试一次登录。失败就停，别把整批机器搞成砖。

光改一次不够。弱口令会复发。新员工入职，图方便设个“welcome123”；外包人员临时开个账号，密码设成“test1234”。三个月后你再扫，又是一堆。所以得把弱口令检查塞进日常流程里。我的做法是每周跑一次自动扫描，结果直接发企业微信群里。不改？第二次通报部门负责人。第三次还没改，直接封端口。别讲情面，安全这事讲情面就是给自己挖坑。

还有个容易被忽略的点：服务账号。数据库连接串里的密码、API调用的token、中间件管理后台的密码——这些往往藏在配置文件、环境变量甚至代码注释里。有人觉得“内网服务账号无所谓”，但攻击者一旦拿到一台普通机器，翻配置文件就能找到这些凭证，然后横向移动到核心系统。处理办法是统一用密钥管理服务，比如Vault或者KMS，把密码从配置文件里彻底拿掉。做不到？至少把服务账号密码设成32位随机串，并且每季度轮换一次。

最后说个真实教训。去年有个客户，运维把所有服务器的密码统一改成了“Xy@2024#Server”，觉得够复杂了。结果三个月后，一个离职员工用这个密码登录了测试环境，删了半个库。为什么？因为密码虽然复杂，但全公司共用一套，离职时忘了回收。弱口令处理的核心不是复杂度，是唯一性和生命周期管理。每台机器独立密码，每个账号独立密码，定期轮换，离职即失效。做不到全自动，至少用密码管理器生成和存储。

别等出事再改。现在就去扫一遍你的内网，哪怕只扫出三台弱口令机器，也比你半夜被叫起来应急强。