Date: Fri, 3 Dec 1999 13:47:43 -0800 (PST) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: adam@algroup.co.uk (Adam Laurie) Cc: nate@mt.sri.com (Nate Williams), jhb@FreeBSD.ORG (John Baldwin), freebsd-security@FreeBSD.ORG Subject: Re: rc.firewall revisited Message-ID: <199912032147.NAA81067@gndrsh.dnsmgr.net> In-Reply-To: <384812A7.EAAB3BD8@algroup.co.uk> from Adam Laurie at "Dec 3, 1999 06:57:43 pm"
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. Rules for DNS should not be written to protect NFS. You want another block of rules to do that. You also have to understand that there are broken DNS clients that will send requests from low numbered ports and if you block those ports on the DNS replies some clients will occasionaly experience DNS lags due to retries, and in a few rare cases total DNS loss. Yes, I have seen Microsoft stacks that use port 2049 as the source of thier DNS query, and yes I have filter rules that stopped that valid query dead in the track, and yes I took the network level 2 escilation problem report to figure out what the bloddy hell had gone wrong. Any modification to the block of rules I wrote to specifically address a single inside DNS server talking to the global outside type of network configuration will cause some DNS problems. Additional rules to protect NFS and other stuff are a totally seperate issue and have to be delt with seperately. I was only addressing the DNS issue, nothering more, nothing less. > > > > > > > > > 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. Ahhh.. now we jumped from a forwarding firewall to a single host, completely different ball game. IMHO, no simple single host should be running named, so: ipfw add X deny all from any to any 53 in via $if ipfw add X+1 deny all from any 53 to any out via $if Note, this _ONLY_ addresses DNS, and if your trying to write complete, coherent, understandable and working rules you have to deal with each and every one on that level. You can collapse whole blocks on the simple host case, but for a real forwarding firewall that often leads to errors. > > > > > 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? Provide a context or uni diff to -currents /etc/rc.firewall and I'll give you a ``review'', and a possible ``commit''. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net 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?199912032147.NAA81067>