BIND and TCP

[Brad Knowles]

At 4:11 PM -0700 2005-09-23, Michael Bernhardt wrote:

>  I'm running BIND 9.2.3. Our outside servers are set to only allow zone
>  transfers to our ISP's slave.

	That's good.

>                                 Our firewall is set to only allow UDP packets
>  to them, except to/from that slave.

	Uh, that's bad.  You cut off yourself to the entire outside world?!?

	If you're going to do that, then why do you even bother to come 
to us, asking for assistance?

>  I understand that BIND will use TCP for queries when the packet size of 512
>  is insufficient (if that's not correct, please educate me). I also am to
>  understand the RFC supposedly requires that DNS use TCP in these
>  circumstances. But we do not want to be bothered with everyone and their
>  bored brothers being able to do any more than absolutely necessary.

	Blindly blocking TCP port 52 is one of the worst things you can 
do.  If you want to prevent people from doing zone transfers to your 
server, you should control that within BIND itself, and not at the 
firewall.

>  Is there a way to tell BIND to never use TCP?

	No.

>                                                 Does anyone have
>  recommendations on how to best balance security and proper application, with
>  the edge going toward security? Can't find anything on this in the O'Reilly
>  BIND book but maybe I missed it.

	On the topic of blindly blocking TCP port 53, I don't think that 
Cricket would ever be so stupid as to recommend that anyone do that. 
In fact, I don't think that he'd even discuss it, so that he doesn't 
accidentally give people the wrong idea.

	Here are some rules-of-thumb:

		1.  Make sure you're running the latest code.  Earlier versions of
			the code have had significant security or operational issues.

		2.  Split your authoritative and caching/recursive services, ideally
			onto completely separate machines.  If you are forced to run them
			on the same machine(s), then you should at least run separate
			instances listening to different IP addresses.

		3.  Run a host-level firewall on each of the nameserver machines,
			configured to be fully stateful on both UDP and TCP packets.
			Don't have it block any port 53 traffic, but do have it toss
			"Martian" packets, "Christmas tree" packets, packets from
			non-existent networks, and any other sort of obviously bogus
			traffic.  Any good book on host firewall configuration should
			have a decent set of starter firewall rules.

		4.  Tighten your BIND security so that you allow only known local
			clients to send queries to your caching/recursive-only server,
			and so that you refuse zone transfers on your authoritative-only
			server.

		5.  Think "defense in depth".  Have multiple layers of security,
			and realize that 90% of security violations come from people
			who are misusing their authorized access (e.g., a disgruntled
			employee), or exceeding their authorized access (e.g., a
			clerk who is getting into files s/he should not).  Using just
			one piece of equipment to provide all your security at one
			point is a recipe for disaster -- once people find a way around
			that point, everything inside would be wide-open.

			Defense in depth is what the Germans did *not* have in the
			Normandy invasion in WWII.  Once the Allies broke through the
			lightly defended front lines, they were able to quickly sweep
			through France, the Netherlands, and most of Belgium.

	Note that there are some IP spoofing tricks that can be played 
with BIND to poison your cache, even if you've done #1, #2, and #4. 
Against BIND 9.3.1, there is only one known slight weakness to what 
is called a "birthday attack", and even that can be virtually 
eliminated by doing #3 above -- the stateful host level firewall 
would prevent those packets from ever getting to BIND.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

   SAGE member since 1995.  See <http://www.sage.org/> for more info.