近几年，随着短视频平台兴起，各种直播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效果依然不理想。
对比项 | 传统方案 | SDK方案 |
|---|---|---|
防护能力 | 仅能靠一个本地机房，带宽无法扩展，无法防御更大的DDoS攻击 | 分布式节点BGP接入，针对游戏提供高可用的网络环境，理论上无上限的抗攻击能力 |
身份验证 | 传统清洗机房仅靠硬件设备来识别，无法解码游戏私有协议 | 数据报文全链路加密，身份验证，防黑客破解，端到端的加密，游戏安全接入 |
节点个数 | 节点数量有限，容易被逐一打死 | 节点数量很多，即使打死几个对绝大多数用户无影响 |
CC防护 | CC攻击防护效果不佳，大量漏杀和误杀，严重影响业务 | 100% CC防护能力，0误封 |
启动防护 | 识别攻击行为需要一个过程 | 即刻识别攻击行为 |
攻击成本 | 黑客轻易打出几百Gbps的攻击 | 找不到攻击目标，黑客成本很高 |
防护成本 | 防护成本很高 | 防护成本较低 |
接入方式 | 需要DNS解析 | 无需DNS解析 |
调度能力 | 调度时间很长 | 秒级调度，快速切换节点 |
调度策略 | 调度策略很简单 | 多维度，调度策略很灵活 |
节点使用 | 用户集中到少数几个防护节点上 | 用户分散到不同节点上 |
隐秘性 | 黑客很容易找到攻击目标 | 混淆加防逆向抓包，无法找到真实节点IP |
防护配置 | 需配置防护策略 | 无需配置防护策略 |
策略制定 | 需根据攻击特征调整防护策略 | 一次接入，终身免疫 |
攻击溯源 | 溯源困难 | 溯源成功率将大大提升 |
三、控制台可视化操作
控制台使用Go语言开发，主要是配合SDK进行节点的调度与分配，用户请求的身份验证识别等功能.
节点池分为临时池、可信池、备用池。根据用户权重等方式进行分配到不同节点池。新用户请求会分配临时池，等通过一系列权重评估之后会分配可信池节点。备用池是在极端情况下进行分配的节点。节点同时支持近源分配。
每个平台会分配唯一的授权码，同时生成SDK的时候也会直接写死的文件里面。
一些列相关配置参数。
中转机配置也就是针对用户业务进行端口转发，并生成虚拟IP。类似127.0.0.2.
debug模式主要是在个别终端出现异常情况下进行远程调试、日志分析等，用来进行排查问题。
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都可以实现。这样保护了重要的原站服务器同时第三方无需保护的接口又可以进行直连，既安全又快速，无需额外多进行一次转发，也避免过多的资源带宽等消耗节省成本。
6、是否可以私有化部署防护系统或者自己二次开发？
答：可以提供私有化部署，甚至如果您有开发能力都可以将源码二次开发，私有化部署更独立，更安全，所有的资源、节点、数据都在用户可控的独立设备上，与外界其他平台无任何关联。
需要技术交流可以加q:278056823 vx: zenops
