Firewall rules order and performance
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
 |
Firewall rules order and performance
by Pierre Blanchet
::
Rate this Message:
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. -- Pierre Blanchet _______________________________________________ firewall-wizards mailing list firewall-wizards@... https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards |
|
|
Re: Firewall rules order and performance
by david@lang.hm
::
Rate this Message:
On Fri, 17 Jul 2009, 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. this is going to depend on which firewall you look at, and potentially which release of the software. ordering the rules by how frequently they are used doesn't hurt performance on systems that do tree-based rules internally, so the only possible thing that you would gain is in the orginization of the rulesets, and I'm not sure that that's enough to worry about trying to keep track of which releases of which firewalls have which behavior. David Lang _______________________________________________ firewall-wizards mailing list firewall-wizards@... https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards |
|
|
Re: Firewall rules order and performance
by Marcus J. Ranum
::
Rate this Message:
Pierre Blanchet wrote:
> This is a well known idea that the rules order is important for the best > performance of a firewall. It's also sometimes significant from a policy standpoint. I know you know that, but I cannot avoid mentioning it. > 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. Maybe. It may be tied to the implementation of the engine; whether or not they are doing any L7 snooping or whether they are just ripping control information out of raw packets. A "stateful" firewall could have state-table entries that are very light weight (e.g.: practically nonexistent or hardly more than relying on the SYN flag - a single bit). It's possible that a "stateful" firewall might have a cruddy stream lookup algorithm, in which case performance might have to do with number of sessions, or it might have a mediocre rules matching algorithm, in which case it would depend on rule quantity, or complexity. I've seen some firewalls that parse rules tables into parse-trees and optimize them and I've seen other firewalls that re-interpret the rules tables as strings, each time something comes in. I kid you not; i.e.: if(strcmp(rp,"permit")) { ... In other words, I think you're dramatically oversimplifying things. "It's more complicated than that." > 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. Hardware does nothing but run software; so if the algorithms burned into the hardware are mediocre, you have a fast version of a mediocre algorithm and aren't necessarily any faster. I know of one firewall that does some clever stuff to reorder rules into something much like a yacc-generated parse tree, to guarantee minimal cycle use in matching. That's a software implementation but it'll kick the living snot out of a linear search implemented in hardware. That's without even taking into account the fact that a 3+Ghz CPU is one hell of a fast engine, even running software, and might kick the snot out of a decent piece of code running in a slower ASIC. Some firewalls do as you say; perhaps some do not. It's hard to know for sure and I only believe in code I've reviewed, anymore. :D > I'm looking for benchmarks/ideas that could prove I'm > right or wrong. There's a paper by Molitor, Kostick, and myself that lays out these problems fairly clearly. The upshot is that, if you really want to test firewall performance, you need to hit firewalls with live streams of application data that match your expected deployment. Anything else is pointless. You might also want to search up a paper I wrote on IDS benchmarking back in the NFR days; the problem there is similar. "Stateful" firewalls nowadays also often have bags on the side that attempt to do various L7 processing. So, for example, if you're just dealing with 10,000 streams/minute of dummy HTTP traffic it's going to perform extremely differently when you turn on URL scanning and the flow path cuts from the hardware (which basically hardly looks at each packet) to the CPU, which has to sequentially handle packets. How do you test this? Feed real application data through it. If your benchmark is measured in packets/second, I can guarantee you that you're doing it wrong. BUT that doesn't mean I know what "right" is; other than that it's simulating as accurately as possible what your real traffic will look like. (The IDS benchmarking paper also points out problems with using packet replays of streams off a hard disk; a correctly functioning IDS or firewall will not love seeing the same TCP session happen over and over again) (Corollary: there are very very very few firewalls, by that definition, that I'd consider "correctly functioning") >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. Firewall vendors are typically very close-mouthed about such implementation details. Because they know that if most of you knew how little the firewalls actually do (but gosh! they do it fast!), you'd scream. I know this isn't the answer you wanted to hear, but it's the truth. mjr. -- Marcus J. Ranum CSO, Tenable Network Security, Inc. http://www.tenablesecurity.com _______________________________________________ firewall-wizards mailing list firewall-wizards@... https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards |
|
|
Re: Firewall rules order and performance
by Carson Gaspar
::
Rate this Message:
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 _______________________________________________ firewall-wizards mailing list firewall-wizards@... https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards |
|
|
Re: Firewall rules order and performance
by lordchariot-2
::
Rate this Message:
I've done this in the past with professional test equipment like SmartBits
or Web Avalanche that was able to measure performance, latency, connection rates, etc. The challenge was establishing unique connections from multiple MAC & IP addresses to emulate real endpoints, and not just alias multiple IPs on the same NIC. Mostly because of the ARP process prior to making a connection. It's a lot faster making 65,000 connections from 1 MAC/IP to another than 10 connections to 6,500 unique MAC/IP/Src/Dest combinations. The test gear could simulate real hosts with unique MAC & IP addrs. We tested 1, 10, 100, 1000 & 10000 rules, all with different IP/port combinations. UDP & TCP with different packets sizes, etc. I was representing a now defunct product at the time, but the product faired pretty well because the rule matches where a tree lookup to select the rule. The overall difference between number of rules on our product was pretty negligible, but it did a lot better than checkpoint at the time. AIR, the rule selection wasn't the bottleneck, the number of already established connections in the kernel was the primary factor. You'd plateau after a certain point as new connections were trying to allocate the memory. -erik > -----Original Message----- > From: firewall-wizards-bounces@... [mailto:firewall- > wizards-bounces@...] On Behalf Of Pierre Blanchet > Sent: Friday, July 17, 2009 10:52 AM > To: Firewall Wizards Security Mailing List > Subject: [fw-wiz] Firewall rules order and performance > > 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. > > -- > Pierre Blanchet > _______________________________________________ > firewall-wizards mailing list > firewall-wizards@... > https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards _______________________________________________ firewall-wizards mailing list firewall-wizards@... https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards |
|
|
Re: Firewall rules order and performance
by Marcus J. Ranum
::
Rate this Message:
lordchariot@... wrote:
the number of already > established connections in the kernel was the primary factor. You'd plateau > after a certain point as new connections were trying to allocate the memory. I never understood why anyone would have a problem with that. Just pre-allocate a pool and (if you're really into it) marshall your pools based on the hash function you use to match the streams so that stream data related to a particular hash chain tend to be in the same memory pages. It always seemed to me that a lot of the "system design" of firewalls was "let's put our head between our knees and hope Moore's law or marketing takes care of it for us." mjr. -- Marcus J. Ranum CSO, Tenable Network Security, Inc. http://www.tenablesecurity.com _______________________________________________ firewall-wizards mailing list firewall-wizards@... https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards |
|
|
Re: Firewall rules order and performance
by Jean-Denis Gorin
::
Rate this Message:
Selon "Marcus J. Ranum" <mjr@...>:
> > It always seemed to me that a lot of the "system design" > of firewalls was "let's put our head between our knees and > hope Moore's law or marketing takes care of it for us." You should mean "system design of software", not only of firewalls (or whatever kind of security software...), and "let's put our head between our knees and hope Moore's law or marketing takes care of it for us. Else, we will deliver some patches." :-( And more than 10 years of that state of mind for software engineering resulted in having pathes as the ultimate solution for all problems! Who remember that firewalls (as application gateways) was designed to solve (or to ease a lot) the patch management problem? Now, we are back to patch management as the solution for all problems because dumb people (managers, marketers, buyers, system admins, network admins, developers, or whatever fit your situation) are unable (or unwilling) to understand what is a firewall, and what is it due for... JDG _______________________________________________ firewall-wizards mailing list firewall-wizards@... https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards |
|
|
Re: Firewall rules order and performance
by Eric G-4
::
Rate this Message:
On Mon, Jul 27, 2009 at 1:21 AM, Jean-Denis Gorin<jdgorin@...> wrote:
> Who remember that firewalls (as application gateways) was designed to solve (or > to ease a lot) the patch management problem? > Now, we are back to patch management as the solution for all problems because > dumb people (managers, marketers, buyers, system admins, network admins, > developers, or whatever fit your situation) are unable (or unwilling) to > understand what is a firewall, and what is it due for... Part of the problem with your argument is that in order for e,g, a web server to be reached, port 80 (and maybe port 443) have to be allowed through the firewall. That fact alone means that the webservers have to be patched, because as long as the firewall is allowing legitimate traffic through, it could also be allowing malicious traffic through... -- Eric http://nixwizard.net _______________________________________________ firewall-wizards mailing list firewall-wizards@... https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards |
|
|
Re: Firewall rules order and performance
by K Kadow
::
Rate this Message:
Only if your "firewall" is a lowly stateful inspection packet filter,
and is not deeply aware of the higher level protocols... The idea behind "deep inspection" and protocol validating proxy firewalls was in part to filter out attacks before they reach vulnerable servers/clients. They do make the attacker's job more difficult. KK On 7/28/09, Eric Gearhart <eric@...> wrote: > On Mon, Jul 27, 2009 at 1:21 AM, Jean-Denis Gorin<jdgorin@...> > wrote: >> Who remember that firewalls (as application gateways) was designed to >> solve (or >> to ease a lot) the patch management problem? >> Now, we are back to patch management as the solution for all problems >> because >> dumb people (managers, marketers, buyers, system admins, network admins, >> developers, or whatever fit your situation) are unable (or unwilling) to >> understand what is a firewall, and what is it due for... > > Part of the problem with your argument is that in order for e,g, a web > server to be reached, port 80 (and maybe port 443) have to be allowed > through the firewall. That fact alone means that the webservers have > to be patched, because as long as the firewall is allowing legitimate > traffic through, it could also be allowing malicious traffic > through... > > -- > Eric > http://nixwizard.net > _______________________________________________ > firewall-wizards mailing list > firewall-wizards@... > https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards > -- Sent from my mobile device _______________________________________________ firewall-wizards mailing list firewall-wizards@... https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards |
|
|
Re: Firewall rules order and performance
by Behm, Jeff
::
Rate this Message:
On Tuesday, July 28, 2009 4:06 PM Eric Gearhart said: >On Mon, Jul 27, 2009 at 1:21 AM, Jean-Denis Gorin<jdgorin@...> wrote: >> Who remember that firewalls (as application gateways) was designed to >> solve (or to ease a lot) the patch management problem? >Part of the problem with your argument is that in order for e,g, a web >server to be reached, port 80 (and maybe port 443) have to be allowed >through the firewall. That fact alone means that the webservers have to >be patched, because as long as the firewall is allowing legitimate >traffic through, it could also be allowing malicious traffic through... True, but if your firewall is stopping (I won't argue whether or not that is actually occurring or not) traffic to all the other ports, wouldn't that imply that your patch management *has* been eased "a lot?" No doubt you have to patch, but "critical" patches for services not exposed (thanks firewall) at least lend some time to have some sense of order, rather than having to patch every time the sun rises. Jeff _______________________________________________ firewall-wizards mailing list firewall-wizards@... https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards |
|
|
Re: Firewall rules order and performance
by K Kadow
::
Rate this Message:
A good example of this is the BIND9 bug released yesterday. A very
good firewall has a DNS proxy and denies malformed packets, or can be set to filter out 'nsupdate' type packets. Even "iptables" can be set to drop these packets, with a one-line rule change. On 7/28/09, K K <kkadow@...> wrote: > Only if your "firewall" is a lowly stateful inspection packet filter, > and is not deeply aware of the higher level protocols... > > The idea behind "deep inspection" and protocol validating proxy > firewalls was in part to filter out attacks before they reach > vulnerable servers/clients. They do make the attacker's job more > difficult. > > KK > > On 7/28/09, Eric Gearhart <eric@...> wrote: >> On Mon, Jul 27, 2009 at 1:21 AM, Jean-Denis Gorin<jdgorin@...> >> wrote: >>> Who remember that firewalls (as application gateways) was designed to >>> solve (or >>> to ease a lot) the patch management problem? >>> Now, we are back to patch management as the solution for all problems >>> because >>> dumb people (managers, marketers, buyers, system admins, network admins, >>> developers, or whatever fit your situation) are unable (or unwilling) to >>> understand what is a firewall, and what is it due for... >> >> Part of the problem with your argument is that in order for e,g, a web >> server to be reached, port 80 (and maybe port 443) have to be allowed >> through the firewall. That fact alone means that the webservers have >> to be patched, because as long as the firewall is allowing legitimate >> traffic through, it could also be allowing malicious traffic >> through... >> >> -- >> Eric >> http://nixwizard.net >> _______________________________________________ >> firewall-wizards mailing list >> firewall-wizards@... >> https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards >> > > -- > Sent from my mobile device > -- Sent from my mobile device _______________________________________________ firewall-wizards mailing list firewall-wizards@... https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards |
|
|
|
|
|
Re: Firewall rules order and performance
by Marcus J. Ranum
::
Rate this Message:
Eric Gearhart wrote:
> makes it sound like the term started with "packet filter," then > evolved to stateful packet inspection, then the third generation of > the term evolved into your definition... Wikipedia has it wrong. First was some packet filtering. Then, it appears Dave Presotto at Bell Labs started at layer-7 with circuit relays. Cisco added "established" to IOS - is that "stateful" or not? Man in the middle layer-7 proxies came next, then Geoff Mulligan at Sun and Bob Braden at ISI started on "Sunscreen" and "Visas", respectively. "Stateful packet inspection" a la Checkpoint didn't enter the scene until relatively late. Sunscreen was already selling poorly but in the market, and the proxy firewall vendors - DEC/Altavista, Raptor, TIS, ANS, Milky Way, and Harris - were selling the hell out of layer-7 solutions. mjr. _______________________________________________ firewall-wizards mailing list firewall-wizards@... https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards |
| Free embeddable forum powered by Nabble | Forum Help |
