A big part of the security of our infrastructure is determined by the access control we enforce on all the components that form the DNSSEC signer infrastructure. Access control is important on several levels:
- Network level
- Access to machines and user privileges on these machines
- Access to sensitive data on the signer
- HSM roles
In this post, we’ll zoom in on how we intend to set up network level access control in our DNSSEC deployment; the other levels will be addressed in upcoming posts.
On the network level, we have singled out all components and enforce strict ACL rules. The diagram below shows our network setup:
The top-half of the diagram shows the core DNS and DNSSEC infrastructure that we maintain in each of the two colocations that have a signer instance. Each colocation has a DNS VLAN; this VLAN contains both the local authoritative nameserver(s) as well as the local OpenDNSSEC signer instance. Access to the VLAN is controlled by a firewall on the local router (shown as a separate component in the diagram). Each colocation also has a specific VLAN for the local HSM; again, access to this VLAN is controlled by a firewall in the local router.
The right hand side of the diagram shows an administrative VLAN containing systems from which system administration may be performed on both the HSM as well as on the DNS infrastructure.
Finally, the bottom right hand side of the diagram shows the SURFdomeinen server, which is the actual web portal in which users can manage their DNS zones.
The dotted red arrows in the diagram show the allowed flow of network data between the various components in the infrastructure. Let’s go through them one by one.
Inside the DNS VLAN, communication is allowed between the authoritative DNS server and the signer. The host-based firewall on the signer, however, will only allow SSH access and access on port 53 to the hidden DNS master running on the signer. On top of that (not shown in the diagram) all other authoritative nameservers that SURFnet operates also have access to this hidden master running on the signer.
The other red arrow going in to the DNS VLAN comes from the SURFdomeinen server. This arrow signifies the DNS transfers that SURFdomeinen does to the zone input on the signer.
The red arrow leaving the DNS VLAN to the HSM VLAN is a link that allows the signer – and only the signer – access to the SSL port on the HSM that it operates to accept commands. On top of this link being shielded by ACL rules in the router, the link is also mutually authenticated using certificates, thus guaranteeing that only the signer can use the HSM. There is also a link from the signer in the other colocation to the SSL port on the HSM (not shown in the diagram); both signers can access both HSMs because the HSMs run in a redundant high-availability setup.
The final red arrow goes from the administrative VLAN to the administrative port on the HSM, allowing authorised system administrators access to the HSM to perform – for instance – backups.
As you can see, there is no direct access for administrators to the signer. System administrators do have access to the authoritative DNS servers (not shown in the figure), and from these they can then access the signer for system administration. This two hop route was deliberately chosen to make it harder for attackers to access the signer.
Note that all data never travels over the Internet but only within the SURFnet WAN.
What we want to show with this post is that it is important to consider access control on a network level. This is your first line of defense against possible evildoers. We recommend that you carefully consider which entities require access to certain resources, and to design your infrastructure such that by default all access is prohibited only opening up ports specific to particular entities to access particular resources. We also recommend that you document your network design so all parties that play a role in your DNSSEC deployment are aware of the restrictions that have been imposed and the rationale behind these restrictions.