系统存在弱口令漏洞的情况整改报告

上周三凌晨两点，系统运维老张被短信告警吵醒——一台对外提供API服务的存弱服务器CPU跑满，登录日志里躺着三万多次SSH失败记录。口令况整他爬起来一查，漏洞root密码是改报告admin123。这台机器已经在公网上裸奔了四个月。系统

这不是存弱段子。弱口令这事儿，口令况整年年说，漏洞年年有。改报告我翻了下近半年经手的系统十二份渗透测试报告，其中九份能通过弱口令直接拿到服务器权限，存弱比例高得离谱。口令况整更让人无语的漏洞是，这些口令翻来覆去就那么几个：123456、改报告password、admin888、qwerty，还有用公司名加年份的，比如ruijie2023。攻击者根本不需要什么0day，一个字典跑十分钟就进去了。

一、问题到底出在哪

很多人觉得弱口令是员工偷懒。这只说对了一半。我见过一家公司，安全部门发了强制密码策略，要求12位以上、大小写加特殊字符。结果呢？运维团队直接把密码写在了内部Wiki上，因为“太复杂了记不住，每次都要重置”。策略是有了，配套的密码管理工具没跟上，最后变成了形式主义。

另一个重灾区是默认口令。新设备上线，管理员图省事，不改初始密码。Redis未授权访问、MongoDB空口令、Tomcat管理后台tomcat/tomcat，这些漏洞的本质都是默认配置没动过。有个客户的内网里有十七台Redis，其中十四台连密码都没设，数据直接被加密勒索。

二、整改不是改个密码就完事

发现弱口令之后，第一反应肯定是改密码。但如果只做这一步，下个月还会复发。我通常建议按这个顺序来：

先把所有暴露在公网的服务梳理一遍。SSH、RDP、数据库端口、中间件管理后台，这些是攻击面最大的地方。能关的关，能限制IP的加白名单。一台Redis没必要对0.0.0.0监听，绑个内网地址能省掉一大半风险。

然后上强制密码策略，但别搞那种反人类的复杂度要求。NIST现在推荐的是长度优先，12位以上的passphrase比P@ssw0rd!这种强得多。配合一个密码管理器，LastPass或者Bitwarden都行，让运维不用靠脑子记密码。

再就是双因素认证。SSH登录加个Google Authenticator，成本几乎为零，但能挡住99%的暴力破解。我们内部从去年开始全部上了2FA，到现在为止没有一台机器因为口令问题被突破过。

三、几个容易忽略的角落

大家盯着服务器，往往忘了网络设备。交换机、路由器、防火墙的弱口令一样致命。有个案例是攻击者用cisco/cisco登进了核心交换机，直接镜像了所有流量。

还有API密钥。很多开发把密钥硬编码在代码里推到GitHub，这些密钥往往权限极大。弱口令不光是“密码”，任何静态的、可猜测的凭证都算。定期扫代码仓库，用trufflehog或者gitleaks这类工具，能捞出来不少。

监控也得跟上。SSH失败登录次数超过阈值就告警，别等CPU跑满了才发现。我们现在的规则是五分钟内失败超过二十次就触发告警，运维手机直接收推送。

四、说点实在的

弱口令这个问题，技术含量不高，但根治很难。因为它本质上是人的问题——懒惰、侥幸、图方便。我见过最离谱的一个案例，安全管理员自己用的密码是admin@123，然后要求全公司用16位随机密码。这种双标，底下人不可能配合。

整改报告写起来容易，列一堆措施，但落地的时候得考虑实际。密码太复杂，员工就会写便利贴贴在显示器上；强制90天改一次，大家就会在密码后面加个1。安全措施得让人能接受，否则就是自欺欺人。

最后说个数据。我们上个月对内部两百多台服务器做了一次弱口令扫描，发现十一台有问题。整改之后这个月复查，全部通过。但我知道，只要有人为因素在，这个问题就不会彻底消失。能做的，就是把门槛抬高，让攻击者觉得不划算，转头去找更软的柿子。

本文地址：http://www.79wt.cn/news/369b9599535.html