securing bind in todays hostile environment

[Grant Taylor]

On 1/19/20 3:25 AM, N. Max Pierson wrote:
> Hi Grant,

Hi,

> 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.

Fair enough.

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 
answer.

> Paranoia I guess lol.

Hum.

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 
reverse zones.

> 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 
following:

  · 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 
criteria:

  · QNAME
  · 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
  - https://www.zytrax.com/books/dns/ch7/rpz.html

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 
products.

> 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.

You're welcome.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200119/b928b72f/attachment.bin>