Traditional packet filters can only forward based on information
in the current packet. SPFs can make forwarding decisions
based on previous packets. That's why they are called stateful,
and that's why they are better than a regular packet filter. Now,
Paul, I think you're overstating how different a SPF is from
an AG, at least in terms of the end result. The mechanism
for getting the packet through the gateway is different
between the two, but the end result of the packet format is
nearly the same. Both will modify the source and destination
addresses (depending if the packet is going out or in) and
the sequences numbers, and the port numbers. That leaves very
little of the headers that aren't changed (I'll cover the exceptions in
a sec.) If a packet goes through an AG and and SPF,
what the packet looks like will be roughly the same.
So, If I look at the flags available in a TCP header, The only ones
that wouldn't normally get automatically modified by an SPF are
URG and PSH. Windows size would probably stay the same, and
the checksum obviously gets recalculated. There would also be an
OOB data pointer if that flag was set. In effect, and AG would
automatically strip those two bits off (and some won't strip off
the PSH flag, as it might be needed, as in Telnet) and the
OOB data if present and not needed, but would otherwise
be the same and the packet going through the SPF?
So, the difference is based on the fact the the main SPF
implementation (FW1) didn't previously filter the URG
pointer, and probably doesn't (currently) handle the
PSH flag intelligently?
If I've identified all of the differences, then the difference
seems rather minor, though it's worth fixing. My suggestion to Checkpoint
would be to have the GUI have a checkbox for each of those when
defining a new service.
This, of course, leaves alone any payload filtering issues for
this portion of the arguement, which may be significant with FW1.
> Many uninformed individuals feel that Check Point's approach is a
> packet filter. This statement is inaccurate. Packet Filters are good
> because they are fast, but lack the complete state and context of a
> conversation, therefore they are rather vulnerable to spoofing and other
Checkpoint applies masks based on rules to a packet, then consults a
state table to decide if the packet should be forwarded. How is that not
a packet filter? If an implementation does not create a new packet, then
it's a packet filter. State table or not, packets are _forwarded_, not
created by Firewall-1. That's why OOB attacks initially were successful
> to the table than just glorified packet filters. Again, because Check
> can interact with layers 2-7, they can extract much more information
> session than a packet filter.
Any packet filter can extract data from the payload portion of the
and act on forwarding a packet based on that data. That doesn't make it
any less a packet filter.