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 masterold 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/rfc7534Similarly, 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
