🚀 go-pugleaf

> -----Original Message-----
> From: Frank Willoughby [mailto:frankw@in.net]
> Sent: Friday, April 10, 1998 8:40 AM
> To: firewalls@GreatCircle.COM
> Subject: RE: socks versus fw-1 [Part I/II]
> Importance: High

[....]
 
> >>Here are a few of my *many* crows to pick with the 
> >>Firewall-1.
> >>o You have to put a deny all at the last of the rules 
> >>to make up for its default stance of being wide open
> >
> >Uh..no.  There is an implicit deny at the end of the 
> >ruleset.
>                                            ^^^
> 
> That's exactly my point.  "There is an implicit deny at the 
> *END* of the ruleset".  A basic axiom of network security 
> design - turn off *all* network services, then turn on only 
> those services that you *really* need to use.  
> 
> The Firewall-1 violates this basic security design principle.  
> IOW, block everything by default, then open up the firewall 
> to permit only known *good* services.  IMO, Checkpoint works 
> in reverse.  It closes the barn door after the horses are all 
> out by placing the deny all at the END of the ruleset instead 
> of the beginning.

That's semantics! Anybody that is involved with network security
should be intelligent enough in the first place to figure that
out. If not he/she is going to do stupid things with it no matter
what you throw at them.

What worries me actually more about the Checkpoint approach is that
you can switch on/off certain often used services like DNS, ICMP
etc. in the property settings. Confuses the hell out of people
since it prevents you from having an all-in-one view of your
security policy. This is really bad and unnecessary. I actually
confronted a high-level Checkpoint rep in front of a lot of people
once, but I don't think he got my point. I think best practice is to
deny everything in the properties and put *everything* into the policy
proper instead.
 
> Further, from my experience, if the "implicit deny at the end 
> of the ruleset" was in there, it sure didn't work very well 
> when I tested it.  I ran a battery of tests across the Firewall-1 
> recently & found a *lot* of vulnerabilities (more than 50).
> If the rule was in there & working, then the firewall leaked.

Actually never even tested this! I always educated (when I used
to be a consultant :) our customers to put an *explicit* deny at the
end of the rule base if just for the sake of clarity. But I agree,
if it indeed leaks that is very, very bad. Maybe you had some services
still allowed through the property settings (see above)?

> >>o It encourages people to do stupid (from a security 
> >> point-of-view) things like permit dangerous (unproxied) 
> >> services through the firewall - a la' if they support 
> >> it, it must be OK).
> >
> >Many proxy vendors include a circuit-level gateway that 
> >does exactly the same.  What I think you meant to say 
> >is that some proxy vendors include application-specific 
> >proxies that validate the data better.
> 
> You're comparing apples & oranges.  Circuit-level gateways are 
> provided for companies who wish to permit secure applications 
> through the firewall for which no proxies exist.  It was *not* 
> designed for people to punch holes thru the firewall so that 
> they can let some (dangerous) services thru the firewall.  The 
> *use* of circuit-level gateways is not supported by the vendors.  
> Again, it was designed to permit secure apps thru the firewall 
> - not to be abused by letting known insecure services thru to 
> the inside network.

But people do use them when there's enough pressure from the
business. And they might actually think they're safer than just
punching a hole into a stateful inspection fw for that service.
After all they bought the 'more secure' application gateway. I
think the argument works both ways. 
 
> From my research, Checkpoint advocates and supports (if you can 
> find 'em) letting in known dangerous unproxied services thru 
> the firewall.

I never read any of the AG vendors manuals thouroughly but do they
actually tell people 'hey listen, we provide you with a generic
proxy, but you're really are putting your business on the line when
you use it!'? I kind of agree though that the reluctance to venture
out and actually configure a generic proxy might be higher because you
have to do something 'special'. With FW-1 the service definition for
NIS is just two clicks away after all.

However, I'm not sure if it's really the firewall vendors
responsibility to educate users on the characteristics of
individual protocols. But then maybe it is...


> >>o I don't like the security architecture of 
> >>the firewall
> >Well, you don't have to I suppose.  Some specifics 
> >would be more useful.
> 
> Good point.  OK, here's a few that come to mind:
> o Insecure Operating System

Which it shares with most other firewalls. Come to
think of if, is there an AG that does *not* run on
top of an insecure OS?

> o Manually configured NAT (instead of automatic)

Don't see why this would be a problem. BTW, version
3.0 let's you have the choice of generating NAT rules
manually or automatically. Also NAT is now integrated
with the GUI which makes it a hell of lot more
intuitive.

> o Compilers on the firewall (to compile the Inspection rules)

What kind of compilers are you talking about? They're not C
compilers or anything. What exactly would you do with an
inspect code compiler if you were a hacker?

> o GUI doesn't reflect the rules or the state of the firewall

I don't understand what you mean.
 
> o Checkpoint supplies very few proxies (about *1/4* - 1/3 that 
>    of other vendors).  They also advocate that Stateful Inspection 
>    is better than using proxies.  If *they're* not comfortable with
>    their own proxies, how would a customer feel about using them?

As you have observed yourself, they have reversed that position.
They're still short of proxies but they patched at least the worst
holes. However, it is beyond me how they could maintain the position
that for example a straight SMTP connection to your mail server
(preferably running an unpatched version of sendmail) would be
more secure than let's say smap. This actually is what pisses me of
the most about Checkpoint. They must have been fully aware of this
(otherwise they wouldn't have come up with security servers), since
it's not too hard to figure out, but publically denied it for several
years. 

> o The firewall "leaks".  If inbound services are blocked, 
>    it is still possible to sneak packets thru the firewall.
>
> o In certain cases, the firewall is unable to maintain state 
>    information (which is interesting since the whole focus 
>    of the product is in this specific area)

> o Source code isn't available

Again this it shares with most of it's commercial competitors
except maybe TIS but they give you hell of a time to obtain the
source ever since 4.0 cam out.

> o Setting up the VPN can be a real pain.

Well if the NSA hasn't been able to get it working maybe they
are underfunded or don't hire the right people ;o). I have gotten
it to work on several occasions and I don't consider myself
overly intelligent.

> o The SecureRemote isn't.

How?

> o The documentation (perhaps not an architecture issue directly,
>    but is problematic, nonetheless.  It's huge & says nothing.
>    Probably the best docset I have seen yet was from a vendor
>    who summed everything up in 27 pages.  It was very-well written.
>    The Checkpoint docset takes up a lot of space 3-4 inches (7.5-10cm)
>    and says very little.

Agreed, the documentation sucks for the most part. Period.

> Some of the above are mentioned in the NSA's report.  You mentioned
> you read the document.  I saw problems.  You didn't.  Perhaps 
> security 
> is in the eye of the beholder.  

-Stefan

BTW, I'm in now way affiliated with Checkpoint, I do not own Checkpoint
shares, I didn't even got a lousy T-shirt from them.