Fail2ban中nftables与iptables防火墙规则差异解析

在Linux服务器安全防护领域，Fail2ban作为一款经典的入侵防御工具，其与系统防火墙的交互机制值得深入探讨。本文将通过一个典型案例，剖析Fail2ban在不同防火墙后端下的工作表现差异。

现象观察

管理员在Ubuntu 22.04系统上部署Fail2ban 0.11.2后，发现SSH防护模块显示已封禁大量IP（超过14000个），但在iptables规则中却找不到预期的f2b-sshd链。这种看似矛盾的现象其实揭示了防火墙后端的配置差异。

技术原理

Fail2ban支持多种防火墙后端，主要包括：

1. 传统iptables：

   • 自动创建f2b-链
   • 在INPUT链中插入跳转规则
   • 每个封禁IP生成独立规则

2. 现代nftables：

   • 使用集合(Set)存储封禁IP
   • 创建完整表结构(inet f2b-table)
   • 通过一条规则引用整个IP集合

问题诊断

通过关键命令分析可确定真实后端：

fail2ban-client -d | grep -E 'sshd.*action'

输出显示实际使用的是nftables-multiport动作，这解释了为何iptables中无对应规则。

解决方案

对于使用nftables后端的系统，应检查nft规则集：

nft list ruleset

预期可见以下结构：

• inet f2b-table表
• f2b-chain链
• addr-set-sshd集合（包含所有被封禁IP）

最佳实践建议

1. 混合环境注意：当系统同时启用iptables和nftables时，需明确Fail2ban配置的banaction参数

2. 性能优化：

   • nftables的集合特性更适合大规模封禁
   • 避免使用永久封禁(bantime=-1)，建议设置递增封禁时间

3. 配置规范：

   • 避免直接修改jail.conf，应使用jail.local覆盖配置
   • 对于Docker环境需特别设置chain参数

深度解析

nftables相比iptables的优势在该案例中充分体现：

• 存储效率：万级封禁IP仅需一个集合条目
• 查询性能：哈希查找比线性遍历更高效
• 原子操作：IP增删不影响现有流量处理

理解这种底层机制差异，有助于管理员更准确地监控Fail2ban的运行状态，避免因工具认知偏差导致的安全盲区。对于从传统iptables迁移到nftables的环境，这一认知尤为重要。