如何使用 Cloudflare 保护云服务——扫盲“WAF”及其它招数

前言

五一前后抽时间维护了一下个人云服务,把集群全部重构了一部分。那几天访问的朋友们应该能看到一个简单的“维护页面”。新的个人云架构,这里就不多讲了,毕竟不是本篇的内容,感兴趣的朋友可以看我之前文章(老架构)。这次改进了之前的诸多不合理的地方,顺便把 IP 和证书全部更换了一遍。

👉Dynamic k8s 集群实现方案

本文的目标读者

本文主要针对两类读者,一是 Cloudflare 的重度用户,在此前提下教你如何“针对性的优化和防护”;二是没用过或刚接触 Cloudflare 的读者,当然,在阅读本文之前,你最起码要使用过云服务器,也能够理解云服务中的相关概念。

如果对 Linux 和云服务不太熟悉,又或者是对 CDN、HTTPS、DNS 之类的网络技能稍有欠缺,建议你买一个便宜的云服务器简单学习一下,每个月 4 美刀的足矣。

概述

咱们既然是对 Cloudflare 和 WAF 扫盲,那么首先来介绍这俩吧。

Cloudflare 是一个全球网络,旨在让您连接到互联网的一切都安全、私密、快速和可靠。

这是官方介绍,说白了,它提供很多服务,但最出名的是 CDN 和 DDNS 服务。

WAF(Web Application Firewall,Web 应用程序防火墙)通过过滤和监控 Web 应用程序与 Internet 之间的 HTTP 流量来帮助保护 Web 应用程序。它通常保护 Web 应用程序免受跨站点伪造、跨站点脚本 (XSS)、文件包含和 SQL 注入等攻击。

注:本文的 WAF 主要指 Cloudflare WAF。

云服务攻击面

说到攻击面,这里我们就拿个人使用云服务来说(大规模云应用场景,我也接触的少,抱歉)。

  • 网络安全:攻击者拿到你的服务器 IP、不安全的传输协议(如 HTTP)等,再进行攻击操作。
  • 访问的合法性:如果每一个用户都能对你的服务畅通无阻的访问,那么必然会增大安全隐患。下面会讲到如何处理,毕竟我们需要保证正常用户的访问。
  • 网络攻击:DDoS 攻击,通常会导致云服务宕机。毕竟在个人笔记本上一通简单的操作,就能”瞬间“把学生机打进黑洞。下面我会聊聊,如何最大程度的“缓解” DDoS。

有心之人防不住,但个人云服务也可以设置一些规则来缓解。真正的大佬,没有必要浪费时间和成本来攻击咱,实际上大多数情况下防的是“无差别攻击”脚本。

当然,什么常说的软件安全、数据安全、供应链安全,不在本文的讨论范围之内,有兴趣的话,也可以找我聊聊!

加密通信

HTTPS 大家想必已经不陌生了,但是证书链“信任”问题,以及客户端到服务器的每一环,是否都进行了可信证书的加密,毕竟源站一旦暴露,各种烦人的脚本就来找你了。而且也要防止数据泄露,以及数据篡改。

这里贴一张官方的图,我们可以看到,图上有 2 把锁。其中浏览器和 Cloudflare 中间的锁,是边缘证书(Edge certificate),它是由Cloudflare 向访问您的网站或应用程序的客户出示的证书。而 Cloudflare 和源服务器中间的锁,是源服务器证书(Origin certificate),它会加密源服务器和 Cloudflare 之间的流量。

巧用阿里云 OSS 玩转免费分布式存储,原理就是这样,保证所有流量经过 CloudFlare 来实现“免流”。

同源策略

这里的同源策略,可能和开发中大家所理解的同源,稍微有点小区别,但原理差不多。

说白了就是结合 CDN 为静态资源设置同源策略,在提高缓存命中率的同时,降低“源站”被发现的风险。

为什么要重视云安全?

云安全(当然也可以扩展到数据安全等),我想我不用过多解释了,对于企业来说,关乎到“生死存亡”,可以说是不过分的。

那对于个人来说的话,我总结了如下几点:

  • 出于保护个人隐私的考虑。
  • 节约时间的考虑,配置好之后,把服务挂上去,可以显著减少维护时间,不至于天天浪费时间应付各种麻烦。
  • 从学习提升的角度考虑。在这个过程中,既能掌握理论知识,也能进行实战,何乐而不为呢😊

常见的攻击手段

简单解释下吧,我不可能教别人干这个,何况我的水平有限,也教不了。

基于 SOP 的攻击与跨域资源检测

SOP,也就是同源策略,是 Web 领域最重要的安全机制之一。一般来说,针对 SOP 的攻击,都是基于浏览器的,也就是“绕过 SOP 技术”。

我们知道,相同主机名、协议和端口,可以视为同一个来源。那么在“云服务”中基于 SOP 的攻击方式有哪些呢?

  • 直接针对资源进行攻击(通常静态资源都放在 CDN 了,这也是大家为什么经常看到“天价账单”)。
  • 对跨域资源进行检测,找出源站,进行攻击。

攻击的前提是,错误的配置了规则。比如资源允许跨域,导致其它来源可以疯狂请求资源。或者是缓存策略配置问题,导致缓存命中率不高。或者是只是对资源进行了缓存,但并没有把源站隐藏好。正确配置的话,可以极大的缓解攻击。

把 HTTPS 降级为 HTTP

这个也称为绕过 HTTPS,这里有个前提,即证书可不可信。

理论上来说,HTTPS 加密的内容,是不会在“传输过程”中泄露的,如果密钥泄露了那就好好反思下自己。

这里说一下很多人可能会忽略的一点,就是在服务端没有设置强制访问 HTTPS,甚至保留了 HTTP 访问,这是有很大的风险的。如果用户能直接通过 HTTP 访问到服务了,那么能拿到什么“有用”的信息,不用我多说了吧?

很多年前,我也犯这个错而不知情,也是后来才改掉的。我上了 HTTPS 通信后,就没有理由继续使用 HTTP 了。使用 HTTP,无疑是告诉别人,嘿,我的源站就在这儿,且无任何缓解防护,快来攻击我(doge

分布式拒绝服务攻击(DDoS)

分布式拒绝服务(DDoS)攻击是通过大规模互联网流量淹没目标服务器或其周边基础设施,以破坏目标服务器、服务或网络正常流量的恶意行为。

说白了,就是有很多“用户”,疯狂的把流量送到你这儿来,然后你扛不住了,就宕机了(同时也影响了服务的正常访问)。

当然,我们不可能把大量访问全当成攻击。所以需要对服务进行流量监控和分析。比如可以看看是不是只有某个 API 或者页面的流量激增、访问者的 IP 地址或者 IP 范围是不是很可疑之类的。或者说用户的设备类型、地理位置、浏览器标头等等,是不是大量重复了。

“发现”服务器 IP 地址以及域名枚举

这个很多人可能不太明白啥意思,我们首先来看一张图。

这里使用了 censys.io 的服务,只要输入一个域名,它就能查询所有该域名(包括子域名)下的源站信息。它会进行批量扫描,且进行证书关联(证书里面有域名),也同时会扫描你所有的端口。当然,也有其它方式,如果你实在是想防住它,可以直接在防火墙关闭它的扫描子网 IP 对你服务器的访问。

虽说关了用这个网站就查不出来的,但这种方式仍然没有杜绝,其它平台/个人依然可以这个扫出来。

图中扫描出了一台我的服务器信息(我只留了这一个用作演示,因为这台服务器宕机没啥影响)。有朋友可能就要问了,这里我已经基于 Cloudflare 配置好了,为什么还是泄露了源站呢?

按平台的分析也是属于证书泄露,基于我对其它的服务器的设置进行对比,我确定是“监控塔”把我的证书泄露了,但到底是我配置错了,还是其它什么原因,我就不管了(退一万步来说,是我配错了,我不用你了还不行吗?)。然后和 Aria2 的 HTTP 端口匹配到了相同的 Body Hash,并且指向了一个 Ngixn 的漏洞,真是防不胜防啊!

挑战黑洞攻击(CC)

挑战黑洞攻击(CC)是一种网络攻击,类似于DDoS攻击,但它针对的是目标网站的特定URL或页面。攻击者利用大量的计算机或设备向目标URL或页面发送请求,使其过载并无法正常工作,从而导致服务中断或不可用。

这个攻击有什么用呢?就比如用 Cloudflare 代理 OSS 的流量,虽然不需要出流量费用了,但是请求次数是需要计费的,也就是防 D 不防 C。

IP 欺骗以及其它

IP 欺骗是指创建源地址经过修改的 Internet 协议 (IP) 数据包,目的要么是隐藏发送方的身份,要么是冒充其他计算机系统,或者两者兼具。恶意用户往往采用这项技术对目标设备或周边基础设施发动 DDoS 攻击。

应对措施

终于到实战环节了,下面咱们就来看看,怎么使用 Cloudflare 的各种配置,来缓解各种攻击以及保护云服务吧。

DDoS 缓解

首先让我们来了解一下,在应对 DDoS 攻击时,要先做什么?答案是:检测。没错,我们必须要先判断,到底是“攻击”,还是说确实是网站“太受欢迎”了🤣,我们要能够区分攻击流量与大规模正常流量。

在提供了 DDoS 缓解的服务商平台,一般有 2 种方式来进行。其一是平台自己的自动缓解措施,也就是全托管形式,又平台自动判断是否遭受了攻击,并进行防护。其二是自定义 DDoS 托管规则,比如 CloudFlare 就是可以自定义规则用于匹配第 7 层(应用层)的攻击媒介。

按图中所示,首先我们找到 部署 DDoS 替代

然后进行填写和选择,并保存。“规则集操作”和“规则集敏感度”就按照自己的需求来了。

需要注意的是,支持自定义的是 HTTP DDoS 攻击防护,而网络层和 SSL/TLS DDoS 攻击防护则是自动缓解的。

你说你不知道自己的需求?那你就跟我一样,使用平台自定义的就行了。

Web 应用程序防火墙(WAF)及 API 保护

WAF 用来缓解恶意请求的流量,根据图中的位置,安全性 -> WAF -> 创建规则

然后开始配置,比如我这里需要对完整的 URI 进行判断,把 api.besscroft.com 下的所有请求全部采取跳过匹配,并记录下来。因为我的 API 是配置了反向代理的,如果直接启用“质询”的话,会出现 403 错误,也就是说没法在页面上加载这个“质询会话”,就是下图所示的内容:

而我们刚才勾选的记录,则会在事件栏中被记录下来。

我是直接全站启用了,因为这样省事儿,你可以理解为这样干的话,自定义配置就变成白名单模式了。而如果你不知道你需要哪些规则的话,你也可以先全站启用,然后自己访问网站看看,再根据事件中的请求详细信息,针对性的调试配置即可!全站启用在 概述 -> Under Attack 模式,直接打开即可!

WAF 的速率限制规则咱们下面会说,至于托管规则,免费用户就不需要管了,如果你想获得更全面的保护、全套的 Cloudflare 托管规则以及防火墙分析,你应该付费啦!

WAF 工具配置,可以自定义规则,声明哪些条件下的用户可以访问。比如 IP 访问规则,ChatGPT 应该就用了这个配置,拦截了某些地方的 IP 访问,很多用过的小伙伴,应该能看到“5 秒盾”(破盾方法当然是有滴)。而在某些地方,访问 ChatGPT 甚至可以说是双向墙了,我不说是哪里🤡。

不过工具配置我都没有添加,因为我暂时还没有类似的需求,也不需要阻止爬虫之类的。

加密证书管理(交给 Cloudflare,降低风险(争议性))

这个标题,为什么我加上了争议性呢?因为你如果认为 Cloudflare 是不可信的,那么确实风险是挺大的,尤其对于企业来说。但是对于咱们个人用户来说,还是能用用的,Cloudflare 没有必要狠狠的砸自己的招牌(大概?

首先我们找到 SSL/TLS -> 概述,然后把加密模式在 完全完全(严格)直接二选一。如果你信不过平台的证书,你用自己的证书也是可以的,看自己需求了。然后 SSL/TLS 建议程序的话,我推荐你打开,有时候确实会收到提示邮件(万一自己有漏配置呢,对吧?

然后图中的 配置规则,和刚才的一个意思,我同样配置了 api 子域名跳过。

DNSSEC

DNSSEC 可抵御伪造的 DNS 应答,也就是保护你的 DNS 解析不被恶意篡改的。

当我们把域名的解析交给 Cloudflare 管理后,在 DNS -> 设置 里面,启用设置,并按照要求,在域名服务商哪里,配置好 DS 记录 即可!

服务器防火墙管理(仅允许来自 Cloudflare 的流量)

这里看标题就知道要干啥了,我建议最好配置上。首先我们访问 Cloudflare IP Ranges,然后将所有 IP 段下的地址,添加进防火墙。

这项措施主要用于进行 API 防护,我上面说,我的 API 要进行反向代理,那么我必须加上这个配置。当然,这里我是直接偷懒了,我用了 CloudPanel 作为服务器管理面板,它有个功能,叫做 仅允许来自 Cloudflare 的流量,直接启用即可!

使用 Rate Limiting 来防止暴力破解和第 7 层 DDoS 攻击

我们有时候,可能需要防止暴力破解,或者说就想防止攻击。但是有的请求,看上去就是伪装的非常正常,根本分辨不出来。这个时候我们就可以限制请求速率了,你一个正常访问的普通用户,总不至于点的飞快吧...

如图,我们可以限制匹配到任意 URI 的请求,同 IP 在多少秒内只能请求多少次。我这里配置了 10 秒钟 50 次,更严格实际上也没问题。

前面说到的 Under Attack 模式,也可以在 安全性 -> 设置 里面启用。而质询通过期,则是在设置的直接过后,要再来一次,否则就无法继续访问请求。去年下半年(2022 年)我使用 ChatGPT 时,就能察觉到开启了这个功能,因为打开了 Chat 页面一段时间后,在当前页面提问后,ChatGPT 就无法给出答案,而是说网络错误相关的提示。当时也很好解决,打开一个新的浏览器标签,过掉验证,然后再关上,就能在当前页面继续使用 Chat。而现在,ChatGPT 明显新增了不少规则,有付费的,也有其它的,有部分我能试出来,但有些还是第一次见。

Q&A

HTTP 和 HTTPS 有什么区别?

HTTP 传输的数据是明文的,不安全;而 HTTPS 使用加密技术保护数据传输,更安全。HTTP 适用于传输非敏感信息,HTTPS 适用于传输敏感信息。

浏览器在使用 HTTPS 通信时,代理(如 Cloudflare)可以看到通信内容吗?

一般来说的话,是没法看到的。这种端到端加密,只有客户端和服务端可以看到数据的内容。但是呢,请求元数据是可以看得到的,也就是咱们经常说的,看不到你访问网站的内容,但是知道你访问了什么网站。

但是呢,Cloudflare 充当了中间人(Man-in-the-middle, MITM),而且一般会使用它颁发的证书,所以...懂我意思吧?

反向代理和源站是什么?

源站,可以理解为“来源”站点,也就是咱们藏在 CDN 后面的原始服务器。用户请求时,CDN 会先看看自己有没有缓存资源,有的话直接响应给用户,如果没有的话,会向源站请求,并按照缓存规则,看是否要缓存下来,以及怎样缓存,并把资源响应给用户。

反向代理是位于一个或多个Web 服务器前面的服务器,拦截来自客户端的请求。它会接受用户的请求,转发给源站,并“代表”源站,向用户发送响应。

为什么使用了 WAF 后,日志中没有真实的访问者 IP 了?

因为流量被 Cloudflare 接管了,你看到的都是 Cloudflare IP。我们可以在 HTTP 请求标头 中查看到客户端 IP 地址,或者直接在源站日志中恢复原始访问者 IP

最后

本文其实只讲到了一小部分,也是我在使用过程中积累的一点点经验,希望能帮到各位读者朋友。Cloudflare 平台上还有各种各样的设置和功能,它能做的事儿远不止这些,它特别的强大。我每年的云服务费用就只有域名的费用,原本每年几十块,今年又买了个新的,现在手里一个 com 和一个 dev 后缀域名,每年就只消费一百多而已。可以说我的整个接入层,和部分基础设施,全部基于 Cloudflare 在管理,真的非常好用且方便。

文章写到这里,也欢迎各位朋友与我交流!

对爱情的渴望,对知识的追求,对人类苦难不可遏制的同情心,这三种纯洁而无比强烈的激情支配着我的一生。

Three passions,simple but overwhelmingly strong,have governed my life:the longing for love,the search for knowledge,and unbearable pity for the suffering of mankind.

—— 《我为什么而活着》罗素 (哲学家 数学家 思想家)

updatedupdated2024-03-192024-03-19