电商平台异常流量检测与防御实战

1. 项目背景与问题定义

上周五凌晨2点37分，我正盯着监控大屏上突然飙升的流量曲线发呆。作为某电商平台的基础架构负责人，这种非大促时段的流量异常往往意味着两种情况：要么是运营偷偷上了新活动没打招呼，要么就是平台正在被恶意爬虫光顾。而这次的情况显然属于后者——流量特征呈现出明显的"添柴不加火"现象。

所谓"添柴不加火"，是我们团队内部的行话，特指那些持续消耗服务器资源却未产生实际业务价值的异常流量。就像往灶台里不断添柴却始终点不着火，这类请求通常具有以下特征：

• 请求频率稳定但明显高于正常用户
• 访问路径集中在非核心页面
• 几乎不触发任何转化行为
• User-Agent呈现规律性变化

2. 流量特征的多维度分析

2.1 时间维度异常检测

通过ELK日志系统提取最近72小时的Nginx访问日志，我们首先进行了时间序列分析。使用Python的statsmodels库进行季节性分解后，发现了三个关键异常点：

python复制from statsmodels.tsa.seasonal import seasonal_decompose
result = seasonal_decompose(requests_series, model='additive', period=24)
result.plot()

1. 周期性异常：本该在凌晨3-5点出现的流量低谷完全消失
2. 振幅异常：工作日晚高峰的流量波动幅度比平日高出47%
3. 相位偏移：周末流量模式与工作日完全重合（正常应有明显差异）

2.2 用户行为指纹分析

借助Flink实时计算框架，我们对用户会话(Session)进行了行为建模。正常用户的行为轨迹通常呈现"搜索→比价→加购→支付"的漏斗形态，而异常流量则表现出：

注：鼠标移动熵值是通过记录光标坐标变化序列计算的香农熵，用于量化操作随机性

2.3 协议层特征提取

在TCP/IP协议栈层面，我们发现了更隐蔽的异常特征。通过tcpdump抓包分析，异常流量的TCP窗口大小固定为64240字节（正常用户会在256-65535间动态调整），且TCP时间戳选项呈现等差数列增长。这些特征强烈暗示着自动化工具的使用。

3. 攻击源定位与画像构建

3.1 IP信誉库交叉验证

将可疑IP导入自建的威胁情报系统后，发现87%的地址满足以下条件：

• 属于数据中心IP段（AWS/GCP/Azure）
• 过去30天内有爬虫访问记录
• 未触发过任何转化事件
• 平均请求间隔在1.2-1.5秒之间

3.2 设备指纹聚类分析

使用FingerprintJS生成的设备ID进行聚类，发现了明显的设备农场特征：

• 浏览器canvas指纹高度相似
• WebGL渲染器信息完全一致
• 屏幕分辨率均为1366x768
• 时区设置集中在UTC+3时区

3.3 攻击者画像还原

综合所有数据，我们还原出攻击者的技术特征：

1. 使用基于Puppeteer的浏览器自动化框架
2. 通过云函数实现分布式调度
3. 每实例配置了固定延时（1.3±0.2秒）
4. 使用住宅代理IP池轮转
5. 针对商品详情页进行价格采集

4. 防御策略的渐进式实施

4.1 实时拦截层配置

在OpenResty层面部署了动态规则：

nginx复制location / {
    access_by_lua_block {
        local latency = tonumber(ngx.var.request_time)
        local entropy = calculate_behavior_entropy()
        
        if latency < 0.5 and entropy < 1.0 then
            ngx.redirect("/challenge.html", 302)
        end
    }
}

4.2 业务层限流策略

采用令牌桶算法对异常特征请求进行分级限流：

1. 第一层级：User-Agent包含HeadlessChrome的请求
2. 第二层级：TCP窗口固定为64240的会话
3. 第三层级：鼠标移动熵值持续低于1.0的用户

4.3 验证机制优化

设计了三阶段验证体系：

1. 轻量级：计算简单JS算术题（0.3秒完成）
2. 中级：识别扭曲文字（阻断普通自动化工具）
3. 严格：行为验证（需要真实鼠标轨迹）

5. 效果验证与误伤监控

实施防御策略24小时后，关键指标变化如下：

对于误拦截情况，我们通过分析发现这些用户均满足以下特征：

• 使用旧版Android系统浏览器
• 处于弱网环境（RTT>800ms）
• 屏幕尺寸较小（360x640）

针对这类情况，我们在规则引擎中添加了白名单逻辑：

python复制def should_bypass_challenge(request):
    return (
        request.user_agent in LEGACY_BROWSERS and
        request.rtt > 500 and
        request.screen_width < 400
    )

6. 经验总结与改进方向

这次攻防对抗给我们带来了几个重要启示：

1. 熵值检测的局限性：纯行为熵检测在移动端场景下误报率较高，需要结合设备传感器数据（如陀螺仪采样）提高准确性

2. IP信誉库的冷启动问题：新建的威胁情报系统需要至少2周的数据积累才能达到90%以上的识别准确率

3. 验证机制的体验平衡：过于复杂的验证虽然能有效拦截爬虫，但会导致移动端用户流失率上升5-8%

后续我们计划在三个方向进行优化：

• 引入WebAssembly计算密集型挑战（如哈希碰撞）
• 部署客户端流量染色技术
• 试验基于强化学习的动态规则生成系统

这次事件最意外的收获是：某个被拦截的IP段后来被证实属于竞争对手的数据分析团队。流量分析不仅能防护系统，有时还能意外发现商业情报战的蛛丝马迹。