From owner-freebsd-security  Fri Dec  3  8: 2:19 1999
Delivered-To: freebsd-security@freebsd.org
Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6E08A151A0; Fri,  3 Dec 1999 08:02:13 -0800 (PST)
	(envelope-from nate@mt.sri.com)
Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id JAA28229;
	Fri, 3 Dec 1999 09:01:22 -0700 (MST)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id JAA10973; Fri, 3 Dec 1999 09:01:21 -0700
Date: Fri, 3 Dec 1999 09:01:21 -0700
Message-Id: <199912031601.JAA10973@mt.sri.com>
From: Nate Williams <nate@mt.sri.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Adam Laurie <adam@algroup.co.uk>
Cc: Nate Williams <nate@mt.sri.com>,
	"Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>,
	John Baldwin <jhb@FreeBSD.ORG>, freebsd-security@FreeBSD.ORG
Subject: Re: rc.firewall revisited
In-Reply-To: <3847C0CB.2E9774A@algroup.co.uk>
References: <199912021954.LAA74271@gndrsh.dnsmgr.net>
	<3846FA12.F1480F19@algroup.co.uk>
	<199912022343.QAA08462@mt.sri.com>
	<3847ACBE.3D66A556@algroup.co.uk>
	<3847C0CB.2E9774A@algroup.co.uk>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Reply-To: nate@mt.sri.com (Nate Williams)
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> > > > > ipfw add X pass udp from any to ${dnsserver} 53
> > > > > ipfw add X+1 pass udp from ${dnsserver} 53 to any
> > > > > ipfw add X+2 deny log udp from any to any 53
> > > > > ipfw add X+3 dney log udp from any 53 to any
> > > >
> > > > This breaks one of the basic rules of firewalling... Trusting traffic
> > > > based on source address. To quote from the ipfw manual:
> > > >
> > > >      Note that may be dangerous to filter on the source IP address or
> > > > source
> > > >      TCP/UDP port because either or both could easily be spoofed.
> > > >
> > > > You've just let anyone that can spoof you DNS's source address onto any
> > > > UDP port.
> 
> And, of course, it also means you are wide open to attack from a
> compromised name server. I do not want to trust hosts. I want to trust
> specific connections to specific services.

How do you propose to stop a compromised name server from giving out
bogus information using a firewall rule?  I'm curious...



Nate


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