cdn节点代理的副作用@fail2ban对接cdn封锁恶意请求ip@fail2ban封锁ip有效性问题

文章目录

    • [使用cdn代理后`iptables` 封禁ip失效的原因](#使用cdn代理后iptables 封禁ip失效的原因)
      • [1. 流量被 CDN 拦截](#1. 流量被 CDN 拦截)
      • [2. 封禁了 CDN 节点](#2. 封禁了 CDN 节点)
    • [应对 CDN 代理下的恶意 IP](#应对 CDN 代理下的恶意 IP)
      • [1. 使用 Fail2ban + Real IP+CDN api](#1. 使用 Fail2ban + Real IP+CDN api)
      • [2. 利用 CDN 平台的 WAF/防火墙](#2. 利用 CDN 平台的 WAF/防火墙)
    • fail2ban对接cloudflare管理ip封锁行为

使用cdn代理后iptables 封禁ip失效的原因

iptables 是在您的 源站服务器 的网络层(Netfilter/防火墙)执行规则。当您的网站使用 CDN 时,数据流向发生了根本性的变化:

1. 流量被 CDN 拦截

当恶意 IP 尝试访问您的网站时,它不是直接连接到您的服务器,而是连接到 CDN 的边缘节点
恶意 IP(A) → 连接 公网 CDN 边缘节点IP (B) → 回源 内网/专线 您的源站服务器 \text{恶意 IP(A)} \xrightarrow\\text{连接}{\text{公网}} \text{CDN 边缘节点IP (B)} \xrightarrow\\text{回源}{\text{内网/专线}} \text{您的源站服务器} 恶意 IP(A)公网 连接CDN 边缘节点IP (B)内网/专线 回源您的源站服务器

  • iptables 看到谁?
    • 您的服务器收到的所有请求,其源 IP 地址都是来自 CDN 的边缘节点的 IP 地址(IP B)。
    • 您在 iptables 中设置的封禁规则是针对特定的 恶意 IP A
  • 封禁无效:
    • 当恶意 IP A 发送请求时,请求被 CDN 接收。
    • CDN 节点 B 将请求转发给您的源站。
    • 您的源站的 iptables 看到的源 IP 是 CDN 节点 B 的 IP,而不是恶意 IP A。
    • CDN 节点 B 的 IP 不在您的封禁列表内,所以请求被放行。
  • 结果: 恶意 IP A 仍然可以通过 CDN 节点 B 访问您的网站。

2. 封禁了 CDN 节点

如果用户在cdn代理的使用上有点经验,那么可能会意识到nginx中日志如果要看到用户的真实ip,需要X-Forwarded-For解析

但如果没有做此真实ip解析许多操作,比如nginx限流配置就会失效(限制的是cdn节点,而不是真实用户ip,导致限流效果不理想或者不生效,这是一种严重的错误)

此外,如果你还在未解析真实ip处理就执行fail2ban封锁失败请求ip,问题会更加糟糕,这时服务器iptables封禁的是cdn的节点ip,可能导致所有用户无法访问你的网站

此外,即便nginx中配置了真实ip解析,那么nginx限流这类配置可以生效,但是fail2ban封锁ip工作原理和nginx限流不同,iptables在流量进来时,看到的是cdn的节点ip,无法分辨真实ip,只能将日志文件(比如nginx日志)中的对应ip做封锁,但这是不够的,还必须cdn层面做相应的封锁

应对 CDN 代理下的恶意 IP

由于 CDN 充当了"中间人",网络层的 IP 封禁(如 iptables)不再有效。您必须将封禁操作提升到 应用层 或利用 CDN 平台本身的功能

1. 使用 Fail2ban + Real IP+CDN api

以nginx服务器搭建的网站为例

  • 步骤 1:配置 Nginx Real IP。 让 Nginx 能够识别 X-Forwarded-For 等头部中的真实恶意 IP,并将其写入日志。
  • 步骤 2:Fail2ban 读取真实 IP。 Fail2ban 读取日志中的真实 IP,并执行封禁操作。
  • 步骤 3:封禁执行在哪里? Fail2ban 的默认动作是调用 iptables。然而,由于 iptables 只能看到 CDN IP,所以此处的 iptables 封禁依然无效。

关键的弥补措施:

  • 修改 Fail2ban 动作 (Action): 不要只让 Fail2ban 调用 iptables,而是让它调用一个脚本,该脚本通过 CDN 提供的 API 将恶意 IP 提交给 CDN 的防火墙。fail2ban的action.d模板目录中提供了cloudflare.conf,可以基于此填写api key和cf邮箱,对接到cloudflare api

2. 利用 CDN 平台的 WAF/防火墙

成熟的CDN平台一般也提供了灵活的安全规则和检测条件配置,可以不需要更改服务器配置实现恶意ip封锁

但是部分服务可能需要收费,站点数量多的话,批量操作要借助api

  • 操作位置: 在您的 CDN 服务商的管理控制台(例如 Cloudflare 的 WAF、阿里云 CDN 的安全配置等)。
  • 操作方式:
    • 手动封禁: 直接在 CDN 控制台的 IP 阻止列表中添加恶意 IP。
    • 自动封禁: 许多 CDN 平台提供自动化的 Web 应用防火墙 (WAF)Bot 管理 服务,它们可以根据访问频率、请求特征、地理位置等,在 CDN 边缘自动阻止恶意流量,根本不让流量到达您的源站。

fail2ban对接cloudflare管理ip封锁行为

本节讨论如何在同一个服务器上对接1个或多个cloudflare的fail2ban规则(主要是action定义和jail中对相应action的引用

重点是在action.d目录中创建和编辑合适的配置文件,不过大多数需求这个配置文件内容比较简单,并且如果是需要对接多个cloudflare账号,且需求类似,只需要复制对应数量的配置文件(但是注意不要复制完整的cloudflare.conf,而是包含关键信息(比如cf密钥和邮箱)的.local文件),然后做更改(主要是不同cloudflare账号的key和email信息)

这些.local可用通过[INCLUDES]引用cloudflare.conf

ini 复制代码
# cloudflare-i.conf
# 引用 fail2ban自带action模板中的cloudflare.conf 文件,并填写你的 Cloudflare API Key 和 Email
[INCLUDES]
before = cloudflare.conf

[Init]

# 不要有多余的引号,这反而会影响配置的解析(填写的时候注意顺序,key和email不要反了)
cftoken = YOUR_CF_API_KEY

cfuser = YOUR_CF_EMAIL

其次是在定义jail的文件中(根据用户的实际情况,可能放在/etc/fail2ban/jail.local或者/etc/fail2ban/jail.d/your_jail.local)这里后缀推荐是.local便于和fail2ban自带模板配置文件冲突或者混淆,也不容易被更新覆盖

相关推荐
乘云数字DATABUFF4 天前
5分钟部署开源APM Databuff:OpenTelemetry全链路追踪入门实战
运维·后端
荣--6 天前
一键部署不是为了省时间 —— 它是把"买来的 PaaS"变成"自己的平台"的拐点
运维·zabbix·工程化·一键部署·平台化·边界设计
江华森6 天前
动手实战学 Docker — 从零到集群编排完全指南
运维
Avan_菜菜6 天前
FRP 内网穿透完整实战:从 HTTP 映射到 HTTPS 自签代理
运维·nginx·https
SelectDB7 天前
Litefuse 开源并推出单进程轻量模式,25 秒就能跑起来的 Agent 可观测与评估平台
运维·后端·自动化运维
XIAOHEZIcode9 天前
Linux系统鼠标偏移常见原因以及修复方案
linux·运维·游戏
用户0328472220709 天前
如何搭建本地yum源(上)
运维
大树8812 天前
金刚石散热越强,管路越先见顶
大数据·运维·服务器·人工智能·ai
摇滚侠12 天前
Linux CentOS7 rpm 安装 MySQL 5.7
linux·运维·mysql
霸道流氓气质12 天前
领域驱动设计(DDD)在 Spring Boot 微服务中的实践指南
运维·spring boot·微服务