Date: Fri, 3 Dec 1999 09:01:21 -0700 From: Nate Williams <nate@mt.sri.com> 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 Message-ID: <199912031601.JAA10973@mt.sri.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912031601.JAA10973>