使用云服务的竞价实例来抵御 DDOS 攻击

前因

之前有写过一篇 记一次接口受到的基于http请求的DDOS攻击 讲述一次抵御 DDOS 攻击的情况。 但是后面攻击的方式又增加了,最明显的两点就是:

  1. user-agent 都是正常的浏览器类型
  2. ip 地址都是很分散的,并且每分钟的请求频率都不高,也就 3-5 次, 但是不同 ip 请求非常多

第二点就会导致我们的禁 ip 策略就被废掉了,因为我们不能把限制降的很低,比如同一个 ip 地址请求登录接口一分钟如果超过 3 次,就会被加入黑名单。这样子固然可以抵御, 但是也会造成大面积的误杀。 说白了,就是这些突然爆增的流量跟正常的用户流量没啥两样。 防刷脚本已经没办法去区别了。

使用竞价实例

面对以上的情况,我们的防刷脚本已经没办法区分非正常流量了,而且依赖的云厂商的普通版的 DDOS 防御,也是没有用的,这种请求频率也触发不了他们的防御机制,除非花大价钱买高防版。 所以我们只能新开机器去扛流量了。 但是新开机器按量使用其实也不便宜, 而且又是临时开的, 后面等不攻击了, 新开的机器就要下架了。 所以也不可能月付或者年付。

因此我们后面选择了使用竞价实例来扛流量。

关于竞价实例的介绍,具体可以看: 什么是竞价实例

竞价实例(Spot)是云服务器 CVM 的一种新实例运作模式,它最核心的特点是折扣售卖和系统中断机制,即您可以以一定幅度的折扣购买实例,但同时系统可能会自动回收这些折扣售卖的实例。当您购买并获得一个竞价实例后,它的使用和按量计费的 CVM 实例基本毫无区别,包括控制台操作、远程登录、服务部署、关联 VPC 等。

简单的来说,他跟普通实例的使用是没啥差别的,唯一有几个点有区别:

  1. 竞价实例非常便宜,一般只有同等配置的实例的 10% 的价钱,具体价格会受当前市场波动
  2. 正是因为他会受市场需求价格波动,所以有可能今天你开的实例,过几天别人开更高的价格来竞价,那么这个实例就会被中断,变成别人的了

不适用场景

由于系统中断机制的存在,您并不能完全掌握实例的生命周期,所以建议避免在竞价实例上运行对稳定性要求极高的服务,例如:

  • 数据库服务
  • 没有采用负载均衡的在线服务、网站服务
  • 分布式架构里的核心主控制节点
  • 长时间(10+小时)的大数据计算作业

适合的场景

适用场景

  • 大数据计算
  • 采用了负载均衡的在线服务和网站服务
  • 网络爬虫业务
  • 其他细粒度或支持断点续算的计算场景

针对负载均衡服务,还有一个最佳实践: 通过负载均衡在保证在线和网站服务的稳定性

  • 接入层使用负载均衡,例如 CLB。
  • 后端资源采用部分按量计费实例 + 大量竞价实例的配比模式。
  • 监听竞价实例中断情况,从 CLB 中移除即将中断的实例。

稳定性,不就是防御 DDOS 攻击吗, 恰好我们的服务都是有用负载均衡的服务的,比如 aws 的 ELB , 或者 腾讯云的 CLB 服务。 所以他的这个最佳实践,刚好很符合我们的这种情况。

实操流程

  1. 在受到 DDOS 攻击的时候,在原有服务扛不住的时候, 开启竞价实例机器
  2. 将某一个业务服务器的快照,放到这台竞价实例上,启动业务服务
  3. 将这台实例加入到负载均衡服务中,并设置一个比较大的权重,让大部分的流量都流到这一台,保证其他实例负载不会太高
  4. 当 DDOS 攻击停止的时候,根据当前负载情况,解绑竞价实例的负载均衡服务,乃至最后下载竞价实例

接下来附上几个图,会比较直观,以腾讯云为例,当我们开启竞价实例的时候,根据具体的业务来选择对应的配置,比如我们这种防 DDOS 攻击的,那肯定 cpu 要足够好,所以可以选择 6 核或者 8 核,这样子处理请求的时候,效率更好。 可以看到相比原价,这个价钱真是太香了。

1

这边要注意一个细节,就是竞价实例最好跟业务所在的实例在同一个 vpc 内网内(比如都在硅谷),这样子很多权限,比如数据库权限,都不用再额外设置,只需要将快照拷过去,然后重新启动服务就行了。

当竞价实例服务启动之后,接下来我们就要将这个竞价实例服务加入到业务所在的负载均衡实例的分配链中,并且设置比较大的权重:

1

这样子这台竞价实例就可以开始抗流量了。 如果一台不够,那就再加一台,看谁更持久。

同禁 ip 一起处理

很多时候,我们通过开启竞价实例之后, 虽然流量抗住了。 这时候如果 攻击者 还是锲而不舍的 一直在攻击, 持续了好几天。 这时候还可以辅助 禁 ip 这个策略。 之前短时间之内,我们无法很快的判断哪些 ip 是刷的,一个是因为 攻击者 用了 ip 池, 少则几千个 ip, 大则几万个 ip, 这时候如果再加上平均请求频率低的话, 我们是很难马上抓到这些刷的 ip 的。 但是他经过一天一夜的刷接口之后, 只要时间足够长, 我们是可以直接从 nginx 的 log 中,分析有哪些 ip 是一直在请求该接口的,并且知道请求的总数, 然后再定一个策略,比如 2 个小时之内, 请求该接口的次数超过了 50 次, 那么这个 ip 无疑就是攻击者的 ip 了, 那么接下来只需要将这些 ip 都禁掉就行了。

总结

通过开启竞价实例,我们可以在 DDOS 攻击期间, 稳定的抗住流量而付出的成本却不会很高。 不过要注意的是, 一旦扛过去之后, 接下来就要考虑解绑和下架机器了,不能一直挂着。 不然后面系统中断竞价实例的时候,就会影响到我们的业务了。 当然, 中断的时候, 系统会提前通知对应的运维人员。 虽然文档说只会提前两分钟通知,但是真实情况应该会至少提前半小时之类的。我们也没有遇到过突然中断的情况,都是手动解绑下架的。 而且也不会频繁中断, 有用过超过一个星期都不会中断的情况, 可能得看市场需求吧。