[EMAIL PROTECTED] wrote:
>
> The PIX has a couple shortcomings.
>
> * it's vulnerable to spoofed address attacks
Vulnerable in what sense? If you know what the legitimate address space
is behind an interface, you construct an ACL so as to block anything
that isn't from that space. No different from Check Point
Anti-Spoofing, essentially.
> * it doesn't validate most streams, so you could, for example, create
> a tunnel through port 80 and the PIX would never know it wasn't
> web traffic
This is true of anything using a stateful packet filter. One needs an
application proxy to prevent what you're describing. Check Point has an
HTTP "Security Server" that sucks, so you don't gain much there. CP's
other app-level proxies also suck.
> * it has some FTP bugs which cause connections to be opened erroneously
Not sure I know which vulnerability you're referring to, but it sounds
likely to be an old one, not in later revs of PIX OS 5.2 and in 5.3.
> not sure if this is a huge security rish though
The FTP exploits of recent days are significant. FTP as a protocol is
Evil. Check Point currently still has problems dealing handling FTP
either securely, or without breaking some clients' FTP behavior.
> * it has a nasty vulnerability that allows spoofed IP RST messages
> to kill any open connections - again this is because the pix doesn't
> go as far into the upper layers in the packets.
RST's are a TCP phenomenon only. PIX goes as far into the packets as
CP, in most areas, further in a few, less in some, but for the most part
they're both stateful packet filters.
> The problem I know of with Checkpoint is if another MAC address claims
> the same IP as on of the firewall interfaces. This will cause
> Checkpoint to crash. You should be able to block this with a rule
> though, so at least there is a workaround.
I only vaguely remember hearing something about this, a while ago, but I
don't believe it's current, and I doubt it affects all platforms CP runs
on. How you would block a rule, exactly, is not clear to me. If you're
talking about a "Stealth" rule, you still have to allow connections to
the firewall unless you have firewall + management console + gui on the
same box, and you never log in via network. Not likely. So if all it
takes is for a packet to have the source IP address == destination IP
address (of firewall interface), and have the source MAC address be
different than the dest MAC address, a rule won't protect you from
someone who is trying to crash you, and can determine what ports you
allow to connect to the firewall. Caveat is that the attacker would
have to be on the local network segment.
> So far this sounds really lopsided to Checkpoint. Let me just temper my
> message by throwing in the fact that Checkpoint also costs roughly twice
> as much as a similar PIX solution. You more or less get what you pay
> for.
Which one costs more would depend on whether you're buying one or two
firewalls (assuming the 2nd was a redundant one) and how many internal
hosts you're protecting, and what platform you're running (for CP).
Michael
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
