Fail2ban与Nginx组合防御CC/DDOS攻击：从原理到实战配置

1. 项目概述：为什么Fail2ban+Nginx是应对CC/DDOS的经典组合

在运维和Web安全领域，CC攻击和DDOS攻击是两种最常见也最令人头疼的流量攻击形式。CC攻击，全称Challenge Collapsar，它模拟大量正常用户，高频访问服务器上消耗资源大的动态页面（比如搜索、登录、数据库查询），目的是耗尽服务器的CPU、内存或数据库连接池，让正常用户无法访问。而DDOS攻击，分布式拒绝服务攻击，则是通过海量僵尸网络发送巨量请求，直接堵塞服务器的网络带宽或耗尽连接数。很多刚接触服务器安全的朋友，面对这两种攻击时，第一反应可能是上硬件防火墙或者购买高防服务，成本高昂。实际上，对于中小型站点和业务，利用好手边的开源软件，比如Nginx和Fail2ban，就能构建一道非常有效的软件防线。

我管理过不少日PV百万级别的站点，早期也吃过不少亏。后来发现，一套配置得当的Nginx，配合上灵活的Fail2ban规则，足以应对90%以上的中低强度CC攻击和部分应用层DDOS攻击。这个组合的核心思路非常清晰：Nginx作为第一道关卡，利用其高性能和灵活的配置，对请求进行初步的过滤、限速和特征识别；Fail2ban则作为背后的“智能分析官”和“执行者”，它实时监控Nginx的访问日志，一旦发现符合攻击特征（比如单个IP在短时间内请求次数异常）的行为，就自动调用系统防火墙（如iptables或firewalld）将该IP封禁一段时间。这个流程形成了一个“监控-分析-处置”的自动化闭环，大大减轻了人工排查的压力。

这个方案特别适合那些已经使用了Nginx作为Web服务器或反向代理的团队。你不需要引入新的复杂组件，只是把现有的工具用得更加深入。接下来，我会从设计思路、具体配置、实战调优到问题排查，完整地拆解如何搭建和优化这套防御体系，其中会包含大量我踩过坑后才总结出的参数设置和规则写法。

2. 防御体系整体设计与核心思路拆解

在动手写配置之前，我们必须先理清防御的逻辑。盲目地封IP可能会误伤正常用户（比如公司出口IP或搜索引擎蜘蛛），而过于宽松的规则又会让攻击者轻易绕过。一个健壮的防御体系应该是分层、递进的。

2.1 理解攻击流量的分层过滤理念

我们可以把防御想象成一道有多层滤网的漏斗。最外层的滤网孔最大，用于过滤最明显、最粗粒度的异常流量；越往里，滤网越精细，处理的判断逻辑也越复杂。

1. 网络层/传输层过滤：这是最基础的一层，主要依靠系统防火墙（iptables/firewalld）或云服务商的安全组。Fail2ban最终的行动就是作用于这一层。它的优点是效率极高，直接丢弃数据包，对服务器资源消耗最小。但缺点是不够智能，一旦封禁，该IP的所有访问都会被阻断。
2. HTTP应用层过滤：这是Nginx的主战场。Nginx可以在处理HTTP/HTTPS请求时，根据URI、User-Agent、请求频率、连接数等维度进行判断和限制。这一层的规则可以非常灵活，例如只限制对/wp-login.php的频繁访问，而不影响网站其他页面的浏览。它的判断比单纯看IP更精准。
3. 业务逻辑层过滤：这一层需要应用程序（如你的PHP、Java代码）配合，例如增加图形验证码、短信验证码、请求令牌、行为分析等。这超出了本文范围，但它是防御高级CC攻击的最终手段。

我们的Fail2ban + Nginx方案，核心是打通了第2层和第1层。Nginx负责在第2层“发现”问题（通过日志记录异常行为），Fail2ban负责分析Nginx的日志，并将判定为攻击的IP“通知”第1层的防火墙执行封禁。

2.2 方案选型：为什么是Nginx日志+Fail2ban？

市面上也有一些其他的工具，比如mod_evasive（Apache模块）、ngx_http_limit_req_module（Nginx自带限流）。这里说说我的考量：

• Nginx自带限流模块：limit_req_zone和limit_conn_zone非常有用，我们一定会用。但它们主要是“限速”和“限制并发”，对于超出限制的请求，Nginx默认返回503错误。攻击者看到503，可能会换一种攻击模式继续试探。而Fail2ban的“封禁”是一种更严厉的惩罚，能给攻击者更强的反馈，使其IP暂时完全失效。
• Fail2ban的灵活性：Fail2ban的核心是其“过滤器”（filter）和“行动”（action）。过滤器基于正则表达式分析日志，这意味着你可以为不同类型的攻击编写不同的规则。例如，可以单独写一个规则来防御对登录页面的爆破，另一个规则防御扫描器。这种灵活性是单纯靠Nginx配置难以实现的。
• 资源消耗低：Fail2ban是Python写的守护进程，定期扫描日志文件尾部，资源占用极小。封禁动作调用的是系统防火墙，是内核层面的操作，效率极高。整个方案不会对Web服务的性能造成明显影响。
• 与现有设施无缝集成：不需要改动现有业务代码，只需要配置Nginx和安装一个Fail2ban，学习成本低，见效快。

注意：这个方案主要针对的是应用层（Layer 7）的DDOS和CC攻击。对于超大流量的网络层（Layer 3/4）DDOS攻击（比如SYN Flood、UDP Flood），其流量在到达Nginx之前就可能已经撑满了带宽，此时更需要运营商或云服务商提供的高防IP、流量清洗服务来应对。我们的方案是在攻击流量到达服务器并能够被Nginx记录日志后，才发挥作用。

3. Nginx核心安全配置详解与实操

Fail2ban依赖Nginx产生的高质量日志进行分析。因此，优化Nginx的配置，让它能更好地识别和记录可疑请求，是第一步，也是至关重要的一步。

3.1 关键模块配置：建立流量控制基线

Nginx有两个内置模块是我们防御体系的基石：ngx_http_limit_req_module（限制请求频率）和ngx_http_limit_conn_module（限制并发连接数）。我们需要在http块中定义共享内存区，然后在具体的server或location块中应用限制。

以下是一个整合的配置示例，我通常放在/etc/nginx/nginx.conf的http{ }块内：

http { # 定义限制请求速率的共享内存区和规则 # $binary_remote_addr 以二进制格式存储客户端IP，比字符串节省空间 # zone=perip:10m 定义了一个名为perip、大小为10MB的内存区，大约可存储16万个IP状态 # rate=10r/s 表示限制为每秒10个请求。超过此频率的请求将被延迟处理。 limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s; # 针对某些特别容易遭受攻击的路径，可以设置更严格的限制 # 例如，登录页面，我们单独定义一个更严格的zone limit_req_zone $binary_remote_addr zone=login:5m rate=2r/s; # 定义限制并发连接数的共享内存区 # zone=conn_limit_per_ip:10m 存储每个IP的并发连接数状态 limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m; # 其他http配置... server { listen 80; server_name yourdomain.com; # 应用全局请求频率限制（宽松） # burst=20 允许超过rate的请求排队，最多20个。nodelay表示对排队的请求立即处理，而不是按rate延迟。 limit_req zone=perip burst=20 nodelay; # 应用全局并发连接数限制 limit_conn conn_limit_per_ip 20; # 对登录页面应用更严格的频率限制 location /login { limit_req zone=login burst=5 nodelay; # ... 其他代理或fastcgi配置 } # 静态资源通常不需要严格限制，可以关闭或放宽限制 location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { limit_req off; limit_conn off; expires 30d; access_log off; # 静态资源访问日志也可以关闭，减少日志量 } # 最重要的：配置访问日志格式，加入更多信息供Fail2ban分析 # 这里定义了一个名为`main`的日志格式，包含了时间、IP、请求状态、请求时间等关键字段。 access_log /var/log/nginx/access.log main; } } # 在http块外（或内部）定义日志格式 log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" ' 'request_time=$request_time'; # 特别添加请求处理时间，用于判断慢速攻击

参数选择背后的逻辑：

• zone=perip:10m：10MB内存能存多少IP？Nginx中每个状态大约占用64字节（在64位系统上）。10MB / 64字节 ≈ 163,840个IP状态。对于大多数网站足够了。如果IP数非常多，可以适当增大。
• rate=10r/s：这个值需要根据你的服务器性能和页面类型调整。一个动态页面（如带数据库查询）可能1秒处理10个请求已经压力不小，而静态服务器可以设置得更高。从保守值开始，观察服务器负载再调整。
• burst=20：这是应对突发正常流量的缓冲池。比如，一个页面加载可能会同时发起对HTML、CSS、JS、多个图片的请求，这些请求在瞬间是并发的。burst允许这些请求先排队，而不是直接被拒绝。nodelay则让排队的请求立即被处理，而不是均匀地按rate处理，这对用户体验更好。
• request_time=$request_time：这个字段非常有用。CC攻击有时会使用慢速连接（Slowloris攻击），保持连接但不发送完整请求，以耗尽服务器的连接资源。记录请求处理时间可以帮助我们后期分析这类攻击。

3.2 日志格式优化与安全加固技巧

默认的Nginx日志格式信息不够丰富。为了给Fail2ban提供更好的“分析素材”，我们进行了增强。此外，还有一些立竿见影的安全小技巧：

1. 隐藏Nginx版本信息：在http块或server块中添加server_tokens off;。这可以防止攻击者通过版本信息寻找已知漏洞。
2. 限制HTTP请求方法：通常，普通浏览只需要GET和POST。可以在server块中添加：

   if ($request_method !~ ^(GET|HEAD|POST)$ ) { return 444; # Nginx特有的非标准状态码，直接关闭连接，不发送响应头。 }

3. 屏蔽特定User-Agent：很多扫描器和恶意爬虫有固定的User-Agent。可以建立一个黑名单：

   # 在http块中定义一个map map $http_user_agent $bad_bot { default 0; ~*(python-requests|Go-http-client|curl|wget|nikto|sqlmap) 1; # 可以不断添加已知的恶意UA } # 在server块中使用 if ($bad_bot) { access_log /var/log/nginx/badbot.log main; # 记录到单独日志 return 403; }

4. 对敏感路径的访问进行日志记录：将针对管理后台、API接口、登录页面等的访问记录到单独的日志文件，便于Fail2ban重点监控。

   location ~ ^/(admin|api/v1/secret) { access_log /var/log/nginx/sensitive_access.log main; # ... 其他配置 }

配置完成后，执行nginx -t测试配置语法，然后systemctl reload nginx重载配置。现在，Nginx已经具备了初步的流量整形和详细日志记录能力。

4. Fail2ban配置实战：从安装到自定义监狱规则

有了Nginx打下的基础，Fail2ban就可以大展拳脚了。它的工作流程是：读取日志 -> 匹配过滤器（正则）-> 达到阈值 -> 执行行动（封禁）。

4.1 Fail2ban安装与基础概念

在CentOS/RHEL系统上安装：sudo yum install epel-release -y && sudo yum install fail2ban -y在Ubuntu/Debian系统上安装：sudo apt update && sudo apt install fail2ban -y

安装后，主要的配置文件目录是/etc/fail2ban/。其中：

• jail.conf：这是主配置文件，但我们不要直接修改它，因为软件升级可能会覆盖它。
• jail.local：用户自定义的监狱配置文件，会覆盖jail.conf中的同名设置。我们在这里进行配置。
• filter.d/：存放各种过滤器（定义如何分析日志）的目录。
• action.d/：存放各种行动（定义封禁时具体执行什么命令）的目录。
• jail.d/：也可以在这里放自定义的.conf文件来启用监狱。

一个“监狱”（jail）就是一个完整的监控-封禁任务单元。它包含三个核心部分：

1. enabled：是否启用这个监狱。
2. filter：使用哪个过滤器（对应filter.d/下的文件）。
3. action：触发后执行哪个行动（对应action.d/下的文件，常用的是iptables或firewalld）。

4.2 编写针对Nginx的定制化监狱规则

Fail2ban自带了一些过滤器，比如nginx-http-auth用于监控登录失败，但针对CC攻击，我们需要更通用的规则。我们来创建两个最常用的自定义监狱。

第一步：创建自定义过滤器我们创建一个过滤器，用于识别在短时间内产生大量错误请求（如404、403）或请求频率过高的IP。

创建文件/etc/fail2ban/filter.d/nginx-cc.conf：

[Definition] # 关键：failregex 定义了匹配“一次失败”的正则表达式。 # 这里我们匹配状态码为 403, 404, 499（客户端提前关闭连接），以及请求时间超过5秒的请求（可能是慢速攻击）。 # 注意：日志格式必须和前面Nginx配置的`main`格式对应，特别是`request_time=`字段。 failregex = ^<HOST> -.*"(GET|POST|HEAD).*" (403|404|499) .*$ ^<HOST> -.*"(GET|POST|HEAD).*" .* request_time=[5-9]\d\.\d+.*$ # ignoreregex 可以忽略某些IP或请求，比如你自己的管理IP或健康检查请求 ignoreregex =

实操心得：failregex的编写是核心，也是最容易出错的地方。强烈建议先用fail2ban-regex命令进行测试。例如：fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-cc.conf。这个命令会详细展示有多少行日志被匹配，帮助你调试正则表达式。

第二步：创建自定义监狱配置我们不直接修改jail.local的全部内容，而是在jail.d/目录下创建单独的.conf文件，这样更清晰。

创建文件/etc/fail2ban/jail.d/nginx-cc.conf：

[nginx-cc] # 监狱名称 enabled = true port = http,https # 监控的端口，封禁时会同时封禁80和443 filter = nginx-cc # 使用我们上面创建的过滤器 logpath = /var/log/nginx/access.log # 要监控的日志路径 # 如果记录了敏感访问日志，可以同时监控多个日志文件 # logpath = /var/log/nginx/access.log /var/log/nginx/sensitive_access.log maxretry = 100 # 在“查找时间”内，允许的最大失败次数 findtime = 60 # 查找时间窗口，单位秒。这里意思是60秒内 bantime = 3600 # 封禁时间，单位秒。这里封禁1小时 # 重要：action是封禁后执行的操作。`action_`是带参数的行动。 # `iptables-multiport`是行动名，`[port="http,https", protocol=tcp]`是传给行动的参数。 action = iptables-multiport[port="http,https", protocol=tcp] # 可选：发送邮件通知 # sendmail-whois[name=nginx-cc, dest=your-email@example.com, sender=fail2ban@yourdomain.com]

参数调优经验：

• maxretry和findtime是黄金组合。maxretry=100和findtime=60意味着：如果某个IP在60秒内，触发了100次过滤器规则（即产生了100个匹配failregex的日志条目），则触发封禁。这个值不能设得太低，否则在促销活动或爬虫正常抓取时，可能误封。对于高流量站点，可以从200-300开始。
• bantime可以阶梯式增长。Fail2ban支持bantime.increment = true等配置，让屡次违规的IP被封禁时间指数级增长。这对于顽固的攻击者很有效。
• action：如果你用的是firewalld，可以改成action = firewallcmd-ipset。

第三步：创建针对特定URI高频访问的监狱（防爆破）比如，我们要重点保护/wp-login.php(WordPress) 或/admin/login。

创建过滤器/etc/fail2ban/filter.d/nginx-wp-login.conf：

[Definition] failregex = ^<HOST> -.*"POST /wp-login.php.*" 200 # 匹配对wp-login.php的POST请求且返回200（可能登录失败但仍返回200，或者探测请求） # 注意：更精准的规则可能需要结合cookie或特定参数，这里是一个简单示例。 ignoreregex =

创建监狱配置/etc/fail2ban/jail.d/nginx-wp-login.conf：

[nginx-wp-login] enabled = true port = http,https filter = nginx-wp-login logpath = /var/log/nginx/access.log # 登录页面要更敏感，阈值设低 maxretry = 10 findtime = 120 bantime = 86400 # 封禁一天 action = iptables-multiport[port="http,https", protocol=tcp]

4.3 启动、测试与监控Fail2ban

配置完成后，启动并设置开机自启：

sudo systemctl start fail2ban sudo systemctl enable fail2ban

使用以下命令监控Fail2ban的状态：

• sudo fail2ban-client status：查看所有启用的监狱。
• sudo fail2ban-client status nginx-cc：查看nginx-cc监狱的详细状态，包括当前被禁IP列表。
• sudo tail -f /var/log/fail2ban.log：实时查看Fail2ban的运行日志，观察匹配和封禁情况。

如何测试规则是否生效？你可以用一个简单的脚本，或者用curl命令，从另一台机器（或使用代理）短时间内快速访问你的服务器上一个不存在的页面（触发404），次数超过你设置的maxretry。然后观察fail2ban.log和sudo fail2ban-client status nginx-cc，看该IP是否被加入封禁列表。同时，从该IP尝试访问网站，应该会连接超时或被拒绝。

5. 高级调优与深度防御策略

基础配置只能应对常规攻击。面对更狡猾或更猛烈的攻击，我们需要更精细的策略。

5.1 应对分布式低频CC攻击

高明的攻击者可能会用成千上万个IP，每个IP在findtime内只发送maxretry-1次请求，这样就不会触发单个IP的封禁规则，但聚合起来依然能给服务器造成压力。这就是分布式低频CC攻击。

应对策略一：利用Nginx的limit_req_zone的zone容量限制。前面提到，zone=perip:10m只能存储约16万个IP的状态。如果攻击IP池大于这个数，最早的IP状态会被挤出，攻击者可以轮换使用IP。对于这种可能，我们可以适度增大zone容量，但更要结合业务。例如，一个正常的中文网站，其真实日活独立IP数是有上限的。如果你发现Nginx日志里短时间内出现了远超正常数量的独立IP，这本身就是一个强烈的攻击信号。

应对策略二：使用Fail2ban的recidive（累犯）监狱。Fail2ban自带一个[recidive]监狱，它不直接监控应用日志，而是监控Fail2ban自己的封禁日志(/var/log/fail2ban.log)。如果一个IP被多次封禁（即多次触发了其他监狱），recidive监狱会将其判定为“累犯”，并执行更长时间的封禁（比如一周或一个月）。这可以有效对付那些频繁更换IP段但行为模式固定的攻击者。

启用recidive监狱（通常在jail.local中已存在，只需启用）：

[recidive] enabled = true logpath = /var/log/fail2ban.log # 封禁策略：24小时内被ban超过2次，则封禁1周 maxretry = 2 findtime = 86400 # 24小时 bantime = 604800 # 1周 action = iptables-multiport[port="http,https", protocol=tcp]

5.2 动态调整与白名单机制

不能一封了之，误封正常用户（如公司网络、合作伙伴API、搜索引擎蜘蛛）后果很严重。必须建立白名单机制。

1. IP白名单（ignoreip）：在监狱配置或全局配置中，设置永远不会被封禁的IP。 在/etc/fail2ban/jail.local的[DEFAULT]部分或每个监狱中加入：

   ignoreip = 127.0.0.1/8 192.168.1.0/24 你的公网IP 搜索引擎IP段

   搜索引擎IP段需要查询各厂商公布的数据。

2. 基于DNS的反向查询白名单：对于动态IP的用户，可以通过其域名进行白名单。Fail2ban的action可以配置actionstart、actionstop等钩子，但实现较复杂。一个更简单的做法是，在Nginx层面，通过geo模块或map模块，将来自特定域名的请求设置一个变量，然后在Fail2ban的过滤器ignoreregex中忽略包含这个变量的日志行。

3. 人工审核与封禁列表管理：

   • fail2ban-client set <JAIL> banip <IP>：手动封禁一个IP。
   • fail2ban-client set <JAIL> unbanip <IP>：手动解封一个IP。
   • fail2ban-client set <JAIL> bantime <seconds>：动态调整某个监狱的封禁时间。

5.3 与云防火墙/安全组联动

如果你的服务器运行在云上（如AWS、阿里云、腾讯云），云平台的安全组是比服务器iptables更前一层的防火墙。Fail2ban可以通过自定义action来调用云厂商的API，直接将恶意IP添加到安全组的拒绝规则中。这样，攻击流量在进入你的服务器实例之前就被拦截了，效率更高。

这需要你编写一个自定义的action文件，放在action.d/目录下，里面使用Python或Shell脚本调用云API。由于各云厂商API不同，这里不展开具体代码，但思路是：在actionban部分执行添加安全组规则的API调用，在actionunban部分执行删除规则的API调用。然后将监狱的action指向你这个自定义的action。

6. 实战问题排查与性能监控指南

即使配置好了，也会遇到各种问题。以下是我总结的常见问题排查清单和监控方法。

6.1 常见问题速查表

6.2 性能监控与日志分析

防御系统本身也需要被监控。

1. 监控Fail2ban状态：使用Zabbix、Prometheus等监控系统，通过fail2ban-client status命令获取JSON输出，解析当前被禁IP数量、各个监狱的状态等，设置告警（如被封IP数突然激增）。
2. 分析Nginx日志：定期分析access.log，关注：
   • 请求频率分布：使用awk或GoAccess等工具，找出请求量最高的IP。
   • 状态码分布：404、403比例突然升高可能是扫描器。
   • 慢请求：request_time过高的请求，可能是慢速攻击或性能瓶颈。
3. 系统资源监控：关注服务器的CPU、内存、网络带宽和TCP连接状态。命令ss -ant | grep ESTAB | wc -l可以查看当前ESTABLISHED状态的连接数。如果连接数异常高，且netstat -an | grep :80 | wc -l也高，很可能正在遭受连接耗尽型攻击。

6.3 防御策略的迭代与更新

安全是一个持续的过程。你需要定期（比如每周）回顾Fail2ban的封禁日志(/var/log/fail2ban.log)和Nginx的访问日志。问自己几个问题：

• 被封禁的IP主要是哪些地区的？是否来自某个特定的ASN？可以考虑在Nginx层面或云防火墙层面直接屏蔽整个恶意IP段。
• 攻击模式是否有变化？例如，从攻击首页变成了攻击API接口。你需要为新的攻击路径创建新的Fail2ban监狱或Nginx限流规则。
• 是否有新的恶意User-Agent或扫描路径特征出现？及时更新Nginx的屏蔽规则。

最后，这套Fail2ban+Nginx的组合拳，是我在多年运维中验证过的、成本效益极高的防御手段。它不能解决所有安全问题，但足以构建起一道坚实的应用层防线，让你在面对大多数自动化攻击脚本和初级黑客时，能有充足的底气。记住，所有的安全配置都是一个平衡的艺术，需要在安全性、用户体验和运维复杂度之间找到最适合你当前业务的那个点。开始时保守一点，慢慢观察、调整、迭代，你的服务器就会越来越稳固。