MongoDB弱密码检测需显式指定authSource认证库,区分ConnectionFailure与OperationFailure异常。空口令用户传空字符串,设serverSelectionTimeoutMS控制超时。扫描限并发、频率,优先测admin、root等高危账户。
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拦截,或者把日志填得满满当当,引起运维人员的警觉。生产环境做扫描必须克制。
ssl=True,否则会直接失败user in ["admin", "root"]配合pwd in ["", "123456", "admin", "password"],别一上来就跑完整字典ping成功了,但db.admin.command("listDatabases")被拒绝,说明已经通过了认证——这时候就可以停手了,不用继续试其他密码说实话,写检测脚本本身并不难,真正难的是判断哪些IP值得扫、哪些用户该优先试、以及如何从一堆OperationFailure里挑出那个真实的空口令——它往往藏在第一个成功建立连接却没有报认证错的case里,而不是等你把字典跑完才出现。
侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述