我正在运行的环境是一个大规模的网络托管业务（管理着数百台服务器，几乎所有公共地址等——所以任何关于管理 ADSL 链接的事情都不太可能运作良好），而且我们'正在寻找可以轻松管理核心规则集（目前 iptables 中约有 12,000 个条目）以及我们为客户管理的基于主机的规则集的东西。我们的核心路由器规则集每天更改几次，而基于主机的规则集可能每月更改 50 次（在所有服务器上，因此可能每月每五台服务器更改一次）。
我们目前正在使用 filtergen（一般是球，在我们的运营规模下是超级球），过去我在其他工作中使用过shorewall（这比 filtergen 更可取，但我认为必须比那更好的东西）。
我们为任何替代系统提出的“必须”是：
- 必须相当快地生成规则集（在我们的规则集上运行 filtergen 需要 15-20 分钟；这简直太疯狂了）——这与下一点有关：
- 必须生成一个 iptables-restore 样式文件并一次性加载，而不是为每个规则插入调用 iptables
- 在重新加载规则集时，不得长时间关闭防火墙（同样，这是上述几点的结果）
- 必须支持 IPv6（我们不会部署任何不兼容 IPv6 的新内容）
- 必须不含 DFSG
- 必须使用纯文本配置文件（因为我们通过版本控制运行所有内容，并且使用标准 Unix 文本操作工具是我们的 SOP）
- 必须同时支持 RedHat 和 Debian（首选打包，但至少不能公然反对任何一个发行版的标准）
- 必须支持运行任意 iptables 命令以支持不属于系统“本机语言”的功能
任何不符合所有这些标准的东西都不会被考虑。以下是我们的“锦上添花”：
- 应该支持配置文件“片段”（即你可以把一堆文件放到一个目录中，然后对防火墙说“把这个目录中的所有东西都包含在规则集中”；我们广泛使用配置管理，希望使用这个特性来自动提供服务特定规则）
- 应该支持原始表
- 应该允许您在传入数据包和 REJECT 规则中指定特定的 ICMP
- 应该优雅地支持解析为多个 IP 地址的主机名（我们已经用 filtergen 被这个主机名捕获了几次；这是一个相当大的痛苦）
- 该工具支持的可选/奇怪的 iptables 功能（本机或通过现有或易于编写的插件）越多越好。我们时不时地使用 iptables 的奇怪功能，而且“正常工作”的功能越多，对每个人都越好。
如果您可能想从规则驱动的方法转变为“描述所需的最终状态”的做事方式，请查看 fwbuilder。
优点：
缺点：
链接：http ://www.fwbuilder.org
自己写。说真的 - 在这个规模上这是合理的。
使用ipset和/或大量 iptable 表/子表。尽可能只重新加载一些子表/一些 ipset 集 - 这将加快重新配置。
可能您已经这样做了，但仍然值得一提 - 使用嵌套表来减少路由器上的负载和数据包建立新连接所需的平均查找次数。显然 -A FORWARD -m state --state ESTABLISHED,RELATED 是您的最高规则。
圣球（让主题保持活力！）伙计……12,000 条核心规则？
我假设您已经考虑了所有简单的选项，例如将集合放入 CVS？木偶还是CFengine？
老实说，从您给出的广泛概述来看，我强烈建议您重新评估您的网络设计。我可能有点过于简单化了，但我根本无法理解需要 12k iptables 规则的设计。这听起来确实像是从 SLB 类型的解决方案中受益的东西，而不是管理防火墙规则的更好方法。
在旁注中，如何添加评论而不是添加“答案”？
12000条规则？你疯了？您不会因为进行如此多的过滤而遇到性能问题吗？我不明白你为什么需要 12,000 条规则？您如何验证您的规则集实际上正在执行该策略？
政策是什么？
你如何测试你的政策？
12,000 条规则可能会破坏书中的每条安全规则。
您还可以尝试使用 SAAS 解决方案来管理 iptables -> https://www.efw.io/Forum它也可以进行 AWS 云集成。