数据库弱口令攻击解决方法

去年某地一家医院的数据内网被拖走2000万条患者数据，攻击者没用什么高级漏洞，库弱口令只是攻击用"admin/123456"登进了一个MySQL从库。这事听起来离谱，解决但类似案例在攻防演练里一抓一大把。数据数据库弱口令攻击的库弱口令本质不是技术问题，是攻击人的问题——运维图省事，开发图快，解决安全规范写在纸上没人执行。数据

我见过最夸张的库弱口令一台服务器，Redis端口直接暴露在公网，攻击连密码都没设。解决Redis有个特性，数据未授权访问时可以写文件到磁盘，库弱口令攻击者往authorized_keys里塞个公钥，攻击SSH直接免密登录。整个过程不需要任何 exploit 代码，redis-cli 敲几条命令就完事。这种案例在Shodan上随手一搜就是几万台。

先搞清楚攻击者怎么找目标

弱口令攻击不是盲猜。攻击者手里有字典——常见密码Top100、数据库默认账户表、企业名拼音缩写加年份的组合。他们用扫描器批量探测3306、5432、27017这些端口，发现开放的就用字典跑一遍。整个过程自动化，一台机器每秒能试几十个密码。

更麻烦的是内网横向。攻击者拿下Web服务器后，翻配置文件找到数据库连接串，密码往往是"root/root"或者"sa/123456"。这种横向移动几乎零成本，因为内网通常没有流量审计。

防御的核心思路

第一件事，数据库永远不要直接暴露在公网。如果业务必须外连，用白名单限制来源IP，或者套一层跳板机。我在阿里云上做过统计，开放3306到0.0.0.0/0的实例，平均每天被扫描3000次以上。

第二，密码策略要强制执行。长度至少16位，大小写加数字加符号，每90天轮换。有人觉得复杂密码记不住，那就用密码管理器，或者接入LDAP统一认证。别用应用名加年份这种规律，攻击者的字典里全有。

第三，删掉默认账户和测试库。MySQL装完就有test库，Oracle有scott/tiger，MongoDB默认无认证。这些不清理，等于给攻击者留后门。

具体操作层面的几个细节

MySQL 8.0之后默认安装了validate_password插件，可以强制密码复杂度。但很多人装完就把它卸了，嫌麻烦。我的建议是留着，配置成medium级别，至少要求长度8位、包含数字和字母。

PostgreSQL的pg_hba.conf文件里，把host all all 0.0.0.0/0 md5改成具体网段。别图省事写trust，那等于没密码。

Redis必须设requirepass，而且密码不能太短。Redis的认证是明文传输的，如果走公网还得配TLS。另外把rename-command CONFIG ""加进去，防止攻击者通过CONFIG SET写文件。

MongoDB启用认证后，还要注意角色权限。别给应用账户root角色，按最小权限原则只给读写权限。

监控和应急

数据库日志要开。MySQL的general_log虽然性能有影响，但可以临时开启排查。更实际的做法是配置审计插件，记录所有登录尝试。发现同一IP短时间内大量失败登录，直接封禁。

万一真被登进来了，先断网再分析。看binlog有没有异常写入，检查用户表有没有新增账户。我处理过一次，攻击者建了个backup用户，权限是ALL，藏在用户表最后一行，不仔细看根本发现不了。

弱口令这事没有一劳永逸的解法。密码策略、网络隔离、权限控制、日志审计，四层里少一层都可能在某个深夜被撞开。最怕的是那种"我们内网很安全"的心态，攻击者往往就是从一台没人管的测试库开始的。

本文地址：http://www.79wt.cn/news/1388c9899763.html