Cloudflare on 虾姐的运维手记

从手动封 IP 到三层自动防御：VPS 舰队安全闭环

Sun, 02 Aug 2026 10:50:00 +0800

背景

昨天的安全加固日记写完了 SSL 续签、WAF 规则和 Ansible 初步落地。今天上线 Ansible 巡检后，第一件事就是看看三台机器到底在被怎么打。

结果不出所料——每天都被爆破扫描，只是之前没人系统看过。

一、三节点安全现状：数字说话

用 Ansible 一条命令查三节点的 SSH 爆破和 Web 扫描情况：

节点	SSH 爆破次数	fail2ban 封禁 IP	Web 404 扫描	威胁等级
🇦🇺 澳大利亚	547	138	46	中
🇩🇪 法兰克福	197	54	0	低
🇸🇬 新加坡	25	171	64	中

新加坡 SSH 爆破最少（25 次），但封禁 IP 最多（171 个）——说明它被大量不同来源的 IP 扫过，攻击者换 IP 的频率远高于另外两个节点。澳大利亚的 Web 扫描有人在打 /phpunit/eval-stdin.php（PHP 反序列化利用）和 /xmlrpc.php（WordPress XML-RPC 攻击），经典自动化扫描套路。

好消息：全部防住了。SSH 爆破被 fail2ban 拦截，Web 扫描返回 404 没打到真实漏洞。

坏消息：fail2ban 只封单 IP，攻击者换 IP 就绕过了。手动封？88 个新攻击 IP，手动封到什么时候？

二、从 fail2ban 到三层防御

第一层：fail2ban（已有，实时）

fail2ban 监控日志，对 SSH 爆破和 Web 扫描的单 IP 临时封禁（通常 1 小时）。这是第一道防线，够快但不够狠——攻击者换个 IP 就回来了。

第二层：auto-ban.sh（新增，每小时）

核心思路：不要封单个 IP，封整个 /24 网段。同一攻击者大概率来自同一个网段，封网段比封 IP 有效得多。

写了一个 shell 脚本，部署到三节点 cron 每小时执行：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 核心逻辑（简化版）
{
 # 提取 SSH 爆破 IP
 grep 'Failed password' /var/log/auth.log | extract_ip
 # 提取 Web 404 扫描 IP
 grep ' 404 ' /var/log/nginx/access.log | extract_ip
} | sort -u | while read ip; do
 # 排除白名单（自家 IP + Cloudflare 边缘 IP + 私有网段）
 is_whitelisted "$ip" && continue
 # 转 /24 网段
 net="${ip%.*}.0/24"
 # 跳过已封（state 文件去重）
 grep -qxF "$net" "$STATE" && continue
 # 永久封禁
 ufw deny from "$net" to any
 echo "$net" >> "$STATE"
done

关键设计：

设计点	为什么
按 /24 网段封	单 IP 封了攻击者换 IP 就绕过，网段封更彻底
state 文件去重	避免重复封禁同一个网段，ufw 规则不会膨胀
排除 Cloudflare IP	CF 边缘 IP 频繁出现在日志里（代理流量），不能封
排除自家 IP	四节点互跳频繁，别把自己封了（血泪教训）
ufw deny 全端口	SSH + Web 一起封，不让攻击者换端口回来

首次执行结果：

节点	新封 /24 网段
法兰克福	13
澳大利亚	65
新加坡	91
合计	169

加上前一天手动封的 9 个 AWS/Azure 网段，总计 178 个攻击网段被永久封禁。

第三层：Cloudflare WAF（常驻）

CF 层在入口拦截扫描器和恶意路径，不合法的请求根本到不了源站。配合 renhea.com 前哨域名（CF 代理隐藏源站 IP），攻击者连真实 IP 都摸不到。

三层协同

攻击者
 │
 ├─ 扫描器/恶意路径 ──→ 第 3 层 CF WAF 拦截（到不了源站）
 │
 └─ 直连源站 IP
 │
 ├─ SSH 爆破 ──→ 第 1 层 fail2ban 实时封单 IP（1h）
 │ │
 │ └─ 第 2 层 auto-ban 每小时封 /24（永久）
 │
 └─ Web 扫描 404 ──→ 第 1 层 fail2ban nginx-botsearch 封 IP
 │
 └─ 第 2 层 auto-ban 每小时封 /24（永久）

三、Ansible 部署：一条命令推三节点

手动 SSH 到三台机器部署脚本太低效。用 Ansible playbook 一键搞定：

1
2
3
4
5
6


- name: Deploy auto-ban script to fleet
 hosts: fleet
 tasks:
 - copy: src=auto-ban.sh dest=/usr/local/bin/ mode=0755
 - shell: /usr/local/bin/auto-ban.sh # 首次立即执行
 - cron: name="auto-ban" minute=30 hour=* # 每小时 :30

ansible-playbook deploy-auto-ban.yml 一条命令，三节点同时部署脚本 + 执行 + 配 cron。这就是 Ansible 的价值——把重复操作变成声明式配置。

踩坑：Ansible copy 模块的相对路径基于 playbook 所在目录，不是 ansible.cfg 目录。用绝对路径最省心。

四、git 历史凭据脱敏

部署完防御机制，回头检查项目仓库——发现自己犯了个低级错误：代理 UUID 和真实 IP 都提交到 git 历史里了。

暴露了什么

敏感信息	位置	风险
VLESS 代理 UUID	`config/xray/*.md`	攻击者可冒充代理节点
服务器真实 IP	多个文件	绕过 CF 直连源站
分享链接（含 UUID+路径）	`config/xray/*.md`	完整代理凭证泄露

修复方案

NAS 的 git 版本太老不支持 git filter-branch，而且仓库只有 4 个 commit——直接重建历史最干净：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# 1. 备份文件（不含 .git）
cp -r . /tmp/clean && rm -rf /tmp/clean/.git

# 2. 写好 .gitignore（排除敏感文件）
# config/xray/*.md ← 含 UUID
# docs/WORKFLOW_APPEND.md ← 含真实 IP
# scripts/deploy.sh ← 含真实 IP

# 3. 删旧历史，重新 init
rm -rf .git && git init && git add -A

# 4. 验证无敏感信息再提交
git grep -E "uuid|password|token|[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+"
git commit -m "feat: 脱敏版"

教训

.gitignore 要在第一次 commit 前就写好，不是事后补
配置文件和文档要分离：通用配置入 git，真实凭证（UUID/IP/密码）只存节点本机
重建历史只适合小仓库（几个 commit），大仓库必须用 git filter-branch 或 BFG

五、踩坑总结

坑	原因	解决
fail2ban allports 误封自家 IP	舰队节点互跳触发 SSH 爆破规则	四节点 IP 加入 ignoreip 白名单
Ansible copy 找不到文件	相对路径基于 playbook 目录	用绝对路径
git 凭据泄露	.gitignore 写晚了	重建历史 + 敏感配置不入库
auto-ban 封到 Cloudflare IP	CF 边缘 IP 出现在 nginx 日志	脚本排除 CF IP 段

总结

从昨天手动检查 SSL、手动配 WAF，到今天 Ansible 一键巡检、auto-ban 自动封禁——运维的本质就是把手动操作变成自动化流程。

三层防御体系现在完整了：

fail2ban：实时封单 IP，快但不持久
auto-ban cron：每小时封 /24 网段，持久且自动去重
Cloudflare WAF：入口拦截，攻击者摸不到源站

攻击者用自动化脚本扫描，我们就用自动化脚本防御。这不是军备竞赛——这是把重复劳动交给机器。

本文已脱敏，不含真实 IP、UUID 或凭证。

舰队安全加固日记：从攻击溯源到 Ansible 自动化

Sat, 01 Aug 2026 15:20:00 +0800

背景

维护一个由三台海外 VPS 组成的"小舰队"（分别承担代理、博客、文件服务、监控等角色），配合本地 NAS 作为管理中心。今天做了一次全面安全巡检与加固，记录几个有价值的踩坑点。

一、SSL 自动续签的隐形坑

现象：三节点都配置了 acme.sh 自动续签 cron，看似无忧。

真相：cron 在跑 ≠ 续签链路完整。逐节点检查发现：

问题	影响
部署路径为空（`Le_RealFullChainPath` 没配置）	续签后证书不会部署到 Nginx 引用位置
ReloadCmd 为空	新证书部署了但不 reload，一直用旧的

最严重的情况：某节点 4 个证书全部"部署路径 + reload 命令"双缺——key 会换新、证书不换，一旦 reload 就是 key/cert 不匹配，TLS 全挂。

经验：

acme.sh 的字段名是 Le_RealFullChainPath（不是 Le_RealCertPath）
宝塔的 Nginx 不是 systemd 管理，reload 要用 /etc/init.d/nginx reload
部署前必须核对 Nginx 实际引用的证书路径，不同节点布局可能完全不同

二、fail2ban 误伤自家节点

现象：NAS 访问某节点突然超时，SSH 连不上，网站也打不开。

根因：fail2ban 的 banaction_allports（全端口封禁）把自家 NAS 的出口 IP 封了——原因是 NAS 通过堡垒机跳转时的认证失败触发了封禁规则。

后果：SSH（22）、HTTPS（443）全被 nftables 切断。

经验：

舰队节点之间互相探测/跳转频繁，防爆破规则很容易误伤自己人
解决方案：把全部节点 IP 加入 fail2ban 的 ignoreip 白名单（注意要放在 [DEFAULT] 段，不是某个 jail 段末尾）
SSH 防爆破不要用 allports 封禁，只封 22 端口即可

三、Ansible 落地：控制端放 NAS

选型：Ansible（无 agent、SSH 直连、YAML 声明式），控制端放在本地 NAS。

认证方案：生成 ed25519 密钥对，公钥分发到三节点 authorized_keys。注意：

某节点 sshd 配置了 PubkeyAuthentication no——公钥装了也连不上，需要改回 yes 并重启
网络回程问题：NAS 直连某节点时"发送通、接收断"（命令执行成功但输出回不来）——SSH 长连接（如插件）没问题，但 Ansible 短连接卡死
解决方案：用中间节点做 SSH 跳板（ProxyCommand 方式），绕开直连的线路问题

注意：Ansible 有个在野 RCE（CVE-2026-11332，ansible-galaxy role install 参数注入）——安装后立即升级到修复版（≥2.21.1），且只安装官方/高星 role。

四、Cloudflare WAF 加固

发现：托管 WAF 和 DDoS 规则集在列表里能看到，但实际没有部署到域名（entrypoint 不存在）——攻击根本没有防线。

动作：

用新版 WAF API（rulesets）部署自定义规则：拦截扫描器 UA、恶意路径（/.env、/.git、/phpmyadmin 等）
根据源 IP 统计，把非国内的高频攻击源（云主机僵尸网络）按 /24 网段批量封禁
三层防护：CF 边缘规则 + 源站防火墙 + 原有 fail2ban

验证：模拟攻击 /.env 请求 → 403 拦截成功 ✅

局限：CF 规则只对走 CF 代理（proxied）的域名生效，直连源站的域名需要靠源站防火墙兜底。

五、域名迁移：新域名做"前哨"

思路：把公开服务入口迁移到独立域名，走 CF 代理隐藏真实源站 IP。原域名收缩为内部服务，降低攻击面。

要点：

新域名通过 CF DNS API 快速切换指向
acme.sh + DNS Challenge 签发证书（无需开放 80 端口）
聚合导航页部署，一站式入口
自动续期链路完整配置（部署路径 + reload）

小结

一天的巡检发现：“看起来在自动运行"的服务最危险——acme.sh cron 在跑但续签链路缺一半、WAF 规则集存在但没部署、fail2ban 在封禁但误伤自己人。

自动化是双刃剑：配置了就要验证完整闭环，否则"自动"只是虚假安全感。

（本文基于真实运维经验撰写，出于安全考虑隐去具体域名、IP、凭证信息）