安全分享｜BOT 流量管理防护实践

1.1 Bot 基本概念

Bot，即机器人，传统意义上的机器人指的是可以代替人工作的物理机器人，随着技术的进步机器人的定义不再限于物理实体。在互联网行业，Bot 一般指的是在 Web、APP 应用、API 接口上通过运行自动化程序执行重复任务的虚拟机器人，它们有的动作比人类快很多，有的行为则很隐蔽不易被发现，这些机器人所产生的活动日志被称为 Bot 流量（机器人流量）。

1.2 Bot 分类

当然，从概念上我们不能简单地将 Bot 理解为机器人，因为 Bot 最终还是为人服务的，举个例子，例如黑灰产和客服团队，两者对 Bot 的需求就不同，黑灰产目的是利用隐蔽手段获取有价值的数据，而客服团队则希望开发客服机器人提高服务效率，故不同的需求驱动塑造了各种各样类型的 Bot。

下面，我们将从目的、属性对 Bot 进行简单的分类。通常，基于 Bot 的目的可以将 Bot 分为友好、中立、恶意三类，通常我们对于恶意类型的 Bot 需要尤其关注，它们对业务的危害最大。

从 Bot 的属性则可以将 Bot 分为（表格内容由 ChatGPT 生成）：

2.1 Bot 流量现状

随着互联网的快速发展，各行各业无论是业务类型、流量都呈现爆发式的指数增长，与此同时，借助于廉价的代理 IP 、虚拟运营商号码资源、自动化工具和云真机技术，发起 Bot 流量的成本越来越低，相应地，Bot 流量的增长也呈现正相关增长的趋势。根据腾讯安全和 Cloudflare 公开的数据，恶意 Bot 流量在整体流量中的占比越来越大。

根据腾讯安全提供的数据，互联网的 Bot 流量正处在逐年上升的趋势：

根据 Cloudflare 提供的数据，在全球范围内，有超过三分之一的网络流量来自于恶意 Bot！

在企业业务增长的路上，恶意 Bot 流量似乎是一道绕不开的障碍，例如社交网络如小红书，就得面临社交机器人、内容爬虫，如果你是电子商务如京东、淘宝，就得防范价格抓取机器人。面对恶意流量的攻击，一方面企业宝贵的信息资源被竞争对手抓取，另一方面浪费了企业网络带宽，如果放任不管，久而久之则会影响正常用户使用体验和降低企业竞争力，所以在此背景下引入了我们本次分享的主题：Bot 管理。

3.1 Cloudflare

Bot 分数机制，Cloudflare 通过五种检测手段：机器学习、启发式引擎、行为分析、已验证 Bot、JS 指纹，在此基础上会给每次请求生成 0-100 区间范围的分数，分数为 1 表示请求为自动化程序发起。在 Cloudflare 的 Bot 检测手段中，通过机器学习检测的 Bot 流量占 98% 以上。

3.2 腾讯云

Bot 管理设置支持配置客户端风险识别（前端对抗）、威胁情报、AI 评估、智能统计、动作分数、自定义规则、Token 配置、合法爬虫模块，通过配置这些模块，实现对 BOT 的精细化管理。

3.3 阿里云 WAF Bot

多维度指纹库+行为分析自学习模型+阿里云全网协同防御情报，配合领先业界的人机识别算法，以及欺骗、限流、打标等多种处置手段，全面满足各种攻防强度和业务场景下的防护需求。

综合上述几家主流 toB 厂商的解决方案，我们大概可以了解到一般的 Bot 管理解决方案都离不开“情报”关键词，实际上在 Bot 管理落地的初期，实际应用效果很大程度取决于威胁情报库、指纹库、行为模型的丰富程度，借助于丰富、及时更新的情报库能大大提高产品落地效率、处置效率和准确性，让运营同学在配置策略时更有信心。Bot 管理一方面依赖于情报资源，另一方面依赖丰富的专家知识、工程师对业务的理解程度。

在介绍了当前几个主流厂商的方案之后，下面将从我们自身的背景出发简要介绍我们的 Bot 管理建设的过程，按照构建的先后顺序我们将 Bot 管理架构分为四层：数据层、特征层、模型层和策略层。

数据层：俗语“巧妇难为无米之炊”，用“米”来形容数据的重要性一点都不过分，数据是 Bot 管理的基石，没有数据就无从谈及特征、模型和策略，数据层主要的工作是收集原始的日志数据、理解业务字段、简单清洗数据入库

特征层：由待需要解决的业务问题驱动，基于已有的日志数据计算多个维度下可用于模型层的特征

模型层：事件驱动模型，分析师基于对具体事件的理解，利用特征层提供的特征构建满足具体事件场景的模型

策略层：策略层是 Bot 管理的终点，数据、特征和模型的工作最终都要服务于实际需要解决的需求，通过组合不同的特征策略召回被匹配的数据以完成决策过程

1.1 现状

在日常业务活动中，我们频繁使用术语“特征”。特征是指用来描述某一维度下某个因素在一定时间范围内与其他因素的区别的特点。特征工程可以被视为一门“艺术”，它的质量很大程度上取决于工程师对业务和数据的理解，特征工程的质量直接影响了模型的实际业务表现。

数据是特征工程的原材料，没有数据就无法进行特征工程。在实际情况中，拥有干净完整的数据几乎是不可能的，因此建模过程中的可预见的是大部分时间都花在数据清洗上。这需要工程师对业务领域有深刻的了解，清楚不同领域下字段的含义。例如，在网络安全领域，关注的字段可能包括数据请求包和设备信息，而在金融领域，可能关注用户信用、订单交易数据以及成交量等指标。

1.2 ETL

Bot 管理所使用的数据源来自于网关日志，在大数据团队将 Kafka 的日志接入 Hive 后仅仅是非结构化原始数据，由于其他部门不熟悉网络安全的日志构成以及各个业务线上报数据规范也不统一，这些日志数据在没有被进一步清洗整理前，故网关的原始数据无法发挥其作用。

ETL（Extract-Transform-Load）的缩写，是将业务系统所生成的粗糙数据经过抽取、清洗、转换之后加载到数据仓库的过程，在数据的生命周期内，加工过后的数据可被重复使用。

依照一般的数据仓库分层体系，数仓分成数据引入层 ODS（Operation Data Store）、数据公共层 CDM（Common Data Model）、数据应用层 ADS（Application Data Service）数据仓库的不同层级负责不同的职能。在 ETL 的过程中，我们的目标是将“脏数据”清洗整理成为可以数据抽象、指标加工、报表展示使用的中间数据。

图片来源于网络*

1.3 特征计算

在数据清洗完成之后，便可以着手特征工程的开发，在这之前，我们首先需要明确特征维度，即特征工程所需要处理的具体数据，一般来说，数据流转的最终落脚点即特征维度，如 IP 地址、用户凭证、用户标识、设备标识等，后续的数据处理、特征设计等工作都将围绕着特征对象展开。另外，我们还需要根据实际的业务需要定义合适的时间窗口，从离线的角度可以是一天、六个小时甚至是一个小时，当然覆盖的区间越长，实际计算所需要的资源和时间就会更久，需要工程师从资源和时效两者中间做出平衡。

在网络安全的对抗中，IP 地址和用户标识是常见的处置维度，以 IP 地址为例，我们可以计算时间窗口内 IP 地址的行为特征、属性特征、统计特征，从行为分析方面出发可找到区别人和机器的特征集合搭建分类模型，从威胁情报可以直接匹配过滤恶意流量，从专家知识出发运营同学可制定区分真人和机器对应的召回策略。当然，以上只是其中的一些思路，没有放之四海皆准的特征开发标准，不同领域和不同的业务问题的侧重点不一样。

2.1 Why

在 Bot 管理建设的过程中，受限于数据基建和业务理解，初期面对异常的 Bot 流量攻击，往往依靠“硬编码”来做异常数据的召回，而到了中期，“硬编码”逐渐跟不上需求的迭代和业务场景增加，不借助于工具，工程师无法从繁杂的规则编写和管理中解放出来，一款高效便捷的规则管理自然会被提上开发日程。

规则引擎负责策略规则的解析和执行，借助于规则管理引擎，运营同学只需要关注抽象单个业务需求，无需关心规则的前因后果，并且规则管理引擎有助于运营策略上线的效率。

2.2 主要功能

场景管理：筛选整理出需高优的业务场景

黑白名单：创建黑白名单库，黑名单直接拦截过滤，白名单放行

管理面板：策略编辑、下发、查看策略面板

规则引擎：负责规则解析和执行，读取、解析规则库中所有可用规则，根据规则优先级执行

业务场景准入：在风险收敛中，考虑到投入产出和有限的计算资源，梳理需要高优覆盖的业务场景

规则策略下发：

· 制定通用策略召回模型，覆盖一般情形的 Bot 流量场景，减轻运营同学维护压力

· 周期性红蓝对抗演练，测试召回效果并优化已有策略

· 根据业务反馈的异常 case，下发策略进行事中对抗

事件产出：

· 告警通知

· 报表跟踪：监控事件明细数据、策略执行情况

· 事后分析

事件处置：落脚点闭环

· WAF 拦截

• 拦截维度：IP、用户标识

• 拦截层级：实时、准实时、离线覆盖

· 风控处置

• 封禁用户

• 其他的惩罚措施

事件回收：

· 接口加固

· 漏洞修复

· 提升准确率和召回率，优化召回策略

事件溯源：

· 来源群体：竞对、黑灰产、白帽子

· IP 情报检验：IDC 机房、基站 IP

· 虚拟运营商号段

分析工具：SQL、Excel、威胁情报、历史数据、社会工程学、分位数

统计方法：抽样检验、全量检验、同比、环比、标准差、相似度

机器学习：时序异常检测算法、CatBoost

群体分析：IP 是否为代理池、UA 是否统一、召回数据是否具备集群特征

离群分析：是否存在大量离群点

本文从简要描述 Bot 管理的概念出发，介绍了主流厂商提供的方案，从我们自身建设的经验来看，Bot 管理是一类很典型的 toB 产品，每个客户所处的行业和业务场景存在很大的差异，对抗的对象可能是帐号、IP、设备等等对象，对抗手段也五花八门，给工程师带来很大的困扰。其实，万变不离其宗，简单来说建设的框架可以分为以下四个步骤：

业务驱动：找到“钉子”之后再挥舞“锤子”，而不是拿着“锤子”找“钉子”

确认数据流转的落脚点：落脚点即“钉子”的类型，所有的工作流程特征工程、异常检测、事件运营等都围绕“钉子”展开

区分正常和异常流量：这是最最最关键的一步，完全取决于工程师对于业务的理解，通常需要反复尝试挑选才能找到好的特征

定制监控指标：根据实际的需要定制衡量实际效果的监控指标，并以图表的方式展示，方便对比和数据回溯

文章参考链接：