On May 6, 2005, at 8:47 AM, John . wrote:
> Well, you surely don't want to sort the firewall rules because they're
> evaluated in order and showing them any other way implies a wrong
Not always true. There are (or at least were) firewall ruleset
optimization engines (code)
that could safely re-order a ruleset.
As a trivial example, if a ruleset is setup to always drop packets to
188.8.131.52/8, then a later rule to drop packets to 184.108.40.206/32 will never
be reached, and can safely be discarded.
At the end of the day, rulesets are a language to describe computation
on a dataset (the network packets). The original "netgate" firewall
actually ran a little p-code engine (and in the end we build a compiler
that would generate native instructions) that ran a "program" that
"interpreted" the packet. The result of the computation determined
the outcome of the packet
processing. bpf (and probably pf) do something quite similar.
Most firewalls also have a look-aside cache of previous results. If
"this" packet matches
the input variables of some previous packet (srcip, dstip, srcport,
dstport, protocol, etc),
and you know the outcome of running the ruleset on the previous packet,
its much quicker
to just lookup what to do with the packet.
Its also possible (in theory) to use a remote firewall's ruleset to
perform useful general-purpose computation, albeit slowly. (Someone
has already done something similar with
the TCP checksum.)