From owner-freebsd-security Wed Jul 29 11:07:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA17403 for freebsd-security-outgoing; Wed, 29 Jul 1998 11:07:14 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.ruhrgebiet.individual.net (in-ruhr.ruhr.de [141.39.224.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA16028 for ; Wed, 29 Jul 1998 11:02:35 -0700 (PDT) (envelope-from bs@devnull.ruhr.de) Received: (from admin@localhost) by mail.ruhrgebiet.individual.net (8.8.5-r-beta/8.8.5) with UUCP id TAA14479; Wed, 29 Jul 1998 19:51:58 +0200 (MET DST) Received: from [192.168.22.75] (helo=rm.devnull.ruhr.de) by devnull.ruhr.de with esmtp (Exim 1.92 #1) id 0z19tm-0000sU-00; Tue, 28 Jul 1998 15:34:38 +0200 Received: from bs by rm.devnull.ruhr.de with local (Exim 1.92 #1) id 0z19tk-00006i-00; Tue, 28 Jul 1998 15:34:36 +0200 To: sthaug@nethelp.no Cc: marcs@znep.com, ben@rosengart.com, security@FreeBSD.ORG Subject: Re: inetd enhancements (fwd) References: <12062.901612512@verdi.nethelp.no> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit From: Benedikt Stockebrand Date: 28 Jul 1998 15:34:36 +0200 In-Reply-To: sthaug@nethelp.no's message of "Tue, 28 Jul 1998 09:55:12 +0200" Message-ID: <87af5um74j.fsf@devnull.ruhr.de> Lines: 57 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sthaug@nethelp.no writes: > If your box is setup *not* to route (net.inet.ip.forwarding = 0), I can > certainly see security advantages in not allowing packets to be accepted > unless they have destination address equal to the interface address. I > have seen a patch for this floating around on the net, but it would be > nice to have this configurable. I'd use a packet filter for that, something like DENY="/sbin/ipfw add deny" IF1="ed0" IP1="192.168.47.11" IF2="ed1" IP2="192.168.227.28" $DENY all from $IP1 to any in via $IF2 $DENY all from $IP2 to any in via $IF1 (this is off my head and a couple months after I've last written a packet filter set, so YMMV). A similar ruleset that's using networks instead of individual addresses should be used on any packet filtering router. Making this the default behaviour will break a variety of things in connection with multihomed hosts that have interfaces in multiple networks (like for performance issues) but leave the actual routing business to some active network component. Example: For performance reasons I've got four networks 192.168.1.0 to 192.168.4.0 and a single high-speed NFS server "nfs.example.com" with an interface in each net on IP addresses 192.168.[1-4].42. If I want to make use of all these interfaces I can either - assign different names to the addresses and configure all machines in the networks to use the proper address for their network - use some ugly DNS hacking - announce host routes to the first address on all other addresses. The first solution involves configuring all client machines, the second is a bl**dy mess and the third may be somewhat weird. If I'm dealing with four crowded class C's I'd always go for the third approach. So long, Ben -- Ben(edikt)? Stockebrand Un*x SA My name and email address are not to be added to any list used for advertising purposes. Any sender of unsolicited advertisement e-mail to this address im- plicitly agrees to pay a DM 500 fee to the recipient for proofreading services. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message