Re: firewall-1: old broadcast address hole?

[brad.powell () WEST SUN COM (Brad Powell)]

> From owner-bugtraq () NETSPACE ORG  Thu Apr 24 20:18:24 1997
> Approved-By: aleph1 () UNDERGROUND ORG
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Date:  Thu, 24 Apr 1997 14:05:27 +0200


 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.
=======================================================================