Date: Fri, 3 Dec 1999 09:58: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: <199912031658.JAA11193@mt.sri.com> In-Reply-To: <3847F55E.B546B2EB@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> <199912031601.JAA10973@mt.sri.com> <3847F55E.B546B2EB@algroup.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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... > > Please re-read my statement. Who said anything about bogus > information? Compromised implies that the information is 'bogus' and/or wrong. > I'm talking about connecting to UDP ports (like NFS) that you're not > supposed to be able to connect to. Since his rule passes UDP that is > sourced from port 53 on the nameserver to ANY UDP port on ANY machine, > you are wide open to *attack*, not misinformation. Huh? How do you figure someone is going to *ATTACK* you by the process of *you* sending out information? > At some point, your chain of name servers has to talk to the outside > world, so this means the machine that does the final relay is open to > attack from the outside world. Right. But, they can only talk to known ports on your machine that you allow (including port 53). And, you only send out data *from* port 53 (as well as other known ports). I'm *really* confused as to how you think sending out data from a known port will compromise your machine? If so, then every machine with external servics has the potential to be compromised by the very act of sending out information. Please remove my confusion. :) 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?199912031658.JAA11193>