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自带模板配置文件冲突或者混淆,也不容易被更新覆盖

相关推荐
西幻凌云1 小时前
了解计算机网络的“物理根基”——物理层与数据链路层
网络·网络协议·计算机网络·数据链路层·物理层
q***04632 小时前
Linux环境下Tomcat的安装与配置详细指南
linux·运维·tomcat
好奇的菜鸟2 小时前
在 WSL 中安装 Docker
运维·docker·容器
x***44012 小时前
linux 设置tomcat开机启动
linux·运维·tomcat
2301_804947582 小时前
nginx的https的搭建
运维·nginx·https
K***43062 小时前
httpslocalhostindex 配置的nginx,一刷新就报404了
运维·nginx
正在努力的小河2 小时前
Linux 块设备驱动实验
linux·运维·服务器
h***67373 小时前
Prometheus(普罗米修斯)----- Nginx监控
运维·nginx·prometheus
颜颜yan_3 小时前
基于CANN多Stream异步执行的智能推理管道:突破传统串行瓶颈
运维·架构·stream·昇腾·cann