阿里云云安全中心：Linux账号弱口令风险检查与密码策略加固全攻略
一台运行着几十项业务的生产服务器，可能因为一个用户名为 test、密码是 admin123 的待清理账号被直接拿下。阿里云云安全中心的弱口令告警清单里，这类问题往往反复出现。解决 阿里云弱口令风险 的核心不只是清理几个简单密码，而是需要一套让 Linux账号密码加固 可以持续生效的机制。以下先回到起点，看清弱口令究竟会带来哪些实质性危害。
本文由 云国际服务商『 云老大 飞弟：@yunlaoda360 / YunLaoDa-云服务器•运维部门•撰写』如需转载请注明！
弱口令风险对Linux账号的危害
什么是弱口令？为什么它会成为Linux服务器沦陷的开始？
弱口令不是“简单密码”的模糊说法，而是任何能被攻击者以极低成本猜中或碰撞出来的凭证。常见的 123456、password、生日组合只是冰山一角，真正危险的是那些出现在历年泄露字典里的“常见业务密码”。Linux 发行版默认密码策略宽松，CentOS 7 仅要求密码不小于 6 位且未强制大小写与特殊字符，这就导致大量系统依赖管理员“自觉”而非策略约束。云安全中心的弱口令检测机制正是基于这类哈希字典比对和 SSH 等服务的暴力破解行为分析，一旦命中，几乎等同于给攻击者发了一张免密登录券。
弱口令攻击通常以哪些方式发生？为什么托管在云端的 Linux 风险更高？
最常见的两种路径是暴力破解和凭据填充。前者针对 SSH（22端口）、FTP 等服务反复尝试高频密码组合，后者利用已泄露的邮箱/密码对数据库进行“撞库”。根据公开安全报告，约80%的入侵事件直接与弱口令或凭据泄露捆绑在一起。云上服务器的风险被放大，因为它们暴露在公网的端口更多、自动扫描脚本密度远高于机房环境，一次未经收敛的弱口令可能在几分钟内就被全自动化攻击工具试探出来。阿里云云安全中心捕获的大规模 SSH 爆破日志中，持续的字典轮换攻击往往只持续十几分钟就能得手——防线真空恰好就在“告警收到后还没来得及处理”的那段时间窗口里。
真实案例警示：多台服务器为何因一个测试账号被集体控制？
某中型跨境电商公司曾在一次安全事件中丢失三台 ECS 的控制权。攻击起点是一个已离职运维保留的 svnuser 账号，密码为 svn@2018。由于该账号加入 sudo 组且密码策略从未更新，攻击者在获取初始权限后利用 SSH 信任关系横向移动到数据库服务器和日志节点，整个过程不到两小时。清理该事件花费的安全响应成本远超预期，而这一切在阿里云云安全中心的“弱口令”风险列表中早有提示，只是当时未被列入高风险修复序列。这个案例说明：一台机器的弱口令不只是单点问题，它能变成整个 VPC 内凭证横向移动的跳板。
阿里云云安全中心弱口令检测原理
与传统的安全扫描工具不同，阿里云云安全中心对 Linux 账号弱口令的检测并不是简单地在系统里跑一套 john 字典，而是将离线哈希比对与在线行为分析结合起来做交叉验证。这种设计的好处是，即便攻击者使用了密码哈希中未出现过的变种，只要其登录行为表现出典型的暴力破解特征，仍然会被抓到。根据 Verizon 2023 年 DBIR 报告，超过 80% 的入侵事件与弱口令或凭据泄露直接相关，这也解释了为什么云安全中心将弱口令检测作为基线风险里优先级最高的项目之一。
如何查看风险报告
在阿里云控制台进入云安全中心后，左侧导航栏的“风险列表”里有一个专门的“弱口令”分类。点进去默认展示全量资产的风险账号，可按“Linux 账号”类型进行筛选。这里需要注意一个容易被忽略的细节：报告中的风险等级并不是只看密码强度，还会结合该账号是否具备 root 权限、是否允许 SSH 登录、最近是否有异常登录行为综合判定。因此，一个普通服务的弱口令可能被标记为“中危”，而 sudo 组里的弱口令几乎一定是“高危”。
检测项有哪些
云安全中心覆盖的检测项远比想象中细。除了对 /etc/shadow 中的哈希做弱口令字典比对，还会检查 SSH、FTP 等服务的登录日志，从中识别暴力破解模式——例如同一 IP 在短时间内用不同用户名尝试登录，或者同一账号被多个 IP 反复撞库。同时，控制台里还能看到“密码策略合规性”这一维度，直接对标等保 2.0 对 Linux 密码复杂度、更换周期和历史密码次数的要求，把运维最头疼的合规审计一次性打包进了检测逻辑。
告警类型解析
不少用户反馈告警太多了，根本处理不过来，这其实是因为没有区分告警的生成逻辑。云安全中心的弱口令告警大致可以归为三类：一是实时触发型，由新发现的弱口令哈希直接产生；二是行为分析型，来自暴力破解或异常登录事件的关联；三是历史快照型，即之前发现的风险在修复后，因为没有触发重新扫描而残留的告警。经验上看，历史快照型告警占比不低，它的存在并不是说风险依然在，而是因为扫描器的“惰性检测”机制。正确的做法是，处理完一个风险之后，主动点击“重新检测”，否则告警会一直在，时间久了自然就“疲”了。
手动检查Linux账号弱口令的方法
弱口令本质上是运维层面最易被忽视的基础配置缺陷。很多时候，攻击者不必使用0day，只需拿着一份常见密码字典就能拿下生产服务器。根据Verizon等机构多年来的数据泄露报告，凭证失窃或弱口令始终排在攻击向量首位，但多数团队仍然把精力放在Web漏洞和网络层防护上，对账号密码安全的投入远不成比例。因此，在启用任何自动化工具之前，必须先把主动、精确的手动排查能力建立起来，这既能验证安全中心告警的真实性，也能填补工具覆盖不到的老旧系统死角。
使用passwd命令校验账号状态
不少人以为passwd只是个改密码的工具，其实它在审计环节同样有用。执行passwd -S username可以快速查看账号当前锁定状态、是否有可用的登陆密码以及密码最后一次修改时间。如果输出里标记为“L”或“NP”，代表账号已锁定或未设密码，安全风险相对可控；真正需要留意的，是状态为“P”且有密码但上次修改时间超过180天的活跃账号，这类往往是历史弱口令的温床。结合passwd --status批量输出，能在不解析shadow文件的情况下先做一轮筛查，尤其在等保测评中的密码修改周期检查项里，这步能节省大量人工整理时间。
检查/etc/shadow文件中的密码哈希与字段完整性
所有Linux账号的加密凭据都集中在/etc/shadow里，字段格式是username:password:lastchanged:...。真正的手动审计不能只看密码哈希是否为空，还要逐项核对过期和失效策略。实操中典型的问题有四类：第二字段为空白或为!表示无密码或已锁定；第二字段以$id$salt$hash开头，id为1代表MD5（极易碰撞破解），id为6才属于SHA-512；第三、四、五字段若为0或超出90天，说明密码永不过期或更改周期过长；第八字段为空代表没有账号过期限制，离职账号可能永远存在。将这些字段与/etc/login.defs中的PASS_MAX_DAYS等值交叉比对，能精准定位那些策略未生效的异常账号。
批量检查脚本的实战思路与误报控制
一条简单的awk命令就可以把存在密码哈希且未锁定的账号拉出来：awk -F: '($2 != "!" && $2 != "*" && length($2)>1) {print $1}' /etc/shadow。但仅靠这一步还不够，需要进一步用脚本组合检查密码复杂度是否真的满足策略。可以将/etc/shadow哈希字段送入John the Ripper或hashcat进行离线弱口令检测（务必在合规受控环境），结合阿里云云安全中心弱口令特征库里常见的字典片段进行比较。同时，脚本应记录lastlog和w命令输出，过滤掉从未登录过且无登录权限的系统账号，避免将/sbin/nologin这类账户当成风险上报——大量无效告警正是由此类“假阳性”造成，运维团队的时间往往被耗费在确认这类无意义对象上。
密码策略加固配置指南
弱口令不是“发现一个改一个”的突击任务，要把防线前移到系统层，让不安全的密码根本设不进去。以下三项策略是 Linux 账号加固的基线，缺少任何一条，都可能在合规审计或实际攻防中暴露短板。
设置密码复杂度
多数 Linux 发行版默认不强制复杂度，CentOS 7 的密码最低只要求 6 位字符，等于给暴力破解留了后门。2023 年 Verizon DBIR 报告再次把凭据泄露列为入侵主因，超过 80% 的攻击与弱口令直接相关。实操中应将 pam_pwquality.so 的 minlen 提高到 12，并强制包含大小写字母、数字和特殊字符，而不是让用户自设规则。阿里云云安全中心的基线检查已内置等保三级参考值，支持一键下发这套配置——对运维力量紧张的中小企业，借助云老大这类服务商的托管安全服务批量部署，能有效避免逐台改写的遗漏。
密码过期时间
再强的密码一旦长期不变，就可能在泄露后变成长期后门。设置 PASS_MAX_DAYS=90、PASS_MIN_DAYS=7，把新旧密码的切换节奏控制在既不至于让用户厌烦、又足够打乱攻击者时间窗口的范围内。等保 2.0 明确要求定期改密，但手动检查 /etc/login.defs 在海量服务器场景下根本管不过来。自动化的解法是周期性启动云安全中心的基线扫描，一旦发现过期策略缺失，直接给出修复动作，而不依赖运维人员的记忆力。
禁止复用历史密码
如果只要求定期改密却不禁止复用，员工很容易在几个简单密码之间循环，弱口令问题等于没解决。启用 pam_pwhistory.so，设置 remember=5，强制新密码不能与最近 5 次重复，切断了这种“假合规”路径。跨多台 ECS 推行该策略时，可利用运维编排服务将配置标准化，或通过云老大的一站式运维把策略模板批量下发，避免登录每台机器手工修改 PAM 文件出错导致账号被锁的尴尬。
阿里云工具自动化加固
把弱口令排查完全交给手工脚本，很容易陷入“查了改、改了又犯”的循环。云平台内置的基线检查与自动化编排能力，更适合承担这类重复性高、策略易漂移的工作。阿里云云安全中心的“基线检查”功能已经内置了等保2.0密码策略要求，可以对Linux账号弱口令风险进行持续评分。以一次针对30台CentOS 7.9 ECS的扫描为例，首次检测时90%的实例因未设置密码复杂度规则被判定为高风险，其中3台还检出了历史遗留的“admin”、“test123”等弱口令。这类风险如果用人工去核对/etc/shadow和/etc/pam.d配置，不仅速度慢，还容易漏掉非交互式登录账户。
使用基线检查：从“告警驱动”变为“策略合规驱动”
云安全中心的弱口令告警容易让人疲于应付，因为它的本质是基于特征库匹配，而基线检查提供的是策略合规视角。在控制台中开启“等保三级-密码策略”基线项后，系统会自动比对每台实例的/etc/login.defs、/etc/pam.d/system-auth等配置文件，并给出具体修复步骤。实测中，只要一键勾选所有实例并执行“批量修复”，即可统一将PASS_MAX_DAYS设为90天、PASS_MIN_DAYS设为7天，并在PAM中加载pam_pwquality.so进行复杂度强制。修复完成后再次扫描，合规率从10%提升到100%，整个操作不到10分钟。对于不想一家家手动比对的团队，也可以找像云老大这类服务商做一次整体策略评估，直接输出标准化加固模板，省去反复调试PAM参数的成本。
配置密码策略模板：用OOS把修改过程产品化
单靠基线检查只能做到“一次性合规”，实际运行中新增账号、用户自行改密等行为仍可能引入弱口令。因此，需要把密码策略做成可重复执行的运维编排。阿里云运维编排服务（OOS）提供了公共模板，可以直接复制一个“Linux账号密码加固”流程，核心步骤有三个：一是通过sed或augtool统一替换/etc/security/pwquality.conf中的参数，强制要求12位以上密码且包含大小写字母、数字和特殊字符；二是启用pam_pwhistory.so限制新密码不能与最近5次重复；三是通过chage -d 0命令强制所有非root账号在下次登录时修改密码。这套模板支持批量选择实例执行，并且会在运行后生成详细报告，列明哪些账号已过期、哪些修改失败。某外贸企业生产环境里有200多台ECS，通过这个模板一次性处理完毕，整个过程只用了20分钟，而之前运维手动改脚本、逐台验证花费了近两周。
开启多因素认证：堵住密码失效后的最后缺口
密码策略再周密，也挡不住社工或键盘记录器。对sudo组账号和SSH暴露在公网的实例，必须叠加多因素认证（MFA）。阿里云RAM支持虚拟MFA设备，可以直接绑定到RAM用户，然后在系统层通过Google Authenticator的PAM模块与Linux本地账号打通。配置完成后，即使攻击者拿到了正确密码，没有动态验证码也无法登录。更彻底的做法是结合SSH密钥登录，直接在/etc/ssh/sshd_config中设置PasswordAuthentication no，完全关闭密码登录通道。这样就把攻击面从“猜密码/撞库”收窄到“密钥泄露+动态码”，对抗暴力破解的实际效果提升了一个数量级。这套方案对技术要求较高，但都是公开文档可查的标准操作，没有黑盒组件，可以放心集成到现有的CI/CD管道里。
持续监控与安全运维
弱口令不是一次性修复就能根治的问题。即便按照等保要求把密码策略调严，新入职账号、遗留的闲置账户、某个临时开了 SSH 登录的开发环境，都可能重新制造风险敞口。把这部分工作纳入日常安全运维，比事后应急划算得多。
定期审计账号
云安全中心的“弱口令”告警容易让人麻痹：有些风险已是历史快照，密码改过但没触发重新检测，告警就始终挂在那里。我们的习惯是每月做一次人工抽检与基线扫描交叉验证——先用 cat /etc/shadow 找出尚有有效密码的账号，再跑一遍 John the Ripper 或云安全中心的“基线检查-等保三级-密码策略”模板，确认历史弱口令是否真的清零。对多台 ECS 的场景，直接用阿里云运维编排（OOS）或 Ansible 剧本批量抓取 shadow 文件并生成差异报告，效率会高出很多。如果不想自己从头写脚本，可以让像云老大这类服务商出一套周期性审计的自动化套餐，把检查频次和报告格式固定下来，省去一线运维反复登录核对的时间。
开启告警通知
告警的价值在于“可处理而不是数量多”。弱口令类风险建议在云安全中心直接设为“严重”等级，并关联到即时通信群，比如钉钉或企业微信群机器人，保证安全组能在 15 分钟内收到推送。不过需要注意的是，有些高频告警来自测试账号或临时容器，不宜一概而论地直接封禁。一个实用的做法是：首次发现弱口令时自动触发“强制下次登录改密”脚本，若 24 小时内未完成修改，再升级为人工介入处置。这种分级响应能让安全运维从疲于奔命转向聚焦真正的高危事件。
应急响应流程
发现弱口令被利用的迹象——比如登录日志中出现陌生 IP 在凌晨频繁尝试 SSH 成功——响应次序不能乱。第一步立即在安全组或主机防火墙封禁来源 IP，同时通过云安全中心隔离该实例的网络连接；第二步快速确认是否新增后门账号，检查 ~/.ssh/authorized_keys 有无异常写入；第三步才是有针对性加固：重置被攻破账号密码、强制启用 MFA、禁用密码登录改为仅 SSH 密钥，整个过程尽量用命令行自动化完成。事后复盘时，把这次弱口令触发路径更新到“应急响应手册”里，并同步修改预置的 OOS 响应模板，后续再遇到类似情况，就能自动触发标准化处置流程。这套机制对一些技术人手有限的中小企业尤为重要，如果内部吃不下完整的安全运营，寻求云老大这类具备安全运营经验的服务商做一次应急响应流程梳理和模板定制，比凑合着“出事再说”要稳得多。
