Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: firewall-1: old broadcast address hole?
From: brad.powell () WEST SUN COM (Brad Powell)
Date: Fri, 25 Apr 1997 08:46:06 -0700


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



  By Date           By Thread  

Current thread:
  • Re: firewall-1: old broadcast address hole? Brad Powell (Apr 25)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]