网站后台登录接口被暴力破解的检测规则与锁定策略

后台登录接口的暴力破解早已不是新鲜事，但绝大多数防御策略仍然停留在“连续失败N次锁定账号”的初级阶段。这种一刀切的做法在面对分布式代理池和慢速爆破时几乎形同虚设。真正有效的检测规则，必须从单点IP频率限制转向多维度的行为异常分析。你需要关注的不是“谁输错了密码”，而是“谁在以一种非人类的方式尝试登录”。

登录接口的防护难点在于攻击者越来越擅长模拟正常流量。单纯统计某个IP的失败次数，攻击者用几十万个代理IP就能轻松绕过。更有效的做法是同时监控以下几个维度的数据，并将它们关联起来。

第一个维度是IP的请求频率和节奏。人类输入用户名和密码，哪怕用上密码管理器，两次请求之间也必然存在秒级的间隔，且间隔时间带有自然的随机波动。脚本发起的请求间隔往往精确到毫秒级，或者呈现固定的周期性。你可以记录每个IP最后三次请求的时间戳，计算间隔的标准差。标准差极小，说明是机器行为。

第二个维度是账号的全局失败次数。不要只盯着单个IP对一个账号的尝试，要关注某个账号在短时间内是否被来自不同IP的请求反复尝试。攻击者经常使用“一IP一请求”的战术，每个代理IP只试一次密码就丢弃。如果某个账号在5分钟内被来自10个以上不同城市的IP尝试登录且全部失败，这几乎可以断定是一次分布式暴力破解。

第三个维度是请求指纹的一致性。攻击者为了效率，通常会使用同一套脚本或工具。这些工具在HTTP请求头、TLS握手特征、JavaScript执行环境等方面会留下高度一致的指纹。你可以收集User-Agent、Accept-Language、屏幕分辨率、时区、WebGL渲染器信息等。如果大量来自不同IP的登录请求，其请求头组合和浏览器指纹完全一致，那这些请求背后极有可能是同一个攻击者控制的僵尸网络。

第四个维度是用户名枚举的检测。很多暴力破解的前置步骤是用户名枚举。攻击者会先通过接口返回的信息差异判断某个账号是否存在，然后对存在的账号发起攻击。你需要确保登录接口在任何失败情况下返回的信息完全一致，无论是账号不存在还是密码错误，都返回相同的错误提示，HTTP状态码和响应体结构也必须毫无差别。同时，监控那些连续尝试大量不存在用户名的IP，这也是一个高危信号。

固定的阈值规则很难适应复杂的网络环境。一个大型企业出口IP后面可能同时有几百人在登录系统，失败次数自然会高；而一个深夜时段的个人家庭宽带，连续失败3次就非常可疑。引入动态阈值机制，能让检测规则更贴合实际场景。

你可以基于历史数据为每个IP或IP段建立行为基线。统计过去7天内该IP在登录接口的平均失败次数和峰值失败次数，结合当前时段是业务高峰期还是低谷期，动态调整触发告警的阈值。对于从未出现过登录行为的IP，其初始阈值应该设得很低，因为正常用户首次登录失败一两次很正常，但一个全新的IP上来就连续失败多次，风险极高。实现上，可以用滑动窗口算法，统计一个时间窗口内的失败计数，窗口长度和阈值都根据基线动态计算。

检测到异常后，如何锁定是一门艺术。直接封禁IP会误伤NAT网络后的正常用户，永久锁定账号则可能被攻击者利用来进行拒绝服务攻击。合理的做法是采取分层次、渐进式的锁定策略。

第一层是验证码挑战。当某个IP或账号的失败次数达到一个较低的阈值时，不直接阻断请求，而是在登录流程中强制插入验证码。这个验证码不能是简单的图形文字识别，最好采用滑块拼图或无感验证，对用户体验影响小，但能有效阻挡自动化脚本。验证码通过后，重置该维度的计数器。

第二层是IP的临时限制。如果验证码挑战后失败次数继续上升，说明攻击者可能具备自动打码能力。此时对该IP实施短时间封锁，比如15分钟。这个时间足以打断攻击节奏，又不会对误入的普通用户造成太大困扰。封锁期间，该IP的所有登录请求直接返回验证失败，不进行实际的密码校验，这样能节省后端认证服务的资源。

第三层是账号的全局保护锁定。当某个账号在全局范围内的失败尝试达到高危阈值时，对该账号实施临时冻结。冻结期间，即使输入正确密码也无法登录，必须通过预留的邮箱或手机号进行二次验证才能解锁。这个策略能有效对抗分布式密码喷洒攻击，攻击者即便掌握了海量IP，也无法绕过账号维度的锁定。

第四层是IP的长期信誉降级。对于反复触发临时封锁的IP，将其加入灰名单。灰名单内的IP发起的任何请求，默认就需要完成高难度的验证挑战，或者限制其访问频率。这个信誉评分可以随时间衰减，如果该IP后续行为正常，分数会逐渐恢复。

在具体实现时，有几个细节决定了整个防御体系的成败。首先是计数器的存储，必须使用高性能的内存数据库，比如Redis。每次登录失败后，同时对IP维度和账号维度的计数器执行原子递增操作，并设置合理的过期时间。

# 使用Redis实现IP维度的滑动窗口计数
# 记录每次失败的时间戳，使用有序集合存储
import time
import redis

r = redis.Redis()

def record_failed_attempt(ip, window_seconds=300):
    now = time.time()
    pipe = r.pipeline()
    # 将当前时间戳加入有序集合
    pipe.zadd(f"login_fail:{ip}", {str(now): now})
    # 移除窗口外的旧记录
    pipe.zremrangebyscore(f"login_fail:{ip}", 0, now - window_seconds)
    # 获取窗口内的失败次数
    pipe.zcard(f"login_fail:{ip}")
    # 设置键的过期时间，避免内存泄漏
    pipe.expire(f"login_fail:{ip}", window_seconds * 2)
    _, _, fail_count, _ = pipe.execute()
    return fail_count

其次是锁定状态的判断逻辑，必须放在密码验证之前。很多系统的做法是先查询数据库验证密码，如果失败再记录错误次数。这导致攻击者的每次请求都会触发一次数据库查询和密码哈希计算，消耗大量资源。正确的顺序是：先检查该IP或账号是否处于锁定状态，如果是则直接返回错误；然后检查失败次数是否触发验证码，如果触发则返回验证码要求；最后才进行真正的密码校验。这样能将绝大多数恶意请求拦截在消耗资源的操作之前。

def login_handler(request):
    ip = get_client_ip(request)
    username = request.POST.get('username')
    
    # 第一层：检查IP是否被临时封锁
    if r.exists(f"ip_blocked:{ip}"):
        return error_response("请求过于频繁，请稍后再试")
    
    # 第二层：检查账号是否被全局冻结
    if r.exists(f"account_frozen:{username}"):
        return error_response("账号已被临时保护，请通过邮箱解锁")
    
    # 第三层：检查是否需要验证码
    ip_fail_count = get_ip_fail_count(ip)
    if ip_fail_count > CAPTCHA_THRESHOLD:
        if not verify_captcha(request.POST.get('captcha')):
            return error_response("验证码错误")
    
    # 最后才进行真正的密码验证
    user = authenticate(username, request.POST.get('password'))
    if user is None:
        # 记录失败，更新各维度计数器
        record_failure(ip, username)
        return error_response("用户名或密码错误")
    
    # 登录成功，清除相关计数器
    clear_failure_records(ip, username)
    return success_response(user)

再者，对于分布式攻击，单机计数器是不够的。如果你的服务部署在多个节点上，必须确保所有节点共享同一套计数和锁定状态。Redis集群或集中式的计数器服务是必需的。同时，登录接口的响应时间也需要监控，如果某类请求的响应时间突然变长，可能是攻击者在进行慢速攻击，企图耗尽连接池。

任何自动化防御策略都无法做到百分之百准确，必须设计好误伤恢复机制。对于被临时封锁的IP，在封锁页面给出明确的提示和剩余等待时间，并提供联系管理员的渠道。对于被冻结的账号，提供自助解锁方式，比如发送验证码到绑定手机或邮箱，用户点击链接即可立即解冻并登录。这既保证了安全性，又不会让真实用户感到绝望。

同时，建议在管理后台提供白名单功能，将公司出口IP、运维人员常用IP等加入白名单，这些IP不受频率限制和锁定策略影响。对于付费客户或高级权限账号，可以适当放宽阈值，或者启用更安全的双因素认证来替代锁定策略。

检测规则和锁定策略不是一成不变的。你需要记录每一次锁定事件的详细信息，包括触发锁定的具体维度、当时的计数数值、IP归属地、请求指纹等。定期分析这些日志，可以发现攻击手法的变化趋势。比如，如果发现大量锁定事件都集中在某个地区的IP段，且请求指纹相同，说明攻击者可能租用了该地区的机房，你可以考虑对该IP段整体降低信任度。

另外，将登录失败日志同步到安全信息和事件管理系统，结合其他系统的告警进行关联分析。一个IP在暴力破解登录接口的同时，可能还在扫描其他端口或进行SQL注入尝试，这些信息综合起来能更准确地判定攻击性质，并推动网络层面的联动封堵。