Date: Fri, 03 Dec 1999 18:57:43 +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: <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>
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 whole point of a firewall is to stop people doing what they're not supposed to do. I'm happy to trust my nameserver to send me DNS. That's all. I don't want it connecting to my NFS mounts, or my syslog or anything else. Rod's rules allow this, and my rules prevent it. Simple as that. > > > > > > As long as we don't allow 'spoofed' traffic to appear to be coming from > > > $dnsserver, this is a very safe set of rules (although incomplete, as > > > Rod points out). > > > > How do you tell the difference between a spoofed packet and a > > non-spoofed packet with ipfw? > > By the IP address being used. If the source is from an address behind > the firewall, it's spoofed. The IP address is the thing being spoofed. It will appear to be the DNS server. If you've only got one interface, there's no way to see the difference between the spoofed and the real. > > Otherwise, you can't know (or care), because 'spoofing' is often used > for legitimate reasons. So, you must assume that any traffic outside is > suspect, and make sure that any 'suspect' traffic is filtered correctly > and hope you catch everything. > > Here's my rules. They could be re-ordered, and probably simplified, but > they work pretty well. > > 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'. Anyway, can we get back to the matter in hand...? This was not intended to turn into a masterclass for firewall rule building - just a simple set of replacement rules for the current ones, regardless of how complete they are. I have pointed out some specific deficiencies in the current rules and proposed some amendments. No-one has yet pointed out a flaw or a hole in my rules, except that they are "not complete". I agree, but they do do the job they set out to do, unlike the current ones... i.e. block low port udp, and nfs, but allow dns and time. Where's the problem? 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?384812A7.EAAB3BD8>