前言
清早一睁眼，看到cloudflare发来的一堆邮件：
从邮件中看到，一共5封攻击通告邮件，按5封邮件的先后顺序，内容分别如下：
1、
2、
3、
4、
5、
第一次被攻击，好奇、惊喜类的心情反而占大部分，不过把我今天workers 10万次get的免费额度用完了又让我有点无语。先不想这些,复盘一下这次攻击的过程。
WAF日志分析
先看看最初收到警告邮件的时间：
凌晨2点16，那么先看看在WAF日志里那个时间段附近有什么异常：
点击86.4k数字进入：
虽然有触发了5种规则，但是我看了一下，这些包从内容上并没有太大差异，就是一个post请求访问我博客的首页，只不过就是从世界各地一起在15分钟内一起访问而已，所以下面就以攻击数量排名第一和第二的两类攻击为例看看大概的内容。
1、排名第一的攻击类型来自第三封邮件
规则ID为："6e3ccc23900c428e8ec0fb8a3a679c52"，规则说明是："Requests coming from known bad sources"。
随便点开一条的详细信息：
从红框中其实看不出太异常的地方，UserAgent还是写得很认真的，和正常浏览器的UA差不多，不像有些爬虫写得很简单甚至干脆是空的。
2、排名第二的攻击类型来自第五封邮件
规则id为："0a07c24f3cd44a57a5c19b73d2f294d7"，规则说明为："HTTP requests trying to impersonate browsers"。
随便点开一条的详细信息：
内容和第一类攻击的差不多，剩下的3类攻击的内容也是一样，估计能够分成5种类型是基于cloudflare自身的特征库以及自己的分析算法，搁在我们人眼里应该都是一样的。
因为免费版的统计太粗糙了，我看不到攻击具体开始的时间点，WAF的攻击日志也没有直接到最后一页的选项，只能我自己点，25项一页，几十几百万项，要翻死我？？所以只能从最早收到邮件通知的时间2点16以及日志里规则ID过滤的最后一个请求的时间来看攻击时长，下面4个是前面4封攻击通知邮件，都是2点16分开始的：
可以看到这4种攻击都是2点16分开始，然后分别在2点28分到2点31分的区间段里结束。
第5封攻击通知邮件2点29收到的，也是2点30分停止，这个持续时间最短：
从上述开始结束时间可以看出，虽然是5种类别，但是都在2点30分左右结束，应该是统一控制的(开始时间不好统一控制，但是结束时间容易控制，所以俗话说：不求同年同日生，但求同年同日死？)。
分析和日志部分
web流量：
威胁：
workers：
全站速率限制
我是设置了全站速率限制的，看看是否生效。
不过这些只对同一个IP发起大量请求，且必须是访问设置中指定的URI才生效，攻击中也有大量一个IP只发1个请求的，对这种就无效。
长亭WAF的数据
看不懂长亭的统计，2个页面的请求数统计差得有点大，不过社区免费版，咱也没啥好说的。。
总体来看，长亭对到来的请求一个都没有拦截，不过也合理，因为我们前面看到，单从一个请求来看，这些请求都看不出啥问题，而且，虽然长亭我也配置了高频访问拦截：
冤枉长亭了，我自己的问题，把部署cloudflare tunnel的设备的IP设置成了白名单。
总结
虽然不知道谁这么无聊对我的小破站还要搞个分布式DDOS攻击，不过不妨碍以此为案例来简单分析一下。
如果依旧采用腾讯云CDN的部署方式，根据我习惯的设置策略：
这次的情况会触发这2个瞬间用量中的一个，而根据我的设置：
5分钟一到会直接关闭CDN服务并返回404，所以消耗的流量和https资源包的请求数目肯定达不到最终cloudflare的35G和1100万的SSL请求数量，但是换来的结果是60分钟解封时间到之前网站无法访问。
所以最终结论是：如果这次不是依靠cloudflare全球布局的IP anycast结构来应对此次分布式DDOS攻击，而是仍旧采用腾讯云CDN方式，就会有一个小时的断网时间。这还是攻击只持续了15分钟，只进行一次，而如果每小时来一次这种攻击，那我的网站就会就用无法访问了(cloudflare威武)。
不过这次也暴露了目前我的家庭数据中心，还缺乏流量追溯方面的解决方案，这个我要好好思考下，不然下次出问题还是没有办法在本地进行追溯，难道科来解决方案来一套？
另1：技术上来看，cloudflare全球布局的IP anycast结构，用来应对此种全球范围发起的分布式DDOS攻击的确是太轻松了，分摊到每个边缘节点的流量就小得可怜。
另2：如果在攻击时候，我手动开启"Under Attack"按钮：
是不是就不会消耗我workers的免费额度了？偏偏凌晨2点多开始攻击，肯定是故意等我睡着才开始的，太阴险了。。。
看来，使用worker每天10万请求的免费额度来优化博客访问的方法还是有点脆弱的，要探求新的访问优化方式了。
家庭数据中心不一般都是部署在内网嘛？这类比较重要的服务我一般要么不映射在公网，要么通过VPN进行访问，感觉直接扔公网很不放心。
一般网上说的”家庭数据中心”，只是美其名曰而已，比如就一台NAS加个公网端口映射或者内网穿透也能称为”家庭数据中心”，这些严格意义上讲，只能勉强算是广义上的”伪·家庭数据中心”。本身从专业角度来说，数据中心按使用场景，就分是对内提供服务(比如只是单位内部员工访问)还是对公众提供服务(比如金融行业、税务行业就是面向公众访问)。而我说的”家庭数据中心”，就是专业上的，本身就是包括安全、缓存在内的一整套完整的解决方案：从域名解析-ddos攻击缓解-web安全过滤-优化访问速度-内网穿透-web应用防火墙二次过滤-负载均衡(应用热备)，还要包含多个wordpress站点数据同步以及家里停电以后的一键启用云服务器镜像站点的同城灾备，这些合在一起才是我说的”真·家庭数据中心”，可不是你说的仅仅是映射在公网或者直接扔公网上的概念，或者说，我的家庭数据中心解决方案的目的，本来就是说的如何把家里的的应用安全的、正大光明的放在公网上(功夫足球里吴孟达说过：我可不仅仅是个瘸子那么简单～)，要知道，家里随便拿个闲置设备的性能都要比云服务器的什么1核2核、1G2G内存这种抠抠搜搜的好多了，而代价就是每月电费多那么一滴滴而已。
性能够用的话，毕竟人类科技上限就在这里，耗电怎么都低不了，15W 功率，一年 60 的电费的设备，性能也就和那些一年 98 的云服务差不多。无非是内存和硬盘能再大点。但考虑到硬件本身成本未来更新换代的成本（对于闲置，本来闲置是可以二手卖掉收回部分成本的）。在一定使用强度范围内，自建可能还真不如用一些云服务解决的成本低。
嗯，技术上是这样，不过购买云服务器，国内要备案，国外访问速度又不见得快，用自家的设备胜在部署简单、灵活、可控性强，只要能解决从国内访问慢的问题，对有一定动手能力的人来说，还是很有折腾的欲望的。