From owner-freebsd-security Mon Aug 23 15:34:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 597031580E for ; Mon, 23 Aug 1999 15:34:35 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id PAA36466; Mon, 23 Aug 1999 15:34:21 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199908232234.PAA36466@gndrsh.dnsmgr.net> Subject: Re: IPFW/DNS rules In-Reply-To: <199908232108.PAA02230@mt.sri.com> from Nate Williams at "Aug 23, 1999 03:08:30 pm" To: nate@mt.sri.com (Nate Williams) Date: Mon, 23 Aug 1999 15:34:20 -0700 (PDT) Cc: freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > > I've got some rules in place, but if someone has gotten DNS firewall > > > > > rules I'd be grateful to see them. > > > > > > > > These rules only log things, they are not meant to stop things, all logs > > ^^^^^^^^ You didn't pay attention to this very > > important point about what these rules DO. I also said later on how to > > change them to do what you wanted. > > Sorry, you're right. I missed that. > > > > > ipfw add 10539 allow log tcp from any to any 53 > > > > > > This seems insecure to me. Any external host can connect to port 53 on > > > your internal hosts. Also, internal hosts can 'leak' information out > > > externally. > > > > You missed the clause above about ``only log things'', change that > > rule from ``allow log'' to ``deny log'' and it does just what you > > wanted. > > Gotcha. See below. > > > > > ipfw add 40530 allow udp from any to A.B.C.D 53 > > > > > > Fairly secure, as long as BIND on A.B.C.D is secure, which we hafta > > > assume at some point. :) > > > > A.B.C.D is YOUR DNS server, you are in control of how secure it is. > > I know, I was (attempting) to be funny. Obviously I failed. :( I missed the :), too few characters for my parser to see it as a smiley, I'll have to go look for the bug in it, must be an off by one error, nope it was a bad regex, needed 3 characters to trigger it, fixed :-) ... > > > > > > > ipfw add 40539 allow log udp from any 53 to any > > > > > > This is also insecure, in that it allows anyone to use source port 53 to > > > connect to *any* UDP port in your network. > > > > You have no idea what my other 400 rules do. All those other UDP ports > > are handled some place else. If you wanted a full firewall rule set, > > well, that'll be $100/hr... > > I've done my best, but I couldn't figure out a 'clean, effecient, and > safe' way of allowing DNS (and NTP, which is in the same boat) to work. > The rules before must disallow connections, but I don't see how you can > do that and still allow connections from port 53. Yes, my rules before these have large blocks of udp/tcp ports that log thier activity, for what you want it would be something like: ipfw add 100 deny log tcp from any 1-52 to any ipfw add 100 deny log tcp from any 54-65535 to any ipfw add 200 deny log udp from any 1-52 to any ipfw add 200 deny log udp from any 54-65565 to any And of cource, the reverse rules ipfw add 300 deny log tcp from any to any 1-52 ipfw add 300 deny log tcp from any to any 54-65535 ipfw add 400 deny log udp from any to any 1-52 ipfw add 400 deny log udp from any to any 54-65535 Now you get what I am doing? The above scripts would in effect shutdown all IP packets except tcp/udp port 53 before it ever hit my other rules. Now, I don't use that wide of port ranges in the real rule set, but there are some pretty big ones that cover a 100 or so ports here and there. > > > > However, I don't like what I have, and was hoping someone could tell me > > > how to lock things down better. > > > > Turn the box off? :-) :-) > > Yeah, wouldn't that be easy. :) Outsource your DNS services so that no public queries ever hit your master would be another way. This is known as a hidden master DNS server, you simply get 2 public secondaries, list them in the SOA for the zone, but leave out the real master. No one even knows to go look at your box, except if they break into the slaves. If you only have a few zones, dnsmgr.net could deal with them for you... -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message