1、使用流量分析解决业务安全问题长亭科技产品技术总监大纲有哪些常见的业务安全问题 解决业务安全问题的思路 为什么可以依靠“流量分析”解决业务安全问题 一个典型的流量分析框架的设计架构 从实际应用场景来看“流量分析”的重要性常见的业务安全问题刷单、刷水、刷排名、刷评论、刷转发、刷点赞、刷使用、刷抽奖、垃圾账号注册、暴力破解、脱裤、撞库、爬虫、盗号、账号恶意登录、黄牛党、羊毛党、反欺诈、反作弊、恶意下单、短信轰炸、僵尸粉我们经常会遇到哪些业务安全问题垂直越权 水平越权 验证码失效 业务流程失序 nonce 失效 访问接口未做频率限制 允许伪造源 IP。可直接导致业务安全问题的漏洞一个典型的“薅羊毛”案

2、例 背景：某业务为了宣传举办了一次线上抽奖活动 每次传播都可以获得一次额外的抽奖机会 奖品是 20 台 iphone 结果：20 位中奖者中有 18 位都是同一个人 业务安全问题案例另一个典型的“薅羊毛”案例 背景：某业务推出了新用户无门槛抵价券 没有对“无门槛抵价券”的转赠做限制 没有对新用户的注册做限制 结果：羊毛党通过批量注册新用户获得了数万张“无门槛抵价券”业务安全问题案例以“薅羊毛”为例，思考几个问题 不同业务遇到的“薅羊毛”是同一个问题么“薅羊毛”问题的本质是什么 不同的“薅羊毛”问题有哪些共性 有什么通用的解决方案 业务安全问题远远不止这些“薅羊毛”问题的本质：利用不同的账号领取

3、无门槛抵价券 批量参与抽奖，提高中奖率 虚假交易刷信用卡，使用积分换礼品 业务安全问题远远不止这些对于此类“薅羊毛”问题，有通用解决方案么？需要考虑几个问题：不同的业务账号体系一样么 不同的业务领优惠券的流程一样么 如何智能识别一个接口是否可以用来领优惠券。业务安全问题远远不止这些以“薅羊毛”为例，思考几个问题 不同业务遇到的“薅羊毛”是同一个问题么“薅羊毛”问题的本质是什么 不同的“薅羊毛”问题有哪些共性 有什么通用的解决方案 业务安全问题远远不止这些业务错综复杂 不同类型的业务需要完全建立不同的风控模型，工作量巨大 容易百密一疏 监控和防护需要面面俱到，一旦漏掉一个点就会发生木桶效应 战场

4、敌暗我明 作为防守方，可能更不知道有没有人在攻击以及在以什么形式攻击 对方麻雀战术 攻击手段变化多端，容易升级解决业务安全问题的难点理解业务模型的重要性解决业务安全问题首先需要“理解业务”对于业务风控而言，需要了解 某个接口接受什么参数，返回什么内容 调用接口会提供什么功能 该功能和哪些其他接口有关系 可实现类似功能的接口还有哪些 在这个场景下：理解业务 业务建模“理解业务”的重要性业务提供相关模型 分析业务代码 业务代码插桩 分析业务日志 分析业务流量有哪些业务建模的途径信息量大 完整 HTTP 请求 完整 HTTP 响应 可通过 SESSION 关联同一个用户的不同请求 实时性强 具有阻断

5、能力 实时阻断请求 实时阻断响应 持久化阻断某个接口 持久化阻断某个用户使用 Web 网关做流量分析的优势支撑“流量分析”的典型 Web 网关架构Web 网关集群的架构设计Web 网关集群的架构设计Web 网关集群的服务组件通常包括：流量转发服务：将用户请求数据引入到 Web 网关以进行检测，根据检测结果执行阻断操作 流量检测服务：从接入服务接收用户请求并进行检测 集中管理服务：为用户提供管理界面 流量分析服务：从检测服务接收日志数据，执行分析逻辑/插件并持久化日志 基础平台服务：管理节点上的服务实例，完成服务创建、更新等操作，并负责在节点和管理服务之间中转数据 此外还包括独立的数据存储服务：

6、PostgreSQL 和 Redis Web 网关集群的服务组件流量转发服务可以工作在代理模式和链路模式 代理模式：使用 Nginx 实现，工作在应用层（七层）。将接收到的用户请求和服务器响应封装之后发送给检测服务，根据接收到的检测结果决定将请求转发至业务服务器或者阻断该请求 链路模式：基于 DPDK/PFRING 和用户态协议栈的流量监测服务。工作在链路层（二层），利用用户态协议栈还原出 HTTP 请求与响应并转发至检测服务进行检测。根据检测结果决定转发或丢弃数据包（桥模式），或者发送 RST 阻断连接流量转发服务流量在线分析服务从检测服务接收日志并进行以下处理 实时流处理：实时分布式流处理

7、框架，对用户访问数据进行实时分析 扩展插件平台：允许用户通过插件的形式扩展日志分析逻辑流量分析服务集中管理服务由 WebServer 和数据库（PostgreSQL/Redis）组成 WebServer 用户操作的入口，提供管理功能，如站点，访问频率控制，防护策略等 管理查看配置，推送策略引擎更新，管理日志等 监控系统状态，记录日志发送告警等 PostgreSQL 配置数据和日志 Redis 数据缓存 消息队列集中管理服务管理节点上的服务 服务的创建、更新、健康检查等 服务配置的生成与更新 API Gateway，负载转发服务之间的 API 调用，为各个服务提供统一的 API 调用入口 管理节

8、点的配置，包括网络管理、性能监控 高可用支持：为节点上的服务提供高可用支持，某个服务出现异常时执行错误恢复 基础平台服务Web 网关集群的架构设计?PostgreSQL?etcd?Redis分布式流量分析框架数据流：非关系型数据库中的一张无限长的表 从数据源持续产生的数据，理论上是无限的 单条数据的结构相对简单 数据与数据之间无耦合数据流流处理：对数据流进行的一系列分析操作流处理批处理流处理处理范围全部数据集当前数据流数据规模大规模，依赖磁盘缓存小规模，纯内存搞定实时性要求低高分析内容复杂分析简单统计统计窗口：按照某种逻辑将无限的数据流分割为有限的数据集 按时间划分 滚动时间窗口 滑动时间窗口

9、 按计数方式划分 滚动计数窗口 滑动计数窗口 按业务划分统计窗口统计窗口API 机制 SDK 机制 脚本引擎 触发器 数据缓存机制 异步处理机制 上下文通信机制定制化流量分析逻辑流量分析框架的 API 机制对“数据流”的常见操作 分组 聚合 过滤 重组对“数据流”的操作分组 GROUP BY 聚合 COUNT/SUM/过滤 WHERE/HAVING 重组 ORDER BY/SELECT DISTINCT使用 SQL 定义流操作SELECT ip,url_path FROM access_log WHERE TIME 10服务器响应时间超过 10s 的请求 IP 与 URLSELECT ip F

10、ROM access_log GROUP BY TUMBLE_WINDOW(TIMESTAMP,60),ip ORDER BY COUNT(ip)DESC LIMIT 10一分钟内访问次数最多的 10 个 IP流量分析框架的 SDK 机制MATCH 触发器 通过简单的过滤器对每一个请求单独设置回调 TICKER 触发器 定时触发 QUERY 触发器 通过高级语义化过滤器进行聚合、筛选插件的执行方式local safeline=require safelinelocal match=ip =0.0.0.0/0,host =*,url_path =/api/*,function process(i

11、p,host,url_path)-在此处理请求endsafeline.register(safeline.TYPE_PROCESS,match,process)MATCH 触发器插件local safeline=require safelinelocal duration=10function tick(dur)-在此处理定时任务endsafeline.register(safeline.TYPE_TICKER,duration,tick)TICKER 触发器插件safeline=require(safeline)query=SELECT ip FROM access_log WHERE ti

12、me 0.01function process(key,rows)-在此处理查询结果end)safeline.register(safeline.TYPE_QUERY,query,process)QUERY 触发器插件提供了 LOCAL 和 GLOBAL 两种缓存机制 目的：维护状态，为插件的多次运行提供联系 为不同插件的运行环境提供通信的可能性 统计、累积计数KV 缓存目的：与其他系统对接 向其他系统输出流量分析结果 从其他系统获取源信息，进一步辅助进行流量分析HTTP 客户端目的：调用外部 API 的结果需要同步处理 强调多次异步调用结果的相关性 通过 Promise 节点链传递多层执行结

13、果Promise 异步支持实际应用场景安全负责人 垃圾评论、垃圾赞 垃圾账号 撞库、盗号 业务资源被竞争对手爬取。觉得可能还有羊毛党在钻其他空子 觉得可能还有黑产在利用一些潜在的逻辑漏洞上线前的关注点使用流量分析“API”根据常见关键字监控所有注册接口 监控 10 分钟后，发现了 7 个注册接口 经过验证，其中有两个接口没有验证码，可以被自动化工具利用 有大量注册用户的用户名符合某种随机特征 追踪所有符合该特征的用户行为 发现了黑产团队的其他动作 发现大量注册用户的来源是同一个 IP 其中调用次数较多的接口是有验证码的 追踪这些 IP 发出的所有请求 几乎没有请求过静态资源 请求集中在评论接口、私信接口、搜索接口。上线后的动作定位了黑产团队常用的接口 以 SEESION 为维度统一做频率限制 以 IP 为维度对敏感接口做频率限制 下线了几个无验证的注册&登录接口 发现了验证码本身存在的不足，排期加强 查封了巨量违规账号 丰富了防爬系统的规则。结果解决业务安全问题十分重要 面对变幻多端、错综复杂的业务没有省力的解决方案 依靠 Web 网关做流量分析是解决业务安全问题的一条捷径 流量分析框架的接口需要足够通用 人工分析不可缺少，需要持续关注总结