iptables可临时封禁高频请求ip，通过-m recent --rcheck --seconds 60 --hitcount 100实现60秒内新建连接超100次即drop，需置于input链靠前位置并配合日志分析与fail2ban自动联动。

怎么用 iptables 临时封禁高频请求的 ip

内网没 waf，又得快速止血，iptables 是最直接的选择。关键是不能只看单次连接数，得统计单位时间内的请求数——否则正常爬虫或批量导出也会被误杀。

• 用 iptables -A INPUT -m state --state NEW -m recent --name BADIPS --rcheck --seconds 60 --hitcount 100 -j DROP 实现“60 秒内新建连接超 100 次即拉黑”
• --rcheck 比 --update 更稳妥：它只检查是否已存在记录，不刷新时间戳，避免高频请求不断续命
• 封禁规则必须加在 INPUT 链靠前位置，否则可能被已有 ACCEPT 规则提前放行
• 别忘了加一条 -A INPUT -m recent --name BADIPS --rsource --remove 在日志规则之后，方便后续分析时清除误判

nginx 日志怎么实时识别异常拉取行为

光靠连接数不够，真实的大批量拉取往往藏在 HTTP 层：比如同一 IP 短时间刷 /api/export?date=2024-01-01 到 /api/export?date=2024-01-31 这类规律性 URL。

• 用 awk '{print $1,$7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20 快速看 Top IP+路径组合
• 重点盯 $request_time 小但 $body_bytes_sent 大的请求——说明服务端快速返回了大量数据，不是慢攻击而是真在“搬数据”
• 如果用了 log_format 自定义日志，务必包含 $http_user_agent 和 $http_referer，有些内网工具（如 Python requests）默认 UA 极简，容易漏判

流量监控和封禁怎么自动联动（不用写脚本）

手动查日志 + 手动 iptables 封 IP，响应太慢。用 fail2ban 是最省事的折中方案，它本质就是把日志匹配和封禁动作串起来。

知周AI笔记

一款本地轻量级markdown AI笔记软件

下载

• 在 /etc/fail2ban/jail.local 里加一段：

  [nginx-bulk-export]
  enabled = true
  filter = nginx-bulk-export
  logpath = /var/log/nginx/access.log
  maxretry = 5
  bantime = 3600
  findtime = 300

• 对应写一个 /etc/fail2ban/filter.d/nginx-bulk-export.conf，用正则匹配高频导出路径，例如：failregex = ^<host>.*"(GET|POST) /api/export\?.* HTTP/1\.1" 200</host>
• 注意 findtime 和 maxretry 要匹配业务节奏：内网导出通常 5 分钟内不会超过 5 次，设太宽松就形同虚设

为什么封了 IP 还有流量进来

常见不是规则没生效，而是流量根本没走你设规则的那台机器。

• 确认请求路径：是直连后端服务？还是经过了负载均衡（如 LVS、F5）或 API 网关？封错节点等于白干
• 检查连接复用：keepalive 会让多个请求复用一个 TCP 连接，iptables 的 --state NEW 就会漏掉后续请求
• 内网 DNS 缓存或客户端长连接池可能导致 IP “换马甲”：同一个用户从不同出口 IP 发起请求，得结合 User-Agent 或 token 做二次识别
• 别忽略 UDP 流量——有些导出接口走的是自研 UDP 协议，iptables 默认不处理，得额外加 -p udp

实际跑起来最麻烦的从来不是封 IP，而是分清“谁在拉”“拉什么”“从哪拉”。日志字段不全、代理透传丢失真实 IP、业务方自己开了多线程导出却没限速——这些比技术方案更拖慢响应。