From owner-freebsd-security  Thu Oct 22 13:43:49 1998
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id NAA27020
          for freebsd-security-outgoing; Thu, 22 Oct 1998 13:43:49 -0700 (PDT)
          (envelope-from owner-freebsd-security@FreeBSD.ORG)
Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA27008
          for <freebsd-security@FreeBSD.ORG>; Thu, 22 Oct 1998 13:43:45 -0700 (PDT)
          (envelope-from sthaug@nethelp.no)
From: sthaug@nethelp.no
Received: (qmail 8999 invoked by uid 1001); 22 Oct 1998 20:43:13 +0000 (GMT)
To: Studded@gorean.org
Cc: freebsd-security@FreeBSD.ORG
Subject: Re: default rules in rc.firewall cause problem
In-Reply-To: Your message of "Thu, 22 Oct 1998 11:38:41 -0700"
References: <362F7BB1.71A13EF3@gorean.org>
X-Mailer: Mew version 1.05+ on Emacs 19.34.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Thu, 22 Oct 1998 22:43:13 +0200
Message-ID: <8997.909088993@verdi.nethelp.no>
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> First off, the
> outside interface should NEVER see traffic from RFC 1918 space, so if
> you have to modify this rule to get your system to work then your system
> is screwed. 

Unfortunately, there's plenty of traffic out there with RFC 1918
addresses. From one of the nearby routers here:

gw> sh access-list 104
Extended IP access list 104
...
    deny   ip 10.0.0.0 0.255.255.255 any (2161 matches)
    deny   ip 172.16.0.0 0.15.255.255 any (5942 matches)
    deny   ip 192.168.0.0 0.0.255.255 any (10313 matches)
...

- There are plenty of ISPs using RFC 1918 addresses for their internal
links (bad idea!), which results in these addresses being visible as
source addresses when you run traceroute etc.

- There are plenty of installations using some form of RFC 1918 for
their internal network, without sufficient filtering. This results in
RFC 1918 destination addresses being visible externally - until they
reach a default free router, where they are of course dropped in the
bit bucket.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message