关于安全防护:社交直播类APP的DDoS防护新思路SDK版

52次阅读

共计 2701 个字符,预计需要花费 7 分钟才能阅读完成。

近几年,随着短视频平台衰亡,各种直播 APP 映入人们视线,目前社交、直播类 APP 行业仍是被攻打的重灾区,之前与几个做社交 APP 的敌人交换,平台服务端被流量攻打了,他们就放松换到高防机房,尽管高防服务器有肯定成果,然而因为社交 APP 波及视频流、图片等内容,再过滤攻打的同时会呈现重大卡顿、提早高的状况,所以敌人始终不太称心,在有攻打的时候关上视频、发送图片等状况下提早很大(有时候没攻打提早也高,可能很多高防复线缘故或者机房其余用户有攻打影响到整个机房环境造成进口稳定),影响用户体验,甚至会因为高防依附策略过滤造成误封用户的状况,导致一些失常用户无奈登录被拦挡的状况。
理解需要之后依据这种利用场景定制了一套解决方案,采纳大量分布式节点部署,攻打流量扩散在不同的节点上,节点间可无缝切换,通过 APP 集成 SDK 跟验证端通信来调度节点,可实现无下限进攻 DDOS,CC 攻打,同时为用户拜访减速。
随后一直有平台接入测试,为不少平台轻松防护了辣手的流量攻打,因为传统高防的有余,针对 TCP 端口的 CC 攻打没有太好的过滤策略,外加流量攻打量一直飙高,依附硬防生抗成果不现实同时防护价格昂贵等,起初这个计划的独创的平安防护引擎 VEC 外围性能在 github 上开源,同时产品通过一直历练进行了三次重构,目前产品曾经足够稳固。
产品原理
这个产品是一款专一于 C / S 架构的平安防护产品,利用分布式星散群拦挡针对用户服务器的 CC 攻打、DDOS 攻打,通过在 APP 客户端集成 SDK 进攻模块,来实现精准疾速的切换以及链路加密通信,因为采纳了隧道加密通信技术,应用动静虚构 IP 连贯,因而,任何 DDOS 攻打流量都无奈进入隧道,同时还能够暗藏实在服务器 IP。

整个防护由三大模块组成,别离是客户端 SDK、智能调度和身份验证。

简略演示一下大略成果,有感兴趣的敌人能够进行沟通交流。市面上有不少同类商用产品,各有各的长处,这个产品是之前给敌人平台提供运维时候本人团队开发的产物,有须要的能够收费提供部署和搭建。
计划演示
一、生成 SDK 文件
通过搭建 jenkins 在线生成 SDK 文件

产品反对 android\ios\windows 三端的源码和无源码集成。
轻易从搜索引擎找了一款社交 APP 进行演示,因为间接下载的 apk 文件并无源码,因而,通过逆向的形式将 SDK 集成进去。

通过脚本进行集成之后进行测试(三端无源码集成过程后续独自写一个独立的介绍)。

二、抓包剖析
首先装置原版 APP 进行抓包剖析。


通过原版抓包能看到大量 dns 申请以及 http 明文申请数据。
再将逆向集成 SDK 的 APP 进行装置并抓包。
SDK 启动的时候会 HOOK 掉 APP 的所有网络通讯,因为 SDK 和节点之间是加密传输的,因而抓包也无奈获取 dns 解析记录以及 http、tcp 等明文信息,全部都是公有加密协议进行了封包。下图为原版 dns 解析

下图为逆向集成 SDK 之后抓包


62001 端口为 SDK 跟节点加密通信端口。所有数据都被加密传输,无奈解密出明文数据,防止了要害数据和内容在网上明文传输。

上图为节点外面进行 dns 解析服务,所有的客户端 dns 解析都会在远端节点进行解析,从而防备了 dns 净化和劫持。也能够防止攻击者获取域名信息。集成 SDK 之后抓包看到的全部都是加密封装后的 TCP 数据包。

抓包看到 SDK 跟调配的节点 203.215 进行通信,在 IP 为 203.215 的节点外面将加密隧道程序断开,模仿节点被攻打产生无法访问的状况。抓包看到 SDK 迅速切换到调配给用户的第二个可用 IP62.24 所有的切换都是无感知进行的。为了防止攻击者反复拉取全副节点池,SDK 的验证端做了身份辨认,token、deviceid 等形式进行验证。每个用户调配的一组 3 个 ip 都不会反复,如果攻击者打死调配给他的节点 IP,也只会影响到黑客本人。

断线重连,节点异样霎时主动切换。
SDK 计划长处次要是不依附生抗来防护,而是通过大量分布式节点调度防护。
其次能完满防护 CC 攻打,因为节点对外不提供任何业务端口,只对外开放一个加密传输隧道端口(62001)。
SDK 节点切换都是霎时切换,不依附域名 dns 解析形式。cname 防护集群切换依附域名解析同时无奈实现无缝切换,并且防 CC 成果仍然不现实。

Q & A 问答集
1、端口防 CC 成果如何?
答:SDK 跟节点之间通信是建设一个加密隧道,只有 APP 集成 SDK 之后的数据才会进入,攻打量无奈进入隧道内,同时节点不对外开放任何业务端口,只有一个加密隧道通信端口 62001 凋谢。因而,任何针对业务端口的 CC 都起不到任何成果。所有的业务数据都通过封装发送到节点的加密隧道端口,达到节点之后进行解密解包将用户业务数据发送给原站服务器。
2、最高能进攻多大攻打量?
答:因为不是依附高防的生抗模式,全副都通过调度算法调配节点,因而,黑客攻击打死的节点也只是影响黑客本人,通过多层辨认,杜绝全副节点被拉取。用户能够在调配的一组惟一 IP 之间无感知切换。cname 高防转发模式则会呈现掉线,提早高,过滤规定误封实在用户的状况。无感知切换是通过 SDK 进行解决的,不存在通过 cname 域名进行调度切换的弊病。
3、文中提到的虚构 IP 如何应用?
答:为了更好的爱护 APP 不被逆向破解,咱们倡议用户客户端链接服务端的域名解析到虚构 IP,如果客户端绑定的是 IP 地址,能够换成咱们的虚构 IP。虚构 IP 是一个环路 IP 不会在互联网上传输,然而客户端集成 SDK 之后就能够应用虚构 IP 跟咱们节点建设加密通信了。虚构 IP 相似 127.0.0.1~127.0.0.255
4、集成之后是否能够抓包到客户端明文数据?
答:APP 集成 SDK 之后会 hook 全副 APP 的通信数据封装到咱们的加密协议外面,并与节点建设加密隧道。任何数据都是加密之后传输的,通过抓包是无奈显示明文的。有的客户有独自需要,比方社交视频等 APP,这类客户流媒体数据较多,如果都走节点会造成减少老本和担心额定提早等状况,因而 SDK 反对例外设置,比方链接第三方流媒体或者存储更新资源等无需爱护的链接进行直连拜访。
5、是否能够将流媒体、图片等资源直连不进行爱护,来进步速度?
答:SDK 默认启动的时候会截获 APP 全副流量传输数据给节点,然而因为大部分用户客户端外面流媒体、图片等存储于第三方接口,无需爱护,因而,咱们会依据用户需要进行定制化转发,也就是提供第三方域名或者将须要爱护的业务应用我方提供虚构 IP 都能够实现。这样爱护了重要的原站服务器同时第三方无需爱护的接口又能够进行直连,既平安又疾速,无需额定多进行一次转发,也防止过多的资源带宽等耗费节省成本。

须要技术交换沟通能够加 q: 278056823 vx:zenops

正文完
 0