Date: Sat, 04 Dec 1999 13:02:13 +0000 From: Adam Laurie <adam@algroup.co.uk> To: Nate Williams <nate@mt.sri.com> Cc: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, John Baldwin <jhb@FreeBSD.ORG>, freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited Message-ID: <384910D5.43271787@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> <199912032006.NAA12109@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams wrote: > > > > > 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. As I pointed out earlier on, this is a generic solution - it just needs a few different versions of the rules to cope with each scenario. I will say it one last time, then give up: your ruleset allows UDP services to be attacked from a "trusted" host, or something that is able to spoof it. Mine does not. cheers, Adam -- Adam Laurie Tel: +44 (181) 742 0755 A.L. Digital Ltd. Fax: +44 (181) 742 5995 Voysey House Barley Mow Passage http://www.aldigital.co.uk London W4 4GB mailto:adam@algroup.co.uk UNITED KINGDOM PGP key on keyservers 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?384910D5.43271787>