securing bind in todays hostile environment

[Grant Taylor]

On 1/18/20 7:06 AM, N. Max Pierson wrote:
> Hi List,

Hi M,

> First off, I should note that I am a novice with administering Bind, so 
> please bear with me.

We all started somewhere.  Hopefully we all continue to learn new 
things.  ;-)

> We are looking to be more pro-active and security minded in our network 
> in general and while we are getting ready to completely replace/upgrade 
> our current instances of Bind, I would like to hear of opinions of the 
> following ansible role that would install, setup, configure, etc our 
> instances taking security into account. I have read some of the common 
> best practices on this very list over time but wanted to ensure what was 
> in this role wasn't missing anything in terms of securing the deployment.

«hat tip»

> So I am aware it’s preferred to split recursive and authoritative 
> services across different instances.

Yes, that's the ideal design.  Unfortunately that doesn't always scale 
down to where some people need it.  It quickly starts to be more 
complexity for smaller networks, particularly SOHO networks.  :-/

My current understanding is that if the server is accessible from the 
Internet, then it probably really should have the recursive and 
authoritative roles separated.  If it's not accessible from the 
Internet, then it's more up to your discretion of what makes sense for 
your network.

My preference for smaller networks that may have multiple servers but 
don't warrant separate servers is to have multiple recursive servers 
slave internal zones off of the internal authoritative master.

> I also understand it’s preferred to use one of the “out of zone” 
> (apologies for not knowing the proper terminology) master methods (such 
> as hidden or shadow master).

I do think it's a good idea to separate recursive servers for clients 
from the master server for the internal zones.  If this is possible in 
your network.  I don't have any reason to hide the master or prevent 
clients from being able to communicate with it.  In fact, clients may 
/need/ to communicate with the master.  I see no reason not to list the 
master as an additional NS record in the zone.

One thing that I couldn't tell from your description is if you need to 
support dynamic updates from clients.  I.e. Windows workstations 
updating DNS based on new DHCP lessees, et al.  This has some 
complications in that the last time I dealt with this, the workstations 
sent their DDNS updates to the master, thus needed to be able to 
communicate with the master.

> It’s also a very good idea to deploy TSIG for transaction 
> signing. And of course, ACL recursive lookups as well as AXFRs.

Why do you want to ACL /recursive/ lookups?  Why single out /recursive/ 
for additional protection?  I'd think that you would want to apply the 
same protection to all DNS server access.  Possibly with a belt and 
suspenders method with the BIND and host firewalls / routing.

> Beyond that, what other best practices should be considered when 
> making a deployment such as the following scenario ….
> 
> ns1 - ns4: authoritative name servers - slaves
> ns0 - hidden/shadow master
> 
> old ns1- ns4: will be used as recursive as these were deployed doing 
> both authoritative and recursive many years ago and policy routing for 
> these old IPs is very ugly, so we would like to keep them there after an 
> upgrade as opposed to try and figure out who’s still using them to 
> notify we’re changing the IPs

Another option to avoid PBR and mass client changes is to use 
traditional routing to get to the ns1–ns4 IPs.  Bind said IPs to a 
loopback / dummy interface on the DNS servers and rely on the networking 
to route to these /32 / /128 IPs.  You effectively turn these IPs into 
Service / Virtual IPs that you can move around your network as you see 
fit.  Of course, this does rely on a routed L3 boundary between your 
clients and ns1–ns4 IPs.  But I'm guessing you already have that.

> The ansible role can be seen here at 
> https://github.com/juju4/ansible-bind . So you don’t have to click on 
> the link, what this role does to secure bind in summary is as follows:
> 
> - Secure template from Team Cymru template 
> (http://www.cymru.com/Documents/secure-bind-template.html). Please note 
> than separated internal/external views are not implemented currently.
> - DNSSEC for authentication,
> - RPZ to whitelist/blacklist entries
> - Malware domains list blackholed

How are you doing the black hole if not with RPZ?

Remember, you can have multiple RPZ zones, as well as RPZ white lists to 
override subsequent RPZ black lists.

> - Eventual integration with MISP RPZ export

I would probably plan for this at deployment time.  Possibly with a stub 
empty (save for requisite zone metadata records) from the start.  Then 
you can simply replace that stub zone with actual MISP content when 
you're ready to do so.

> - Authoritative DNS (mostly for internal zones) Mostly as 
> cache/forwarder but could be other roles.
> 
> Taking into consideration what I have already learned plus the few 
> things above mentioned on GitHub (mainly the security template and 
> malware domain blackhole as we do not use RPZ or Views), is there 
> anything else that should be considered/added/changed/removed to/from 
> the defaults of this role when we go to deploy the above scenario?

I would encourage you to start with stub RPZ configuration, especially 
if you know that you want it.

I would encourage you to think about starting with views, even if 
everything is in a single view.  Doing that will allow you to more 
easily add additional views without needing to clear the hurdle of going 
from no views to multiple views.

I would strongly suggest that everybody read about BIND's deny-answer-* 
filtering capability.  In short, it allows you to tell BIND to filter 
answers containing IPs in the first list except for zones in the second 
list.  This will help prevent attacks, like DNS Rebinding, that cause an 
external name (not in the 2nd list) from resolving to internal IPs (in 
the 1st list).

    // block name to protected IP
    deny-answer-address { … } except-from { … };
    // block alias to protected name
    deny-answer-alias { … } except-from { … };

I'm a fan of BIND's empty zones and tweaking them to look mostly like 
what IANA uses.

    empty-zones-enable   yes;
    empty-server         "prisoner.iana.org";
    empty-contact        "hostmaster.root-servers.org";

You can adjust server and contact as you like.  I was trying to make my 
server respond as close to the same way as would be responded by 
external servers.  (Don't make it obvious that something local is doing 
this filtering of non-local zones.)

While you're filtering spurious zones that you aren't authoritative for, 
take a look at AS112.

Link - AS112 Nameserver Operations
  - https://tools.ietf.org/html/rfc7534

Similarly, consider being a root zone slave.  If your version of BIND 
supports it, use mirror zones instead of a slave zone.

Aside:  A mirror has a better failure mode than slave a slave zone. 
Mirror fails as if it doesn't exist instead of a broken slave breaking 
things.

I'm a big fan of DNSSEC.  But sometimes you need to "break-dnssec", 
particularly if you're doing things like RPZ or overriding external 
domains with internal zones or filtering AAAA for some reason.*

*I've had to filter AAAA records for IPv6 enabled clients to be able to 
access Netflix b/c Netflix doesn't like my IPv6 provider.  :-(

Enable "minimal-responses".

Depending on how many internal zones you have, and how dynamic they are, 
you may want to consider catalog zones.

TL;DR:  Catalog zones are a way for slave servers to learn what zones 
they should serve, where the masters are, and other pertinent 
information.  Read:  Less reconfiguration.

Given that you're talking about five servers, in what sounds like an SMB 
configuration, you might appreciate rndc's ability to remotely control 
servers.  Be it from the from the master to the slaves or management 
workstation(s) to all DNS servers.

Depending on your environment, you might appreciate a VPN (or something 
else to protect traffic) between servers.  IPSec Transport Mode with 
minimal (manual / automated / orchestrated) configuration comes to mind.

You may be interested in BIND's monitoring and / or API interface too.

Finally, I believe there are methods to allow clients to authenticate to 
BIND via Kerberos for things like authorizing DDNS.  Also,

Link - RFC 2136 Dynamic DNS Updates using GSS-TSIG and Kerberos
  - 
https://jpmens.net/2012/06/29/dynamic-dns-updates-using-gss-tsig-and-kerberos/

I'm sure that there are other things to think about.  But that's what 
came to mind as I read and replied while drinking coffee.  I'll be 
keeping an eye on this thread to learn what others think and suggest.



-- 
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/20200118/5002ed21/attachment.bin>