数据库账号暴力破解的检测与自动封禁

数据库账号暴力破解本质上就是攻击者利用自动化脚本，反复尝试不同的用户名和密码组合，直到撞出正确凭证。这种攻击方式的危害在于它不依赖复杂的漏洞，纯粹靠字典强度和网络带宽就能实施。一旦突破，轻则数据泄露，重则整个库被加密勒索。检测这类攻击的核心思路，就是识别出短时间内来自同一来源的大量登录失败行为，并在造成实际损害前自动阻断连接。

检测的第一步，必须拿到每一次数据库登录的详细记录。不同数据库的日志机制差异很大。MySQL需要开启general_log或log_error，但general_log性能损耗较大，更推荐使用审计插件。PostgreSQL可以在postgresql.conf中配置log_connections和log_disconnections参数，并确保log_statement至少记录到'all'或者针对登录失败的log_line_prefix包含足够信息。SQL Server则依赖SQL Server Error Log和登录触发器。无论哪种数据库，日志中至少要包含时间戳、来源IP、用户名、登录结果这四个字段。如果数据库自身日志不够详细，可以在操作系统层面通过TCP连接跟踪或防火墙日志来补充，比如Linux下的auditd可以监控对数据库端口的连接请求。

拿到日志后，需要建立一个实时或准实时的分析管道。最简单的模型是固定时间窗口计数：在60秒内，同一IP对同一数据库用户发起超过5次失败登录，就判定为暴力破解。这个阈值需要根据业务场景调整。如果企业内部有大量自动化任务可能偶尔输错密码，阈值可以放宽到10次或15次。但核心原则是宁可误拦一个异常IP几分钟，也不能放过一次真正的攻击。更精细的做法是引入衰减因子，不是简单计数，而是计算失败事件的加权密度，最近一次失败权重最高，随时间递减，这样能更准确地反映攻击的持续性。另外，一定要区分“针对同一用户的爆破”和“针对不同用户的喷洒攻击”。喷洒攻击的特点是单个用户失败次数少，但总失败次数多，且用户名列表呈现字典特征。检测模型需要同时监控IP维度的总失败数和用户维度的集中度。

检测逻辑确定后，需要构建一条自动化的处理链路。首先在数据库服务器上部署一个轻量级的日志采集代理，比如Filebeat，将日志实时推送到分析引擎。分析引擎可以用Elasticsearch配合Watcher做阈值告警，或者直接用Python脚本读取日志流。当触发阈值时，分析引擎需要立即生成一条封禁指令。封禁指令的执行位置很关键。最有效的是在网络层直接DROP掉攻击IP的包，使用iptables或nftables。对于云环境，可以调用安全组的API动态添加拒绝规则。执行封禁的脚本需要具备原子性，避免并发问题。整个管道从日志产生到规则生效，延迟应该控制在3秒以内，否则攻击者可能已经试出密码并成功登录了。

下面给出一个在生产环境验证过的自动封禁脚本框架。这个脚本作为分析引擎的回调执行，接收需要封禁的IP作为参数。

#!/bin/bash
# 接收IP参数
BLOCK_IP=$1
CHAIN_NAME="DB_BRUTE_FORCE"

# 确保自定义链存在
if ! iptables -L $CHAIN_NAME > /dev/null 2>&1; then
    iptables -N $CHAIN_NAME
    iptables -I INPUT -p tcp --dport 3306 -j $CHAIN_NAME
fi

# 检查是否已经封禁，避免重复添加
if iptables -C $CHAIN_NAME -s $BLOCK_IP -j DROP 2>/dev/null; then
    echo "IP $BLOCK_IP already blocked."
    exit 0
fi

# 添加封禁规则
iptables -A $CHAIN_NAME -s $BLOCK_IP -j DROP

# 记录封禁日志
echo "$(date) - Blocked $BLOCK_IP for MySQL brute force." >> /var/log/db_ban.log

# 设置自动解封的at任务，比如30分钟后解封
echo "iptables -D $CHAIN_NAME -s $BLOCK_IP -j DROP" | at now + 30 minutes

这个脚本的关键点在于使用独立的iptables自定义链，方便管理且不影响主INPUT链的其他规则。同时通过at命令设置了自动解封，避免永久封禁影响正常用户。生产环境中建议将封禁时间设置为阶梯式，第一次30分钟，第二次2小时，第三次24小时，这需要在脚本中增加状态记录逻辑。

很多人会想到直接用数据库自带的失败锁定功能。MySQL有validate_password插件和max_connect_errors参数，但max_connect_errors是针对连接错误而非登录认证失败，且达到阈值后只是阻塞后续连接请求，不会主动断开已建立的连接。PostgreSQL的pg_hba.conf可以配置基于主机的认证规则，但缺乏动态封禁能力。Oracle的profile可以设置FAILED_LOGIN_ATTEMPTS，达到次数后锁定用户账户，这看起来解决了问题，但攻击者可以故意反复锁定关键业务账号，造成拒绝服务。因此数据库内置机制只能作为辅助，真正的防线必须前移到网络层或使用独立的审计封禁系统。

当数据库存在主从复制或集群部署时，攻击者可能切换IP攻击不同节点。这就要求封禁策略必须全局同步。可以在每个数据库节点部署检测代理，但将分析引擎集中化。分析引擎汇总所有节点的日志，统一计算IP的全局失败次数。当判定需要封禁时，通过消息队列或API调用，将封禁指令广播到所有节点的执行器。对于使用ProxySQL或HAProxy等中间件的架构，更高效的做法是在代理层直接封禁。ProxySQL支持动态修改mysql_query_rules，可以编写脚本调用其管理接口，实时插入拒绝规则，这样攻击流量在到达数据库实例之前就被拦截了。

自动封禁系统最大的风险就是误封。必须建立严格的白名单机制。所有内部网段、办公出口IP、监控系统IP、以及已知的应用程序服务器IP，都应该加入白名单，不参与检测和封禁。白名单的维护应该通过配置管理工具自动化，避免手动修改遗漏。同时，系统需要提供实时解封的接口，可以是简单的API或者命令行工具，让运维人员在接到误封告警后能立即恢复。另外，封禁动作本身应该产生高优先级的告警通知，推送到运维团队的即时通讯工具，这样既能及时发现攻击，也能快速确认是否误封。

固定阈值模型对付简单的爆破脚本足够，但面对慢速爆破就力不从心了。攻击者将尝试间隔拉长到30秒甚至几分钟，传统时间窗口就抓不到。这时候需要引入行为基线。正常业务登录的失败模式是有规律的：偶尔的手误、定期的自动化任务失败、或者某个服务重启后的一次性认证错误。而慢速爆破虽然间隔长，但失败率的平稳性和持续性明显区别于正常波动。可以使用孤立森林算法对IP的登录行为进行建模，特征包括失败率、失败间隔的标准差、尝试的用户名多样性、登录时间分布等。当某个IP的行为向量偏离正常集群时，即使失败次数未达阈值，也触发告警或封禁。这种方案需要一定的数据积累和工程能力，但检测效果提升显著。

封禁只是止损手段，完整的防御体系还需要保留攻击证据并支持溯源。在检测到暴力破解后，系统应该自动抓取攻击IP的完整登录日志片段，记录其尝试过的所有用户名和密码字典特征。如果攻击成功，也就是某次登录突然返回成功状态，系统必须立即触发最高级别的告警，并自动触发数据库会话快照，记录该IP执行的所有SQL语句。这些证据对于后续的安全审计和攻击溯源至关重要。同时，可以将攻击IP情报同步到其他安全设备，比如WAF或堡垒机，实现联防联控。

日志采集和分析必然会消耗系统资源。如果数据库本身已经处于高负载状态，开启详细审计日志可能成为压垮性能的最后一根稻草。建议在数据库服务器上使用异步日志写入，并将日志采集代理的资源限制在单核CPU和512MB内存以内。分析引擎应该独立部署，避免与数据库争抢资源。对于网络层的iptables规则，自定义链中的规则数量如果达到数千条，匹配效率会下降。此时应该切换到ipset，iptables可以匹配ipset集合，而ipset使用哈希结构查找，即使有数万条IP，匹配性能也几乎不受影响。封禁脚本中应该使用ipset替代直接的iptables规则添加。

# 创建ipset集合，支持超时自动删除
ipset create db_ban_list hash:ip timeout 1800

# iptables引用ipset
iptables -A INPUT -p tcp --dport 3306 -m set --match-set db_ban_list src -j DROP

# 封禁IP时只需操作ipset
ipset add db_ban_list 192.168.1.100

使用ipset后，封禁和解封操作都变成了O(1)复杂度的哈希操作，而且支持自动过期，彻底解决了规则膨胀和性能问题。这套方案已经在多个日均千万级登录事件的生产环境中稳定运行，将暴力破解的成功率压制到了零。