家庭数据中心系列 cloudflare教程(五) DDoS攻击介绍及CF DDoS防护配置教程
本文最后更新于 176 天前,其中的信息可能已经有所发展或是发生改变,如有失效可到评论区留言。

前言

在CF免费提供的诸多功能中,除了WAF以外,就要属DDoS防护功能最实用了,甚至从某些角度来讲,DDoS防护才是CF免费提供的功能中最实用的(主要是对于那些在国内苦于被DDos攻击消耗购买的云供应商CDN流量的朋友而言,采用静态站点且托管在国外免费云上的站长请无视~)。

所以,续WAF之后,我就把DDoS防护功能作为第2个单独拿出来讲的功能吧,不过在这之前,需要先搞清楚DDoS攻击究竟是什么。

DDoS攻击介绍

DOS攻击是什么?

在正式介绍DDoS攻击之前,要先搞清楚DOS攻击是什么。

DoS(Denial of Service,拒绝服务)攻击是通过耗尽目标系统的资源,使其无法正常提供服务的网络攻击方式,DoS攻击通常是由单一来源发起的。

DoS攻击的特点

  1. 单一攻击源:DoS攻击通常来自单一来源或单台计算机,而不是多个分布式来源。
  2. 相对容易检测:由于攻击流量来自单一来源,因此在检测和防御上相对容易。
  3. 攻击强度有限:单一来源的攻击能力有限,通常无法达到DDoS攻击那样的规模和破坏力。

常见的DoS攻击类型
Slowloris:攻击者保持大量不完整的HTTP请求连接,消耗Web服务器的资源,使其无法处理其他请求。
RUDY(R-U-Dead-Yet):类似于Slowloris,但使用的是HTTP POST请求。攻击者发送大量的POST请求,保持请求的连接打开,逐渐消耗目标服务器的资源。
HOIC(High Orbit Ion Cannon):主要通过发送大量的HTTP GET请求,利用目标服务器的资源。虽然HOIC不完全是慢攻击,但可以通过发送大量的请求来达到类似的效果。
Slow Read:攻击者通过发送一个缓慢的HTTP请求,然后在服务器响应时缓慢读取数据,导致服务器长时间保持连接,消耗资源。
Slow POST:攻击者通过发送一个缓慢的POST请求,使服务器在响应时保持连接,逐渐耗尽服务器资源。攻击者发送的数据量很大,但请求和响应过程很慢。

总体来说,DoS就像是一般的单体武器(例如左轮手枪),不是大规模杀伤性武器,所以没有覆盖杀伤能力,且直接杀伤力也不强,所以一般都走技术路线,对应用进行针对性攻击(slowloris、RUDY、HOIC、Slow Read、Slow POST等),这样隐蔽性强且有一定杀伤力。

另:其实洪泛类攻击本来也是DoS的范畴,只不过在服务器性能越来越强以及网络带宽越来越大的当下,DoS单一来源导致洪泛能力远不够看,且很容易被安全策略针对性封锁,所以基本不会被采用。

DDoS攻击是什么?

DDoS(Distributed Denial of Service,分布式拒绝服务)攻击是一种通过大量分布在不同地点的计算机或设备发起的攻击,旨在使目标系统、服务或网络无法正常工作。与传统的DoS攻击不同,DDoS攻击利用了多个攻击源,增加了攻击的规模和复杂性,使得防御变得更加困难和复杂。

DDoS攻击的主要特点:

  1. 分布式来源:攻击流量来自多个不同的计算机或设备,通常是被控制的僵尸网络(Botnet)。
  2. 大规模攻击:由于攻击源的分布广泛,攻击流量通常非常庞大,能够迅速耗尽目标的带宽和资源。
  3. 难以防御:由于攻击源分散,单一的防御措施难以有效阻止攻击,需要综合多种防护手段。

常见的DDoS攻击类型:

  1. 洪泛(Flood)攻击
    SYN Flood:发送大量的TCP SYN请求,耗尽目标服务器的连接资源。
    UDP Flood:发送大量UDP数据包,耗尽目标服务器的网络带宽和资源。
    ICMP Flood:发送大量ICMP Echo请求,耗尽目标的带宽和处理能力。
  2. 资源耗尽攻击(Resource Exhaustion Attack)
    DNS放大攻击:利用DNS服务器的响应放大特性,发送伪造请求,放大响应流量,攻击目标的DNS服务器。
    NTP放大攻击:利用NTP服务器的响应放大特性,发送伪造请求,放大响应流量,攻击目标的网络带宽。
  3. 应用层攻击(Application Layer Attack)
    HTTP Flood:发送大量HTTP请求,耗尽Web服务器的处理能力,导致服务不可用。
    Slowloris:攻击者保持大量不完整的HTTP请求连接,消耗Web服务器的资源,使其无法处理其他请求。
    RUDY(R-U-Dead-Yet):类似于Slowloris,但使用的是HTTP POST请求。攻击者发送大量的POST请求,保持请求的连接打开,逐渐消耗目标服务器的资源。
    HOIC(High Orbit Ion Cannon):主要通过发送大量的HTTP GET请求,利用目标服务器的资源。虽然HOIC不完全是慢攻击,但可以通过发送大量的请求来达到类似的效果。
    Slow Read:攻击者通过发送一个缓慢的HTTP请求,然后在服务器响应时缓慢读取数据,导致服务器长时间保持连接,消耗资源。
    Slow POST:攻击者通过发送一个缓慢的POST请求,使服务器在响应时保持连接,逐渐耗尽服务器资源。攻击者发送的数据量很大,但请求和响应过程很慢。

相对于DoS而言,DDoS的可选攻击类型就没有任何限制了,除了包括DoS惯用的慢攻击类型,洪泛类攻击更是DDoS的代表攻击手段。如果说DoS的拒绝服务是靠慢攻击(利用TCP协议、http协议的漏洞)把用户应用资源消耗殆尽,还算有点技术含量,DDoS的拒绝服务就是直接使用洪泛攻击把用户网络出口的带宽资源、应用服务器的CPU、内存等系统资源消耗殆尽,可以说简单粗暴,完全没有任何技术含量可言了。

DDoS攻击的杀伤力有多大?

如果DDoS攻击的规模不算太大,且主要采用应用层攻击对应用资源进行消耗,那么,只能算DoS攻击的加强版,威胁性还不算太大,还是可以通过安全设备使用合理的安全策略进行防护的。

最可怕的是大规模的DDoS攻击,可以直接把传统以"点"方式部署的架构(比如自建数据中心)的出口带宽完全淹没。所谓的大规模能有多大呢?以我自己遇到的攻击为例。

总攻击流量2.13T,峰值带宽541.75G:

image.png

总请求总数6.51亿,峰值RPS(每秒请求数)1.71亿:
image.png

攻击来源于多个国家:
image.png

就问这种规模的攻击有多少传统的以"点"方式部署的架构能扛住?

如何防护DDoS攻击?

这个问题不展开来说,否则针对形形色色的攻击方式,要一一来说明都可以出书了(以前卖的防D产品,关于每一种攻击的原理的介绍以及防护配置的手册都有几十兆大小,这个以后有机会用专门的安全类系列文章来讲),简单来说可以分为两类:应用资源消耗型和带宽消耗型。

应用资源消耗型:主要是应用层攻击为主,例如:Slowloris、Slow Read、Slow POST,加上部分针对应用资源的洪泛类攻击:SYN Flood、HTTP Flood。

带宽消耗型:主要是洪泛类攻击为主,例如:UDP Flood、ICMP Flood、DNS放大攻击、NTP放大攻击。


注:SYN Flood和HTTP Flood虽然归到应用资源消耗型,但是在规模大的情况下,一样可以达到带宽消耗的效果,比如前面我遇到的攻击,其实就是HTTP Flood类型的。


应用资源消耗型攻击的防护,主要是依靠应用类防火墙,搁在CF就是WAF的工作。当然,应用服务器方面也可以进行相关的配置优化,比如启用SYN Cookie、限制半开连接数的数量、缩短连接超时的时间,或者使用负载均衡设备将访问请求负载到多个服务器上并限制每个服务器的连接数等操作。

而对于带宽消耗型攻击的防护,仅仅依靠"点"的防护就不行了,一般有如下可选方式:

  • 站点建立冗余备份(比如灾备数据中心、双活或者多活数据中心),这样可以大大提升应用吞吐量,并且如果某个节点带宽被消耗殆尽,可以通过修改域名解析结果的方式将请求快速重定向到其他节点,只不过这种方式只有大型机构才能使用。
  • 将应用"套"上CDN,由于CDN的工作机制,访问用户解析到的不是单一IP而是多个IP(达到了隐藏了源站IP的效果),所以访问请求也被分发到多个IP上,加上CDN上缓存了应用内容可以直接响应,所以如果遇到攻击,最终到达源站的实际访问流量大大减少,也就达不到淹没源站带宽的目的(前提是不能暴漏源站IP)。
  • 外部流量清洗,通过在遭遇攻击时使用多种技术(比如BGP路由、DNS重定向、API调用等方式)将可疑流量到达源站网络出口之前就牵引到专门的设备进行处理,过滤恶意流量并仅将合法流量重新传递回目标服务器,从而保护源站网络和应用免受攻击,一般由宽带提供商(如果应用部署在云环境则是由云供应商)或者专业的安全供应商提供。

除了第一点之外,CDN和外部流量清洗国内都有对应的方案,只不过嘛,CDN流量靠买(外加一些方式还有坑),DDoS又单独花钱(还非常非常贵),导致对个人站长而言,时时刻刻都要担惊受怕,深怕一不小心就要被DDos攻击搞破产(或者被断网),所以这也是我年初义无反顾投奔CF的最重要原因之一:免费的CDN、免费的DDoS基础防护加上免费的基础WAF功能,直接让我不再担心DDoS攻击了(不管是应用资源消耗型还是带宽消耗型)。

另:由于Free计划的WAF功能只提供了基础规则集,其实对很多应用资源消耗型攻击还是防不了的,不过由于我的"家庭数据中心"内部还有WAF,在这种"异构"结构的双重防护下,还是比较放心的,当然,最主要的是访问量小~~。

CF DDoS防护的配置

其实前面虽然讲了那么多基础知识来铺垫,但是实际上,CF 的DDoS相关的配置却很简单,大家依据以下步骤即可完成基础防护,当然,前提是已经将域名托管到CF上并且已经选择了合适的方式完成了建站(建站方式的选择可以参见文章:)。
配置网站安全级别:

image.png


注:安全级别中有一个特殊的选项叫I'm Under Attack!

image.png

当网站受到攻击且严重影响正常访问时,可以将安全级别设置为该模式。这样设置以后,会对所有访问网站的请求(包括正常访问和攻击流量)开启JS质询,只有通过JS质询的请求才会被允许访问网站内容,这样虽然会影响正常用户访问网站的体验,但是却能保证拦截掉绝大部分的异常访问,是在网站受到攻击时的最后手段之一。

该模式也可以在CF的概述页面快速开启:

image.png

如果网站是使用wordpres建站,也可以直接在cloudflare插件里开启而不用登录cloudflare网站:
image.png

部署DDoS替代:

image.png

image.png


注:CF HTTP DDoS 攻击防护规则集是一组预先配置的规则,用于匹配 CF全球网络第 7 层(应用层,以HTTP为主)的已知 DDoS 攻击向量。 这些规则匹配已知的攻击模式和工具、可疑模式、协议违规、导致大量源错误的请求、击中源/缓存的过大流量以及应用层的其他攻击向量。CF会定期更新规则集中的规则列表。

阻止的攻击可以在"安全性"-"事件"中进行查看,日志格式如下:

image.png


自动程序:

image.png

速率限制:
image.png

image.png

完成以上配置之后,对于"一般"规模的DDoS攻击,已经可以忽略不计了,再结合WAF的正确配置(参见文章:家庭数据中心系列 cloudflare教程(四) CF WAF功能及详细配置教程),对于个人站长而言,安全性方面已经不是需要担心的问题了。


注:为什么要说"一般"规模的DDoS攻击可以忽略不计?

因为CF的DDoS防护固然厉害,可以将攻击流量(或者请求数)的99%都挡掉,但是如果规模太大,就算只剩下1%的攻击流量(或者请求数)也足以把一般个人站长的应用撑死。以我文章前面的提到的攻击的最高瞬时带宽541.75G以及1.71亿的RPS(每秒请求数)为例,5.41G的瞬时带宽和171万的RPS,如果进入了内网,也足够把常规应用打死了。所以,如果要防住大规模的DDoS攻击,仅靠CF还是不行的,必须依靠内网进一步的流量控制和整形才行,比如进一步的基于IP的访问速率限制以及负载均衡设备的最大连接数功能等功能相配合来实现。

感兴趣的朋友可以参考我以前关于受到攻击时写的3篇实时纪录以及如何调整家庭数据中心内部架构以应对大规模攻击的文章:家庭数据中心系列 惨遭破处!记博客第一次被DDOS攻击家庭数据中心系列 二次攻击!新形势下内部博客访问流程的优化家庭数据中心系列 压力测试成功完成!感谢兄弟的帮忙,已经可以了!,而家庭数据中心的详细拓扑结构可以参看文章:家庭数据中心系列 家庭数据中心IPv4/IPv6双栈网络架构及应用访问流程优化


总结

CF的DDoS防护相对于其他竞争对手的最大优势包括以下几个方面:

  1. 全球大规模网络基础设施:CF拥有覆盖全球的边缘网络,遍布200多个城市。这使得它能够在多个地理位置上分散流量,快速响应并缓解DDoS攻击,提供更低的延迟和更高的可用性。
    注:这个优势就是最大的优势,没有其他任何一个厂商能把自己的骨干网遍布全球,这导致对于其他厂商来说是100G的攻击流量,而对CF来说,可能只是100个节点每个节点1G的毛毛雨流量,这怎么比?
  2. 智能威胁检测和自动化响应:CF利用先进的机器学习和AI技术,实时分析和检测流量中的异常行为和攻击模式,其自动化系统能够迅速识别和应对DDoS攻击,无需人工干预,从而缩短响应时间,提高防护效率。
    注:CF的实时分析、检测技术的确不俗,5秒盾是多少恶意爬虫的噩梦?
  3. 集成的多层防护:除了DDoS防护,CF还提供WAF、CDN、SSL/TLS加密等多层防护,这种综合防护策略可以全面提升网站和应用的安全性。也正是因为独立提供多层防护,才能在任何一个层面遭遇攻击时能快速响应。
  4. 无需额外硬件或软件:CF的DDoS防护服务基于其云平台,用户无需购买或安装额外的硬件或软件,只需采用适合的回源方式(走公网或者Tunnel,详情参见文章:家庭数据中心系列 cloudflare教程(三) 如何进入CF的边缘网络及如何选择适合的回源方式)将应用接入CF的网络即可享受全面的DDoS防护。这简化了部署和维护流程,降低了使用门槛。
  5. 定价透明和成本效益高:CF提供透明的定价策略,并且在Free计划中就提供基本却实用的防护服务(WAF和DDOS防护),无需额外付费。这使得其服务在性价比上具有显著优势,尤其适合中小企业和个人用户,江湖人称:大善人。
  6. 全流量防护:CF的DDoS防护不仅限于HTTP/HTTPS流量,还包括DNS、TCP、UDP等多种协议的流量。这种全面的防护能力确保了各种类型的攻击都能得到有效应对。
  7. 大规模的实时数据共享和合作:CF与全球多个安全组织和企业合作,分享实时威胁情报和攻击数据。这种合作和数据共享使得CF能够更快地识别和应对新兴威胁,提高整体防护能力。

相对于国内CDN流量要买、DDoS服务单独付费的模式,CF提供的DDoS防护对个人站长而言,真的可以称得上"福音"了。

注:随手发一个google上搜DDoS防护价格搜出来的"高防CDN"的价格:

image.png

按这个收费标准,我遭受的2.13T流量要防住需要给多少钱??瞬间感觉自己赚了好几万有没有!

博客内容均系原创,转载请注明出处!更多博客文章,可以移步至网站地图了解。博客的RSS地址为:https://blog.tangwudi.com/feed,欢迎订阅;如有需要,可以加入Telegram群一起讨论问题。

评论

  1. Windows Edge 127.0.0.0
    6 月前
    2024-7-31 11:18:22

    要是只是自己使用我建议可以上VPN

    • 博主
      GoodBoyboy
      Macintosh Chrome 127.0.0.0
      6 月前
      2024-8-01 15:22:31

      个人博客嘛,肯定是大家一起用啊。

  2. Windows Chrome 126.0.0.0
    6 月前
    2024-7-29 10:53:45

    最近看到一种基于CF前置+负载均衡+家宽的DDos流量清洗方案。当进入防御状态后,利用CF挡住99%的攻击,流量再负载均衡到位于多个省市的家宽节点,家宽一大特性就是高下行低上行,正好适配DDOS流量清洗的状态。用家宽拼出一个负载过百G的清洗流量入口。加上前边的CF,约等于实现了10T以上的防护。不过最终的延迟那是真的高只适合HTTP应用。

    • 博主
      秋风于渭水
      Macintosh Chrome 127.0.0.0
      已编辑
      6 月前
      2024-8-01 15:21:51

      这种方式感觉意义不是很大,一来CF都档了99%,剩下的1%杀伤力其实已经不算很大了(除非真的攻击规模超大,但是再大,能比我遇到过的大?我还是比较怀疑的)。一般的DDoS攻击(以常用的http flood为例),可以同时产生应用资源消耗及带宽消耗的双重结果,带宽消耗经过CDN和速率限制的双重处理之后,已经没啥威胁了,剩下的关键反而已经不在攻击带宽而在于RPS请求数的控制了,这个时候只要源站本地使用流量整形(本地限速以及最大连接数控制)处理下流量就已经没有什么伤害了(如文中所述,我验证过峰值541G每秒的攻击带宽以及1.71亿每秒的请求数都翻不起一点浪花)。

      至于多个省市的家宽节点,这个部署倒是简单,只是这种方式又折腾而且感觉事倍功半,除非平时正常时就是多个节点进行负载均衡(否则难道需要的时候再起),但是对于个人用户的话,在单个节点性能平时完全足够的情况下,使用多节点本来就没太大的意义,而且还要多费电或者多费钱~,除非和攻击检测机制配合:当检测到攻击时使用API或者脚本方式远程启动多个节点分担流量,没攻击时有关闭多余节点,但是这样又需要折腾(其实又能分担多少流量?进入内部的流量一般也就几百兆,对于现在千兆家宽遍地的情况下其实都是小意思了,而且我怀疑多个节点的真正目的不是为了分担带宽,而是为了分担请求数,毕竟请求数产生的连接才是最容易卡死应用的罪魁祸首,但是分担请求数其实也只需要本地跑个负载均衡就行),我现在都只是在家里停电或者断网的时候,云主机上的冗余节点才会自动启用进行接管。

    • keinn
      秋风于渭水
      Windows Edge 129.0.0.0
      4 周前
      2024-12-31 10:07:47

      每个省买个房子才有这效果吧

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇
       

本站已禁用鼠标右键和各种快捷键,代码块内容可以直接在右上角点击复制按钮进行复制

zh_CN