Re: Firewall rules order and performance

["Marcus J. Ranum" <mjr () ranum com>]

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 () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards