securing bind in todays hostile environment
gtaylor at tnetconsulting.net
Sun Jan 19 17:23:36 UTC 2020
On 1/19/20 3:25 AM, N. Max Pierson wrote:
> Hi Grant,
> I should have been a little more descriptive in the scenario by giving
> the purpose of these name servers. They are basically being deployed
> as a managed DNS service that we offer. We are a MSP for the most
> part and the DNS infrastructure was not being very well maintained
> when I got here. Knowing that and the fact we sell this as a service,
> it needs more attention that it has gotten in the past plus someone
> with more knowledge than the ones that originally set them up. Having
> that said, I have my work cut out for me.
With that in mind, I'm speculating that the list of zones (in scope)
will be somewhat dynamic. As such, I *STRONGLY* encourage you to take a
look at catalog zones.
I'm sure that you can get Ansible to add / remove / modify the list of
zones on the slave servers. But is that the best solution when BIND has
something built in for doing the same thing?
> We do not use dynamic entries and as far as the hidden/shadow master,
> I do not have an issue with the master being on the public segment
> and part of the NS records. I was thinking of simply poking a hole in
> the firewall to a static NAT for the master (restricted by the slave
> IPs) so that it could be contacted from the outside. I would have the
> master in the DMZ. Since this isn’t being used for any internal name
> services, I guess it may not make much sense to have it in the DMZ.
If the master is functionally identical to the slaves, save for the
master vs slave configuration, then it probably can live with the
slaves. However, if the master has any other data / configuration /
internal DB access / etc, I would recommend that it be separated.
I like to think of slave servers in the DMZ as a line of defense for the
master. Sometimes it's appropriate, sometimes it isn't.
I don't know your network topology. But I'd be tempted to see if I
could use standard routing in lieu of NAT between the slaves and the
master. At least I would evaluate if it's reasonably possible to do.
Is the added complexity of NAT /required/ -> /needed/ -> /desired/? The
same questions should be asked about routing, and chose the appropriate
> Paranoia I guess lol.
I'm failing to understand why the /reverse/ zones have more security
than /other/ zones.
I guess I should mention that I'm assuming that you're talking about
in-addr.arpa zones for reverse DNS of globally routed IPs. As such, I
would think that (at least the slave) servers should be accessible for
the world to query.
> I should have mentioned said servers will have proper IPtables
> configured but will not have a formal next-gen firewall appliance in
> front of it. Even though we do implement some sort of packet filter
> for access to the services, I also tell bind to only respond to
> certain sources as well. Possibly overkill and more administrative
> work but I always go back to the “security in layers” train off
> thought. And since we use ansible for management, the second argument
> is sort of moot.
Sure. Multiple levels of defense is a good thing. I'm an advocate for
closing and latching every picket fence gate.
I'm still pondering if the zones are public or private and what the
scope of access /should/ be.
I would still expect the scope of access to be the same for forward and
> Your strategy for putting the old resolver IPs as loopbacks on the
> new servers is a spiffy idea that I had not thought of before. That
> would make life easier as it could be queried by the interface IP for
> new users should we want to use the new IP and the old users would
> still just work because of the loopback. And we actually have each
> server on it’s own /29 or /64 (due to VRRP) so the actual IPs are
> very easily movable.
> As or the RPZ, I understood how it works at a high level but have never
> had the experience in using it. I was not aware the blackhole mechanism
> was also provided by it ( i had assumed they could send responses to
> something like /dev/null which Im guessing is now wrong ), so I do
> need to correct my self and state that we will need them because I
> intend on implementing filtering at that level since it is available.
Ah. Response Policy Zones are — in my (not so) humble opinion — wonderful!
Depending on the version of BIND in question, you can do (at least) the
· Return an NXDOMAIN for a QUNAME with ".".
· Return a NODATA for a QNAME with "*.".
· Return the response unmodified with "rpz-passthru.".
· Drop the response with "rpz-drop.".
· Truncate the response with "rpz-tcp-only.".
· Replace the response with local data.
You can trigger the above actions based on (at least) the following
· IP in response
· Client IP
· Name Server Name
· Name Server IP
The following page on Zytrax's site is one of my favorites for RPZ info.
I actually quite like Zytrax's site for all things BIND related.
Link - BIND9 - Response Policy Zone Configuration
Note: Depending how serious you are about filtering, there is a
relatively new — and seemingly lesser known — BIND technology, Response
Policy Service. I liken RPS to Sendmail milters to actively filter DNS
content. Conversely, RPZ is more a comparison of a static list. An RPS
back end could do more active analysis on queries and / or replies.
I've not done much with RPS, because it's still relatively new, somewhat
under documented, and all the backends that I'm aware of are commercial
> As for the rest, some of them would not apply since these are public
> servicing name servers and not internal. The rest of the suggestions
> will certainly be researched more so that I can fully understand how
> to implement them should they apply to our deployment.
> Thanks for the lengthy and descriptive response. It gives me several
> things to think about and research.
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
More information about the bind-users