攻击复盘

5点起夜的时候，无意中瞟了一眼邮件：

卧槽，又来搞我？而且上次是02:16，这次是02:21，合着凌晨2点20左右是上班时间？赶紧看下流量简报：

看看持续时间：

到2:21:37秒完全结束，包内容和上次差不多，我就不发了，简单来说就是基于http/2版本的请求对我博客主页进行疯狂的get操作。这次攻击持续时间5分钟(上次16分钟)，请求总数649万(上次1000万)，请求带宽23.7G(上次35G)，可以看到，这次的攻击用了1/3的时间达到了上次2/3的效果，说明啥？说明我这次的响应能力是上次的2倍，为什么会这样？这是因为我改变了优化方式所致。还记得上一次攻击时的邮件中关于worker额度的提示内容吗：

这次没这个提醒了，因为我上次就觉得自建workers-KV的方式来优化访问这种方式太脆弱，虽然正常情况下1天10万请求的额度根本用不完，但是一旦有无聊傻逼人士来搞这种没有技术含量的DDOS攻击就会很惨，所以我就决定尝试一下自建workers-KV这种方式的官方正式版：基于wordpress的APO，其实它的实现原理和自建workers-KV是差不多的，都是将wordpress的内容以静态html的形式缓存在边缘网络的缓存中，都是依靠的workers-KV，只不过这种方式貌似没有worker每次使用次数的限制，并且和缓存功能结合得非常好.

但是嘛，虽然响应能力提高了一倍，但是这次我发现了一个上次没有发现的问题，那就是北斗神拳里的名言：虽然看起来活着，但是其实我已经死了！为啥这么说，因为我发现了一个问题，虽然网站能打开，但是内容是这个：

而我正常的是这样的：

怎么内容都变了？？然后我才反应过来，应该是我的主wordpress站点已经死了，负载均衡直接把流量转到备用wordpress站点上去了，而备用站点我来没来得及做数据同步。。然后看了一下uptime的监控，果然：

这是因为我才修改了uptime的监测页面地址指向https://blog.tangwudi.com/me这个链接，而这个链接是我在wordpress的主站上几天前才新建的，备用站点上没有这个链接，所以负载均衡将流量切换到备用站点之后，虽然站点是正常运行的，但是监控却显示为down(至于中途为什么会有少量的绿色，我估计是因为主站点大部分死了，但是还有点魂在，偶尔回下魂能响应几个请求，所以负载均衡偶尔又会转几个请求过去，而这时候监测页面又是存在的，所以显示绿色，不过马上又死了，负载均衡又转回到备用站点，然后监测页面又没了~)，从当时长亭雷池的统计也可以看出：

61.1%的404，就是当时主站点死了，流量还没切换到备用站点之前造成的(nginxWebUI切换流量到备用站点之前有个等待超时的时间)，这个从从我的一封邮件也能间接证实：

为什么这封邮件能证明上述的推测呢？因为wordpress使用php，而php因为工作机制的问题，只有被访问请求触发的时候计划任务之类的操作才能被执行，这其中也包括wordpress的自动更新。平时主站点正常的时候，备用站点是收不到访问请求的，所以即便设置了wordpress的自动更新也没用，而2:21分主站点被打死了(攻击流量也在那个时候结束，难道是探测到我的站点没有响应了才结束的？颇节约资源啊)，经过了超时时间，博客流量被切换到备用站点，有了请求之后触发了备用站点wordpress的自动更新机制，然后2:23分升级完成。PS：我的主站点，早在前天就自动完成了版本升级：

而直接证据就是使用内网地址访问主站点，基本打不开，重启主站点的docker后就恢复正常了～。

现在想来，上次攻击之前我刚好给备用站点做了数据同步，所以主备站点内容看起来完全一样，我就没发现这个问题，而后面我因为心里洁癖又重启了主站的docker，导致死去的主站重新复活，又接管了流量，就更发现不了了。

好吧，大概分析清楚了，根据手头的信息总结一下目前博客服务架构的优缺点。
1、优点

• APO的确牛逼，目前正常访问的响应速度以及应对攻击的能力都大幅提升
• cloudflare基于anycast+无限量缓存的架构在遭遇DDOS攻击时再次发挥奇效，最终进入家庭数据中心内部的，攻击请求只进来了千分之1.6，攻击带宽只进来了百分之1.6
• 基于nginx的负载均衡正常工作，能实现最基本的故障转移
• 相同数据中心内wordpress的主备冗余架构还是发挥了作用
  2、缺点
  • 目前的性能瓶颈在wordpress，通过cloudflare tunnel进入家庭数据中心内部的攻击流量对nginx(长亭雷池waf和nginxWebUI负载均衡都没啥压力)，反而是wordpress主站点本身被打死了
  • nginxWebUI提供的负载均衡在性能方面没啥问题(现在用的是基于stream的4层tcpproxy模式)，但是功能实在是太简单了，默认的健康检查(其实都不算健康检查)应该是采用的TCP端口是否可以建立连接这个标准，略显简陋，而且没有统计图表很不方便(当然，这也是因为我用的全是默认值有关，不过，这种简版的负载均衡功能实在是没有什么研究和折腾的动力)。
  • 家庭数据中心内主备wordpress站点的数据同步频率是个问题，不过目前看来，1周一次差不多，少1、2篇文章可以接受

流程优化

流程优化的目的是解决前面提到的缺点中的第1点和第2点。

第一点：

wordpress所谓的性能瓶颈只是被异常流量攻击的时候才会出现，正常情况下，经过APO的缓存，需要回源的请求本来就少了很多，加上我这小破站又没啥流量，四舍五入后等于平时根本就没啥访问量好不好，所以只需要解决有攻击时的"异常流量"问题。那么，这个异常主要是异常在哪里呢？由于在cloudflare我配置了全站单IP的速率限制：

在长亭waf上也配置了单IP高频访问限制：

所以，异常的主要原因不是单IP的多次访问，而是并发连接数的问题。只要限制了并发连接数，同一时间到达wordpress的请求数上限就是固定了，那么不管异常请求数有多少，对wordpress来说都没有了区别。长亭雷池社区版没这个功能，我又不想去改长亭的底层nginx，而nginxWebUI虽然可以改，但是我想直接换成专用的开源负载均衡，所以想来想去，还是在长亭雷池waf之前再部署一个nginx(我的宝塔面板又重出江湖了)，专为wordpress限制并发连接数：

然后通过宝塔面板的反向代理指向长亭雷池waf。

第二点：

鉴于nginxWebUI功能实在是简单，正式启用zevenet进行替代并完成割接，步骤如下：

同理添加备用站点，唯一不用的是需要设置Priority，最后结果如下：

接下来只需要在长亭雷池waf上把原本指向nginxWebUI负载均衡的IP和端口改为指向zevenet上的VIP及端口即可：

然后终于可以摆脱nginx负载均衡那种默认啥都看不到的尴尬了：

总结

经过上述流程优化，现在通过cloudflare tunnel进入家庭数据中心内部访问博客的请求路线，变成了：
cloudflare tunnel—>宝塔nginx—>长亭雷池waf—>zevenet负载均衡—>wordpress主站点。

通过宝塔面板的nginx控制了进入博客的总体并发连接，解决了第一个问题；又使用专业负载均衡zevenet(zevenet是开源负载均衡里比较出名的了)的社区版代替了以前的nginx，带来了更强大的扩展性，通过gui界面的运维也方便了很多，虽然相对商业版功能少点，但是面对一般人的环境也错错有余了，这样也解决了第二个问题。

博客内部访问流程优化结束，接下来我就期待下次攻击的到来，看能否再把我主站点打死了(其实不用打死，只要打得我切换到备用站点就算我输了～)。