Pardon my curmudgeonliness. I'm getting over the flu.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 14 April 2000 2:11 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Packet Filtering vs. Proxy
>
>
> 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".
There is no reason why not, but there is no reason (and history suggests
that this is a more realistic view) why it _should_ either.
In addition, obviously, an ALG can drop packets that look dodgy from a
_data_ point of view (cgi queries like AAAA.[..].AAA) etc). Whether they
_do_ or not (most don't) is a different matter.
[bickering snipped]
> > 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".
I don't know if you're looking for cheap points or if you just
misunderstood. Looking in the packet body so that new connections can be
spawned is not the same as inspecting the application level _data_. We're
talking about catching SMTP DEBUG commands. We're talking about blocking
dodgy FTP GET commands. That sort of thing. If your SPF does this then it's
NOT just an SPF. Call it something else.
>
> > 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.
You can disagree as much as you like but to defend your point of view you
need to offer some rebuttal.
Fact: an ALG can block application level attacks by inspecting the _data_.
An SPF can't.
Even IF you posit that an SPF did this, which they don't by definition, you
still run up against this one...
Fact: an ALG terminates the IP connection from the remote node before it
gets to the local node. This offers complete protection against
fragmentation and other nasty IP level attacks. An SPF does not do this,
therefore it cannot offer me _design level_ assurance that it will protect
me. Some SPFs may (at their peril) offer me _implementation_ level assurance
- but who has time to do a complete code review of every product on offer?
>
> > 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?
SPFs are faster than ALGs. This is because they perform easier checks. Also,
since ALGs need to actually RUN some services (eg DNS, SMTP) in order to
"filter" them, they have a much bigger RAM footprint. That's why it's hard
to make a small, cheap, fast ALG. There are lots of small/cheap/fast SPFs.
>
> > 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.
No, HTTP is an _excellent_ example. Not because it's hard to pass traffic -
SPF people always seem to think in terms of getting traffic from one end to
the other. It's hard to write a good ALG for HTTP because there's so much
crap that gets tunneled over it that it's next to impossible to work out
what's legit traffic and what's evil h4x0r doom.
>
> > 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?
>
No idea. I picked on it because it has lots of market share and does a
not-very-good job of stateful filtering. Given that it's the biggest seller
it must be the best, right? ;)
Cheers,
--
Ben Nagy
Network Consultant, Volante IT
PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
