数据库弱口令检测与安全加固完整流程

数据库弱口令问题，是安全攻防对抗中最古老、最基础，却至今仍高居漏洞排行榜前列的致命伤。无论部署了多少台下一代防火墙，配置了多少条入侵防御策略，一个root/root或者sa/123456的凭据组合，就能让攻击者在几秒钟内拿到数据库的最高权限。这不是理论推演，而是每天都在发生的现实。解决这个问题不需要高深莫测的技术，需要的是系统化的检测手段和铁腕的执行流程。

弱口令绝不仅仅是“123456”或“password”这么简单。在实际工作中，弱口令包含三个层次：第一是默认出厂口令，比如MySQL的root空密码、PostgreSQL的postgres无密码、Oracle的scott/tiger等，这些在安装后未被修改的初始凭证是最危险的。第二是简单组合口令，包括admin/admin、sa/sa123456、test/test等，以及数据库名与口令相同的情况，比如wordpress数据库用户密码也是wordpress。第三是符合复杂度要求但已被泄露的口令，这些口令虽然包含大小写字母、数字和特殊符号，但由于曾在其他平台泄露，被收录进了社工库，攻击者通过撞库同样可以轻松获取。理解这三个层次，才能在执行检测时做到全面覆盖。

在动手检测之前，必须完成资产测绘工作。很多安全团队之所以漏掉弱口令，根本原因不是工具不行，而是根本不知道公司有多少数据库实例。需要梳理的内容包括：所有内网和外网开放的数据库端口，MySQL默认3306、MSSQL默认1433、Oracle默认1521、PostgreSQL默认5432、Redis默认6379、MongoDB默认27017；每个数据库实例的版本信息，因为不同版本的认证机制有差异；数据库账号列表，包括系统账号、业务账号、运维账号和管理账号；网络可达性，确认检测主机到目标数据库的网络是否畅通，是否需要跳板机。把这些信息整理成表格，后续的检测工作才能有条不紊地推进。

虽然市面上的自动化扫描工具很多，但在生产环境中直接使用往往风险不可控。自研脚本的好处是逻辑透明、可定制、不会触发莫名其妙的插件行为。以下是一个基于Python的多线程MySQL弱口令检测脚本的核心逻辑，重点在于连接超时控制和错误码处理，避免因为频繁尝试导致账号被锁定。

import pymysql
import threading
import queue
import time

class MySQLBruteChecker:
    def __init__(self, host, port, user_dict, pass_dict, threads=10):
        self.host = host
        self.port = port
        self.user_dict = user_dict
        self.pass_dict = pass_dict
        self.queue = queue.Queue()
        self.threads = threads
        self.results = []
        self.lock = threading.Lock()
        
    def load_targets(self):
        for user in self.user_dict:
            for pwd in self.pass_dict:
                self.queue.put((user, pwd))
    
    def check_single(self):
        while not self.queue.empty():
            user, pwd = self.queue.get()
            try:
                conn = pymysql.connect(
                    host=self.host,
                    port=self.port,
                    user=user,
                    password=pwd,
                    connect_timeout=5,
                    charset='utf8mb4'
                )
                with self.lock:
                    self.results.append((user, pwd, True))
                conn.close()
            except pymysql.err.OperationalError as e:
                error_code = e.args[0]
                if error_code == 1045:
                    pass
                elif error_code == 1129:
                    print(f"[警告] 账号{user}因频繁尝试被锁定，等待60秒")
                    time.sleep(60)
                else:
                    print(f"[错误] 连接异常: {e}")
            except Exception as e:
                print(f"[异常] {user}:{pwd} - {e}")
            finally:
                self.queue.task_done()
    
    def run(self):
        self.load_targets()
        threads_list = []
        for _ in range(self.threads):
            t = threading.Thread(target=self.check_single)
            t.daemon = True
            t.start()
            threads_list.append(t)
        self.queue.join()
        return self.results

这个脚本的关键设计在于：连接超时设置为5秒，避免长时间阻塞；捕获1045错误码代表口令错误，静默跳过；捕获1129错误码代表连接频率过高被锁定，主动休眠等待；所有结果通过线程锁安全写入列表。实际使用时，用户名字典和口令字典需要根据前期资产梳理的结果来定制，而不是盲目使用通用大字典。比如已知该数据库业务系统使用admin账号，就优先针对admin进行爆破，效率会高得多。

自研脚本适合精细化的单点检测，但面对几十上百个数据库实例时，还是需要专业工具来提高效率。Hydra和Medusa是两款经典的在线破解工具，支持几乎所有主流数据库协议。以Hydra检测MSSQL为例，命令如下：

hydra -L user.txt -P pass.txt -t 4 -f -v 192.168.1.100 mssql

参数解释：-L指定用户名字典，-P指定口令字典，-t 4表示同时4个线程，-f表示找到第一组有效凭据就停止，-v显示详细过程。对于Oracle数据库，协议名改为oracle，对于PostgreSQL改为postgres。需要注意的是，线程数不要设置太高，4到6个线程是比较稳妥的选择，既能保证效率，又不会因为并发过高触发目标数据库的登录限制策略。Nmap的脚本引擎也能做弱口令检测，命令为nmap -p 3306 --script mysql-brute 目标IP，但Nmap自带的字典较小，实际检出率不如Hydra配合自定义字典。

对于某些特定数据库，专用工具的效果远超通用工具。比如针对MSSQL的SQLPing3，不仅能检测弱口令，还能探测数据库版本、实例名、是否开启xp_cmdshell等关键信息。针对Oracle的OraBrute，专门处理TNS协议和SID枚举。针对Redis，由于其协议简单，直接用redis-cli配合bash脚本就能批量检测未授权访问和弱口令。下面这段bash脚本可以快速扫描内网Redis实例：

#!/bin/bash
for ip in $(cat redis_hosts.txt); do
    result=$(redis-cli -h $ip -a "password123" --no-auth-warning PING 2>&1)
    if [[ "$result" == "PONG" ]]; then
        echo "[弱口令] $ip 口令为 password123"
    fi
done

MongoDB的情况类似，很多老版本默认不需要认证，新版本即使开启了认证，也经常出现admin/admin的情况。使用mongosh或者pymongo编写检测脚本时，要特别注意连接字符串的格式和认证数据库的指定。

工具跑出来的结果不能直接写进报告，必须经过人工验证。原因有三：第一，某些数据库的认证机制在密码错误时会返回模糊的错误信息，工具可能误判；第二，网络抖动或数据库负载过高可能导致连接超时，工具将其误报为口令错误；第三，部分数据库存在登录触发器，即使口令正确也可能被拒绝。验证方法很简单，用标准的数据库客户端手动连接一次，确认能够成功登录并执行一条查询语句，比如MySQL执行SELECT VERSION()，MSSQL执行SELECT @@VERSION，Oracle执行SELECT * FROM v$version。只有手动验证通过的，才能确认为有效弱口令。

检测只是第一步，加固才是最终目的。口令策略的制定要遵循“最小权限、足够强度、定期轮换”三个原则。具体操作上，首先要删除或锁定所有不需要的默认账号和测试账号。MySQL中执行DROP USER 'test'@'%'，MSSQL中执行ALTER LOGIN sa DISABLE，Oracle中执行ALTER USER SCOTT ACCOUNT LOCK。其次，为所有业务账号设置符合复杂度要求的口令，长度至少12位，包含大小写字母、数字和特殊字符，且不与业务名称、公司名称有任何关联。MySQL修改口令的命令为ALTER USER 'username'@'host' IDENTIFIED BY '新口令'，MSSQL为ALTER LOGIN username WITH PASSWORD = '新口令'，Oracle为ALTER USER username IDENTIFIED BY "新口令"。再次，配置登录失败锁定策略，MySQL通过安装validate_password插件并设置FAILED_LOGIN_ATTEMPTS参数实现，MSSQL在服务器属性中设置登录锁定阈值，Oracle通过FAILED_LOGIN_ATTEMPTS参数配置。

口令加固只是第一道防线，纵深防御还需要多个层面的配合。网络层面，通过防火墙或安全组限制数据库端口的访问来源，只允许应用服务器和运维堡垒机的IP地址连接，拒绝所有其他来源。传输层面，强制启用SSL/TLS加密，防止口令在网络上明文传输被嗅探。认证层面，对于核心数据库，引入双因素认证或证书认证，即使口令泄露也无法直接登录。审计层面，开启数据库的详细审计日志，记录所有登录尝试，包括成功和失败的，MySQL的general_log、MSSQL的登录审核、Oracle的审计功能都要配置到位。监控层面，建立登录异常告警机制，当某个账号在短时间内出现大量失败登录，或者从非工作时间、非预期IP地址登录时，安全运营中心能第一时间收到告警。

一次性检测和加固解决不了根本问题，因为新业务上线、开发人员临时调试、运维人员紧急操作，随时可能引入新的弱口令。必须建立长效机制：第一，将弱口令检测纳入新系统上线前的安全检查流程，不通过检测不允许上线；第二，每月至少执行一次全量数据库弱口令扫描，扫描结果纳入安全考核指标；第三，建立口令管理规范，禁止在任何文档、代码、配置文件中明文存储口令，强制使用密钥管理服务或凭据管理系统；第四，定期开展安全培训，让开发、运维人员真正理解弱口令的危害，而不是把安全要求当成麻烦。只有把这些措施固化为制度和流程，弱口令这个老问题才能得到持续有效的控制。

每种数据库都有自己独特的安全配置项，这些配置如果被忽略，即使口令再复杂也无济于事。Redis必须设置requirepass，同时禁止使用CONFIG命令修改配置，在redis.conf中重命名或禁用危险命令：rename-command FLUSHALL ""，rename-command CONFIG ""。MongoDB必须启用访问控制，在mongod.conf中设置security.authorization为enabled，并且绑定到内网IP，设置bindIp为内网地址而非0.0.0.0。MySQL要特别注意FILE权限的控制，因为这个权限允许用户读写服务器文件，通过REVOKE FILE ON *.* FROM 'user'@'host'收回非必要账号的FILE权限。PostgreSQL的pg_hba.conf文件控制着客户端认证方式，要确保所有远程连接都使用md5或scram-sha-256认证，而不是trust。

数据库弱口令的检测与加固，本质上是一场与人性弱点的持久对抗。技术手段可以解决大部分问题，但最终决定安全水平的，是组织对安全规范的执行力度和持续投入的决心。把上述流程真正落地执行，而不是停留在纸面上，才能让攻击者无机可乘。