Re: Firewall rules order and performance
Carson Gaspar <[email protected]>
| Newsgroups | gmane.comp.security.firewalls.wizards |
|---|---|
| Message-ID | <[email protected]> |
Pierre Blanchet wrote: > This is a well known idea that the rules order is important for the best > performance of a firewall. However, nowadays: 1. Stateful firewalls use their > stateful engine for existing connections to allow traffic. That means that > their performance is more related to the number of existing sessions rather > than the number of rules, or more exactly it is tied to the ratio > new/existing sessions. 2. Some firewalls no longer parse the configuration > line by line but use hardware-based or tree-based model. Again, the number > of rules has less effect on the performance. > > I'm looking for benchmarks/ideas that could prove I'm right or wrong. I know > for sure that FW-1 and IOS depend on the rules order but what about the > others ? Google didn't give any information one way or the other. Define "performance"... For state keeping packet filters, the general rules (in my experience) are: - New connections / s is generally limited by ruleset size and complexity. As I recall, several years ago Lucent had an O(1) algorithm for packet filtering on some of their high end routers (OC-12 +) that leveraged some tricky algebra, but it was (at the time) limited to 256 not very complex rules. I suspect some other folks may have figured out similar optimizations. A simple test is to insert 10,000+ dummy rules followed by a rule you'll actually hit. Test connection setup rate that way, and with your matching rule first. You'll quickly determine if there's anything "interesting" going on. Be sure to make the dummy rules annoyingly similar to the real one, but not quite the same (say, filter on TCP flags) - Throughput tends to be limited by packet rate and # of existing sessions. This is why every vendor specifies throughput based on large packets - ask them for 64-byte packet throughput and watch them squirm. - Throughput can also be limited by how much protocol parsing is done and how complex it is. If you just have to forward packets, you can do it faster than if you have to look for embedded port numbers in FTP, SIP, etc. Include NAT in the complexity calculation. - The above variables can also effect _latency_ which can be more or less important that simple throughput, depending on your application. Application proxies have similar performance correlations, but they're not as straightforward. -- Carson