目前游戏行业
此产品设计之初仅仅是“江湖救急”为了帮助几个朋友的游戏和在线教育平台抵抗大流量攻击，后来朋友介绍朋友，不断有平台接入测试，为不少平台轻松防护了棘手的流量攻击。由于传统高防的不足，针对TCP端口的cc攻击没有太好的过滤策略，外加流量攻击量不断飙高，依靠硬防生抗效果不理想同时防护价格昂贵等，产品经过不断历练进行了三次重构。目前产品已经足够稳定。
这个产品是一款专注于C/S架构的安全防护产品，利用分布式云集群拦截针对用户服务器的CC攻击、ddos攻击，通过在APP客户端集成SDK防御模块，来实现精准快速的切换以及链路加密通讯，由于采用了隧道加密通讯技术，使用动态虚拟IP连接，因此，任何ddos攻击流量都无法进入隧道，同时还可以隐藏真实服务器IP。
仍是攻击的重灾区，这个产品也应运而生，采用分布式节点部署，攻击流量分散在不同的节点上，可以无上限防御DDOS，CC攻击其他协议攻击等。非常全面的防御各种攻击入侵渗透，同时为用户访问加速。
整个防护由三大模块组成，分别是客户端SDK、智能调度和身份验证。
简单演示一下大概效果，有感兴趣的朋友可以进行沟通交流。市面上有不少同类商用产品，各有各的优点，这个产品并非商业软件，而是之前给客户平台提供运维时候自己团队开发的产物，有需要的可以免费提供部署和搭建。后续根据实际情况考虑开源。
一、生成SDK文件
通过搭建jenkins在线生成SDK文件
产品支持androidioswindows三端的源码和无源码集成。
随便从搜索引擎找了一款游戏app进行演示，因为直接下载的apk文件并无源码，因此，通过逆向的方式将SDK集成进去。
通过脚本进行集成之后进行测试（三端无源码集成过程后续单独写一个独立的介绍）。
如果客户端有微信登录需要提供证书文件进行重签名。
二、抓包分析
首先安装原版app进行抓包分析。
通过原版抓包能看到大量dns请求以及http明文请求数据。
再将逆向集成SDK的app进行安装并抓包。
SDK启动的时候会HOOK掉app的所有网络通讯，由于SDK和节点之间是加密传输的，因此抓包也无法获取dns解析记录以及http、tcp等明文信息，全部都是私有加密协议进行了封包。（截图中dns解析记录应该是在app启动SDK之前或者手机其他app解析请求）对比原版app的dns解析记录。
62001端口为SDK跟节点加密通讯端口。所有数据都被加密传输，无法解密出明文数据。
上图为节点里面进行dns解析服务，所有的客户端dns解析都会在远端节点进行解析，从而防范了dns污染和劫持。也可以避免攻击者获取域名信息。集成SDK之后抓包看到的全部都是加密封装后的TCP数据包。
抓包看到SDK跟分配的节点117进行通讯，在IP为117的节点里面将加密隧道程序断开，模拟节点被攻击产生无法访问的情况。抓包看到SDK迅速切换到分配给用户的第二个可用IP154.所有的切换都是无感知进行的。为了避免攻击者重复拉取全部节点池，SDK的验证端做了身份识别，token、deviceid等方式进行验证。每个用户分配的一组3个ip都不会重复，如果攻击者打死分配给他的节点IP，也只会影响到黑客自己。
断线重连，节点异常自动切换。
SDK方案优点主要是不依靠生抗来防护，而是通过大量分布式节点调度防护。
其次能完美防护CC攻击，因为节点对外不提供任何业务端口，只对外开放一个加密传输隧道端口（62001）。
SDK节点切换都是瞬间切换，不依靠域名dns解析方式。cname防护集群切换依靠域名解析同时无法实现无缝切换，并且防CC效果依然不理想。
|
对比项 |
传统方案 |
SDK方案 |
|
防护能力 |
仅能靠一个本地机房，带宽无法扩展，无法防御更大的DDoS攻击 |
分布式节点BGP接入，针对游戏提供高可用的网络环境，理论上无上限的抗攻击能力 |
|
身份验证 |
传统清洗机房仅靠硬件设备来识别，无法解码游戏私有协议 |
数据报文全链路加密，身份验证，防黑客破解，端到端的加密，游戏安全接入 |
|
节点个数 |
节点数量有限，容易被逐一打死 |
节点数量很多，即使打死几个对绝大多数用户无影响 |
|
CC攻击防护效果不佳，大量漏杀和误杀，严重影响业务 |
100% CC防护能力，0误封 |
|
|
启动防护 |
识别攻击行为需要一个过程 |
即刻识别攻击行为 |
|
攻击成本 |
黑客轻易打出几百Gbps的攻击 |
找不到攻击目标，黑客成本很高 |
|
防护成本 |
防护成本很高 |
防护成本较低 |
|
接入方式 |
需要DNS解析 |
无需DNS解析 |
|
调度能力 |
调度时间很长 |
秒级调度，快速切换节点 |
|
调度策略 |
调度策略很简单 |
多维度，调度策略很灵活 |
|
节点使用 |
用户集中到少数几个防护节点上 |
用户分散到不同节点上 |
|
隐秘性 |
黑客很容易找到攻击目标 |
混淆加防逆向抓包，无法找到真实节点IP |
|
防护配置 |
需配置防护策略 |
无需配置防护策略 |
|
策略制定 |
需根据攻击特征调整防护策略 |
一次接入，终身免疫 |
|
攻击溯源 |
溯源困难 |
溯源成功率将大大提升 |
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支持例外设置，比如链接第三方流媒体或者存储更新资源等无需保护的链接进行直连访问。
原文链接：https://blog.51cto.com/u_15446497/5052144
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/23139
