随着物联网的发展, DDoS 攻击变得越来越普遍. 站长们或多或少都听说过或实际被 DDoS 攻击过. 本文通过我这几年应对 DDoS 的经验, 来给大家描述一个开销比较小的 DDoS 防御思路, 希望能够抛砖引玉.
分类
常见的 DDoS 攻击从流量真实性 (流量是否真正作用到了业务上) 上来讲, 显而易见只有两种:
- 真实流量 DDoS
- 假流量 DDoS
我们先看真实流量 DDoS. 真实流量 DDoS 其实是很难防御的, 尤其是对站点资源真实请求的攻击, 将会对运维带来极大压力.
比如利用网络上公开的 web 反向代理站点发起的攻击, 这种攻击与正常用户访问高度相似, 很难解决.
又或者注入了大流量网站, 将大流量网站的请求跨域请求到了受害者的站点.
但这种攻击成本高, 而且收益不高, 所以对于中小型站点是很少见的.
接下来是假流量 DDoS.
从攻击成本, 流量放大倍数等因素综合来看, 基于非 TCP 协议的反射型 DDoS 攻击仍然是现在针对中小站点小规模 DDoS 攻击的最佳选择.
因此, 站点所受攻击大概率也是反射型的假流量 DDoS 攻击.
想要完成这样的攻击, 需要以下条件:
- 可以修改 Packet Header 来将流量导向受害者.
- 可利用的反射节点存在反射.
我们来依次讲解:
可修改 Packet Header 指, 由于 UDP 等协议是非面向连接的, 因此伪造 Source IPv4 Address 是很容易的, 这样就可以把 Source IPv4 Address 设置为受害者的 IPv4 地址.
反射节点指, 利用上面的可篡改的协议访问一些特定暴露在网络上的服务时, 这些服务返回的数据比请求所需的数据大, 并且大很多倍. 越大攻击效果越好.
例如 Memcached 协议漏洞, 假设有一些 Memcached 服务器没有加任何保护措施就放在了公网上, 我们甚至可以自由操作这些 Memcached 服务器. 那么我们只需在 Memcached 里面 SET 一个巨大的数据, 然后发起一个对 Memcache 的请求, 该请求的 Source IPv4 Address 填写为攻击目标的 IPv4 地址. 这样就完成了攻击.
这样的攻击足足可以把流量放大 10,000 - 51,200 倍, 毕竟请求的 Payload 就是一个 GET {key} 的二进制数据. 但返回的却是我们之前 SET 到里面的一大坨数据. 假设我们控制的僵尸网络可以发起 50Mbps 的请求, 那么经过 Memcached 协议漏洞的放大, 我们得到的攻击带宽就是 50Mb * 51,200 = 2.44Tb. 这是多么可怕的结果. 要知道历史上最大的 DDoS 带宽也才 1.35Tb.
这样的攻击的成本是相当低的. 现如今家用宽带的上行都有很多甚至能达到 30Mb 的带宽, 而家用物联网设备也越来越多. 我们可以想象到, 一旦家里有存在漏洞的设备, 那么这些漏洞很有可能被利用. 最典型的就是一些家用路由器的 SSDP 漏洞, 路由器恰好又是插在宽带的入口上的. 如果能被访问到, 这将是很可怕的后果.
云服务商的防护服务
普通对于反射式 DDoS 攻击最好的防御方式当然还是交给云服务商去做. 但云服务商提供的高防 IP 或 DDoS 防护服务也有以下缺点:
- 售价高
下面是国内某云服务商的最低档高防 IP 服务的售价:
线路资源: 八线BGP, 地域: 中国大陆, 保底防护带宽: 30Gb, 弹性防护带宽: 30Gb, 业务带宽: 100 M, 功能套餐: 标准功能, 防护域名数: 50, 业务QPS: 3000, 端口数: 50, 购买数量: 1, 购买时长: 1个月, 配置费用: 20,800.00 CNY
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 以上的攻击, 更多的比的是耐心, 尤其是在买不起高防的情况下, 只能人工防御, 尽量减小损失了.
本文仅是个人经验, 欢迎各位大佬不吝斧正.
