1. 项目概述为什么Nginx防火墙是运维的“硬通货”最近和几个做运维的朋友聊天发现一个挺有意思的现象面试的时候但凡问到Web服务安全面试官总会拐弯抹角地探探你对Nginx防火墙配置的深浅。是让你手写个简单的deny规则还是让你聊聊怎么防CC攻击基本就能判断出你是“背题选手”还是真有实战经验。这也难怪Nginx作为流量入口它的安全配置就像是自家大门的锁配得不好家里再豪华也白搭。今天我就结合自己踩过的坑和总结的经验聊聊怎么给Nginx配上一套既智能又实用的“门禁系统”——实现IP自动封禁和CC攻击防护。这不仅仅是应付面试更是日常运维中保障服务稳定性的基本功。所谓IP自动封禁核心思想是“事不过三”。对于那些在短时间内频繁恶意请求的IP地址系统能自动识别并将其加入黑名单在一段时间内拒绝其所有访问。而CC攻击防护则是应对一种更“狡猾”的攻击方式。CC攻击不像DDoS那样用海量流量冲垮带宽而是模拟大量正常用户高频地请求网站中那些消耗资源大的动态页面比如搜索、登录接口目的是耗尽服务器的CPU、内存或数据库连接资源导致真正的用户无法访问。这两种防护机制结合起来才能构建起一道有效的应用层防线。这套配置方案特别适合中小型Web项目、API服务以及那些暂时没有部署专业WAFWeb应用防火墙的团队。它不依赖于额外的硬件或昂贵的商业软件完全利用Nginx自身的模块和简单的脚本就能实现相当程度的主动防御。接下来我会从设计思路开始一步步拆解如何实现并分享几个我实践中总结的、文档里不会写的关键技巧和避坑指南。2. 核心防护策略与架构设计2.1 策略分层从边界到核心的纵深防御在设计Nginx防火墙时最忌讳的就是把所有规则都堆在location /里。一个清晰的、分层的策略架构不仅能提高规则的可读性和可维护性更能提升防护效率。我的思路通常是分为三层第一层全局IP黑名单最快拦截这一层放在Nginx配置的最外层http块使用geo和map模块。它的目标是拦截那些已知的恶意IP段、数据中心IP或通过其他渠道如威胁情报获取的攻击源。这一层的规则判断速度最快因为geo模块的数据在Nginx启动时就加载到内存中对每个请求的匹配开销极低。适合封禁长期、大范围的恶意IP。第二层动态IP限流与封禁核心逻辑这是实现“自动封禁”的核心层主要依靠limit_req限制请求频率和limit_conn限制并发连接数模块。我们通过为特定的location如登录、搜索、提交表单的接口设置严格的频率限制。当某个IP触犯规则时Nginx会返回503或429状态码。但仅仅返回错误码不够我们需要一个“监工”通常是lua脚本或外部程序来监控Nginx的日志一旦发现某个IP频繁返回这些错误码就将其IP自动写入黑名单配置文件并触发Nginx重载配置。第三层关键位置精细防护CC攻击重点关照针对最容易遭受CC攻击的动态页面或API接口实施更严格的策略。例如对/api/login、/search等URL设置比网站首页/严格得多的频率限制。同时可以结合验证码、令牌等手段在限流触发后对用户进行二次验证。这一层的配置需要业务逻辑的配合。2.2 模块选型为什么是limit_req和geoNginx内置的模块很多为什么首选limit_req_zone和geo来实现这个方案limit_req_zone模块是防CC攻击的利器。它基于“漏桶算法”工作你可以把它想象成一个底部有固定小孔的水桶。请求就像水流进桶里桶的容量burst参数决定了能暂存多少突发请求而水从孔流出的恒定速率rate参数就是服务器允许的处理速率。超过桶容量的请求会直接溢出被拒绝。这种算法能平滑突发流量精确控制请求速率非常适合防御那种每秒发起数百次相同请求的CC攻击。geo模块则是一个高效的地理IP分类和黑白名单工具。它最大的优势是性能。geo指令块内定义的IP列表会在Nginx启动时被编译成一个高效的内存查找结构通常是CIDR前缀树这使得即使面对数万条IP规则对单个请求的匹配判断也几乎不消耗时间。相比之下如果在location里用大量的if ($remote_addr x.x.x.x) { deny all; }性能会急剧下降因为每个if判断都是顺序执行的。注意网上有些教程会教你在location里用if配合$binary_remote_addr做判断这在规则很少时没问题但一旦规则上百条绝对会成为性能瓶颈。务必使用geo或map模块来管理IP列表。2.3 自动封禁的闭环设计“自动”二字是关键我们不能总靠人工去看日志加黑名单。一个完整的自动封禁闭环需要三个角色协同规则执行者Nginx通过limit_req等模块定义“什么行为是异常的”如每秒请求超过10次。行为记录者Access LogNginx需要将触发限流的请求返回429或503状态码详细记录下来包括IP、时间、URI。决策执行者外部脚本一个定时任务如Cron定期如每分钟扫描最近的日志分析每个IP触发限流的次数。如果某个IP在短时间内如5分钟触发次数超过阈值如10次则判定为恶意IP将其追加到geo黑名单配置文件中并执行nginx -s reload使新配置生效。同时这个脚本还应该负责“解封”即一段时间如1小时后后将IP从黑名单文件中移除。3. 核心配置解析与实操要点3.1 构建全局IP黑名单库首先我们创建一个独立的黑名单配置文件比如/etc/nginx/conf.d/ip_blacklist.conf。这样做的好处是规则独立方便管理和脚本自动化修改。# /etc/nginx/conf.d/ip_blacklist.conf geo $blacklist_ip { default 0; # 默认值为0代表不在黑名单 # 以下是手动添加的永久黑名单IP或网段 192.168.1.100 1; 10.0.0.0/8 1; # 封禁整个10.0.0.0/8网段 # 注意后续脚本自动添加的IP也会被放在这个区域 }这里用geo创建了一个变量$blacklist_ip。如果客户端IP匹配到上面的规则变量值就被设为1否则为0。geo模块支持CIDR格式如/24/16非常方便。接着在主配置文件或http块中利用map模块将这个变量转换为一个更直观的变量比如$is_denied。# 在主nginx.conf的http块内 http { include /etc/nginx/conf.d/ip_blacklist.conf; # 引入黑名单 map $blacklist_ip $is_denied { 0 ; # 不在黑名单变量为空 1 1; # 在黑名单变量为1 } # 其他配置... }最后在server块的开头根据$is_denied变量来决定是否拒绝访问server { listen 80; server_name yourdomain.com; # 全局黑名单拦截 - 放在最前面效率最高 if ($is_denied) { return 403; # 或者444直接关闭连接 } # ... 其他location配置 }实操心得return 444是Nginx的一个非标准状态码意思是“无响应并关闭连接”。对于明确的攻击IP用444比403更好因为它不返回任何数据包能节省一点点带宽并且让攻击者更难以判断防火墙规则。3.2 配置CC攻击防护请求限流接下来是防御CC攻击的核心——请求限流。我们在http块中定义一个共享内存区用来存储所有客户端的请求状态。http { # 定义限流规则。$binary_remote_addr以二进制形式存储IP比字符串节省空间。 # zonereq_per_ip:10m 定义了一个10MB大小的内存区名为req_per_ip用来存储键值IP是键。 # rate10r/s 表示限制每秒10个请求。 limit_req_zone $binary_remote_addr zonereq_per_ip:10m rate10r/s; # 可选针对特定URI如登录设置更严格的限制 limit_req_zone $binary_remote_addr zonelogin_per_ip:10m rate2r/s; server { listen 80; server_name yourdomain.com; # ... 之前的黑名单判断 location / { # 应用限流 # zonereq_per_ip 使用上面定义的规则。 # burst20 允许超过rate的突发请求数超过20后的请求才会被直接拒绝或延迟处理。 # nodelay 对于burst范围内的请求立即处理不延迟。如果没有nodelayburst的请求会被延迟处理以平滑流量。 limit_req zonereq_per_ip burst20 nodelay; # 当请求被拒绝时返回429状态码Too Many Requests limit_req_status 429; # 你的正常代理或root配置 root /var/www/html; index index.html; } location /api/login { # 对登录接口使用更严格的限制 limit_req zonelogin_per_ip burst5 nodelay; limit_req_status 429; # ... 你的代理配置 } } }关键参数解读10m内存区能存储多少状态大约可以处理16万个独立IP地址的状态估算公式10MB * 1024KB/MB * 1024B/KB / 64字节每IP ≈ 16.8万。对于绝大多数网站足够了。rate10r/s这个值需要根据你的服务器性能和页面类型调整。静态页面可以高一些如50r/s动态API尤其是数据库查询一定要设低如2-5r/s。burst20这是应对正常用户突发流量的缓冲池。比如用户刷新页面可能会瞬间产生几个并发请求。burst允许这些请求排队等待处理而不是直接被拒绝。nodelay参数让这些排队请求立即被处理而不是等待这对用户体验更友好但会瞬间消耗更多资源需权衡。3.3 记录“案发现场”配置日志格式要让自动封禁脚本工作我们必须让Nginx把触发限流的请求记录下来。我们需要修改日志格式添加关键信息。http { log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for 限流状态$limit_req_status; # 新增字段记录限流状态 access_log /var/log/nginx/access.log main; }这个$limit_req_status变量在请求通过限流检查时为空当请求被拒绝时其值为我们设置的limit_req_status如429。这样我们的脚本就可以通过筛选日志中状态码为429的记录来找到“罪犯”IP。4. 实现自动封禁的“大脑”监控脚本配置好了规则生效了接下来就是实现自动化。这里提供一个用Shell脚本实现的简单但可靠的方案。脚本思路定期分析过去几分钟的Nginx日志统计每个IP触发429状态的次数超过阈值就封禁。4.1 脚本编写与部署创建一个脚本文件例如/usr/local/bin/nginx_auto_ban.sh#!/bin/bash # 自动封禁触发Nginx限流规则的IP # 作者你的名字 # 使用前请根据实际情况修改以下变量 # 可配置参数 LOG_FILE/var/log/nginx/access.log # Nginx访问日志路径 BLACKLIST_FILE/etc/nginx/conf.d/ip_blacklist.conf # 黑名单配置文件 TEMP_BLACKLIST_FILE/tmp/nginx_blacklist_temp.conf # 临时黑名单文件用于去重排序 NGINX_RELOAD_CMD/usr/sbin/nginx -s reload # Nginx重载命令 CHECK_INTERVAL_MINUTES5 # 检查过去多少分钟内的日志 BAN_THRESHOLD10 # 同一IP在检查周期内触发429的次数阈值 BAN_DURATION_HOURS1 # 封禁时长小时 # # 获取当前时间戳秒 NOW$(date %s) # 计算检查时间点CHECK_INTERVAL_MINUTES分钟前 CHECK_TIME$(date -d -${CHECK_INTERVAL_MINUTES} minutes %d/%b/%Y:%H:%M:%S 2/dev/null || date -v-${CHECK_INTERVAL_MINUTES}M %d/%b/%Y:%H:%M:%S) echo [$(date %Y-%m-%d %H:%M:%S)] 开始分析日志时间范围${CHECK_TIME} 之后 # 1. 分析日志找出触发429的IP及其次数 # 使用awk高效处理筛选包含“限流状态429”且时间在CHECK_TIME之后的日志行然后统计每个IP的出现次数 IP_TO_BAN$(awk -v check_time$CHECK_TIME BEGIN { # 将月份缩写转换为数字用于时间比较这里简化处理依赖日志时间格式严格 month_map[Jan]1; month_map[Feb]2; month_map[Mar]3; month_map[Apr]4; month_map[May]5; month_map[Jun]6; month_map[Jul]7; month_map[Aug]8; month_map[Sep]9; month_map[Oct]10; month_map[Nov]11; month_map[Dec]12; } # 匹配限流状态429的行 /限流状态429/ { # 提取日志时间格式如[02/May/2023:14:30:25 log_time substr($4, 2) # 去掉开头的[ # 简单字符串比较如果日志时间晚于传入的CHECK_TIME则计数 # 注意此比较基于字符串字典序要求日期格式完全一致dd/mmm/yyyy:HH:MM:SS if (log_time check_time) { ip_count[$1] # $1是remote_addr } } END { for (ip in ip_count) { if (ip_count[ip] $BAN_THRESHOLD) { # 这里使用shell变量传入阈值 print ip } } } $LOG_FILE) # 2. 如果没有需要封禁的IP则退出 if [ -z $IP_TO_BAN ]; then echo 未发现需要封禁的IP。 exit 0 fi echo 发现需要处理的IP echo $IP_TO_BAN # 3. 读取现有的黑名单文件准备生成新文件 # 先复制原始黑名单文件中geo块之前的内容如果有的话 touch $BLACKLIST_FILE $TEMP_BLACKLIST_FILE # 确保文件存在 $TEMP_BLACKLIST_FILE # 清空临时文件 # 假设黑名单文件结构简单geo块从geo $blacklist_ip {开始 # 我们提取这个标记之前的所有内容通常是注释或配置头 HEADER$(sed /^geo \$blacklist_ip {/Q $BLACKLIST_FILE 2/dev/null) if [ -n $HEADER ]; then echo $HEADER $TEMP_BLACKLIST_FILE fi # 4. 写入新的geo块开始标记 echo geo \$blacklist_ip { $TEMP_BLACKLIST_FILE echo default 0; $TEMP_BLACKLIST_FILE # 5. 合并现有黑名单IP排除过期项和本次需要封禁的IP # 先收集所有需要写入的IP用关联数组去重bash 4.0 declare -A ALL_IPS # 读取现有黑名单文件中的IP规则行格式如 192.168.1.1 1; while read -r line; do # 匹配IP/网段规则行排除注释和default行 if [[ $line ~ ^[[:space:]]*([0-9]{1,3}(\.[0-9]{1,3}){3}(/[0-9]{1,2})?)[[:space:]]1\; ]]; then ip_cidr${BASH_REMATCH[1]} # 这里简化处理不判断过期。实际可扩展在行尾添加时间戳如 1 # 1683000000 ALL_IPS[$ip_cidr]1 fi done (sed -n /^geo \$blacklist_ip {/,/^}/p $BLACKLIST_FILE 2/dev/null) # 添加本次需要封禁的IP并记录封禁时间写入注释 BAN_EXPIRE_TS$((NOW BAN_DURATION_HOURS * 3600)) while read -r ip; do # 避免重复添加 if [ -z ${ALL_IPS[$ip]} ]; then ALL_IPS[$ip]1 echo 新增封禁IP: $ip 解封时间: $(date -d $BAN_EXPIRE_TS %Y-%m-%d %H:%M:%S) fi done $IP_TO_BAN # 6. 将所有IP已去重按数字顺序排序后写入临时文件 # 排序有助于提高geo模块的查找效率可选但推荐 printf %s\n ${!ALL_IPS[]} | sort -t . -k 1,1n -k 2,2n -k 3,3n -k 4,4n | while read -r ip_cidr; do echo $ip_cidr 1; $TEMP_BLACKLIST_FILE done # 7. 写入geo块结束标记 echo } $TEMP_BLACKLIST_FILE # 8. 用临时文件替换原黑名单文件 if mv $TEMP_BLACKLIST_FILE $BLACKLIST_FILE; then echo 黑名单文件更新成功。 # 9. 重新加载Nginx配置 if $NGINX_RELOAD_CMD; then echo Nginx配置重载成功。 else echo 警告Nginx配置重载失败请手动检查 2 exit 1 fi else echo 错误更新黑名单文件失败 2 exit 1 fi echo [$(date %Y-%m-%d %H:%M:%S)] 自动封禁脚本执行完毕。4.2 脚本关键逻辑与使用说明日志时间处理脚本使用awk分析日志。这里的时间比较log_time check_time基于字符串字典序要求Nginx日志时间格式如02/May/2023:14:30:25与脚本生成的格式完全一致。这是一种简单有效的过滤近期日志的方法。去重与合并脚本使用Bash的关联数组(declare -A)来合并现有黑名单和本次要封禁的IP确保IP不重复。排序对IP地址进行数字排序后写入虽然geo模块不要求排序但有序的列表在维护和查看时更清晰。封禁时效当前脚本版本将新封禁的IP永久写入直到手动移除或被解封脚本移除。更完善的版本应该在每个IP规则后面添加注释记录封禁时间并另写一个“解封脚本”定期清理过期的IP。上述脚本中BAN_DURATION_HOURS变量和相关的解封逻辑需要你自行扩展。权限与路径确保脚本有执行权限(chmod x /usr/local/bin/nginx_auto_ban.sh)并且所有文件路径日志、配置文件都正确。4.3 设置定时任务使用crontab -e命令添加一行定时任务让脚本每分钟执行一次* * * * * /usr/local/bin/nginx_auto_ban.sh /var/log/nginx_auto_ban.log 21这样脚本就会每分钟检查一次过去5分钟内的日志自动封禁恶意IP。5. 高级优化与深度防护技巧基础的配置和脚本已经能应对大部分场景但要做得更专业、更稳健还需要一些进阶技巧。5.1 利用map实现更灵活的黑白名单geo模块是静态的而map模块可以实现动态的、基于其他变量的黑白名单。例如我们可以根据User-Agent来封禁一些恶意的爬虫或扫描器。http { map $http_user_agent $bad_bot { default 0; ~*(python-requests|Go-http-client|curl|wget|nikto|sqlmap) 1; # 匹配常见扫描工具UA ~*(AhrefsBot|SemrushBot) 1; # 匹配某些SEO爬虫 } server { ... # 在黑名单判断后加入坏爬虫判断 if ($bad_bot) { # 可以记录到特殊日志或直接返回403 access_log /var/log/nginx/bad_bot.log main; return 403; } ... } }注意事项map的匹配是顺序执行的直到第一个匹配成功为止。所以要把最具体、最可能匹配到的规则放在前面。另外过度依赖User-Agent拦截容易被绕过应作为辅助手段。5.2 连接数限制 (limit_conn) 作为补充CC攻击可能也伴随着大量并发连接。limit_conn模块可以限制单个IP的同时连接数。http { # 定义连接数限制的共享内存区 limit_conn_zone $binary_remote_addr zoneconn_per_ip:10m; server { ... location / { limit_conn conn_per_ip 20; # 每个IP同时最多20个连接 limit_req zonereq_per_ip burst20 nodelay; ... } location /download/ { # 对于下载目录可以放宽连接数限制但限制请求速率 limit_conn conn_per_ip 50; limit_req zonereq_per_ip burst10 nodelay; ... } } }limit_conn对于防止某些长连接攻击如慢速攻击很有效。但要注意对于通过公网NAT出口访问的用户比如一个公司的员工都用一个公网IP这个限制可能会误伤正常用户。5.3 应对高级CC攻击验证码挑战最狡猾的CC攻击会模拟正常用户使用不同的IP并以较低的频率请求绕过简单的频率限制。这时就需要在应用层进行干预。一个常见的策略是“验证码挑战”。思路当Nginx发现某个IP在敏感接口如/api/login上请求频率略高于正常阈值但又不至于直接封禁时可以将其重定向到一个返回429状态码并携带一个“验证码挑战页面”URL的响应。前端收到429后弹出验证码让用户完成验证通过后再继续操作。这需要前后端配合Nginx配置对/api/login的limit_req设置一个较低的rate如5r/s和较小的burst如3。后端提供一个生成和验证验证码的接口。前端拦截429响应调用验证码接口并展示给用户。用户输入验证码后前端带着验证码令牌重新发起原请求。这种方案实现成本较高但防护效果非常好能有效区分机器和真人。5.4 日志分析与监控告警自动封禁脚本是“事后处理”我们还需要“事前预警”。可以通过监控Nginx的error.log其中会记录被限流拒绝的连接或分析access.log中429状态码的比例来设置告警。例如使用Zabbix、Prometheus配合nginx-lua-prometheus模块或简单的logtail脚本# 每分钟检查一次过去1分钟内429状态码的数量 COUNT$(tail -n 1000 /var/log/nginx/access.log | grep -c \ 429 \) if [ $COUNT -gt 50 ]; then echo 警告过去1分钟内发现 $COUNT 次限流拦截可能存在CC攻击 | mail -s Nginx CC攻击预警 adminyourdomain.com fi6. 常见问题、排查技巧与性能调优6.1 配置不生效按这个顺序排查语法检查任何修改后第一件事是运行nginx -t。如果报错仔细检查括号、分号、文件路径。配置重载语法检查通过后执行nginx -s reload。仅仅修改配置文件不会生效必须重载。查看错误日志如果重载失败或生效后有问题第一时间查看Nginx错误日志/var/log/nginx/error.log。验证黑名单在服务器上用curl -I http://localhost从本机测试或者用tail -f /var/log/nginx/access.log实时观察日志看黑名单IP的请求是否被正确拦截返回403或444。验证限流使用工具如ab或wrk对某个接口进行压测观察是否返回429状态码以及日志中是否记录了限流状态429。6.2 性能影响评估与调优很多人担心加这么多规则会影响Nginx性能。实际上合理配置下影响微乎其微geo/map模块数据在内存中是O(log n)级别的查找效率上万条规则对性能的影响也几乎可以忽略。limit_req/limit_conn模块会在共享内存中进行原子计数操作这是非常快的。主要的开销在于为每个请求分配和查找对应的计数器。在极端高并发下每秒数十万请求可能会成为瓶颈。这时可以考虑增大共享内存区zonereq_per_ip:20m确保内存足够存储所有活跃IP的状态。调整限流维度如果不必须按IP限流可以按$server_name或$request_uri来划分zone减少键的数量。升级硬件CPU性能直接影响这些模块的处理速度。一个简单的压测对比在一台2核4G的云服务器上对配置了包含5000条IP黑名单和请求限流的Nginx与未配置任何规则的Nginx进行wrk压测100并发持续30秒其QPS每秒查询率下降通常不超过5%。这个损耗对于安全收益来说是完全可以接受的。6.3 误封怎么办—— 白名单机制自动封禁最怕误伤。务必为你的办公室IP、公司VPN IP、重要的API调用方IP等设置白名单。白名单的优先级应该高于黑名单和限流规则。http { # 白名单 - 放在黑名单前面定义 geo $whitelist_ip { default 0; 你的办公室公网IP/32 1; 你的云服务器IP段 1; } map $whitelist_ip $is_allowed { 1 $binary_remote_addr; # 如果是白名单$is_allowed值为客户端IP 0 ; # 非白名单则为空 } # 黑名单定义略... server { ... # 先判断白名单 if ($is_allowed) { # 白名单IP跳过所有限制 break; } # 再判断黑名单 if ($is_denied) { return 403; } # 最后应用限流规则 location / { limit_req zonereq_per_ip burst20 nodelay; ... } ... } }通过if ($is_allowed) { break; }白名单IP的请求会跳过后续的所有limit_req和黑名单判断。break指令在这里用于终止当前阶段的处理防止后续的if判断继续执行。6.4 应对分布式CC攻击如果攻击者使用成千上万个不同的IP僵尸网络进行低频率请求单IP限流就会失效。这时策略需要升级限制总并发连接数在http块使用limit_conn_zone $server_name zonetotal_conn:10m;然后在server块使用limit_conn total_conn 1000;来限制整个站点的总连接数。限制总请求速率类似地可以定义一个基于$server_name的limit_req_zone限制整个服务器每秒处理的总请求数。启用Nginx缓存对于攻击者频繁请求的动态页面如果内容更新不频繁可以设置proxy_cache或fastcgi_cache将结果缓存起来。这样即使请求打到Nginx也无需转发给后端应用服务器极大减轻后端压力。寻求外部帮助当攻击规模超出单台服务器防御能力时应考虑使用云服务商提供的DDoS/CC防护如阿里云DDoS高防、腾讯云大禹、CDN如Cloudflare的Under Attack模式或专业的WAF服务。最后再分享一个我自己的习惯每次更新Nginx安全配置后不是马上reload而是先在一个测试环境或者用nginx -t严格测试然后用一个保底的crontab任务每隔5分钟检查一次Nginx是否在运行如果挂了就自动重启并告警。因为一个错误的配置可能导致Nginx启动失败线上服务就中断了。这个简单的监控能为你争取到宝贵的修复时间。防火墙配置是运维的盾牌既要锋利也要握得稳。