Ben Nagy <[EMAIL PROTECTED]> wrote:
>
> > >So if the packets have been intentionally fiddled with in
> > > some way
> > > the 'fiddled' packet will get to the server.
>
> Absolutely right.
If the filter does not drop them. There is no reason that the filter
cannot detect the fiddling and drop packets. A stateful filter is
capable of "remembering" things about previous packets it has seen with
regard to a particular "conversation".
> Please, _do_ try to moderate your tone and be a bit polite.
My tone was not meant to be impolite. Maybe to the point, but not
impolite. My appologies if it came across that way.
> without you
> verbally slapping people about.
I was not verbally slapping anyone. I was pointing out the responder
that the query was about stateful packet filters which are much more
powerful than "regular ol'" packet filters.
> Strictly speaking, a stateful packet filter only keeps state (duh).
> This
> means that an SPF is supposed to know everything about the TCP/IP
> rules for
> the flow of data between the internal and external hosts.
Indeed!
> However, SPFs
> aren't really supposed to look at application level data - and indeed
> they
> usually don't.
On the contrary. The first protocol that I am sure most SPF developers
implement is FTP (I have some insight, I wrote an SPF for Linux :-).
That by definition means looking into the packets' data at the
application level because it is at the application level that FTP
negotiates the "data channel".
> There are some hybrids that look at the application data of
> the first few packets of a flow but (IMO) these should be called
> something
> different to avoid confusion.
There maybe some filter/proxy hybrids out there but that is not what I
am talking about. There are more and more protocols that require a
(stateful) filter to look into the application level to properly allow
access to the application while keeping the rest of the security policy
intact. I do not define this a proxying at all however.
> So, essentially, by using a SPF you trade-off some security for a
> reasonable
> speed / RAM saving.
I disagree. You don't necessarily trade off on security with a packet
filter. I will agree that it performs a different job than proxying,
but that does not necessarily mean it is less secure.
> Of course in theory, an ALG will subject a packet to much closer
> application
> level scrutiny than any SPF ever could due to the speed/RAM problem.
What speed/RAM problem?
> In
> practice, however, it's damn near impossible to write an effective ALG
> for
> lots of the protocols streaming in and out of networks now (notably
> HTTP).
HTTP is a bad example. It is a very simple protocol that in fact a
proxy can do a very effective job with. FTP, or ICQ, or RealAudio, etc.
are protocols where proxying is more difficult mainly due to the
client's need to know there is a proxy involved and react differently.
> However the key point that Darryl made is that an ALG (Application
> Level
> Gateway - Proxy if you like) terminates the IP connection and forms a
> new
> one to the internal hosts. This _ensures_ that no "fiddled" packets
> get
> through.
This is true.
> If FW-1 is anything to judge the current state-of-the art for SPFs
> by, you don't have anywhere near that kind of assurance with current
> SPF
> implementations.
Is FW-1 the benchmark by which current SPFs should be judged?
b.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
