moo*_*ick 2 performance firewall
我很好奇使用负匹配与正匹配是否会影响netfilter堆栈的性能。例如iptables -I INPUT -p tcp -s 192.168.0.0/16 -j DROP相当于iptables -I INPUT -p tcp !-s 192.168.0.0/16 -j ACCEPT在性能方面？
有人告诉我，负匹配可能会产生更差的性能，但我认为没有任何事实支持；据我所知，匹配迭代次数（即规则）对性能的影响最大。不幸的是，我手头没有可以测试该假设的测试设置。
我问这个问题的原因是我工作的公司使用许多小型（在规模和计算能力方面）MikroTik 路由器，我正在尝试提出合理的最佳实践防火墙策略。显然 RouterOS 是这些路由器附带的专有操作系统 MikroTik，基于 Linux 内核 2.6.16，所以我相信 vanilla 2.6.16 内核的限制也适用于那里。由于声称表现存在差异的人是我的老板，我想确保我可以安全地忽略这种说法。
我的第一直觉是，在你的例子中，你的规则的成本和复杂性是相同的，哪个更好是个人偏好和其他任何事情一样。反演一般不会像 netfilter 中的匹配规则那样复杂。
普遍的共识似乎是，规则的数量和顺序对于最佳性能比如何制定单个规则更重要，尽管您也可以从中获益。
Linux netfilter 防火墙通常在第一次匹配的基础上运行，并且每个链中的规则都是按顺序处理的，因此在匹配之前需要处理的规则越少，您的性能就越高。
这就是大多数防火墙配置具有以下内容的原因：-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT作为第一条规则。通常，该单一规则与相当繁忙的站点上的大部分流量相匹配。（在所有流量的 99% 以上...）
现在，仅针对新连接触发和处理剩余的防火墙规则，从而显着减少了所需的处理量。
由于规则是按顺序处理的，从性能的角度来看，按规则被触发的可能性对规则进行排序是有意义的。
例如，在网络服务器上，绝大多数流量都在默认的 HTTP 端口上。因此，像-A INPUT -p tcp -m state --state NEW -m multiport --dports 80,443 -j ACCEPT影响大多数用户这样的规则应该是你的第二条规则，而不是作为规则编号 199 之后的一系列规则，除了少数特定用户和/或不常见的协议之外，不太可能与任何人匹配。
就制作规则而言，通过使用正确的模块，例如 multiport 和 iprange，您可以创建智能规则，而不是许多单独的规则。