*sigh* Why am I such a sucker for these?


> -----Original Message-----
> From: Nathan Long [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, 6 November 1999 7:21 AM
> To: Lars Kronfält; Ashley Culver
> Cc: [EMAIL PROTECTED]
> Subject: RE: Enterprise Level Firewalls?
> 
> 
> Disclaimer: while I do not work for Check Point, I have 
> purposefully chosen
> to work only with Check Point firewalls.  My following 
> comments will reflect
> this educated bias.

Educated bias huh? A philospher might say that there is no such thing.

> 
>   >>packet filters are often very fast ( could even be just a 
> router with
> firewall software ). For example a basic Cisco PIX.

This was one of Lars' points, not Nathan's. A PIX is NOT a simple packet
filter. Go read Cisco docs to find out all about it - I'm not going to run
you an ad.

>   >>Stat.. like FW-1 offer more security, but are not as fast.
>   >>Proxy, are slower then stat... but offers even more security.
>   >>App... are the slowest, but most secure.

Lars again - I don't think I understand the difference between a proxy and
an application gateway. Either the thing looks at layer 7 data or it
doesn't. I'm going to guess that you mean something about the stringence of
the protocol analysis. If this is the case, then I submit that it is very
hard to find a single solution that has good app gateways for ALL protocols.
There are always going to be a heap of "proxies" that do very little in the
way of checking. I think you'd find that the TIS/Gauntlet/Anyone else SMTP
proxy is much more likely to save your bacon from protocol level attacks
that the HTTP proxy, f'rinstance.

> Bunk, complete and total bunk.  Well, that's a bit harsh.  

Damn right it's harsh. A lot harsher than _I'd_ be if I were wrong, anyway.

> The first two
> lines are accurate but the last two lines are not.
> Yes, proxies and application gateways are slower than 
> stateful inspection.
> That having been said, they are not more secure than true stateful
> inspection.  

I don't think I can take this on faith. You claim that a good stateful
inspection box will offer you as much security as a well written application
gateway? How is an SPF going to stop me connecting to your SMTP server and
sending a perfectly crafted, completely valid packet that happens to exploit
a Sendmail bug (maybe you forgot to disable DEBUG, maybe there's a buffer
overflow and I can send you four bazillion '0xFF's...)? An application
gateway will stop me. What if your application chokes on IP options? An SPF
doesn't know you don't need them for your protocol - an application gateway
does. I wonder if you could elaborate on what "true" stateful inspection is?

> Lance Spitzner had written a great paper, detailing what
> semi-intelligent Stateful Inspection really is and how it 
> really works,
> (http://www.enteract.com/~lspitz/fwtable.html) so I won't 
> belabor that here.

Uh, since it looks to me like it was intended to point out FLAWS with FW-1,
that might be a good plan.

> (By the way, nobody makes truly intelligent Stateful Inspection)

Again, I'll have to take this on faith. If it's true, then I presume that
it's only because it's too slow to do full checking and you may as well use
a more secure method, like an application gateway. 8)

> IMNQSHO Check Point Firewall-1 (particularly now that they 
> have developed
> the SVN architecture) is the most secure, most reliable, and 
> definitively
> most enterprise scalable, not to mention manageable firewall 
> on the market.

I always worry about people who are in the throes of one-eyed love with a
product, solution, protocol, vendor...I think you may need to re-examine
some of your assumptions. I'm not saying you're wrong (except about the SPF
vs Application Gateway thing), but I think that even if you're right you're
quite possibly ignoring any better solutions that may be out there. 

> 
> Nathan A. Long

Cheers,

--
Ben Nagy
Network Consultant, CPM&S Group of Companies
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.]

Reply via email to