Tom Vandepoel <tom@NETVISION.BE> Writes:
>
>This mail is about something checkpoint has overlooked in it's
>firewall-1 v2.1. I believe it to be a flaw in lots of ruleset
>implementations anywhere.
>
>Say I build a ruleset around the following assumptions:
>
>First of all, I want to allow administrators access to the firewall.
>Second, I want to block all other access to the firewall itself.
>Third, I want to allow some services from the inside nets to the
>outside.
>
>To implemement this, one would have the following ruleset structure:
>
>1) Allow access to firewall for adminstrator access
>2) Block all other access to the firewall object
>3) Allow traffic from inside net to any for certain services
>
>Now, this will correctly block all access to the firewall's interface
>addresses for non admin access. However, if you use the network
>address of, say, the external interface of the firewall, as your
>destination address. The ruleset will not block this in the second rule,
>and it will match on the third.
Tom-
*any* packet filter if set up incorrectly will cause unexpected
results.
I'd say the rule designer made a logic flaw not that the product
was faulty.
A packet filter is only as good as the rule set.
A proper rule would be to create an "outside" or "internet" (whatever)
rule and specifically -exclude- the FW's IP interface.
To use your rules as an example:
>1) Allow access to firewall for adminstrator access
a) Define "inside interface" on the firewall; define "outside interface"
of the firewall.
b) allow access to the "inside" interface of the FW from IP address
admin-user-ip-address (or group of IP addresses if more than one admin)
OR
b2)disallow access of remote changes and force admin to access console.
OR
b3)use FW-1's proxy to force strong authentication using a token;
still allow only access to "inside" interface from "admin-ip-address"
>2) Block all other access to the firewall object
this rule ins unneeded its the default; if you don't have a rule allowing
access its by design dropped. no extra rule needed.
>3) Allow traffic from inside net to any for certain services
Nope.
a)Allow traffic from "inside net" to a defined "outside or untrusted nets"
this rule should be an "exclude" rule. e.g. "outside" is everything -except-
for the "inside net(s)" -and- the *two* FW interfaces.
>
>In some cases (in my case on Solaris 2.5 sparc) this can actually be
>used to connect to services on the firewall. I'm not sure if this works
>with all tcp implementations, but I think this has something to do with
>the deprecated use of the subnet address as the all-subnets directed
>broadcast address. Also, I've seen this only in a situation where the
>network was subnetted. I will try to reproduce this for non-subnet
>situations as soon as I can find some time.
shouldn't matter. Your rules allowed for this sub-netting makes no difference.
>
>This particular problem situation is not as much a threat, as it will
>only allow access to firewall services from the internal network.
>However, if liberal access is allowed from outside too, this may be
>exploitable from outside as well. All it takes is a rule allowing
>a service to anywhere, or a network including the firewall. This will be
>enough to match the network address...
Rules to "anywhere" are not a good idea anyway. Exclude lists are better.
>
>A fix would be to define *host* objects for each of these network
>addresses and deny access to them too in the second rule...
>
see above.
>I sent this to bugtraq too to give checkpoint a little motivation to
>look into this problem...
Hmm. Should have come to a firewall mailing list first. Could have saved
some time.
Regards,
=======================================================================
Brad Powell : brad.powell@Sun.COM
Sr. Network Security Consultant
Sun Microsystems Inc.
=======================================================================
The views expressed are those of the author and may
not reflect the views of Sun Microsystems Inc.
=======================================================================