云服务商的防护服务

普通对于反射式DDoS攻击最好的防御方式当然还是交给云服务商去做. 但云服务商提供的高防IP或DDoS防护服务也有以下缺点:

- 售价高

下面是国内某云服务商的最低档高防 IP 服务的售价:

DDoS防护能力	线路	标准功能费用	增强功能费用
30 Gbps	八线BGP	20,800元/月	28,800元/月
60 Gbps		46,800元/月	54,800元/月
100 Gbps		328,000元/年（包年优惠价）	424,000元/年（包年优惠价）
300 Gbps		528,000元/年（包年优惠价）	624,000元/年（包年优惠价）
400 Gbps		968,000元/年（包年优惠价）	1,064,000元/年（包年优惠价）
500 Gbps		3,753,600元/年（包年优惠价）	3,849,600元/年（包年优惠价）
600 Gbps		4,467,600元/年（包年优惠价）	4,563,600元/年（包年优惠价）

30Gb, 每月 2 万块. 可以负责任的说, 这个防护带宽人家想打垮你简直是欺负幼儿园小朋友. 但这个价格可不是一般中小型站点能接受的.

- 延时不理想 接入高防后, 用户流量会先到高防, 然后回源到你的业务. 但是, IDC 的高防设备需要巨大的带宽接入, 因此高防设备为了节省带宽等费用, 所在的 IDC 很有可能不在一线城市. 这就带来了第二个问题, 延时会增加许多. 这对用户体验是伤害性的.

- 回源 IP 不慎泄露 这个严格来讲不是高防服务商的问题, 而是自身的问题. 由于回源 IP 不慎泄露, 导致 DDoS 还是直接打在了自己的业务对应的 IP 上.

一种新思路

那么, 我们本次就讨论如何去通过一些其他的思路去防御类似这样的攻击.

我们先分析攻击者的整个操作流程.

首先, 攻击者需要确定攻击目标, 因为攻击数据包的协议是 4 层协议, 所以攻击者需要的信息只有一个IP地址. 可能他接到的就是个IP地址, 也有可能他接到的是个域名, 或者URL. 这时候他就要通过 DNS 把域名转换到 IP 地址.

然后它把 IP 地址, 或一堆 IP 地址 (比如你的域名负载均衡到了多个IP). 填写到他的攻击程序中. 然后剩下就是运行程序, 开始攻击了.

我们可以想到, 攻击者控制的发起带宽肯定不是无限的, 可以用的反射资源也不是无限的, 因此, 如果同时攻击的目标越多, 每个目标分摊的攻击带宽就越小.

好的, 这就是我们防御的第一个核心思路: 通过多 IP 来减少每 IP 的被攻击带宽.

另外, 在我对攻击过程的观察中, 发现有的攻击对 IP 的变化是不敏感的.

比如, 你遭到攻击的 IP 被 IDC 下线了, 这时候你换了个新 IP, 攻击有时并不会立刻来攻击你的新 IP. 这种要么是你其实是无辜的, 对面攻击的是一个 IP 范围, 你只是恰好被波及了. 这种情况常见于跟别人复用服务器的情况.

另外的可能就是攻击者没有及时跟进变化或者放弃了攻击.

那么, 我们可以通过以上的思路, 去构建我们的防御体系.

首先我们需要买一个服务, 叫做 CNAME 负载均衡.

应用了 CNAME 负载均衡后, 用户访问你的域名, 首先会请求 DNS, 得到目标域名对应的 CNAME 域名, 然后通过 CNAME 域名去获取真实的目标 IP. CNAME 负载均衡的优势是, DNS 切换 CNAME 记录比切换 A 记录生效更快, 客户端缓存比较容易得到更新 (当然这要看 DNS 服务商和客户端的具体设置和实现).

生效快缓存容易更新就意味着, 发生攻击时, 通过切换 IP 来让正常用户继续访问这个过程会代价更小. 那么不妨我们来计算一下. 假设我 CNAME 负载均衡后面对应了 50 个 IP. 那么一波300Gb的攻击, 如果被均摊, 每 IP 受到攻击的平均带宽是 300Gb / 50 = 6Gb. 这个攻击带宽很有可能会包含在购买 IP 时赠送的防御带宽之内了.

那么, 50 个 IP 的成本是怎样的呢? 每 IP 的租用均价 (按流量付费,流量费用另计) 大概是 0.020 CNY/h, 50 个 IP 一个月就是 0.02 x 24 x 30 x 50 = 720CNY. 是不是很便宜?

甚至我们还能再屯它 50 个 IP, 被打了的时候就挨个换, 跟他玩, 看谁先没耐心.

进阶防御

有了多 IP 后, 我们甚至可以再弄一些更复杂的防御策略.

我们刚才假定的都是每 IP 的流量是均分的. 但实际上站点用户在地理位置上不是均匀分布的. 因此有些 IP 必然正常流量会大一些. 那么针对这些IP, 我们可以买一些便宜的防护服务. 通过变相降级的方式, 让大部分用户遭到攻击时, 仍然可以继续访问. 由于攻击者跟我们信息不对等, 因此他如果想知道哪些 IP 是大流量 IP 而转去攻击的话, 还是很难的. 这样也算变相节省了防御部分的费用.

如果我们能接入云服务商的 OpenAPI, 甚至我们可以通过程序去动态的更换IP, 进一步降低运维压力.

总结

以上所讲的防御方式, 对于无状态业务是最有效的, 例如网站. 但对于有状态业务, 例如游戏服务器, 是很难的. 游戏服务器无论是什么协议, 很难去切换IP. 因为一但切换, IP 对应的所有客户端就要重新连接服务器, 这对一些实时性很高的游戏是难以忍受的. 但对于本身就用 HTTP 的一些实时性较低的游戏, 例如棋牌类游戏, 是可以考虑的. 多屯点 IP 没坏处, 毕竟一个 IP 放着一个月也才 14 块. 上述方案在我接近 3 年的实际应用期间, 起到了不小的作用, 对于 100Gb 以下的攻击, 基本在发现被攻击 15 分钟之内, 就可以让大部分用户继续正常访问了. 但对于 500Gb 以上的攻击, 更多的比的是耐心, 尤其是在买不起高防的情况下, 只能人工防御, 尽量减小损失了.