From owner-freebsd-security Fri Dec 3 12: 7: 6 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 8A8C71517B; Fri, 3 Dec 1999 12:07:03 -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 NAA00527; Fri, 3 Dec 1999 13:06:57 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA12109; Fri, 3 Dec 1999 13:06:56 -0700 Date: Fri, 3 Dec 1999 13:06:56 -0700 Message-Id: <199912032006.NAA12109@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Adam Laurie Cc: Nate Williams , "Rodney W. Grimes" , John Baldwin , freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited 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> 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 > > > 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