linux账户级锁定（如pam_faillock）作用于用户而非ip，真正实现ip级自动封禁需结合fail2ban：它解析/var/log/auth.log或secure中的失败日志，提取ip并调用iptables/nftables封禁；pam_faillock负责用户侧防撞库，fail2ban负责网络侧防暴力探测，二者协同构成分层防御。
Linux 本身不直接“锁定 IP”，账户级失败锁定（如 pam_faillock）作用对象是用户，不是 IP 地址。真正实现“IP 级自动封禁”的，必须靠日志分析工具联动防火墙，最常用、最成熟的组合是：pam_faillock + fail2ban。
为什么 pam_faillock 不能锁 IP？
pam_faillock 是 PAM 模块，运行在认证流程中，它只感知“哪个用户”在“本次请求”中失败了，不记录、也不识别源 IP —— 因为 SSH 连接建立后，PAM 认证阶段通常已丢失原始 TCP 层的客户端地址（尤其在有代理、NAT 或负载均衡时）。它的计数单位是“用户失败次数”，存储在 /var/run/faillock/ 下按用户名命名的文件里。
所以，单独配置 pam_faillock 只能做到：
- 同一用户 60 秒内输错 5 次密码 → 账户被锁 15 分钟（该用户无法用任何方式登录，无论从哪个 IP）
- 但攻击者换一个 IP、换一个用户，照样能继续暴力探测
fail2ban 是怎么把“用户失败”变成“IP 封禁”的？
fail2ban 的核心逻辑是：持续扫描系统认证日志（/var/log/auth.log 或 /var/log/secure），从中提取包含“Authentication failure”“Failed password”等关键词的行，并解析出其中的 用户名 和 IP 地址。一旦发现某 IP 在指定时间窗口内触发了足够多的失败事件，就调用 iptables 或 nftables 命令，临时添加一条拒绝该 IP 访问 SSH 端口的规则。
关键点：
- 它不依赖 PAM 模块是否启用，只要日志里有记录，就能捕获
- 默认监控的是
sshd日志段，但也可扩展监控sudo、postfix、nginx等任意服务日志 - 封禁动作发生在网络层，对所有端口生效（可配置仅限 22 端口）
实战配置：pam_faillock + fail2ban 协同工作
这不是二选一，而是分层防御：
-
第一层（用户侧）：用
pam_faillock防止同一账户被撞库成功（例如员工密码泄露后被反复试） -
第二层（网络侧）：用
fail2ban防止单个 IP 对多个账户发起大规模探测
配置步骤简明如下：
- 确认
pam_faillock已启用（如在/etc/pam.d/sshd或/etc/pam.d/password-auth中添加三行标准配置），确保失败日志写入auth.log - 安装 fail2ban：
apt install fail2ban（Debian/Ubuntu）或yum install fail2ban（RHEL/CentOS） - 复制默认 jail 配置：
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local - 编辑
/etc/fail2ban/jail.local，启用并调优 sshd 规则：[sshd] enabled = true filter = sshd logpath = /var/log/auth.log # Debian/Ubuntu # logpath = /var/log/secure # RHEL/CentOS maxretry = 5 findtime = 600 # 10 分钟内达 5 次即封 bantime = 3600 # 封禁 1 小时
- 重启服务：
systemctl restart fail2ban
验证与排查要点
别只看配置文件是否保存，要确认真实生效：
- 用错误密码从测试机 SSH 登录目标服务器 5 次，等待 10 秒后再次尝试 → 应直接超时或拒绝连接（不是密码错提示）
- 执行
fail2ban-client status sshd查看当前封禁 IP 列表 - 检查
iptables -nL INPUT | grep 22或nft list chain inet fail2ban filter_sshd，确认规则已插入 - 若未封禁，用
fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf测试日志正则是否能正确匹配失败行
