Cloudflare 最新漏洞修复教程｜附源码

本文面向站长、运维工程师、安全负责人和开发者，主要介绍在使用 Cloudflare 过程中，如何快速排查与修复可能存在的安全风险，并提供可直接参考的防护配置与脚本源码。
说明：本文提供的“源码”仅用于安全加固、自动化检测、防护配置与日志审计，不包含漏洞利用代码或攻击性 PoC。

一、前言：为什么 Cloudflare 也需要持续修复漏洞？

Cloudflare 是目前非常常见的 CDN、DNS、WAF、DDoS 防护与边缘安全平台。很多网站接入 Cloudflare 后，会认为自己已经“天然安全”，但实际情况并非如此。

Cloudflare 的确可以显著提升网站的抗攻击能力，例如隐藏源站 IP、拦截恶意请求、过滤常见 Web 攻击、提供访问控制与 Bot 管理等。但是，如果配置不当，仍然可能出现以下问题：

1. 源站 IP 泄露
   攻击者绕过 Cloudflare，直接访问你的真实服务器。

2. DNS 记录配置错误
   某些子域名未走 Cloudflare 代理，导致安全策略失效。

3. WAF 规则未开启或过于宽松
   常见 SQL 注入、XSS、路径穿越等攻击可能绕过基础防护。

4. SSL/TLS 模式配置不安全
   例如使用 Flexible 模式，导致 Cloudflare 到源站之间未加密。

5. 源站未限制 Cloudflare IP 访问
   即使前端接入 Cloudflare，攻击者仍可直接请求源站。

6. API Token 权限过大
   一旦泄露，可能导致 DNS 被篡改、规则被删除、站点被接管。

7. 缓存策略错误
   敏感接口、用户页面被缓存，可能造成数据泄露。

因此，所谓“Cloudflare 漏洞修复”，在很多场景下并不是单指 Cloudflare 官方产品自身的漏洞，而是指网站接入 Cloudflare 后，由于配置、源站、防火墙、访问控制、缓存策略等问题导致的安全风险修复。

本文将从实际运维角度，提供一套完整的 Cloudflare 安全加固教程。

二、适用场景

本文适用于以下情况：

• 网站已经接入 Cloudflare；
• 使用 Cloudflare 进行 DNS 解析；
• 使用 Cloudflare CDN 代理 Web 流量；
• 使用 Cloudflare WAF、SSL/TLS、防火墙规则；
• 希望隐藏源站 IP；
• 希望加强网站抗扫描、抗攻击能力；
• 希望自动化检查 Cloudflare 配置风险；
• 希望通过脚本定期审计 DNS 记录和安全配置。

三、修复前的准备工作

在正式修改配置前，建议先准备以下内容：

1. 确认 Cloudflare 账户权限

建议使用具备管理员权限的账号操作，但日常自动化脚本不要使用全局 API Key，推荐创建最小权限的 API Token。

推荐权限：

Zone.Zone: Read
Zone.DNS: Read
Zone.Firewall Services: Edit
Zone.Settings: Edit

如果脚本只用于读取 DNS 记录，则只给读取权限即可。

2. 备份 DNS 记录

在修改 DNS 配置前，务必备份所有 DNS 记录。错误修改 DNS 可能导致网站无法访问、邮件中断或业务异常。

可以通过 Cloudflare 控制台导出，也可以使用下方脚本自动导出。

3. 记录当前 SSL/TLS 与 WAF 配置

建议截图或导出以下配置：

• SSL/TLS 加密模式；
• Edge Certificates；
• Origin Server 证书；
• WAF Managed Rules；
• Firewall Rules；
• Cache Rules；
• Page Rules；
• Transform Rules；
• Rate Limiting Rules。

这样即使修改后出现问题，也可以快速回滚。

四、核心风险一：源站 IP 泄露

1. 风险说明

接入 Cloudflare 后，用户访问的是 Cloudflare 节点 IP，而不是你的真实服务器 IP。Cloudflare 再回源访问你的源站。

但是，如果源站 IP 被泄露，攻击者可以绕过 Cloudflare，直接请求源站服务器。这样会导致：

• WAF 无法生效；
• DDoS 防护被绕过；
• 源站暴露真实地理位置；
• 攻击者可直接扫描源站服务；
• 服务器带宽和资源被打满。

常见泄露原因包括：

• 历史 DNS 记录泄露；
• 子域名未开启 Cloudflare 代理；
• 邮件服务与 Web 服务共用 IP；
• GitHub、日志、报错信息暴露 IP；
• 证书透明日志泄露域名；
• 源站未限制访问来源。

2. 修复方案

方案一：开启橙色云代理

在 Cloudflare DNS 面板中，确保 Web 相关记录开启代理，也就是显示为橙色云朵。

例如：

不建议将后台管理域名直接暴露为 DNS Only。

方案二：源站防火墙只允许 Cloudflare IP

这是最关键的修复步骤。即使源站 IP 被别人知道，只要防火墙只允许 Cloudflare 官方 IP 段访问 80/443 端口，攻击者也无法直接请求源站。

Cloudflare 官方 IP 地址列表：

https://www.cloudflare.com/ips-v4
https://www.cloudflare.com/ips-v6

五、Linux 源站防火墙加固源码

下面提供一个适用于 Linux 服务器的防火墙配置脚本。该脚本会自动拉取 Cloudflare 官方 IPv4 与 IPv6 地址段，并仅允许这些 IP 访问 80 和 443 端口。

注意：执行前请确认你有服务器 SSH 权限，并且不要误封 SSH 端口。

1. iptables 版本脚本

#!/bin/bash

# cloudflare-firewall.sh
# 功能：仅允许 Cloudflare IP 访问源站 80/443 端口
# 适用：Debian / Ubuntu / CentOS 等使用 iptables 的系统

set -e

CF_IPV4_URL="https://www.cloudflare.com/ips-v4"
CF_IPV6_URL="https://www.cloudflare.com/ips-v6"

echo "[+] 正在下载 Cloudflare IPv4 地址段..."
CF_IPV4=$(curl -s "$CF_IPV4_URL")

echo "[+] 正在下载 Cloudflare IPv6 地址段..."
CF_IPV6=$(curl -s "$CF_IPV6_URL")

echo "[+] 清理旧规则..."
iptables -D INPUT -p tcp --dport 80 -j DROP 2>/dev/null || true
iptables -D INPUT -p tcp --dport 443 -j DROP 2>/dev/null || true

ip6tables -D INPUT -p tcp --dport 80 -j DROP 2>/dev/null || true
ip6tables -D INPUT -p tcp --dport 443 -j DROP 2>/dev/null || true

for ip in $CF_IPV4; do
    iptables -C INPUT -p tcp -s "$ip" --dport 80 -j ACCEPT 2>/dev/null || \
    iptables -I INPUT -p tcp -s "$ip" --dport 80 -j ACCEPT

    iptables -C INPUT -p tcp -s "$ip" --dport 443 -j ACCEPT 2>/dev/null || \
    iptables -I INPUT -p tcp -s "$ip" --dport 443 -j ACCEPT
done

for ip in $CF_IPV6; do
    ip6tables -C INPUT -p tcp -s "$ip" --dport 80 -j ACCEPT 2>/dev/null || \
    ip6tables -I INPUT -p tcp -s "$ip" --dport 80 -j ACCEPT

    ip6tables -C INPUT -p tcp -s "$ip" --dport 443 -j ACCEPT 2>/dev/null || \
    ip6tables -I INPUT -p tcp -s "$ip" --dport 443 -j ACCEPT
done

echo "[+] 阻止非 Cloudflare IP 访问 80/443..."
iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -j DROP

ip6tables -A INPUT -p tcp --dport 80 -j DROP
ip6tables -A INPUT -p tcp --dport 443 -j DROP

echo "[+] Cloudflare 源站防火墙规则配置完成。"

执行方式：

chmod +x cloudflare-firewall.sh
sudo ./cloudflare-firewall.sh

如果你使用的是云服务器安全组，例如阿里云、腾讯云、AWS、Azure，也应在安全组层面同步限制 80/443 端口只允许 Cloudflare IP 段访问。

六、核心风险二：SSL/TLS 配置不安全

1. 不推荐使用 Flexible 模式

Cloudflare 的 SSL/TLS 加密模式包括：

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

其中，Flexible 不推荐用于生产环境。

Flexible 模式下，用户到 Cloudflare 是 HTTPS，但 Cloudflare 到源站可能是 HTTP。这意味着：

• 回源链路未加密；
• 容易出现重定向循环；
• 源站数据传输存在风险；
• 安全合规性较差。

2. 推荐配置：Full Strict

建议使用：

SSL/TLS encryption mode: Full (strict)

同时，在源站安装有效证书。可以选择：

• Let’s Encrypt 免费证书；
• Cloudflare Origin Certificate；
• 商业 CA 证书。

如果只允许 Cloudflare 回源，Cloudflare Origin Certificate 是一个不错的选择。

3. Nginx 源站 HTTPS 配置示例

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/ssl/cloudflare/origin.pem;
    ssl_certificate_key /etc/ssl/cloudflare/origin.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    root /var/www/html;
    index index.html index.htm index.php;

    location / {
        try_files $uri $uri/ =404;
    }
}

配置完成后，重载 Nginx：

sudo nginx -t
sudo systemctl reload nginx

七、核心风险三：真实访客 IP 获取错误

1. 风险说明

接入 Cloudflare 后，源站看到的访问 IP 通常是 Cloudflare 节点 IP。如果没有正确配置真实 IP，日志、安全策略、限流策略都会失准。

例如：

• Nginx 日志中全是 Cloudflare IP；
• 应用层限流失效；
• 黑名单封禁错误；
• 登录风控不准确。

2. Nginx 配置真实 IP

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

CF-Connecting-IP

Nginx 可以使用 real_ip_header 获取真实 IP。

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

real_ip_header CF-Connecting-IP;
real_ip_recursive on;

建议将该配置放到：

/etc/nginx/conf.d/cloudflare-real-ip.conf

然后执行：

sudo nginx -t
sudo systemctl reload nginx

八、核心风险四：WAF 规则未开启

1. 开启 Cloudflare 托管规则

进入 Cloudflare 控制台：

Security → WAF → Managed rules

建议开启：

• Cloudflare Managed Ruleset；
• Cloudflare OWASP Core Ruleset；
• Cloudflare Exposed Credentials Check；
• Cloudflare PHP Ruleset；
• WordPress Ruleset，如果你使用 WordPress；
• Joomla / Drupal 相关规则，如果你的站点使用这些 CMS。

2. 推荐 WAF 自定义规则

如果后台路径是 /admin、/wp-admin、/manage，建议增加访问限制。

示例规则：

(http.request.uri.path contains "/admin")

动作可以设置为：

Managed Challenge

如果后台只允许固定国家、固定 IP 或 VPN 访问，可以进一步收紧。

例如，只允许指定 IP 访问后台：

(http.request.uri.path contains "/admin") and not ip.src in {203.0.113.10}

动作：

Block

九、核心风险五：缓存敏感数据

1. 风险说明

Cloudflare 缓存可以提升访问速度，但如果缓存策略配置不当，可能导致敏感页面被缓存。

不应缓存的内容包括：

• 用户个人中心；
• 登录后页面；
• 购物车；
• 支付页面；
• API 鉴权接口；
• 后台管理页面；
• 含 Token、Session、Cookie 的响应。

2. 推荐 Cache Rule

建议对以下路径设置绕过缓存：

/admin/*
/login*
/logout*
/user/*
/account/*
/cart/*
/checkout/*
/api/*

缓存动作：

Bypass cache

如果你使用 WordPress，也建议绕过：

/wp-admin/*
/wp-login.php

同时，对于带 Cookie 的动态请求，建议不要缓存。

十、自动化检查 DNS 代理状态源码

下面提供一个 Python 脚本，用于检查 Cloudflare DNS 记录是否开启代理，并输出未代理的记录。

1. 安装依赖

pip install requests

2. Python 源码

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

"""
cloudflare_dns_audit.py
功能：检查 Cloudflare DNS 记录代理状态
用途：发现可能暴露源站 IP 的 DNS 记录
"""

import requests
import sys

API_TOKEN = "请替换为你的 Cloudflare API Token"
ZONE_ID = "请替换为你的 Zone ID"

headers = {
    "Authorization": f"Bearer {API_TOKEN}",
    "Content-Type": "application/json"
}

def get_dns_records():
    records = []
    page = 1

    while True:
        url = f"https://api.cloudflare.com/client/v4/zones/{ZONE_ID}/dns_records"
        params = {
            "page": page,
            "per_page": 100
        }

        resp = requests.get(url, headers=headers, params=params, timeout=10)
        data = resp.json()

        if not data.get("success"):
            print("请求 Cloudflare API 失败：", data)
            sys.exit(1)

        records.extend(data["result"])

        total_pages = data["result_info"]["total_pages"]
        if page >= total_pages:
            break

        page += 1

    return records

def main():
    records = get_dns_records()

    print("=== Cloudflare DNS 代理状态检查 ===")

    risky = []

    for record in records:
        r_type = record.get("type")
        name = record.get("name")
        content = record.get("content")
        proxied = record.get("proxied")

        if r_type in ["A", "AAAA", "CNAME"]:
            if proxied is False:
                risky.append((r_type, name, content))

    if not risky:
        print("未发现未代理的 A/AAAA/CNAME 记录。")
    else:
        print("发现以下记录未开启 Cloudflare 代理，请确认是否必要：")
        for item in risky:
            print(f"类型: {item[0]} | 域名: {item[1]} | 内容: {item[2]}")

if __name__ == "__main__":
    main()

运行：

python3 cloudflare_dns_audit.py

注意：并不是所有 DNS 记录都必须开启代理。例如邮件相关记录、某些第三方验证记录可能需要保持 DNS Only。但 Web 相关记录应尽量开启代理。

十一、自动化导出 DNS 记录源码

在进行任何修改前，建议先导出 DNS 记录。

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

"""
cloudflare_dns_backup.py
功能：导出 Cloudflare DNS 记录为 JSON 文件
"""

import requests
import json
import datetime

API_TOKEN = "请替换为你的 Cloudflare API Token"
ZONE_ID = "请替换为你的 Zone ID"

headers = {
    "Authorization": f"Bearer {API_TOKEN}",
    "Content-Type": "application/json"
}

def fetch_records():
    all_records = []
    page = 1

    while True:
        url = f"https://api.cloudflare.com/client/v4/zones/{ZONE_ID}/dns_records"
        params = {
            "page": page,
            "per_page": 100
        }

        response = requests.get(url, headers=headers, params=params, timeout=10)
        result = response.json()

        if not result.get("success"):
            raise RuntimeError(result)

        all_records.extend(result["result"])

        info = result["result_info"]
        if page >= info["total_pages"]:
            break

        page += 1

    return all_records

def main():
    records = fetch_records()
    date = datetime.datetime.now().strftime("%Y%m%d_%H%M%S")
    filename = f"cloudflare_dns_backup_{date}.json"

    with open(filename, "w", encoding="utf-8") as f:
        json.dump(records, f, ensure_ascii=False, indent=2)

    print(f"DNS 记录已备份到：{filename}")

if __name__ == "__main__":
    main()

十二、API Token 安全加固

Cloudflare API Token 是非常敏感的凭证。如果泄露，可能导致 DNS 记录被修改、WAF 被关闭、站点流量被劫持。

推荐做法

1. 不使用 Global API Key；
2. 使用 API Token；
3. 遵循最小权限原则；
4. 不将 Token 写入公开代码仓库；
5. 使用环境变量保存 Token；
6. 定期轮换 Token；
7. 给 Token 设置明确的 Zone 范围；
8. 离职人员及时移除账户权限。

推荐使用环境变量：

export CF_API_TOKEN="你的Token"
export CF_ZONE_ID="你的ZoneID"

Python 中读取：

import os

API_TOKEN = os.getenv("CF_API_TOKEN")
ZONE_ID = os.getenv("CF_ZONE_ID")

这样可以避免 Token 直接硬编码在源码中。

十三、速率限制与 Bot 防护

1. 登录接口限流

如果网站存在登录接口，例如：

/login
/api/login
/wp-login.php

建议配置 Rate Limiting。

示例策略：

路径包含 /login
同一 IP 1 分钟内请求超过 10 次
执行 Managed Challenge 或 Block

这样可以有效降低撞库、爆破、自动化扫描的风险。

2. 开启 Bot Fight Mode

对于普通站点，可以开启：

Security → Bots → Bot Fight Mode

如果你是 Pro、Business 或 Enterprise 套餐，可以使用更强的 Bot Management 功能。

十四、Cloudflare 页面规则与重定向加固

建议开启 HTTPS 强制跳转：

SSL/TLS → Edge Certificates → Always Use HTTPS

同时开启：

Automatic HTTPS Rewrites

对于旧的 Page Rules，如果存在缓存全部内容的规则，例如：

example.com/*
Cache Everything

需要特别谨慎。该规则可能会缓存动态页面。更推荐使用 Cache Rules 精准控制缓存范围。

十五、日志审计与告警

修复安全问题后，还需要持续监控。建议定期查看：

• Cloudflare Security Events；
• WAF 命中日志；
• Rate Limiting 命中情况；
• DNS 记录变更；
• 源站 Nginx/Apache 日志；
• 服务器防火墙日志；
• 应用登录日志。

如果使用企业级日志，可以接入：

• Cloudflare Logpush；
• SIEM；
• Grafana；
• Elasticsearch；
• Splunk；
• Datadog。

对于中小型网站，也可以至少开启账户安全通知，并定期导出审计记录。

十六、修复完成后的验证清单

完成配置后，建议按以下清单逐项验证：

• [ ] Web 域名 A/AAAA/CNAME 记录已开启 Proxied；
• [ ] 源站 80/443 仅允许 Cloudflare IP 访问；
• [ ] SSL/TLS 模式已设置为 Full Strict；
• [ ] 源站安装了有效证书；
• [ ] Nginx/Apache 已正确获取真实访客 IP；
• [ ] WAF Managed Rules 已开启；
• [ ] 后台路径已配置 Challenge 或 IP 限制；
• [ ] 登录接口已配置速率限制；
• [ ] 敏感路径已设置 Bypass Cache；
• [ ] API Token 已使用最小权限；
• [ ] DNS 记录已备份；
• [ ] 安全事件日志可正常查看；
• [ ] SSH、数据库、Redis 等端口未暴露公网；
• [ ] 邮件服务未与 Web 源站共用敏感 IP，或已做隔离。

十七、常见问题

1. 开启防火墙后网站打不开怎么办？

可能原因：

• Cloudflare IP 段未完整加入；
• IPv6 规则遗漏；
• 源站 Nginx 没有监听正确端口；
• SSL 证书配置错误；
• 云服务器安全组与系统防火墙冲突。

建议先检查：

sudo iptables -L -n
sudo ip6tables -L -n
sudo nginx -t
curl -I https://example.com

2. 是否必须隐藏所有子域名？

不一定。邮件、验证、第三方服务相关记录可能不能开启代理。但后台、API、业务入口应尽量通过 Cloudflare 代理，并做好访问限制。

3. Cloudflare IP 会变化吗？

会变化，但频率不高。因此建议使用脚本定期同步 Cloudflare IP 段，例如每天执行一次。

可以添加 crontab：

0 3 * * * /bin/bash /opt/cloudflare-firewall.sh >> /var/log/cloudflare-firewall.log 2>&1

4. Full Strict 配置后报错怎么办？

通常是源站证书问题。请确认：

• 证书未过期；
• 证书域名匹配；
• 中间证书链完整；
• Nginx/Apache 正确加载证书；
• Cloudflare Origin Certificate 已正确安装。

十八、总结

Cloudflare 是非常强大的边缘安全平台，但安全效果取决于正确配置。很多所谓“Cloudflare 漏洞”并不是 Cloudflare 自身被攻破，而是源站、DNS、缓存、SSL、WAF 或 API Token 管理不当导致的风险。

本文给出了一套实用修复方案：

1. Web 记录开启 Cloudflare 代理；
2. 源站防火墙只允许 Cloudflare IP；
3. SSL/TLS 使用 Full Strict；
4. 正确配置真实访客 IP；
5. 开启 WAF 托管规则；
6. 对后台和登录接口设置挑战或限流；
7. 避免缓存敏感数据；
8. 使用最小权限 API Token；
9. 定期备份 DNS；
10. 通过脚本自动化审计配置风险。

只要按照本文步骤逐项落实，大多数 Cloudflare 接入后的安全隐患都可以得到有效修复。对于生产环境，建议将这些检查纳入日常运维流程，并结合日志审计、告警系统和定期安全评估，形成持续性的安全闭环。