BIND and TCP
Brad Knowles
brad at stop.mail-abuse.org
Sat Sep 24 12:55:22 UTC 2005
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.
More information about the bind-users
mailing list