使用CDN怎么防止被攻击巨额欠费

　　CDN盗刷流量可能导致游戏厂商因为意外的流量消耗而支付高昂的费用，甚至可能超出其预算。此外，攻击者盗刷的流量可能会占用游戏的网络带宽，导致游戏变得不稳定或无法正常运行，从而影响游戏的玩家体验。此外，如果攻击者通过盗刷流量的方式攻击游戏服务器，则可能会导致玩家数据泄露或游戏服务中断等安全问题。因此，游戏厂商应该采取适当的措施来保护其游戏服务的安全和稳定性，例如监控CDN访问量、限制单个IP地址的访问速率、过滤恶意请求等。由此可见，CDN测试的重要性，下面就请看作者以第一人称为大家介绍有关CDN方面的一些实例。

　　01CDN相关介绍

　　最近一个月，有不少项目组发现自己的项目成本暴增了好多，我们项目组也不例外的中招了，排查原因发现，是有人通过不停的下载客户端安装包来刷我们的客户端发布平台 CDN流量，那具体是怎么一回事呢?下面让我以一个负责打包、外放的测开第一人称视角为大家介绍一下从发现到解决的过程。在详细介绍前，首先介绍几个术语，让之前没接触过的同学也可以顺利的理解这部分内容。

　　1.

　　内容分发网络（CDN ）

　　简单来说，我们想让用户下载到我们的游戏包体，如果只上传到一个服务器上，那同时有几十个玩家下载，网速就会特别慢，并且如果用户距离该服务器较远，则网速也会随之降低。那么就提出一种方案，在全国各地都布设服务器，将资源先上传到总服务器，总服务器再将资源分别上传到全国各个服务器节点上，用户在下载时会根据算法自动选择最快的服务器节点下载，并加入负载均衡架构，既分摊了大量用户同时下载时的服务器压力，又能让用户因下载距离他最近的服务器的资源提升了网速。

　　2.

　　分布式拒绝服务（DDoS）

　　指黑客通过大量终端如电脑、手机等设备通过网络向服务器发送请求，占用其他用户使用该服务器资源以达到攻击服务器的目的，就是 DDoS 攻击。具体破坏的表现如：消耗网络带宽导致服务器无法正常应答用户的服务、网络阻塞甚至服务器宕机等。像我们这次遇到的这个问题，实际上就是黑客模仿用户来下载大量重复资源，一来可以造成服务器资源不足以支撑正常用户的请求，二来可以造成大量的 CDN 租赁费用，因为 CDN 是按流量计费，有不少的个人网站运营者因为没有服务器防护或者没有购买 CDN 运营商提供的防护服务，导致夜深人静的时候被黑客刷了几百 TB 的流量，第二天短信提示信用卡欠费(甚至银行来收你房子)。

　　3.

　　客户端发布

　　项目要上线新版本当天，需要让玩家能更新到我们的最新版本，那项目组负责打包的QA 需要在上线前将游戏安装包、patch 等文件打包并上传到发布平台，我们网易的客户端发布平台叫做 gdl 或 Gaia，gdl 会帮我们把文件分发给各 CDN 节点，内网测试好文件可以正常下载后，在更新当天将 updatelist 外放出去，让玩家的客户端可以下载到更新内容。

　　发布流程

　　4.

　　用户代理（User Agent，简称UA）

　　是一个记录了来自用户使用的下载客户端的请求来源信息字符串，一般会记录在请求头中，使得服务器能够识别客户端使用的操作系统及版本、CPU 类型、浏览器及版本、浏览器渲染引擎、浏览器语言、浏览器插件等。比如某个用户的 UA 为：Mozilla/5.0 (Windows; U;Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11.值得一提的是，UA 是可以伪造的，并不是不能修改的内容。

　　02实例介绍

　　以上了解清楚后，就让我们一起来看看本次问题排查的经过。

　　某天，组内的 SA 找到我说：“你看看最近是不是版本有更新?还是营销拉新力度比较大，我们下载客户端的流量大了好多。”并附给我一张当天流量排行榜的截图。

　　流量排行榜截图

　　我一看，下载流量排名第一的游戏包体竟然是今年 1 月份的，而官网投放的是 9 月份的，明显不合理，引起了我的警觉。通过调查发现，下载该包体的下载 IP 来源也比较密集，主要是来自河南和广东，看起来比较符合 DDoS 攻击的特征。

　　下载包体ip分布

　　同时 SA 发现不止我们项目的 CDN 流量被盗刷，包括其他两个项目组都出现类似问题，为了最快的减少损失，我们只保留了两个月以内的旧包体，其余完整包全部删除，操作之后很快从监控中看到有大量 4xx(找不到资源)的请求状态码报错，代表我们成功下掉了资源，实时带宽和流量也明显降了一大截。

　　宽带流量趋势图

　　实时宽带流量

　　明显抑制住了流量盗刷问题之后，由于我们即将上线月版本，工作比较多，我就先去处理月版本的测试工作。本以为可以先告一段落，想在这之后再详细制定如何防范流量盗刷的方案时，11 月 5 日黑客又开始刷流量了，且这次盗刷的包体是官网上最新的包体，无论如何也不能再下掉这个包体了，就算下掉这个资源，黑客一样可以刷其他资源，治标不治本。

　　二次刷流量

　　为了稳妥起见，我们先咨询了其他项目组，了解到他们也被同一个黑客盗刷了很多流量，采用了 UA 封禁措施，据说效果比较显著，且没有外网玩家反馈无法下载游戏客户端的问题(UA封禁可能存在误封禁的问题，导致使用与黑客一样的 UA 下载的正常用户会被误禁)。有了前一个项目组的成功经验(帮我们趟雷)，我们决定与其保持一致，先禁掉这个下载来源的 UA，禁掉之后，可以明显看到实时带宽占用少了 80%以上。

　　实时宽带流量

　　禁用前后对比

　　11 月 25 日，我们又封禁了另一个盗刷 UA：okhttp，流量盗刷又被砍了一刀大动脉，至此我们的流量盗刷问题被成功遏制住了。目前虽然仍存在极少量盗刷的问题，但对项目成本的影响已经非常低了，属于可接受范围内。

　　另一个盗刷

　　在这次的问题复盘中，我觉得在我的工作中存在 2 个问题：

　　1. 缺乏安全意识

　　说到这个问题，让我想到在春招面试的时候，最怕别人问到网站开发安全性问题，比如如何防止 MySQL 注入，因为总是把精力放在开发能力的提升，却忽略了安全。现在回想起来实在是给我敲了一个警钟，因为在承担打包发布工作的一年来，我从来没有关注过上传的包体的下载情况，也没有想到我需要关注这一块内容，而 GDL 平台是在 10 月才上线了实时监控和每日巡查，而在这之前流量是否被盗刷，我们无从得知，换句话说，这个问题可能已经潜伏已久，只是没有发现，直到最近有一个猖狂的黑客在疯狂的刷流量才引起了我们的注意，此时已是亡羊补牢，为时已晚。安全问题无小事，建议所有未上线的项目都应该未雨绸缪，上线的项目也要及时查漏补缺。

　　2. 需要提高团队意识

　　这一次的事情如果不是 SA 发现的及时可能会酿成更大的危机，虽然线上监控这项工作不是所有 QA 都能接触到，但它仍属于质量保障的范畴内，我们应该主动的去思考并承担好这项工作。好的 QA 不仅仅能把自己的功能测好，更应该做到能够推动各种角色来共同推进，好的质量是整个团队的荣耀，体现的不仅是质量管理团队的能力，还是整个产品团队的能力。

　　我希望能通过这件事带来的启发，弥补我们这块工作的空白，让测试右移覆盖的更为全面。所以痛定思痛，狠狠的补习了安全方面的知识，并在下面以自问自答的形式，通过分享关于 DDoS 攻击方面的内容，以及如何结合到项目组的实际工作中，来提升读者们的安全防范意识，让其他项目组同学在遇到该问题的时候有可复用的经验供其参考。

　　03 关于DDoS攻击

　　1.

　　为什么黑客要攻击我们

　　人们在做一件事的时候，往往背后都有一定的动机，尤其是发动 DDoS 攻击的成本也不低，所以我推测有这么几种可能的原因。

　　1. 炫技：

　　黑客刚学会了一门“独门剑术”，磨刀霍霍，迫不及待的想找个沙包试试威力，从而获得极大的虚荣和满足感，可以对外吹嘘说“我可是攻击过网易的服务器~”

　　2. 盈利：

　　有个人或者行业内存在竞争关系的公司找黑客攻击服务器来实现不正当竞争的手段，或者像杀手一样接悬赏来盈利的也是存在的。也有出于民族、政治等原因来攻击、敲诈的成分在里面。

　　3. “毁灭你，与你何干”：

　　借用《三体》里的一句名言，意思是：三体人在进攻地球的时候，根本不会考虑地球人的感受，也不像地球人一样存在道德和法律的约束，没有底线可言。在我们这次的问题里指“我就是想攻击你，没有任何原因”。

　　4. 无良 CDN 服务商监守自盗

　　据传闻有些小平台 CDN 服务商与黑客狼狈为奸，专门挑没有购买 CDN 服务商提供的流量防护套餐的用户，把他们绑定的信用卡刷欠费。我对此传闻持怀疑态度，但不排除有这种可能，如果有同学有个人的 CDN 购买需求的话，在选择供应商时要选择口碑好的大品牌，以免哪天起床发现自己的信用卡被刷爆了。

　　2.

　　黑客会采取什么手段攻击我们？

　　为了保护好我们的服务器，我们要分析黑客能从哪些方向来攻击我们。如果学习过《计算机网络》的同学应该知道，我们的网络是遵循 OSI 七层模型的，而 DDoS 攻击主要面向的是上四层。

　　OSI七层模型

　　1. 流量攻击：

　　主要攻击的是应用层，通过向服务器发送大量的请求，导致服务器响应缓慢甚至宕机。比较鲜明的案例就是每年某宝双十一付尾款的时候或者抢一些比较火的门票时，一到时间点由于大量人同时付款，导致服务器处理不过来如同洪水般的请求，用户这边会出现服务器繁忙、请求超时等各种问题支付失败。

　　流量传输

　　2. 协议攻击：

　　主要攻击的是传输层，与流量攻击不同的是，他旨在通过发起大量的 TCP 请求且不释放掉连接，将服务器资源占满，导致其他用户不可用。举个生动的例子：可以把服务器当做一个餐厅，每一个用户的请求代表有客人来到这个餐厅就餐，黑客就相当于来了一批流氓，把所有座位都占满了但不点菜，让餐厅无法正常营业，通过这种方式来使服务器无法发挥作用。该攻击的实现细节是通过将 TCP 建立连接的三次握手中最后一步，黑客的请求机是通过始终不向服务器发送 SYN 请求，导致服务器一直处于请求等待状态来实现攻击，服务器需要等到请求超时、重发、再超时才会将该请求丢弃，而这段时间里，大量的攻击请求几乎瞬间将服务器的连接池、等待队列都占满了，导致服务器无法处理正常请求。目前的处理方案大多是通过增加网关、防火墙来阻断攻击。

　　数据传送

　　3. 带宽攻击：

　　这个跟我们的 CDN 盗刷问题比较像，但它是通过发起大量的大流量请求，比如下载视频、文件来让带宽占满。就像我们在寝室用连同一个 wifi 下载电影时，一个人下载可以独占100MB/s 的网速，但两个人下就需要平分，各自占用 50MB/s 的网速，同理黑客占用的服务器带宽越多，正常用户能分到的就越少甚至没有。与我们这次问题不同的是，虽然也能对我们造成带宽的影响，但影响比较小，原因是 CDN 通过负载均衡可以将大请求分流，平均到每个 CDN 节点的流量就比较小了，对我们最大的影响是：通过下载我们 CDN 上大量的资源来造成成本上的负担。(CDN 是按量付费，比如 60 元/TB)

　　值得一提的是带宽攻击中的一种手段：DNS 放大攻击，它是通过攻击应用层实现，巧妙的利用域名系统 (DNS) 服务器中的漏洞，DNS 服务器递归查询会将最初很小的请求变成较大的负载，达到其消耗光服务器网络资源的目的。发起需要满足若干条件：1.DNS 支持递归查询。2.需要通过大量僵尸机发起请求。3.发送的数据量要远大于请求的数据量。

　　那么如何知道自己的 CDN 流量被刷了呢?或者流量被盗刷的特征是什么呢?

　　如果你的 CDN 出现了以下情况，那你可就要小心了!

　　①非版本更新、推广导致的带宽/流量突增。

　　②CDN 上下载流量排行的前几名是旧包体或 patch，且下载量极大

　　③个别 IP 下载量很大，来源都是同一地区且 UA 相同或相似

　　④使用的 UA 为

　　wget/curl/Go/python-requests 或无 UA，下载流量占比很高

　　⑤下载端游安装包的 UA 是手机的如“IOS16”，或者下载手游安装包的 UA 是电脑的如“Windows NT 10”。

　　3.

　　我们该如何防范DDoS攻击呢？

　　想要阻断 DDoS 攻击，最大的难点是如何区分正常流量和异常流量，不误伤到正常的用户，否则干扰了业务的正常运转，对于我们是得不偿失的，我们的核心思想是不断的“做减法”，提取出异常流量的特征，并想办法阻断掉。把我们的服务器比作一座城池，如何能保证出入城池的都是正常人，而不是刺客，这才是我们的目的。

　　1. 开启专业的防 DDoS 防火墙

　　顾名思义就是直接为计算机搞一条护城河，只允许特定端口和特定 IP 的访问，分为硬件和软件两种，但这种一般都是开放某个端口供外网访问对应的应用，只能防的了萌新小白，稍微有点技术基础的都能轻松的绕开，不过没关系，这只是我们的第一道关卡。

　　2. IP 白名单/黑名单、UA 封禁

　　只允许特定的 IP 能或不能访问服务器，就像进入城门会有官兵检查你的文书，也就是身份证，一看你是从经常出现刺客的国家来的，那对不起，此路不通。但这个方案不够完美，如果黑客伪造自己从一些像网吧、校园网这样的 IP 出口进入公网，那么会将一些正常用户给误伤。所以会多方核实这个 IP 确实有问题或只是短暂的 Ban 掉这个 IP 来源的请求，才会用这个手段。

　　3. 速率限制+最大请求数限制

　　有些黑客会通过一台机器发送成千上万个请求攻击服务器，正常玩家是根本达不到这种请求程度的，那我们就可以设置同一个 IP 最多只能发起 10 个请求，每个请求分配的带宽不超过 10Mbps，这样能够显著的减轻对我们服务器的影响。但缺点是只能应对简单的 DDoS攻击，高超的黑客可以做到用几万台客户端来发起 DDoS 攻击，那我们的服务器也是防不住的。

　　4. 权限校验

　　只有通过身份校验的用户才能允许访问服务器的资源，比如注册账号、验证码、url 鉴权、refer 防盗链等措施，就像给每个出入城门的用户做人脸识别，虽然会对服务器有一定的性能负担，但是是比以上所有措施效果都好的防护措施。缺点是对产品的场景有要求，尤其是应用于 CDN 这种希望无鉴权下载的场景的开发成本会较高，且还是有较小的可能被黑客破解你的校验密钥可能。

　　5. 使用 CDN 分流抗压

　　这点我们上面有介绍过，此处不详谈了。

　　6. 提升服务器配置

　　打铁还需自身硬，黑客往往需要超过服务器数倍的资源来发动攻击，那我们可以通过提高服务器规格，让其能扛住攻击，任他风吹雨打，我自巍然不动。不过服务器配置是和成本挂钩的，一般不会采取这个措施。

　　我们又该如何结合到实际业务中呢?俗话说得好，不怕贼偷，就怕贼惦记。就算我们做了再充足的措施，想攻击你的黑客也找得到可乘之机。最好的解决办法就是定期监控线上的下载情况，并及时更新我们的安全策略，保证黑客在没造成更大的损失前，把损失降到最低，想做到这一点，就万万离不开发布平台提供的运维工具，以实时、定期的监控服务器情况，通过关注一些重要的指标和数值来快又好的关注线上的更新、下载情况。

　　04 关于运维工具

　　运维工具除了用来监控流量盗刷问题外，主要用于以下场景：

　　测开检查 Patch 更新、外网整包换包后，更新、下载情况如何?

　　pv、uv 数据怎么样?

　　SA 确认流量、带宽增加是正常访问还是攻击?

　　用户报障后，功能 QA 排查原因，确认是 CDN 的原因还是运营商原因还是用户自己的原因?

　　接下来会介绍 GDL 平台为我们提供的几个非常有帮助的工具以及他们的作用和需要重点关注的指标，来帮助我们更好的使用这些工具：

　　GDL平台工具

　　1.

　　实时监控

　　顾名思义，就是展示最近几天到现在线上实时的下载数据，产品组测开可以投入一点精力来关注以下指标，与 SA 互补：

　　（1）带宽均值与峰值：

　　需要关注近几个月版本、周版本和日常每天的峰值流量和均值流量，趋势基本每个版本都是一样的，如果出现某天凌晨不合常理的带宽暴增，说明大概率是出现流量盗刷的问题。如下图

　　流量被盗刷

　　（2）总流量：

　　一段时间内所有访问者下载资源产生的总流量数。与带宽比较类似。

　　（3）总请求数

　　所有访问下载资源的请求总数，如果资源采用了大文件分片下载，一个资源可能产生多次请求，且状态码为 206.常出现于安装包资源、全量 patch 资源下载的场景。当出现大量4XX 请求时，可能是某个资源出现了问题，玩家下载不到，测开需要第一时间排查原因并处理问题，也有可能是黑客在攻击时没有访问到对应资源，这种情况就可以忽略。另外 GDL也提供了实时报警的告警规则，会在 10 分钟内将报警信息推送到 PoPo，以下我们设置的阈值可以供大家参考，基于自己项目组情况进行调整。

　　设置阈值

　　2.

　　每日巡检

　　每日巡检会对 2 天前(由于日志聚合需要一定时间，有两天的延迟)的下载情况输出报告供相关同学查阅。

　　输出报告

　　阈值的设定参数，同样供大家参考

　　阈值设定

　　负责打包的同学可以每天检查当天的报告，尤其是 Top 客户端 IP 和 TopURL 两个面板，提供的数据能够清楚的检查到问题。

　　Top 客户端 IP

　　该看板提供了流量前几名的 IP 地域分布以及对应的 UA。地域相同的 IP 可能是同一个刷流量的源头，如下图中 TopIP 的地域分布中东莞占大多数，且 UA 也相同，明显是有问题的。还要关注 user_agent 字段，如“wget”是指通过 linux 下载，但对于在 Windows 平台上运行的端游来说使用“wget”来下载明显不正常。

　　流量topip

　　TopURL：

　　该看板提供了目前 CDN 上当天下载的流量前几名，主要要结合自己项目来检查几个内容：

　　1. 目前线上玩家应该下载的版本流量是否正常?

　　2. 目前线上玩家下载不到的版本是否还能下载的到?或者流量明显不正常(去年的版本流量比今年的版本还大)

　　3. 请求数与 UV(unique visitor，可以理解成每个人重复访问多次也只算一次)的比例我们设为 rc/uv，我们可以估算一下正常包体的 rc/uv 作为基准，如果某个版本的 rc/uv 明显大于基准值，则该资源可能被巨量请求(DDoS 攻击)访问，对于 CDN 的影响几乎可以忽略，但如果是个人网站服务器的话就非常危险了，也是一个值得注意的指标。

　　UV监控

　　3. 用量分析

　　这个看板和实时监控所展示的内容基本接近，更多的是为了展示每天的流量数据，以及一段时间内的数据走势，可以视为加强版的实时监控，这里不再多赘述，比较容易上手。

　　实时监控

　　4.运营分析

　　这个面板和用量分析差不多，也是以天为单位展示 TopURL 数据。不过我们可以在“下载来源”中检查 referer 字段(表示当前流量的来源参考页面，可以简单理解成从哪个页面跳转来下载的)

　　下载来源检查

　　如果该字段为“-”，则大概率代表该资源被刷，如下图所示。

　　资源被刷

　　有的同学可能会想到我上面介绍的内容，“明明是运维方向的工作，有 SA 操心就好了，为什么要 QA 来投入精力做这件事呢?”我有两个想法：

　　1. 不能过度依赖 SA。

　　SA 不如 QA 了解项目组的情况，出现问题时可能没有 QA 这么敏感，这也是为什么他们是中台部门，而我们则是属于产品组的原因，SA 的工作更多的致力于解决不同项目组高度类似的需求，提供通用程度高的解决方案，而 QA 的职能以质量保障业务为导向，关注点会有很大不同。有时 SA 看到异常数据时，细心的 SA 会来问一下项目组，那假设 SA 同学就是没关注到这个异常，导致了线上事故，如果造成服务器宕机、回档而导致玩家流失，不论是谁的责任，影响的是整个产品组未来长期的运营，是非常大的损失。

　　2. 接触不同的工作有利于从其他角度提高测试质量。

　　举一个我在实际工作中的例子：我们 QA 组之前向 CP 方提出提供类似于自研项目配表的需求，但出于安全原因遭到拒绝，CP 方虽然提供了替代的解决方案，但对于我们开展测试工作仍然存在极大的不便。但我在接手打包工作后，发现 CP 方交付的 SVN 目录下有 Json版配表压缩包，并通过 SVN-Diff 实现了每次版本更新时检查配表修改内容的工具，极大的降低了我们每次版本中关于数值修改的事故率，而之前一直是程序负责打包部署工作，他知道这是配表，但他不知道我们需要配表，也没有想过这个内容对测试工作和质量保障有什么积极意义。所以我们 QA 应当主动地去发掘其他职能中可以提升测试效率的工作，不仅可以提高测试右移的覆盖度，还很有可能发掘出对质量保障有益的创新点。

　　05 结语

　　最后，基于这次出现的问题，我们项目组会结合实际情况可能会采用如下手段：

　　1.新的月版本安装包上线后马上删除老版本客户端包体，防止老版本包体成为盗刷缺口。

　　2.URL 鉴权，NGP、下载器、官网的更新和下载接口开启 url 鉴权，通过 timestamp+salt 生成 token，未经过校验的请求将直接返回 403.

　　3.收到流量突增报警后，人工查证并 ban 掉恶意盗刷 IP(条件：请求数>15 流量>600GB)

　　4.通过 CDN 配置频次控制，比如在 60 秒内，每个资源最多下载 5 次。

　　以上就是我的全部经验分享，希望能对各位有所帮助。