Contents
前言
在上一篇教程中(参见文章:家庭数据中心系列 CF教程(一) CF相关介绍及其对个人站长的助益),我介绍了cloudflare(下文中统一简称为CF)公司及其解决方案(Free计划)提供的主要功能。不过,只凭上篇文章中的介绍大家可能会有似懂非懂的感觉:比如这么多功能,分别在CF控制台哪些部分进行配置?以及这些功能的生效是否有先后顺序?
所以这一篇中,我准备介绍一下CF整体方案中的各个具体的技术节点在CF整个流量序列中的优先级以及其提供的主要的功能和在CF控制台对应的配置位置。
CF的流量序列
何为流量序列?
CF的整体方案是由一系列技术节点构成,访问请求在发往源服务器之前,CF的这些技术节点会按照事先规定的的命中判定优先级顺序对访问请求进行处理,这个命中判定优先级顺序就是流量序列,如下图:
本篇文章就依照流量序列的顺序,简单介绍一些各个技术节点实现的功能。
注1:需要注意的是,这个优先级是命中判定优先级,一旦命中流量序列中的某个节点功能并进行正常处理之后(所谓正常处理不包括终止类行为,例如:阻止、丢弃、重定向等),会继续按照流量序列的顺序交给下一个功能模块进行判定。
注2:经过所有上述流量序列中的节点技术模块处理后,如果请求仍然是合法且需要访问源服务器,CF才会将请求传递给源服务器(回源)。
注3:源服务器响应后,响应数据会经过相关的节点处理模块(如缓存、内容优化)返回给客户端。
前置条件:域名托管在CF
在正式开始之前,请先达成前置条件:将你的域名托管到CF上。如果你的域名是托管在其他域名供应商,需要先将域名迁移到CF上,一般需要5天左右的时间。
注:具体迁移域名到CF的步骤,可以参考我另一篇文章:家庭数据中心系列 通过国内备案云主机白嫖CF实现国外快速访问国内站点。
1、DDOS防护
CF的DDoS 防护功能是一项关键的安全服务,旨在保护网站和网络免受分布式拒绝服务 (DDoS) 攻击。DDoS 攻击通过大量虚假流量淹没目标服务器,导致服务中断。CF 提供全面的 DDoS 防护,确保网站的可用性和性能。
CF DDoS 防护功能的简要介绍如下:
- 自动检测和缓解:
• 描述:CF 使用先进的算法和机器学习模型实时监控流量,自动检测异常流量模式。
• 用途:一旦检测到 DDoS 攻击,CF 会立即采取缓解措施,将恶意流量过滤掉,确保正常流量不受影响。 - 全球 Anycast 网络:
• 描述:CF 依托其庞大的 Anycast 网络,在全球 200 多个数据中心分布流量。
• 用途:通过分布式网络吸收和分散攻击流量,防止单点故障和网络拥塞。 - 多层次防护:
• 描述:提供应用层 (L7)、传输层 (L4) 和网络层 (L3) 的全面防护。
• 用途:保护网站、应用程序和整个网络基础设施免受各种规模和复杂度的 DDoS 攻击。 - 自定义规则:
• 描述:管理员可以根据特定需求配置自定义防护规则。
• 用途:针对特定的流量模式或攻击类型设置精细化的防护策略,进一步增强安全性。 - 实时监控和报告:
• 描述:CF 提供详细的流量监控和攻击报告,帮助管理员了解攻击详情和缓解效果。
• 用途:通过可视化的监控工具和报告,及时调整和优化安全策略。
个人觉得这是CF提供的最有价值的免费功能,只需简单配置即可实现对常规DDOS攻击的不限量防护,拦截率个人感觉可达99%。不过,即便只剩1%,如果没有其他防护,也非常容易把源站打死,毕竟大多数人使用的云主机性能都不咋地~(土豪买贵的性能好的云主机除外),所以这也是我推荐家庭数据中心的原因之一。
具体的CF DDos攻击介绍及CF DDoS攻击防护的配置教程参见:家庭数据中心系列 cloudflare教程(五) DDoS攻击介绍及CF DDoS防护配置教程。
URL重写
注:URL 重写是指将用户请求的原始URL转换为另一个URL的过程,它通常用于服务器端,由Web服务器或应用程序框架处理(准确的说,是由服务器上的软件模块来完成,例如Apache的mod_rewrite模块、Nginx的rewrite指令、应用程序框架内置的URL重写功能)。
在这里,URL重写则是由CF来完成,之后到达源服务器上时就是已经重写完成的URL了。
URL重写的主要目的包括:
- 提高用户体验:通过使用简洁、易读的URL,可以让用户更容易记住和理解网站的结构。例如,将example.com/product.php?id=123重写为example.com/product/123。
- SEO优化:搜索引擎更喜欢清晰、简洁且包含关键词的URL。通过URL重写,可以使URL更具描述性,从而提高搜索引擎排名。
- 安全性:通过隐藏内部架构和参数,可以提高网站的安全性。例如,将实际请求路径和参数隐藏,避免泄露敏感信息。
- URL规范化:解决由于不同URL指向相同内容而导致的重复内容问题。例如,将
example.com
和www.example.com
统一重写为一种形式。 - 简化路由:在Web应用程序中,通过URL重写可以更容易地处理复杂的路由和参数传递。例如,在MVC框架中,可以将请求重写为特定控制器和操作。
- 如果浏览器不支持Cookie或者用户阻止了所有
cookie
,可以将sessionId
添加到url
上发送到服务器(或者负载均衡设备),是支持session
的非常可靠的方法。
页面规则
CF的页面规则是用于管理和优化特定URL或路径的功能。通过页面规则,用户可以为其网站上的特定页面或路径设置不同的行为和优化策略,从而提高性能、安全性和用户体验(注:Free计划只支持3个页面规则)。
以下是一些常见的页面规则的用法:
- 重定向URL:可以将特定的URL重定向到另一个URL。例如,将旧的页面重定向到新的页面,或者将不带“www”的URL重定向到带“www”的URL。
- 缓存设置:可以为特定页面或路径设置缓存策略,以提高加载速度。例如,可以设置静态资源(如图片、CSS、JavaScript)的缓存时间。
- SSL/TLS设置:可以为特定页面或路径强制启用或禁用SSL/TLS。例如,可以强制将HTTP请求重定向到HTTPS,确保页面通过安全连接传输。
- 防火墙规则:可以为特定页面或路径设置访问控制。例如,可以限制特定国家或IP地址的访问,或启用特定的安全保护(如DDoS防护)。
- 页面优化:可以为特定页面或路径启用或禁用特定的优化功能。例如,可以启用自动压缩、优化图片加载,或禁用某些性能优化以确保页面正确渲染。
- 自定义HTTP标头:可以为特定页面或路径设置自定义的HTTP标头。例如,可以设置内容安全策略(Content Security Policy)标头,增强页面的安全性。
- 带宽节省:可以为特定页面或路径设置带宽限制。例如,可以限制大文件的下载速度,避免占用过多带宽。
注1:前段时间CF已经宣布废除了页面规则,原因是因为页面规则里的很多功能选项在后续其他技术节点里都能完成,比如重定向、缓存等,但是现在又恢复了~~,个人感觉是因为页面规则有其自己的特点,被不少用户反对废除,这个我们单独讲页面规则的时候再说。
注2:页面规则的优先级很高,但是条数也少(Free计划只有3条),所以如果能使用后续优先级更低的专项功能实现的,比如重定向功能和Cache Rules,就尽量不要使用页面规则来完成。
Origin Rules
CF 的 Origin Rules(源站规则)是用于在访问请求到达源服务器之前对其进行调整和优化的功能。根据请求的特定属性(例如URL路径、HTTP标头等)执行特定操作从而增强网站的性能、安全性和灵活性。
不过,在Free计划中,Origin Rules仅能实现的唯一功能是修改回源服务器时的访问端口:
且也只在源服务器使用公网IP建站的时候才能用得到。我之前使用家庭宽带的公网IP建站的时候,因为没有80和443端口,所以使用了这个功能来将回源端口改为非标准端口,不过后来使用tunnel功能之后,这个功能我就用不上了(tunnel功能可以随意指定源服务器上的服务端口以及host等内容)。
Cache Rules
CF的Cache Rules(缓存规则)允许用户自定义如何缓存网站内容,以提高性能并减少源服务器负载。通过设置缓存规则,用户可以更精确地控制哪些内容被缓存、缓存的时长以及何时刷新缓存。
通过合理配置缓存规则,可以达到如下效果:
• 提高性能:通过缓存规则,可以显著减少源服务器的负载,提高内容的加载速度。
• 灵活控制:可以根据实际需求精确控制哪些内容被缓存、缓存多久以及何时刷新缓存。
• 降低成本:减少了源服务器的带宽消耗和处理请求的数量,从而降低运营成本。
Cache Rules的常见用途如下:
- 设置缓存级别:定义缓存策略,如“标准缓存”、“无缓存”、“仅缓存静态内容”等。
- 自定义缓存TTL(Time to Live):为特定内容设置缓存的有效期。例如,可以为静态资源(如图像、CSS、JavaScript)设置较长的缓存时间,而为动态内容(如HTML页面)设置较短的缓存时间。
- 绕过缓存:对特定的URL或路径设置不进行缓存,以确保内容实时更新。例如,登录页面或购物车页面通常不适合缓存。
- 缓存关键字:使用查询参数、cookie或其他标头来确定缓存策略。例如,可以根据用户的语言偏好缓存不同版本的页面。
- 缓存规则触发条件:根据URL路径、文件扩展名、查询参数等设置条件,触发特定的缓存规则。
具体的Cache Rules的功能介绍及配置教程参见:家庭数据中心系列 cloudflare教程(六) CF Cache Rules(缓存规则)功能介绍及详细配置教程
注:前面的页面规则也可以针对某一URL配置缓存规则,实际上的确有一定重复性,因为页面规则只有3条,所以我后面有设置缓存规则的需求,都转到了Cache Rules里来实现。
Configuration Rules
CF的Configuration Rules(配置规则)允许用户根据访问请求的特定条件来动态地应用不同的配置设置。通过配置规则,用户可以在不影响整个网站的情况下,为特定的路径、URL、HTTP方法等应用定制化的设置,从而提高性能、安全性和灵活性。
Configuration Rules的常见用途如下:
- 安全设置:根据请求的特定条件(如来源IP、国家、HTTP方法等)应用不同的安全策略。例如,为特定路径启用或禁用WAF(Web应用防火墙)、DDoS防护等。
- 性能优化:为特定的页面或资源应用不同的性能优化设置。例如,启用或禁用自动压缩、图片优化等。
- 流量管理:根据请求的特定条件,调整流量管理策略。例如,为特定区域的用户启用负载均衡、智能路由等。
- 用户体验优化:根据用户设备类型、浏览器等条件,应用不同的用户体验优化设置。例如,为移动设备用户提供简化版本的页面。
和Origin Rules吝啬的只能作用于回源请求的访问端口比起来,configuration Rules对访问请求能实现的功能就要多太多了,比如:
举个例子,我配置访问主机名包含"tangwudi.com"并且不等于"blog.tangwudi.com"的时候,将SSL的加密模式单独设置为"严格"方式(默认值是完全),只需如下设置即可:
重定向规则
CF的重定向规则允许用户根据自定义条件将请求重定向到不同的URL。通过重定向规则,用户可以灵活地管理网站流量,优化用户体验,并确保SEO的有效性。
重定向规则一些常见的用途如下:
- HTTP到HTTPS重定向:确保所有流量通过安全的HTTPS连接进行传输。
- 域名重定向:将不带www的域名重定向到带www的域名,或者相反,以确保URL的一致性。
- 页面迁移:在网站改版或内容迁移时,将旧URL重定向到新URL,以保持SEO排名和用户访问的连续性。
- 路径重定向:将特定路径或目录重定向到新的路径或目录。
- 自定义重定向:基于查询参数、用户代理等条件,进行更复杂的重定向操作。
注:前面的页面规则也可以针对某一URL配置重定向,所以能够单独用重定向规则实现的,就尽量不要用页面规则。
URL 重写(URL Rewriting)和 URL 重定向(URL Redirecting)虽然在概念上有些相似,但它们在功能和实现方式上有明显的区别:
• URL 重写:
1、用户在浏览器中看到的URL不会改变。
2、通常用于创建用户友好和SEO优化的URL,隐藏内部结构。
3、在服务器端处理,用户对重写过程不可见。
• URL 重定向:
1、用户在浏览器中看到的URL会改变。
2、通常用于页面迁移、强制HTTPS、域名一致性等。
3、通过HTTP状态码通知浏览器进行跳转,用户对重定向过程可见。
IP访问规则
这里可以直接从IP地址层面上(可以是单独的IP地址、IP地址范围、国家/地区、ASN号)对访问请求设置对应的操作(阻止、允许、质询等),还可以根据UserAgent(用户代理)阻止特定类型请求的访问。
注:其实这里的功能在WAF里也能实现,但是WAF规则毕竟是有限的(Free计划只有5条),所以如果需要的效果可以在这里实现,就可以不用消耗WAF规则实现同样的效果了。
自动程序
CF的自动程序功能是一种智能安全措施,旨在检测并管理自动化流量,例如爬虫、机器人和其他自动程序。通过这些功能,CF可以帮助网站管理员区分人类用户和自动化流量,从而保护网站免受恶意活动的影响,同时确保合法的自动化程序可以正常访问。
CF自动程序功能的几个关键方面如下:
- 自动检测:CF使用先进的机器学习和行为分析技术,自动检测和分类自动化流量。这些检测技术可以识别常见的机器人行为模式,并根据用户活动、请求频率等因素进行判断。
- 挑战和验证:对于可疑的自动化流量,CF可以施加挑战,例如CAPTCHA验证,确保流量来源于真实用户而非恶意机器人。
- 速率限制:CF可以设置速率限制规则,根据IP地址或其他标识符,限制每个用户在特定时间内的请求数量,从而防止爬虫或DDoS攻击。
- 自定义规则:网站管理员可以自定义规则,以针对特定类型的自动化流量。例如,允许可信的搜索引擎爬虫访问,同时阻止未知或恶意的机器人,需要结合WAF功能实现。
- 分析和报告:CF提供详细的流量分析和报告,帮助网站管理员了解自动化流量的来源和行为模式,从而调整安全策略。
这个自动化程序功能其实本身只是一个检测机制:能够检测出自动化程序的访问(包括爬虫、攻击等)以及对这些自动化程序进行分类识别,而具体要实现对这些自动化程序的策略控制还需要结合其他功能一起来实现,比如WAF的规则设置。
WAF
CF的Web应用防火墙(Web Application Firewall,简称WAF)是一项强大的安全功能,旨在保护网站免受常见的网络攻击,如SQL注入、跨站脚本(XSS)攻击、跨站请求伪造(CSRF)等。通过分析和过滤HTTP/HTTPS流量,WAF可以识别并阻止恶意请求,确保网站和应用的安全性。
CF WAF的主要功能和优势如下:
- 规则集:CF WAF包含了大量预定义的安全规则集,涵盖了OWASP Top 10漏洞及其他常见威胁。这些规则集会定期更新,以应对最新的安全威胁:
- 自定义规则:网站管理员可以创建自定义规则(Free计划有5条额度),以满足特定的安全需求。例如,可以基于特定的URL路径、查询参数或HTTP标头来创建规则:
- 虚拟补丁:在发现漏洞后,网站管理员可以立即应用虚拟补丁,而无需等待开发团队修复代码,从而快速阻止潜在攻击,实现方式是根据漏洞的原理使用WAF自定义规则进行防护。
- 防御高级攻击:通过集成的机器学习和行为分析技术,CF WAF可以检测并阻止复杂和高级的攻击,如零日漏洞攻击,也是通过自定义规则实现。
- Bot管理:除了保护网站免受人类攻击者的威胁,CF WAF还可以识别和管理自动化流量,防止恶意爬虫和僵尸网络的攻击,需要自定义规则结合自动程序功能实现。
- 日志和监控:WAF提供详细的攻击日志和实时监控,帮助网站管理员了解攻击来源和类型,并及时调整安全策略:
具体的CF WAF功能介绍及详细配置教程参见: 家庭数据中心系列 cloudflare教程(四) CF WAF功能介绍及详细配置教程
标头修改
CF的标头修改功能允许网站管理员通过配置规则来添加、删除或修改 HTTP 请求和响应标头。
标头修改功能的简要介绍如下:
- 添加标头:
• 描述:向 HTTP 请求或响应中添加新的标头。
• 用途:可以用于传递自定义信息、实施安全策略(如 Content-Security-Policy)、优化浏览器缓存(如 Cache-Control)、设置跨域资源共享(如 CORS)等。 - 修改标头:
• 描述:修改现有的 HTTP 请求或响应标头。
• 用途:可以用于更新安全策略、调整缓存设置、更改用户代理信息等。 - 删除标头:
• 描述:从 HTTP 请求或响应中删除特定的标头。
• 用途:可以用于移除敏感信息、禁用不必要的标头、提高安全性等。
常见用途
- 安全性:
• 添加安全标头:如 X-Frame-Options、X-XSS-Protection、Strict-Transport-Security (HSTS) 等,以防止点击劫持、跨站脚本攻击和其他常见安全威胁。
• 内容安全策略(CSP):通过 Content-Security-Policy 标头控制资源加载,防止 XSS 攻击。 - 性能优化:
• 缓存控制:通过 Cache-Control 和 Expires 标头优化浏览器缓存,提高页面加载速度。
• 压缩设置:设置 Content-Encoding 标头以启用 Gzip 或 Brotli 压缩,减少传输数据量。 - 跨域资源共享(CORS):
• 设置 CORS 标头:如 Access-Control-Allow-Origin、Access-Control-Allow-Methods 等,以允许或限制跨域请求。 - 流量管理:
• 自定义标头:添加自定义标头以跟踪或分类流量,支持应用程序的特定需求。
access(Zero Trust)
注:自 2022 年 5 月 25 日起,Access 配置已移至 Zero Trust。
Zero Trust 功能是一套综合的安全解决方案,旨在通过零信任架构保护企业网络和应用。零信任模型假设所有网络流量都是不可信的,无论其来源,必须通过严格的验证和授权机制来确保安全性。 Zero Trust 功能的简要介绍如下:
- 身份验证和访问控制:
• 描述:通过集成单点登录 (SSO)、多因素身份验证 (MFA) 和细粒度访问控制策略,确保只有经过验证和授权的用户才能访问企业资源。
• 用途:保护内部应用、SaaS 应用和远程工作环境,防止未经授权的访问。 - 安全 Web 网关 (SWG):
• 描述:监控和过滤所有出站的互联网流量,防止恶意软件、钓鱼攻击和其他威胁。
• 用途:保护员工上网的安全性,确保符合公司的互联网使用政策。 - 应用程序和 API 安全:
• 描述:通过 Web 应用防火墙 (WAF)、Bot 管理和 DDoS 防护,保护应用程序和 API 不受各种网络攻击。
• 用途:确保企业的在线服务和应用程序的可用性和安全性。 - 零信任网络访问 (ZTNA):
• 描述:为分布式工作环境提供安全访问,无需传统的 VPN。通过策略驱动的访问控制,确保用户仅能访问他们被授权的资源。
• 用途:保护远程和混合办公环境,提供更安全和高效的访问。 - 数据保护:
• 描述:通过数据丢失防护 (DLP) 和云访问安全代理 (CASB) 功能,保护企业敏感数据不被泄露。
• 用途:确保企业数据在传输和存储过程中的安全性,防止数据泄露和未经授权的访问。
Zero Trust有优势如下:
- 增强的安全性:通过严格的身份验证、访问控制和实时威胁检测,保护企业网络和应用免受各种攻击。
- 简化的管理:集中管理所有安全策略和配置,简化 IT 团队的管理工作。
- 灵活性和扩展性:支持分布式工作环境,提供适用于各种规模和行业的安全解决方案。
- 合规性:帮助企业满足各种法律和行业法规的安全要求。
注:Zero Trust功能和配置太多了,几句话说不完,后续我会专门用多篇文章来介绍,这里只提一下2个平时用得最多的功能:Tunnel和WARP+,都是在Zero Trust部分配置的。
Workers路由
CF的Workers 路由是一种无服务器计算平台,允许开发者在全球范围内的 CF 边缘网络上运行 JavaScript 和 TypeScript 代码(这两种语言都是基于 V8 JavaScript 引擎运行的,V8 引擎是 Google Chrome 浏览器和 Node.js 的核心),并且允许开发者基于特定的规则和条件将网络请求路由到不同的 Workers 脚本。通过这些路由规则,开发者可以实现对请求的精细化管理和处理,从而提高应用的灵活性和性能。
CF Workers 路由功能的简要介绍如下:
- 基于路径的路由:
• 描述:根据请求的 URL 路径,将请求路由到特定的 Workers 脚本。
• 用途:适用于为不同的 URL 路径分配特定的处理逻辑。例如,将 /api/* 路径的请求路由到处理 API 请求的 Workers 脚本。 - 基于子域名的路由:
• 描述:根据请求的子域名,将请求路由到不同的 Workers 脚本。
• 用途:适用于多租户架构或子域名分割的场景。例如,将 blog.example.com 的请求路由到处理博客内容的 Workers 脚本,而将 shop.example.com 的请求路由到处理电商功能的 Workers 脚本。 - 基于查询参数的路由:
• 描述:根据请求的查询参数,将请求路由到特定的 Workers 脚本。
• 用途:适用于需要根据查询参数进行特殊处理的场景。例如,根据查询参数 ?lang=en 将请求路由到处理英文内容的 Workers 脚本。 - 自定义规则和条件:
• 描述:创建复杂的自定义规则和条件,基于请求的各个属性(如用户代理、请求头、地理位置等)进行路由。
• 用途:适用于需要根据多个条件进行复杂决策的场景。例如,根据用户代理将请求路由到不同的处理脚本,以适配不同的客户端设备。
具体Worker功能的介绍及使用worker优化网站访问的配置教程参见文章:家庭数据中心系列 cloudflare教程(七) CF worker功能介绍及基于worker实现"乞丐版APO for WordPress"功能加速网站访问的实操、验证及相关技术原理研究。
注:CF Workers功能非常强大,我后续会用专门的文章来讲,这里简单提一下:比如docker hub被封后国内无法访问,可以在Workers上部署JS脚本实现反向代理功能来实现镜像拉取;又比如国内正常访问自己部署在CF上的网站即使使用了CDN依旧觉得慢,这时可以在Workers上部署JS脚本来实现乞丐版的APO功能加速网站访问(Free计划)。并且github上还有很多基于Workers的项目,可以实现众多功能,唯一要注意的是Free计划一天只支持10万次请求的额度,超过以后就不生效了(比如遇到攻击~)。
总结
相信大家看了这篇文章之后,会对流量序列中涉及到的各个技术节点的功能及处理访问请求的命中判定优先级顺序有了大概的认识,至于具体各个部分的配置细节我会在后续文章中详细介绍,当然,会根据各个技术节点涉及的功能多少以及重要性的不同用不同篇幅的文章来写。
一句话总结:这篇文章就是介绍用户的访问请求从"进入CF的边缘网络"直到"准备发往源服务器"这期间CF做的事。
至于如何让"用户的访问请求达到CF的边缘网络"以及"CF如何将请求发往源服务器"就是下一篇文章要讲的事了。
另:这一篇文章我一直想写,但是一直懒得写,总觉得太麻烦,不过要介绍CF的整体方案这一步是避不过的。所以这次趁着写CF系列教程的机会,逼自己一把,终于写出来了,别说,还真发现了我之前没有注意的一些细节,比如,WAF界面里的IP访问规则实际处理优先级高于WAF。
非常好的文章感谢分享
哈哈,谢谢,有用就好,我只是担心写得太技术了没人愿意看。
感谢分享,谢谢站长!!@天天下载
哈哈,没事,不过我还以为没啥人对这些感兴趣呢,有人看我还是很开心的:)