> "Reckhard, Tobias" wrote:
> > 
> > FTP), stateful inspection can theoretically be application-aware, too,
> while
> 
Paul Cardon wrote:
> As to the possibility of stateful inspection being fully application
> aware, consider this.  If a stateful inspection firewall only makes
> filtering decisions based on the current packet and information culled
> from previous packets, it can be fooled.  That is what happened to
> Checkpoint with the PASV FTP vulnerability.
> 
True. If it can't buffer packets long enough to be able to put together all
the information in the payload that is required for a specific action and
perhaps modify these packets (performing defragmentation, for instance),
then it is obviously not up to par with an ALG. However, since a stateful
filter works at the TCP/IP level(s), it has all the information that an ALG
can get and then a bit more. It *could* therefore be made to work like an
ALG. It's not happening however, obviously. I just wanted to avoid people
saying that "it can examine the complete IP packets, so it's got all of IP,
all of TCP and the whole payload to inspect". Sure, it's got them. Does it
use all of them like an ALG?

> When you are dealing with
> making decisions using information at the application layer, you may
> need information in *subsequent* packets to definitively determine that
> the current packet is safe to pass or to make a state table change.  In
> other words some amount of TCP stream reassembly may be required.  Or
> you can do what Checkpoint did as a "fix" and restrict the permitted
> traffic to a subset of valid TCP behavior.  :^(
> 
Yep, I'm with you all the way. And I can't consider the method Check Point
used to be more than a crude hack, but it seems they impose non-standard
restrictions on the behaviour of FTP elsewhere too.

Bottom line: Stateful filters (and packet filters too) could perform
decisions just like ALGs, but they currently don't. And I see no trend in
the direction.

Tobias

-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to