From owner-freebsd-security Mon Aug 23 17: 3:31 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 948FD15942 for ; Mon, 23 Aug 1999 17:03:24 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id RAA36810; Mon, 23 Aug 1999 17:03:21 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199908240003.RAA36810@gndrsh.dnsmgr.net> Subject: Re: IPFW/DNS rules In-Reply-To: <199908232255.QAA02707@mt.sri.com> from Nate Williams at "Aug 23, 1999 04:55:34 pm" To: nate@mt.sri.com (Nate Williams) Date: Mon, 23 Aug 1999 17:03:21 -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 > > > > > > 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. > ... > > > > 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 > > Except that you're still allowing connections *from* port 53 to any UDP > service in your network, which bothers me. (I'm doing it as well, FWIW, > although I'm limiting it to a single box.) > > *sigh* If you want me to write you a complete set of rules, you'll have to pay for that. I've given you the data you need to create a correct set, your just not looking at it right. > > 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. > > Ahh, this is an idea. This is essentially what I'm doing now, except I > didn't think to hide the master. :-), lots of folks do this, espcially when the real master is sitting on the long side of anything slower than fractional T1. > > However, we are trying to be more and more 'independant' of the parent > company, so for now I think we'll deal with the paranoia. Also, I don't > trust the people who are my secondaries as much to be secure. > > > Nate > -- 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