Cloudflare 安全漏洞分析｜附完整命令

声明：本文仅用于企业自查、授权安全评估与防御加固。文中命令应仅在你拥有或已获得明确授权的域名、服务器与网络资产上执行，禁止用于未授权扫描、攻击或绕过第三方安全防护。

一、Cloudflare 的安全定位

Cloudflare 是目前非常常见的 CDN、DNS、WAF 与 DDoS 防护平台。很多网站接入 Cloudflare 后，会将域名 DNS 托管到 Cloudflare，并通过其边缘节点代理访问请求，从而隐藏真实源站 IP、过滤恶意流量、缓存静态资源、抵御大流量攻击。

但需要注意的是：

Cloudflare 不是“一接入就绝对安全”的产品。

在实际安全测试和企业安全运营中，很多风险并不是 Cloudflare 本身存在严重漏洞，而是由于以下原因导致：

1. 源站真实 IP 泄露；
2. 源站仍允许公网直接访问；
3. DNS 记录配置不当；
4. SSL/TLS 模式配置错误；
5. WAF 规则过于宽松；
6. 缓存策略配置不合理；
7. 后台接口、管理路径未额外保护；
8. 业务 API 未做鉴权或限流；
9. Cloudflare Access、Zero Trust 未启用；
10. 仅依赖 Cloudflare，忽略源站自身安全。

因此，分析 Cloudflare 相关安全问题，本质上是分析：

Cloudflare 边缘防护、DNS 配置、源站暴露面与业务安全之间的关系。

二、常见风险一：源站真实 IP 泄露

1. 风险说明

Cloudflare 的一个重要作用是隐藏源站真实 IP。正常情况下，用户访问域名时，看到的是 Cloudflare 的边缘节点 IP，而不是源站 IP。

但是，如果源站 IP 因历史 DNS 记录、子域名、邮件服务、证书记录、第三方服务、错误配置等方式泄露，攻击者可能绕过 Cloudflare，直接访问源站服务器。

一旦源站可以被直接访问，就可能导致：

• 绕过 Cloudflare WAF；
• 绕过 DDoS 防护；
• 直接扫描源站开放端口；
• 直接攻击 Web 服务；
• 发现未经过滤的后台服务；
• 对源站进行压力测试或资源消耗攻击。

2. 检查当前域名解析结果

假设授权测试域名为：

example.com

查看 A 记录：

dig example.com A

查看 AAAA 记录：

dig example.com AAAA

使用 +short 简化输出：

dig +short example.com A
dig +short example.com AAAA

如果返回的 IP 属于 Cloudflare，则通常说明主域名经过了 Cloudflare 代理。

可以使用如下方式查看 IP 所属组织：

whois 104.21.10.10

或者：

curl -s https://ipinfo.io/104.21.10.10

如果看到类似以下信息，说明可能是 Cloudflare 边缘节点：

Cloudflare, Inc.
AS13335

三、常见风险二：历史 DNS 记录泄露源站

1. 风险说明

很多网站在接入 Cloudflare 之前，曾经直接将域名解析到源站 IP。即使后来切换到了 Cloudflare，历史 DNS 记录也可能被第三方搜索引擎、被动 DNS 平台或证书透明度平台记录。

这类信息如果被攻击者发现，可能暴露真实源站。

2. 检查历史子域名

可以使用证书透明度日志查询子域名。

命令示例：

curl -s "https://crt.sh/?q=%25.example.com&output=json"

为了便于查看，可以结合 jq：

curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq -r '.[].name_value' | sort -u

如果没有安装 jq，可以安装：

Debian / Ubuntu：

sudo apt update
sudo apt install -y jq

CentOS / Rocky Linux：

sudo yum install -y jq

macOS：

brew install jq

3. 查询子域名解析

假设发现了一些子域名：

www.example.com
api.example.com
admin.example.com
old.example.com
dev.example.com

可以逐个查询：

dig +short www.example.com A
dig +short api.example.com A
dig +short admin.example.com A
dig +short old.example.com A
dig +short dev.example.com A

也可以写成批量脚本：

cat > subdomains.txt << EOF
www.example.com
api.example.com
admin.example.com
old.example.com
dev.example.com
EOF

while read domain; do
  echo "===== $domain ====="
  dig +short "$domain" A
done < subdomains.txt

如果某些子域名没有经过 Cloudflare 代理，而是直接解析到源站 IP，就需要重点关注。

四、常见风险三：源站允许公网直接访问

1. 风险说明

即使域名已经接入 Cloudflare，如果源站服务器没有限制访问来源，那么攻击者一旦知道源站 IP，就可以直接访问。

正确做法是：

源站防火墙仅允许 Cloudflare 官方 IP 段访问 Web 端口。

2. 检查源站是否可直接访问

假设源站 IP 为：

203.0.113.10

通过 HTTP 访问：

curl -I http://203.0.113.10

通过 HTTPS 访问：

curl -k -I https://203.0.113.10

如果源站使用虚拟主机，需要指定 Host 头：

curl -k -I https://203.0.113.10 -H "Host: example.com"

如果返回正常的业务页面状态码，例如：

HTTP/1.1 200 OK

说明源站可能可以被直接访问。

如果返回：

403 Forbidden

或者连接被拒绝，说明源站可能已经做了限制。

五、常见风险四：源站防火墙未限制 Cloudflare IP

1. 获取 Cloudflare 官方 IP 段

Cloudflare 官方 IPv4 列表：

curl -s https://www.cloudflare.com/ips-v4

Cloudflare 官方 IPv6 列表：

curl -s https://www.cloudflare.com/ips-v6

保存到本地：

curl -s https://www.cloudflare.com/ips-v4 -o cloudflare-ips-v4.txt
curl -s https://www.cloudflare.com/ips-v6 -o cloudflare-ips-v6.txt

2. 使用 UFW 限制源站访问

如果源站使用 Ubuntu，并启用了 UFW，可以执行：

sudo ufw default deny incoming
sudo ufw default allow outgoing

允许 SSH 管理端口，例如只允许你的办公 IP：

sudo ufw allow from 198.51.100.20 to any port 22 proto tcp

允许 Cloudflare IPv4 访问 80 和 443：

while read ip; do
  sudo ufw allow from "$ip" to any port 80 proto tcp
  sudo ufw allow from "$ip" to any port 443 proto tcp
done < cloudflare-ips-v4.txt

允许 Cloudflare IPv6 访问 80 和 443：

while read ip; do
  sudo ufw allow from "$ip" to any port 80 proto tcp
  sudo ufw allow from "$ip" to any port 443 proto tcp
done < cloudflare-ips-v6.txt

启用 UFW：

sudo ufw enable

查看规则：

sudo ufw status verbose

3. 使用 iptables 限制访问

如果使用 iptables，可以参考：

sudo iptables -F
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

允许本地回环：

sudo iptables -A INPUT -i lo -j ACCEPT

允许已建立连接：

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

允许管理 IP 访问 SSH：

sudo iptables -A INPUT -p tcp -s 198.51.100.20 --dport 22 -j ACCEPT

允许 Cloudflare IPv4 访问 80 和 443：

while read ip; do
  sudo iptables -A INPUT -p tcp -s "$ip" --dport 80 -j ACCEPT
  sudo iptables -A INPUT -p tcp -s "$ip" --dport 443 -j ACCEPT
done < cloudflare-ips-v4.txt

最后拒绝其他访问：

sudo iptables -A INPUT -j DROP

保存规则：

Debian / Ubuntu：

sudo apt install -y iptables-persistent
sudo netfilter-persistent save

CentOS / Rocky Linux：

sudo service iptables save

六、常见风险五：Cloudflare SSL/TLS 模式配置不当

1. 风险说明

Cloudflare SSL/TLS 常见模式包括：

• Off；
• Flexible；
• Full；
• Full Strict。

其中风险较高的是 Flexible 模式。

在 Flexible 模式下：

浏览器  <--HTTPS-->  Cloudflare  <--HTTP-->  源站

也就是说，用户到 Cloudflare 是 HTTPS，但 Cloudflare 到源站可能是 HTTP 明文传输。

这会带来以下风险：

• 源站链路不加密；
• 登录 Cookie、Token 在源站链路可能暴露；
• 安全策略不一致；
• 容易引发重定向循环；
• 给用户造成“全程 HTTPS”的误解。

推荐使用：

Full Strict

即：

浏览器  <--HTTPS-->  Cloudflare  <--HTTPS-->  源站

并且源站证书必须有效。

2. 检查源站证书

查看证书信息：

openssl s_client -connect example.com:443 -servername example.com

简化查看证书主题和颁发者：

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

检查证书过期时间：

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate

如果源站使用 Cloudflare Origin Certificate，也可以满足 Full Strict 的要求，但该证书通常只被 Cloudflare 信任，不一定被普通浏览器直接信任。

七、常见风险六：真实客户端 IP 获取错误

1. 风险说明

接入 Cloudflare 后，源站看到的访问 IP 通常是 Cloudflare 节点 IP，而不是用户真实 IP。

Cloudflare 会通过请求头传递真实客户端 IP，例如：

CF-Connecting-IP
X-Forwarded-For

如果源站没有正确配置，就可能导致：

• 日志中全是 Cloudflare IP；
• 风控系统失效；
• 限流策略失效；
• 后台审计不准确；
• 应用误判用户来源。

2. Nginx 获取真实 IP 配置

下载 Cloudflare IP：

curl -s https://www.cloudflare.com/ips-v4 -o /etc/nginx/cloudflare-ips-v4.conf
curl -s https://www.cloudflare.com/ips-v6 -o /etc/nginx/cloudflare-ips-v6.conf

生成 Nginx real_ip 配置：

sudo bash -c 'curl -s https://www.cloudflare.com/ips-v4 | sed "s/^/set_real_ip_from /;s/$/;/" > /etc/nginx/conf.d/cloudflare-real-ip.conf'
sudo bash -c 'curl -s https://www.cloudflare.com/ips-v6 | sed "s/^/set_real_ip_from /;s/$/;/" >> /etc/nginx/conf.d/cloudflare-real-ip.conf'

追加真实 IP 头配置：

sudo bash -c 'cat >> /etc/nginx/conf.d/cloudflare-real-ip.conf << EOF
real_ip_header CF-Connecting-IP;
real_ip_recursive on;
EOF'

检查 Nginx 配置：

sudo nginx -t

重载 Nginx：

sudo systemctl reload nginx

查看日志：

tail -f /var/log/nginx/access.log

八、常见风险七：WAF 规则过于宽松

1. 风险说明

Cloudflare WAF 可以拦截常见攻击，例如 SQL 注入、XSS、路径穿越、恶意爬虫等。但很多企业为了避免误报，会关闭规则或仅使用默认规则，导致防护能力不足。

常见问题包括：

• 未启用 Managed Rules；
• 未启用 OWASP Core Ruleset；
• 未针对后台路径设置更强限制；
• 未对 API 设置速率限制；
• 未对敏感路径设置验证码或访问控制；
• 未根据国家、ASN、风险评分设置策略。

2. 使用 curl 检查响应头

查看站点是否经过 Cloudflare：

curl -I https://example.com

常见 Cloudflare 响应头包括：

cf-ray
cf-cache-status
server: cloudflare

完整查看：

curl -v https://example.com

仅查看响应头：

curl -s -D - https://example.com -o /dev/null

3. 检查敏感路径是否有额外保护

例如：

curl -I https://example.com/admin/
curl -I https://example.com/login/
curl -I https://example.com/wp-admin/
curl -I https://example.com/api/

如果这些路径对公网直接开放，并且没有多因素认证、验证码、Access 策略或 IP 限制，就存在较大风险。

建议对以下路径启用更强保护：

/admin/
/login/
/wp-admin/
/manager/
/console/
/api/internal/
/grafana/
/prometheus/
/jenkins/

九、常见风险八：缓存配置错误导致敏感信息泄露

1. 风险说明

Cloudflare 缓存可以提升访问速度，但如果缓存规则配置错误，可能把用户个人页面、接口响应、鉴权后的内容缓存到边缘节点，从而导致敏感信息泄露。

高风险场景包括：

• 登录后页面被缓存；
• API 返回用户隐私数据但被缓存；
• 带 Token 的 URL 被缓存；
• 后台页面被设置 Cache Everything；
• 未区分 Cookie、Header、Query String；
• 静态资源与动态接口缓存策略混用。

2. 检查缓存状态

命令：

curl -I https://example.com/

关注响应头：

CF-Cache-Status
Cache-Control
Set-Cookie

示例：

curl -s -D - https://example.com/ -o /dev/null | grep -Ei "cf-cache-status|cache-control|set-cookie"

检查 API：

curl -s -D - https://example.com/api/user -o /dev/null | grep -Ei "cf-cache-status|cache-control|set-cookie"

如果接口返回用户相关数据，却出现：

CF-Cache-Status: HIT

就需要立即检查缓存规则。

3. 推荐缓存头

对于敏感页面：

Cache-Control: no-store, no-cache, must-revalidate

对于需要登录的 API：

Cache-Control: private, no-store

对于静态资源：

Cache-Control: public, max-age=31536000, immutable

十、常见风险九：后台管理系统未使用 Cloudflare Access

1. 风险说明

很多企业的后台路径虽然经过 Cloudflare，但仍然直接暴露在公网。攻击者可能通过弱口令、撞库、钓鱼、漏洞利用等方式尝试进入后台。

Cloudflare Access 可以在应用前面增加一层身份认证，例如：

• Google Workspace；
• Microsoft Entra ID；
• Okta；
• GitHub；
• One-time PIN；
• SAML；
• OIDC。

这样即使后台系统自身登录页存在风险，也会先被 Cloudflare Access 拦截。

2. 检查后台路径

curl -I https://admin.example.com
curl -I https://example.com/admin/

如果返回普通登录页面，并且没有额外认证，建议启用 Cloudflare Access。

启用后，访问后台时应先出现 Cloudflare Access 登录流程，而不是直接进入业务登录页。

十一、常见风险十：API 缺少限流与机器人防护

1. 风险说明

Cloudflare 可以拦截一部分恶意流量，但如果 API 本身缺少限流、鉴权和风控，依然可能面临：

• 短信轰炸；
• 邮箱轰炸；
• 登录爆破；
• 撞库攻击；
• 接口枚举；
• 批量注册；
• 数据爬取；
• 订单接口滥用。

2. 基础连通性检查

查看 API 响应头：

curl -s -D - https://example.com/api/login -o /dev/null

检查是否有安全响应头：

curl -s -D - https://example.com/api/login -o /dev/null | grep -Ei "rate|limit|cache|cf|security|x-frame|x-content|strict"

常见建议：

• 登录接口启用速率限制；
• 注册接口启用验证码；
• 找回密码接口限制频率；
• 短信接口限制手机号、IP、设备指纹；
• API 统一鉴权；
• 对高风险接口启用 Bot Fight Mode 或 Turnstile；
• 使用 Cloudflare Rate Limiting Rules。

十二、安全基线检查清单

以下清单可以作为企业自查模板。

1. DNS 与代理状态

检查主域名：

dig +short example.com A
dig +short www.example.com A

检查是否经过 Cloudflare：

curl -I https://example.com

确认是否出现：

server: cloudflare
cf-ray

2. 子域名暴露面

查询证书透明度日志：

curl -s "https://crt.sh/?q=%25.example.com&output=json" | jq -r '.[].name_value' | sort -u

批量解析：

while read domain; do
  echo "===== $domain ====="
  dig +short "$domain" A
done < subdomains.txt

3. 源站直接访问检查

curl -k -I https://203.0.113.10 -H "Host: example.com"

理想结果：

403 Forbidden

或无法连接。

4. 源站端口最小化

仅在授权环境中对自有服务器进行端口检查：

nmap -Pn -sT -p 80,443 203.0.113.10

如果需要检查常见管理端口，仅限自有资产：

nmap -Pn -sT -p 22,80,443,3306,6379,9200,9300 203.0.113.10

高风险端口如数据库、Redis、Elasticsearch、管理面板等不应直接暴露公网。

5. SSL/TLS 检查

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

6. 缓存策略检查

curl -s -D - https://example.com/ -o /dev/null | grep -Ei "cf-cache-status|cache-control|set-cookie"

7. 敏感路径检查

curl -I https://example.com/admin/
curl -I https://example.com/login/
curl -I https://example.com/api/

十三、推荐加固方案

1. 源站只允许 Cloudflare 访问

这是最重要的措施之一。

原则：

公网用户 -> Cloudflare -> 源站
公网用户 -X-> 源站

源站的 80、443 端口应仅允许 Cloudflare IP 段访问。

2. 使用 Full Strict 模式

Cloudflare SSL/TLS 建议配置为：

Full Strict

并在源站安装有效证书。

3. 后台系统使用 Cloudflare Access

对于后台、监控、运维系统，应使用：

Cloudflare Access + MFA + 最小权限策略

4. 开启 WAF Managed Rules

建议启用：

• Cloudflare Managed Rules；
• OWASP Core Ruleset；
• Bot Fight Mode；
• Security Level；
• Browser Integrity Check。

5. 为 API 配置速率限制

尤其是：

• 登录接口；
• 注册接口；
• 短信接口；
• 邮件接口；
• 查询接口；
• 导出接口；
• 支付相关接口。

6. 正确配置缓存

敏感接口禁止缓存，静态资源积极缓存。

动态内容建议：

Cache-Control: no-store

静态资源建议：

Cache-Control: public, max-age=31536000, immutable

7. 配置真实 IP

Nginx 应使用：

real_ip_header CF-Connecting-IP;
real_ip_recursive on;

并仅信任 Cloudflare IP 段。

8. 定期巡检 Cloudflare IP 段

Cloudflare IP 段可能发生变化，应定期同步。

示例定时任务：

sudo crontab -e

添加：

0 3 * * * curl -s https://www.cloudflare.com/ips-v4 -o /tmp/cloudflare-ips-v4.txt && curl -s https://www.cloudflare.com/ips-v6 -o /tmp/cloudflare-ips-v6.txt

实际生产环境中，建议同步后自动更新防火墙规则，并在测试通过后生效。

十四、总结

Cloudflare 能显著提升网站安全性，但它并不能替代源站安全、业务安全和访问控制。很多所谓“Cloudflare 漏洞”，本质上都是由于源站暴露、DNS 配置错误、缓存策略不当、SSL 模式选择错误或后台防护不足造成的。

企业应重点关注以下几点：

1. 源站真实 IP 不应泄露；
2. 源站 Web 端口只允许 Cloudflare IP 访问；
3. SSL/TLS 使用 Full Strict；
4. 后台系统启用 Cloudflare Access；
5. WAF、Bot、防爆破和速率限制要启用；
6. 敏感页面和接口禁止错误缓存；
7. Nginx、日志、风控系统要正确获取真实客户端 IP；
8. 子域名、历史 DNS、旧业务系统要定期清理；
9. 源站自身仍需保持系统更新和漏洞修复；
10. 所有检测命令必须限定在自有或授权资产范围内执行。

Cloudflare 是安全架构中的重要一环，但不是唯一一环。只有将 Cloudflare 防护、源站防火墙、应用安全、身份认证、日志审计和业务风控结合起来，才能构建真正可靠的防护体系。