Date: Fri, 3 Dec 1999 13:06:56 -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: <199912032006.NAA12109@mt.sri.com> In-Reply-To: <384812A7.EAAB3BD8@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> <199912031658.JAA11193@mt.sri.com> <3847F939.47978597@algroup.co.uk> <199912031729.KAA11375@mt.sri.com> <384812A7.EAAB3BD8@algroup.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > This works, believe me. I've done it. I can squirt data into a > > > "protected" syslog on port 514, which shouldn't be possible. Using my > > > rules, this is no longer possible. > > > > What I'm hearing you state is never trust anything outside your > > firewall, which is a great rule, but not one that I believe you can rely > > on. Sooner or later you must depend on *something* external (other DNS > > servers, etc...), but you can tighten them down. > > Ok, well we're making some progress then... you're almost hearing what > I'm trying to say... :) The problem here is that you're assuming a particular kind of setup that we're not assuming. You're assuming that the box is a standalone system, and we're not assuming that. The thing we're assuming is that this box is a firewall, which I don't believe you are assuming. From that, I think we can agree that attempting to build any sort of generic ruleset that fits every situation is impossible to do. > > 1) Drop anything that claims to be you coming from the outside. > > 2) Drop RFC 1918 unroutable traffic (incoming/outgoing) > > 3) Don't allow packets with a multicast source address (in/out). > > 4) Drop anything that isn't using an internal network address from going out. > > 5) Don't allow broadcast traffic in/out > > > > [ At this point, the traffic is mostly 'sanitized'. You know that > > whatever is coming and going is 'legitimate'. The outside stuff is not > > to be trusted. > > When I dial into the net from my notebook, there is only an outside. > No-one is 'sanitised'. Again, you're making an assumption about a particular setup. That assumption isn't any more/less valid than our assumptions, so we end up with a non-generic solution. > Anyway, can we get back to the matter in hand...? This *is* the matter at hand. You're making a solution for your situation, which is not necessarily appropriate for my situation, or for Rod's situation. The problem is that there is no generic solution. 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?199912032006.NAA12109>