企业官网建设流程全解析

Bash 调用 Cloudflare API 自动启用 DDoS 防护：Introduction to Bash Scripting 实战章节解析

【免费下载链接】introduction-to-bash-scriptingFree Introduction to Bash Scripting eBook项目地址: https://gitcode.com/GitHub_Trending/in/introduction-to-bash-scripting

本篇文章围绕开源电子书Introduction to Bash Scripting（西班牙语版第 019 章 Trabajar con la API de Cloudflare en Bash）展开，讲解如何用 Bash 脚本结合 Cloudflare API，在服务器 CPU 负载异常飙升时自动启用 Cloudflare 的 DDoS 防护（"I'm under attack" 模式），并在负载恢复正常后自动关闭。读完本文，你将掌握 Cloudflare API 的认证与调用方式、CPU 负载监控的 Bash 写法，以及用 Cron 实现每 30 秒自动巡检的完整落地方案。

一、章节背景：为什么需要自动化 DDoS 防护

该章节作者将自己的网站托管在 DigitalOcean Droplet 上，并把 Cloudflare 作为 CDN 提供商。使用 Cloudflare 有两个直接收益：一是显著降低回源流量，二是把服务器真实 IP 隐藏在 CDN 之后，避免攻击者直接打向源站。

其中最具实用价值的是 Cloudflare 的免费 DDoS 防护能力，它曾多次在真实攻击中保护作者服务器。而 Cloudflare 提供的 API 允许程序化地开启/关闭该防护，这就为"检测到攻击自动开启、攻击结束后自动关闭"的自动化脚本提供了可能——本章正是以此为背景，向读者发起一个实战挑战：

编写一个简短的 Bash 脚本，在必要时自动启用和禁用 Cloudflare 对服务器的 DDoS 防护。

这一章在全书的定位是"实战篇"。正如 README.md 所说明的，前 13 章聚焦 Bash 脚本基础，之后的章节则给出真实世界的示例与脚本；本章正是把前面学过的变量、条件、循环、函数等语法综合运用到真实运维场景的典型示范。

二、前置条件：账号、密钥、Zone ID 与 curl

在开始写脚本之前，需要完成以下准备：

1. 注册 Cloudflare 账号并把网站接入 Cloudflare（在 Cloudflare 控制台添加站点、完成 DNS 接管）。
2. 获取三个关键信息：

3. 确认服务器上安装了 curl，因为脚本要通过 curl 发起 HTTP 请求调用 Cloudflare API：

curl --version

如果 curl 未安装，根据发行版选择安装方式：

• RedHat/CentOS：

yum install curl

• Debian/Ubuntu：

apt-get install curl

提示：本章以旧版 X-Auth-Email / X-Auth-Key 认证方式为例，这也是示例脚本采用的认证方式；较新的 Cloudflare 也支持 API Token（Bearer Token）认证，实践中可以按需切换。

三、理解你要调用的 Cloudflare API

虽然原文档没有逐行给出 API 请求，但其核心思路是调用 Cloudflare 的zone 级安全设置接口，把security_level设为under_attack（我正在遭受攻击）来开启高强度防护，再在攻击结束后恢复为正常等级（如high/medium/low）。

一个代表性的请求形如：

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/${CF_ZONE_ID}/settings/security_level" \ -H "X-Auth-Email: ${CF_EMAIL_ADDRESS}" \ -H "X-Auth-Key: ${CF_API_KEY}" \ -H "Content-Type: application/json" \ --data '{"value":"under_attack"}'

其中：

• zones/{zone_id}/settings/security_level是设置指定 zone 安全级别的端点；
• X-Auth-Email与X-Auth-Key是请求头认证信息；
• --data '{"value":"under_attack"}'表示启用 "I'm under attack" 模式；恢复正常时把value改回high（或其他正常级别）即可。

under_attack模式会向访问者展示质询页面（challenge），几乎能拦下所有自动化流量，因此在攻击结束后必须及时恢复，否则会严重影响正常访客体验——这正是"自动开启 + 自动关闭"这套逻辑存在的意义。

四、挑战：脚本需求拆解

原文档给出了明确的挑战要求，脚本需要监控服务器 CPU 使用率，当 CPU 负载相对 vCPU 数量偏高时，自动通过 Cloudflare API 启用 DDoS 防护；核心功能有三点：

• 检查服务器的 CPU 负载；
• CPU 出现峰值时，触发对 Cloudflare 的 API 调用，为指定 zone 启用 DDoS 防护；
• CPU 负载恢复正常后，关闭 "I'm under attack" 选项，将安全级别恢复为正常。

这是一个典型的"监控 → 决策 → 动作 → 恢复"闭环，恰好可以把本书前面章节的知识点全部串起来：

• Bash 变量：存储 Zone ID、邮箱、API Key 等配置；
• Bash 条件表达式：用[[ ... ]]、数值比较-gt/-le判断负载是否超标；
• Bash 条件语句：用if / else决定启用还是关闭防护；
• Bash 函数：把"启用防护""关闭防护"封装为可复用函数；
• Bash 循环 与 Cron：让检查周期性执行。

五、动手实现：脚本核心步骤拆解

原文档鼓励读者先自己尝试编写，再看参考脚本。下面结合前序章节的语法给出一个可运行的教学版实现骨架。

1. 定义 Cloudflare 配置变量

脚本头部集中定义认证信息，方便维护（对应 Bash 变量 章节）：

#!/bin/bash CF_ZONE_ID="TU_ID_DE_ZONA_DE_CLOUDFLARE" CF_EMAIL_ADDRESS="TU_CORREO_ELECTRÓNICO_DE_LA_CUENTA_DE_CLOUDFLARE" CF_API_KEY="TU_CLAVE_API_DE_CLOUDFLARE"

2. 读取 CPU 负载

获取当前 1 分钟平均负载并换算为相对 vCPU 数目的占用比例。vCPU 数量可以用nproc获取，负载可以从/proc/loadavg读取第一列：

carga_1min=$(awk '{print $1}' /proc/loadavg) vcpu=$(nproc)

结合 Bash 算术与条件表达式 中-gt、-le等数值比较运算符，即可判断"负载是否超过 vCPU 的某个百分比阈值"。

3. 封装 API 调用函数

把"开启防护"与"关闭防护"分别封装为函数（对应 Bash 函数 章节的function nombre() { ... }写法）：

function habilitar_proteccion() { curl -X PATCH "https://api.cloudflare.com/client/v4/zones/${CF_ZONE_ID}/settings/security_level" \ -H "X-Auth-Email: ${CF_EMAIL_ADDRESS}" \ -H "X-Auth-Key: ${CF_API_KEY}" \ -H "Content-Type: application/json" \ --data '{"value":"under_attack"}' } function deshabilitar_proteccion() { curl -X PATCH "https://api.cloudflare.com/client/v4/zones/${CF_ZONE_ID}/settings/security_level" \ -H "X-Auth-Email: ${CF_EMAIL_ADDRESS}" \ -H "X-Auth-Key: ${CF_API_KEY}" \ -H "Content-Type: application/json" \ --data '{"value":"high"}' }

4. 用条件语句组装决策逻辑

主流程用if / else（对应 Bash 条件语句 章节）把负载判断与 API 调用串起来：

if [[ $(echo "${carga_1min} > ${vcpu}" | bc) -eq 1 ]]; then echo "⚠ 检测到高负载，正在启用 Cloudflare DDoS 防护..." habilitar_proteccion else echo "负载正常，确保 Cloudflare 防护处于正常级别..." deshabilitar_proteccion fi

注意：bc用于浮点数比较；若使用整数比较，可直接用[[ ${carga_1min} -gt ${vcpu} ]]。实际阈值建议结合服务器规格调优（例如负载达到 vCPU 数量的 80% 再触发）。

写完后给脚本添加 shebang 与执行权限，即可手动运行验证：

chmod +x protection.sh bash protection.sh

六、参考脚本：获取、配置与部署

原文档作者为本章准备了一个演示脚本protection.sh，托管在其配套仓库cloudflare-ddos-protection中。文档建议读者先自行尝试编写，再对照参考实现。获取方式如下：

wget <作者配套仓库中的 protection.sh 地址> -O protection.sh

下载后用编辑器打开查看内容：

nano protection.sh

然后把脚本开头的配置占位符替换为自己的 Cloudflare 信息（原文档示例，注意其中CF_CONE_ID是作者笔误，实际应为CF_ZONE_ID）：

CF_CONE_ID=TU_ID_DE_ZONA_DE_CLOUDFLARE CF_EMAIL_ADDRESS=TU_CORREO_ELECTRÓNICO_DE_LA_CUENTA_DE_CLOUDFLARE CF_API_KEY=TU_CLAVE_API_DE_CLOUDFLARE

接着赋予执行权限：

chmod +x ~/protection.sh

此时脚本已具备手动运行条件。若希望验证脚本语法质量，本仓库提供了 shellcheck-ebook.sh 工具脚本：它会提取电子书各章节中所有bash代码块并逐一运行 shellcheck 静态检查。参考实现通过set -euo pipefail等严谨写法，也体现了该工具倡导的脚本健壮性标准。

七、用 Cron 实现每 30 秒自动巡检

要让防护"自动"生效，需要定时调度。由于 Cron 的最小粒度是 1 分钟，原文档给出了经典的"两条 Cron 错峰 30 秒"技巧：第一条整分钟执行，第二条先sleep 30再执行，从而实现每 30 秒一次的巡检频率。

编辑 crontab：

crontab -e

并添加以下内容（务必把/ruta-al-script替换为脚本的真实存放路径）：

* * * * * /ruta-al-script/cloudflare/protection.sh * * * * * ( sleep 30 ; /ruta-al-script/cloudflare/protection.sh )

解释一下这两行的调度语义：

• 第一行：每分钟的第 0 秒执行一次脚本；
• 第二行：每分钟的第 0 秒先sleep 30，即每分钟的第 30 秒再执行一次。

两者错开，综合起来就是每 30 秒执行一次负载检查。本仓库的 shellcheck-ebook.sh 在扫描代码块时也会识别并跳过 crontab 语法行（其排除规则中明确包含SC2211 - glob used as command (crontab syntax lines)），说明这种 Cron 行属于配置片段而非可独立执行的 Bash 代码，部署时请原样写入 crontab 而不是 shell。

八、局限性与更稳健的替代方案

原文档在结论部分坦诚指出了这套方案的缺陷：

• 如果攻击导致服务器完全无响应，脚本可能根本来不及执行。DDoS 打到源站时，进程调度、命令执行都可能被拖垮，"自救"脚本在极端场景下会失效；
• 这是一种简单且低成本的解决方案，适合学习与轻量场景，但不适合作为生产环境的唯一防线。

更稳健的做法是引入独立于源站之外的监控系统（例如 Nagios），由监控系统持续采集统计指标，当指标异常时再由监控系统触发脚本或直接调用 Cloudflare API。这样即使源站失联，监控端依然能执行"开启防护"的动作。

此外，还可以把本章的 API 调用能力与本书后续章节组合出更丰富的自动化链路，例如：

• 用 jq 处理 JSON 解析 Cloudflare API 返回的success与errors字段，实现更可靠的重试与日志；
• 用 Bash 重定向 把 API 响应与错误输出写入日志文件，便于事后审计；
• 用 交互式菜单 把"查看 CPU 负载 / 开启防护 / 关闭防护"整合成一个管理员手动操作面板。

九、小结

本章是Introduction to Bash Scripting中"学以致用"的代表性章节：它把变量、条件、函数、Cron 调度等基础知识，落到了一个真实的运维痛点——DDoS 攻击下的自动防护——之上。核心要点可概括为：

1. 通过X-Auth-Email/X-Auth-Key认证，调用 Cloudflare v4 API 的zones/{zone_id}/settings/security_level接口，用under_attack值开启防护、用high等正常值恢复；
2. 用nproc与/proc/loadavg（或uptime）读取 CPU 负载，配合[[ ]]数值比较实现阈值判断；
3. 用两条 Cron 行错峰 30 秒，实现每 30 秒一次的自动巡检；
4. 清醒认识方案边界：源站失联时脚本可能失效，生产环境应配合 Nagios 等独立监控系统，或直接由监控端触发 API。

想继续深入，可以阅读本书后续章节，如 处理 JSON 的 jq 用法 与 Bash 重定向，把本章的 API 调用打磨成带日志、带错误处理的完整自动化组件。

【免费下载链接】introduction-to-bash-scriptingFree Introduction to Bash Scripting eBook项目地址: https://gitcode.com/GitHub_Trending/in/introduction-to-bash-scripting