2019年使用流量分析解决业务安全问题.pdf

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 阻断连接流量转发服务流量在线分析服务从检测服务接收日志并进行以下处理 实时流处理：实时分布式流处理