From owner-freebsd-security Fri Dec 3 9:30: 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 DC2F1151EF; Fri, 3 Dec 1999 09:29:40 -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 KAA28992; Fri, 3 Dec 1999 10:29:18 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA11375; Fri, 3 Dec 1999 10:29:16 -0700 Date: Fri, 3 Dec 1999 10:29:16 -0700 Message-Id: <199912031729.KAA11375@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: <3847F939.47978597@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> 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 > > > I'm talking about connecting to UDP ports (like NFS) that you're not > > > supposed to be able to connect to. Since his rule passes UDP that is > > > sourced from port 53 on the nameserver to ANY UDP port on ANY machine, > > > you are wide open to *attack*, not misinformation. > > > > Huh? How do you figure someone is going to *ATTACK* you by the process > > of *you* sending out information? > > > > > At some point, your chain of name servers has to talk to the outside > > > world, so this means the machine that does the final relay is open to > > > attack from the outside world. > > > > Right. But, they can only talk to known ports on your machine that you > > allow (including port 53). And, you only send out data *from* port 53 > > (as well as other known ports). I'm *really* confused as to how you > > think sending out data from a known port will compromise your machine? > > ipfw add X pass udp from any to ${dnsserver} 53 > ipfw add X+1 pass udp from ${dnsserver} 53 to any > ^^^^^^^^^^^^^^^^^^^^^^ > This rule says the name server can talk to any UDP port on any machine > (including the firewall itself) as long as it's sourced from port 53. > Since I, as the attacker, now own the nameserver, I can use port 53 for > anything I like (as I demonstrated in my original post using netcat). Ahh, you're assuming that 'dnssever' is compromised? *light bulb* In this case, you're screwed. There is *NOTHING* (nadda, zero, zilch, zippo) that can be done to protect from this. If you're nameserver is compromised, you're hosed. That's why most folks that I know run the nameserver that they trust either *ON* the firewall, or on a host inside the firewall. Then you have a bastion DNS server for the world outside the firewall that gets all of it's information from the internal firewall, but if it's compromised you don't lose the internal integrity inside the firewall. > 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. > > > 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. 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. Next, the policy decisions for TCP. 1) Block out silly TCP services from being made from internal hosts [ Normally, we trust our users not to do stupid things, but that's a policy decision on our part. However, certain services should never be attempted. ] 2) Block out all traffic from 'evil.org' hosts. (Local policy) 3) Allow in SMTP *ONLY* to the firewall (I only have to worry about one version of sendmail now) 4) Block out 'SMTP' from being from internal boxes (just in case) 5) Allow other TCP connections to be made *from* internal hosts (scarey, but current policy ) 6) Allow in secure services (SSH) and certain necessary services in a limited manner to my internal DNS server (DNS/TCP). # Next, policy decision for UDP 1) Allow in UDP connections from anywhere to whatever port my service lives on (DNS/53, NTP/123). 2) Alllow outgoing queries from these server to go out only from the machines with that service. 3) Filter out responses from low-numbered ports incoming (we've allowed people to connect to our well-known services, we know block out other services which may appear to come from well-known ports as responses to our requests). [ Note, a stateful firewall such as IPFilter wouldn't need these rules ] 4) Allow outgoing responses from our internal services. 5) Allow incoming responses to our internal server requests. Block the rest! Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message