用脚本检测MongoDB弱密码用户的方法

在进行MongoDB弱密码检测时，许多人认为只需写一个脚本连接数据库即可，然而实际遇到的坑远比想象中多。最常见的场景是：你使用mongo命令行能够正常登录，但换成Python脚本后却反复报认证失败——问题往往出在认证数据库（authentication database）没有被显式指定。许多脚本只传递了用户名和密码，默认采用admin库进行认证，而实际用户可能创建在test或local等其他数据库中，自然会被拒绝连接。另一个容易遗漏的细节是异常类型的区分：连接失败（ConnectionFailure）和认证失败（OperationFailure）是完全不同的两类问题，如果不加区分就简单判定为“不存在弱口令”，可能会遗漏真正的安全隐患。合理设置serverSelectionTimeoutMS也能避免脚本因超时而卡死，提升检测效率。

最可靠的方案仍然是借助pymongo进行登录尝试，但必须配合正确的连接参数以及细致的错误处理逻辑，否则空口令用户、认证数据库配置错误、或是超时误判等状况，都会导致检测结果失真，无法准确评估风险。

为什么mongo命令行能连接成功，脚本却报错？

在MongoDB的认证机制中，有三个关键参数缺一不可：用户名、密码和认证数据库（authentication database）。很多脚本只传入了username和password，默认采用admin作为认证库——然而实际用户可能被创建在test或其他数据库中，导致连接被拒绝，并抛出类似not authorized on admin to execute command的错误。

• 务必在连接字符串中显式指定authSource参数，例如authSource="admin"或authSource="test"，确保认证指向正确的数据库
• 如果不清楚认证数据库是哪一个，建议针对常见数据库（admin、test、local）分别进行尝试
• 空口令用户（例如user: "admin", pwd: ""）必须显式传递空字符串，不能使用None或直接省略该参数

使用pymongo.MongoClient连接时，需分清timeout与异常类型

连接失败并不等同于认证失败。网络不通、服务没有响应、或者bindIp配置有误等都可能导致超时，但这些情况与弱口令并无直接关系。如果盲目地将所有异常都归类为“失败”，反而会掩盖真正的安全风险，影响判断准确性。

• 设置serverSelectionTimeoutMS=3000用于控制连接建立超时时间，避免脚本长时间卡在等待状态
• 区分不同异常类型：ConnectionFailure（无法连接）、OperationFailure（已连接但认证失败）、ConfigurationError（参数配置错误，例如authSource指定的数据库不存在）
• 只有当异常类型为OperationFailure，并且错误消息中包含"Authentication failed"时，才能算作一次有效的认证尝试失败

如何避免扫描过程被阻断或触发安全告警？

MongoDB自身并没有内置的登录失败锁定机制，但高频并发试探很容易被防火墙限速、WAF拦截，或者导致日志量急剧膨胀，引起运维人员的警觉。因此，在生产环境中进行弱密码扫描必须保持克制，避免对正常业务造成影响。

• 单个IP对单一实例建议控制并发数不超过5个线程，每次尝试间隔至少1.5秒
• 除非目标明确启用了TLS，否则不要设置ssl=True，否则会直接导致连接失败
• 优先测试已知存在安全风险的常见用户名与密码组合：例如user in ["admin", "root"]配合pwd in ["", "123456", "admin", "password"]，不要一开始就使用完整字典进行大规模扫描
• 如果发现ping操作成功了，但执行db.admin.command("listDatabases")被拒绝，说明已经通过了认证——此时可以停止尝试其他密码，避免浪费资源

说实话，编写检测脚本本身并不复杂，真正的难点在于判断哪些IP值得扫描、哪些用户应该优先尝试、以及如何从一堆OperationFailure异常中准确找出那个真实的空口令——它往往隐藏在第一个成功建立连接却没有报认证错误的案例中，而不是等到你跑完整本字典后才出现。