针对登录接口的慢速CC攻击防御实践

慢速CC攻击，尤其是针对登录接口的慢速CC，是当下Web应用面临的最隐蔽、最难防御的攻击类型之一。它不像洪水攻击那样瞬间打满带宽或CPU，而是像温水煮青蛙，通过极低的速率、长时间维持连接，逐渐耗尽服务器的连接池、数据库连接或会话资源，最终导致正常用户无法登录。登录接口之所以成为重灾区，是因为它通常涉及数据库查询、密码加密比对、会话创建等高成本操作，攻击者用极小的代价就能撬动巨大的服务端资源消耗。

要防御，先要看清对手。慢速CC攻击在登录接口上通常表现为每秒只有几个甚至更低的请求，每个请求的IP都是真实的、分散的，请求内容完全符合HTTP协议规范，用户名和密码看起来也是合法的格式。它和正常用户输错密码的行为高度相似，传统基于频率的限速策略很难奏效。你如果把阈值设高了，攻击流量就能混过去；设低了，正常用户稍微手抖多输错几次就被封禁。攻击者还会利用HTTP/1.1的Keep-Alive特性，在请求头中声明一个很长的超时时间，然后缓慢发送请求体，或者在发送完请求后不关闭连接，持续占用服务器的Worker线程。

更深层次的识别难点在于，攻击者往往会利用代理池、肉鸡或者家庭宽带IP，每个源IP的请求频次极低，完全落在正常用户的基线范围内。你去看日志，可能来自几千个不同城市的IP，每个IP一小时只请求了十几次，单看任何一个IP都毫无异常。但聚合到登录接口的整体负载上，就会发现连接数持续偏高，数据库的慢查询逐渐堆积，登录成功率下降，响应时间变长。这种攻击的破坏是渐进式的，等你从监控告警中发现异常时，服务可能已经濒临不可用的边缘。

防御慢速CC攻击不能靠单一手段，必须构建一个从前置代理到应用层、再到数据层的纵深防御体系。第一层是网络边缘的限流和连接管理，第二层是应用层的请求合法性校验和行为分析，第三层是业务层的风险决策和处置。

在边缘层，反向代理或负载均衡器需要承担起连接管理的职责。对于慢速攻击，最有效的手段之一是限制客户端请求的传输超时和最小传输速率。比如在Nginx上，可以通过client_body_timeout和client_header_timeout来限制客户端发送请求头和请求体的最长时间，通过send_timeout来限制服务端响应传输给客户端的时间。更关键的是limit_rate相关指令，可以要求客户端在指定时间内必须发送完数据，否则直接断开连接。

# Nginx配置示例：防御慢速请求体攻击
server {
    listen 443 ssl;
    server_name login.example.com;
    
    # 客户端必须在10秒内发送完请求头
    client_header_timeout 10s;
    # 客户端每两次发送请求体数据之间的间隔不能超过10秒
    client_body_timeout 10s;
    # 限制请求体的最小传输速率为每秒500字节，超过10秒未达到则断开
    client_body_buffer_size 128k;
    # 服务端响应给客户端的超时时间
    send_timeout 10s;
    
    location /api/login {
        proxy_pass http://backend;
        # 限制请求体大小为合理值
        client_max_body_size 2k;
        # 关闭代理缓存，避免额外内存占用
        proxy_buffering off;
    }
}

但仅靠Nginx的配置还不够，因为攻击者可以完全遵守传输速率要求，只是单纯地维持大量长连接，或者以极低频率不断发送完整的登录请求。这时就需要在应用层引入更精细的控制。

登录接口的防御需要在用户体验和安全之间找到平衡。对于疑似慢速攻击的流量，直接弹出图形验证码是最简单粗暴的方式，但会严重伤害用户体验，而且现在的打码平台和AI识别已经能绕过大部分传统验证码。更优的做法是引入无感验证机制，在前端通过JavaScript收集浏览器的环境信息、运行一些计算任务来证明客户端是一个真实的浏览器而非脚本。

具体实现上，可以在登录页面嵌入一段JavaScript SDK，它会在用户输入用户名密码的同时，静默地收集浏览器指纹，包括Canvas指纹、WebGL指纹、字体列表、屏幕分辨率、时区、插件信息等，并将这些信息哈希后生成一个设备标识。同时，SDK会执行一个小型的计算挑战，比如求解一个服务端下发的随机数哈希难题，这个计算在普通浏览器上只需要几十毫秒，但对于需要伪造大量请求的攻击脚本来说，每个请求都执行一次计算会显著增加其资源开销。

服务端在收到登录请求时，除了校验用户名密码，还需要校验这个动态令牌。令牌的生成逻辑可以和会话绑定，设置较短的有效期，防止攻击者重放。这种方案的核心价值在于，它把攻击者的成本从几乎为零提升到了需要运行完整浏览器环境或逆向JS逻辑的程度，而正常用户完全无感知。

传统的固定阈值限速在慢速CC面前基本无效。我们需要建立基于行为基线的动态限速模型。这个模型不只看单个IP的请求频率，而是综合多个维度的特征进行实时计算。关键特征包括：单个IP对登录接口的请求间隔分布、请求中User-Agent的多样性、请求来源IP的地理分布和ASN归属、登录失败后的重试模式、以及该IP是否同时访问了站点的其他页面。

一个正常用户的行为模式是：先访问首页或者某个落地页，然后跳转到登录页面，停留几秒到几十秒输入信息，再提交登录请求。如果登录失败，可能会间隔几秒后重试一两次，然后可能会点击“忘记密码”。而慢速攻击的流量往往直接命中登录接口，Referer为空或伪造，不会加载页面上的静态资源，不会执行JS，登录失败后的重试间隔高度规律，且从不访问其他页面。

我们可以用Redis或本地内存维护一个滑动窗口计数器，但计的不是请求次数，而是行为评分。每个请求到达时，从请求头、时序、关联上下文等维度提取特征，输入到一个轻量级的评分模型。例如：缺少有效Referer扣分，请求间隔过于均匀扣分，User-Agent与TLS指纹不匹配扣分，短时间内来自同一C段的IP集中出现扣分。当某个IP或设备指纹的评分低于阈值时，触发更严格的验证或直接拒绝服务。

很多系统对登录失败的处理过于简单：连续失败N次后锁定账户或IP一段时间。这在慢速CC攻击下会带来严重问题，攻击者可以用大量不存在的用户名尝试登录，导致正常用户的账户被误锁，形成另一种形式的拒绝服务。因此，账户锁定策略必须与IP信誉、设备指纹关联起来。

一个更健壮的方案是：对于同一个账户，连续登录失败达到阈值后，不是直接锁定账户，而是对该账户的登录请求启用更严格的验证，比如要求输入验证码或进行二次认证。同时，对于来自同一个设备指纹或IP段的登录请求，如果短时间内涉及多个不同的用户名且全部失败，则对该设备或IP段进行降级处理，而不是针对每个被尝试的账户进行锁定。这样可以有效区分“一个用户忘记密码反复尝试”和“攻击者在撞库或喷洒密码”。

慢速CC攻击有时候会配合TCP层面的慢速攻击，比如SYN Flood的变种，或者利用TCP拥塞控制机制拖慢连接。在服务器内核参数层面，需要开启并调优SYN Cookie机制，缩短SYN_RECV状态的超时时间，增大半连接队列的长度。同时，在负载均衡器或防火墙层面，对单个源IP的并发连接数进行硬限制。

# Linux内核参数优化示例
# 开启SYN Cookie，防止SYN Flood
net.ipv4.tcp_syncookies = 1
# 缩短SYN_RECV状态下的重试次数和超时时间
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
# 增大半连接队列
net.ipv4.tcp_max_syn_backlog = 8192
# 缩短TIME_WAIT状态的回收时间
net.ipv4.tcp_fin_timeout = 15
# 开启TCP时间戳，有助于快速回收连接
net.ipv4.tcp_timestamps = 1

在应用层，可以利用Nginx的limit_conn模块来限制每个IP对登录接口的并发连接数。注意这里限制的是并发连接数，不是请求速率。对于慢速CC来说，攻击者通常会维持大量并发连接，每个连接上发送请求的速率极低。把单个IP的并发连接数限制在一个很小的值，比如2到3个，就能有效遏制这种攻击，同时不影响正常用户，因为正常用户在登录时通常只会有一个到两个并发连接。

防御不能只靠实时阻断，事后分析同样重要。慢速CC攻击的流量特征在单点上看很微弱，但通过离线分析，可以聚合出攻击的全貌。建议将登录接口的访问日志全量接入分析平台，重点关注以下聚合指标：每分钟的独立IP数、独立设备指纹数、登录失败的总次数、失败请求中Top用户名列表、请求间隔的标准差、连接的平均持续时间等。

当这些指标中的某几项同时出现异常波动时，即使实时防御系统没有触发告警，也应当引起安全团队的注意。通过回溯分析，可以提取出攻击源的特征，将其加入黑名单或输入到防御模型中，持续优化防御策略。这种持续迭代的能力，是应对不断演进的慢速CC攻击的关键。

最终，防御登录接口的慢速CC攻击，本质上是一场成本对抗。攻击者的目标是最大化你的资源消耗，而你的防御目标是最大化攻击者的成本，同时最小化对正常用户的影响。通过连接层超时控制、应用层无感验证、行为基线动态限速、精细化失败处理以及内核参数调优的组合拳，可以构建起一个让攻击者觉得得不偿失的防御体系。