怎么在Linux利用Fail2ban监控Nginx报错日志实现应用层自动防御-linux运维-PHP中文网

fail2ban 通过自定义 error log（如 attack.log）配合精准 failregex（如匹配 wp-login 444 请求）识别异常，需独立配置 jail 并确保日志权限、selinux 和 iptables 服务正常。

怎么在linux利用fail2ban监控nginx报错日志实现应用层自动防御

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 系统上会失败。

Linux installer

先解析安全源，运行本地CLI安装、启动、卸载Linux桌面应用。用户请求时使用。

下载

在 /etc/fail2ban/jail.local 加：
[nginx-bad-request]
enabled = true
filter = nginx-bad-request
logpath = /var/log/nginx/attack.log
port = http,https
action = iptables-multiport[name=nginx, port="http,https", protocol=tcp]
maxretry = 5
findtime = 600
bantime = 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-multiport action 会失败且无提示
用 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）的职责边界，才是最难调的地方。