Fail2ban 通过自定义 error log（如 attack.log）配合精准 failregex（如匹配 wp-login 444 请求）识别异常，需独立配置 jail 并确保日志权限、SELinux 和 iptables 服务正常。
Fail2ban 怎么识别 Nginx 的 404/403/502 等异常请求
Fail2ban 本身不解析日志语义，它靠 failregex 正则匹配日志行。Nginx 默认 access log 不记录状态码触发条件（比如暴力扫后台），必须用 error log 或自定义 access log 格式。更稳妥的做法是让 Nginx 在 error log 中显式记录可疑行为，例如在 location 块里用 log_subrequest on，或通过 return 444 + error_log 主动打点。
常见误操作：直接监控 /var/log/nginx/access.log 并写个匹配 404 的正则——这会把正常爬虫、死链、前端资源 404 全封掉。真正该抓的是高频 403（如 /wp-login.php）、重复 502（后端崩了但攻击者还在猛刷）、或带恶意路径的 444 日志。
- 推荐在 Nginx 配置中加：
error_log /var/log/nginx/attack.log warn;，再用map或if把特定 UA、路径、频率异常的请求重定向到 444 并记入该文件 -
failregex示例（匹配 444 请求）：^<host> -.*"(GET|POST) .*(wp-login|xmlrpc|shell\.php).*" 444</host> - 务必用
fail2ban-regex实时验证：fail2ban-regex /var/log/nginx/attack.log /etc/fail2ban/filter.d/nginx-bad-request.conf
怎么写一个只封 IP 不碰 SSH 的 Nginx 专用 jail
默认的 [sshd] jail 会干扰运维，Nginx 防御必须独立配置，且禁用对 SSH 端口的操作。关键在 jail.local 里声明新 jail，并明确指定 action 只调用 iptables-multiport 封应用层端口（如 80/443），而非全局 iptables-allports。
容易踩的坑：没设 enabled = true，或写了 port = http,https 却忘了在 action 里传参，导致封错端口；还有人用 ufw action，但在非 Ubuntu 系统上会失败。
- 在
/etc/fail2ban/jail.local加： [nginx-bad-request]enabled = truefilter = nginx-bad-requestlogpath = /var/log/nginx/attack.logport = http,httpsaction = iptables-multiport[name=nginx, port="http,https", protocol=tcp]maxretry = 5findtime = 600bantime = 3600
为什么 fail2ban 启动后不封 IP？检查这三处
最常卡在日志权限、SELinux 和 systemd 依赖上。Fail2ban 进程默认以 fail2ban 用户运行，若 /var/log/nginx/attack.log 所属为 root:adm 且权限是 640，它根本读不了——不是报错，而是静默跳过。
- 执行
ls -l /var/log/nginx/attack.log，确保组为adm且fail2ban用户在该组：usermod -a -G adm fail2ban - 检查 SELinux：
ausearch -m avc -ts recent | grep fail2ban，若有拒绝记录，临时关 SELinux 测试：setenforce 0 - 确认
iptables-services（CentOS）或netfilter-persistent（Debian）已启用，否则iptables-multiportaction 会失败且无提示 - 用
fail2ban-client status nginx-bad-request查看是否在监控、当前 ban 数、日志路径是否被识别
封禁后怎么验证真实生效且不影响健康检查
封 IP 是瞬时的，但 iptables 规则不会自动加注释，下次重启 fail2ban 或服务器可能丢失规则。更重要的是，某些云厂商（如 AWS ALB、腾讯云 CLB）的健康检查源 IP 是固定段，若误封会导致服务被判定为宕机。
- 手动测试封禁：
fail2ban-client set nginx-bad-request banip 192.168.1.100，再查 iptables：iptables -L f2b-nginx-bad-request -n - 加白名单防误伤：
ignoreip = 127.0.0.1/8 10.0.0.0/8 192.168.0.0/16（填你自己的 LB 或监控 IP 段） - 长期封禁需持久化：
iptables-save > /etc/sysconfig/iptables（CentOS）或用iptables-persistent（Debian） - 别依赖
bantime = -1永久封——它只是“重启前有效”，真要永久得配合外部脚本写入黑名单文件并 reload
实际部署时，error log 打点粒度、failregex 宽严程度、以及和现有 WAF（如 ModSecurity）的职责边界，才是最难调的地方。
