翻一下远程登录日志，一天里来自不同地址的尝试经常有几千次，账号名从 root、admin 到 test、oracle 挨个试，密码列表里全是简单的数字组合和常见单词。这种攻击不需要任何技巧，只要机器对公网开着管理端口，就会被自动扫到。更麻烦的是，有些设备和管理面板用的是出厂默认口令，安装完没人改，等于把钥匙插在门上。
弱密码的问题不在于复杂度不够，而在于它出现在公开的字典里。只要密码能在常见的泄露库里搜到，再复杂也撑不住几轮尝试。
最有效的一招往往不是换密码，而是让攻击者根本连不上。管理端口改成一个不常见的高位端口，能过滤掉绝大部分自动化扫描；更稳的做法是改用密钥登录并关掉密码认证；再配合安全组，只允许公司出口或跳板机的地址访问管理端口。云平台的控制台登录同样要收：绑定固定出口、开启登录保护、关掉不再使用的账号。
普通用户的账号也要管。给每个使用者单独开账号并配好授权，不要多人共用最高权限账号；离职或调岗后及时清理；给服务用的账号禁止交互登录，只能跑指定程序。这些看起来繁琐，出问题时却能一眼看出是谁操作的。
指望每个人自觉设强密码不现实，得有机制。对内网账号统一接入集中认证，把口令策略、复杂度、有效期、失败锁定交给它管；云上的账号启用多因素认证，即使密码泄露还有一道验证；数据库、缓存、对象存储这些组件的口令单独生成并定期轮换，不要和系统账号复用。
已经存在的弱密码要能找出来。可以拿常见泄露口令字典对内部账号做一次离线比对，重点看数据库、后台、运维工具这几类；也可以借助专门的口令审计工具扫描。发现之后不是简单改掉就完事，还要回溯这些账号最近的登录日志，确认有没有异常来源登录过。
轮换口令这件事要提前安排。很多团队等到出事才集中改一遍密码，改完之后没有记录，过一阵子又回到原来的样子。比较稳的做法是给每类账号定一个周期，到期前提醒，改完登记到凭据管理系统里，需要时按权限取用，而不是靠人与人之间传递。这样既避免了口令在同一批人手里反复流转，也让谁在什么时候取用过哪条凭据有据可查。真出了事，能迅速定位到泄露的环节，而不是把所有人都换一遍口令了事。
密钥同样要定期轮换。长期不换的密钥一旦泄露，影响会一直持续到被发现为止，而密钥泄露往往没有任何告警。
加固时大家的注意力都在登录账号上，容易被忽略的是那些不常使用的账号：测试环境遗留的账号、外包人员开通后没回收的账号、装软件时顺手建的账号。它们平时不产生登录日志，一旦被使用很难发现异常，往往是攻击者拿到权限之后最喜欢保留的后门。
比较实际的做法是定期拉一份账号清单，逐个确认是否还在使用、权限是否还合适。超过一定时间没有登录记录的，先禁用而不是直接删除，观察一段时间确认没有影响再清理。
发现正在被破解时，别急着一条条封来源——地址往往是分散的，封不胜封。更有效的顺序是：先确认密码策略和认证方式还有没有漏洞，把密码认证换成密钥、把多因素开起来；再看有没有成功登录的记录，重点核对失败次数很多却突然成功的那一次；必要时临时缩小管理端口的来源范围，把攻击面压到最小。
事后回头看日志能发现不少信息：被尝试的账号名说明攻击者认为这台机器上有哪些服务；尝试的时间分布能看出是自动化脚本还是有人在操作。把这些整理出来，后续加固就有明确方向。账号安全没有一劳永逸的配置，定期复核一次授权和口令，比出事后补救轻松得多。
售后客服
企业微信
