Re: BIND-8.1.1 w/ "allow-query" OR split-DNS?

[Matthew Patton <patton () sysnet net>]

This came up (again) in fwtk-users and I wanted to bounce my thoughts off a
larger community. Hope you don't mind.

> > Hello fellow firewallers,
> >
> > after having built some firewalled networks with FWTK and split-DNS with
> > BIND-4.9.5 (both on the bastion and on the internal nameserver, being a
> > "slave") I had to look for a "cheaper" solution.  All I wanted to do was
> > building a firewall with only 1 host.  No need for mail forwarding.

IMO, you'd be smarter to run 2 intances of bind 8.1.1 on the bastion and
chroot each of them to their own little space as well as explicitly
specifying which interfaces the instances can bind to. You can play even
funnier games by su'ing after the chroot to force the daemon to run
non-privileged on a high port. (you need to add something like IPNAT to the
mix however) This is what I did for a while. If you need configs, I have
them. BTW, is there any means of doing a chroot and su at the same time? As
far as I can tell you can't. If you're su'd to a low account you can't use
chroot. If you're chrooted you have to place the su binary inside that
tree. Bummer. (yes, yes the binary is chmod 0100, owned by root and tagged
immutable)

Recently I had decided to simplify the firewall a tad and offload the
internal DNS onto a box on the DMZ. Running chrooted of course. I'm not
sure I really like this but at least it's consistant with my policy that
NOTHING on the DMZ can initiate an outbound connection to either the
Internet or internal network. The one major drawback I see is that if
somebody has control of a host on the DMZ they can attempt to poison my
primary DNS that serves the internal network. Oops! Not to mention all of
my internal hosts (or at least secondaries) will need to cross the firewall
to get DNS information. Upon further thought, this doesn't sound like such
a smart idea at all!!

If the firewall held both instances (like it did originally) there is a
very small tradeoff (basically political) in allowing a DMZ host to even
contact the firewall. I initially wanted (and am now reconsidering) the
firewall to be invisible for all practical purposes. If the name server
were located in the internal network, I'd have to open holes for the DMZ to
talk thru. No matter where I put it, the DMZ has to be able to do DNS
lookups so there doesn't seem to be a big win in any of these alternative
configurations.

However, there is a 3rd option (lightbulb!) which is that the DMZ hosts
could get their own limited view of the network (like outside hosts do), or
I run a slave server in the DMZ which get's a full view of the internal
mappings from the real master (located on the internal network), and this
slave furthermore forwards all unresolved (ie. foreign) lookups to the
firewall's pubic (ie external) instance. This at least solves the cache
poisoning problem of my primary name server. I'd have to look into seeing
if secondaries can be instructed to accept updates only from primaries.
Then again, if an attacker is sitting on my DMZ he's potentially quite
capable of spoofing packets and I've got a huge problem and the whole house
of cards collapses. (Note to attacker, bring you're own tools cause you
ain't going to find them on the DMZ) Hmmm... maybe I *should* use the built
in IPSEC capabilities of OpenBSD afterall. But the flip side is IPSEC
(actually photuisd) uses RPC and dynamic ports. Damn!

Somewhere in all of this, the increasing complexity of the configuration
starts to outweigh the benefits of better security. Has anyone tried
something as 'bizarre'  as that last idea? Just for laughs I might try
running 3 intances of bind v8.1.1, a copy for each interface, each with
different views of the domain on the firewall. (no sense letting that
486/66 just sit idle all day long, right?) Still I think that's getting a
bit rediculous even if I were to pursue security thru obscurity to the
hilt. The upside is the marginal cost of another intance of bind on the
firewall is pretty small.  Need I also mention that the firewall itself
doesn't use DNS for it's rules and like the DMZ is incapable of originating
connections (DNS sessions excepted)?

Does it gain the attacker any particular advantage if he knows the names
and IP addresses of all of the internal hosts? Bear in mind he has to be
sitting inside the DMZ to do this (barring a DNS root egg being discovered)
and that the firewall isn't going to let him do anything about sending
these hosts any packets. Well, I guess of course he could try to see if any
of the DMZ hosts had trust relationships with internal ones that he could
exploit. But if I'm allowing that, I'm a flaming idiot to begin with. (I
guess I WILL do those remote backups by hand instead of cron...) The more I
think about this the more it seems like a catch-22.

Any further thoughts or feedback from the esteemed community? Am I nuts?
It's 11pm on a Friday night and here I sit aganizing/debating this with
myself. Boy, do I need a life!!

--------
"I've always thought we could solve a lot of problems if we didn't let
managers read PC magazines." - Corporate Software & Technology's Mickey
McIntire