AWS Public Sector Blog
Using Protective DNS services with AWS workloads
Protective DNS services, commonly known as PDNS, are a go-to solution if you’re aiming to bolster the security of your infrastructure from the ground up. Unlike traditional methods involving software-based agents or devices for traffic filtering, PDNS services take a unique approach – they scrutinise the DNS requests made by users and adjust responses based on predefined rules within the service.
This proactive strategy not only secures networks at a foundational level, but also hinders potential attacks from gaining traction in the first place. Additionally, PDNS services offer real-time visibility into DNS traffic, enabling swift identification and response to security threats. In this post, we explore the seamless integration of PDNS services with workloads in the Amazon Web Services (AWS) Cloud, showcasing their effectiveness in enhancing cybersecurity within cloud environments.
How PDNS services work
Organisations in the public sector, and other regulated industries, often have a need to ensure that important workloads or devices are not easily compromised. Preventing workloads from making requests to malicious websites, by stopping the workload from being able to resolve a DNS name, is an important step.
For example, a PDNS service could mitigate against a botnet threat. Botnets often need to contact command and control infrastructure to receive instructions and report back results. In addition, they also often look to spread on a network by reporting to the control infrastructure on other visible hosts and await new instructions. Botnet behaviour is, therefore, not confined to a specific host, making the infection inherently more problematic because the attack scope is larger. Botnet attacks can be made significantly less impactful by restricting access to the control infrastructure. Furthermore, we can limit the impact of attempts to exfiltrate data to malicious third parties.
Because PDNS services alter DNS responses, their behaviour is ordinarily configured using response policy zones, or RPZs. An RPZ is a policy which sits alongside the resolving functionality of a DNS server. RPZ policies are usually updated regularly, in line with threat intelligence received from trusted sources. You can gather threat intelligence on existing networks or from both public and commercial sources. RPZ policies are written in the same format as Berkeley Internet Name Domain (BIND) DNS zones.
When a client makes a DNS request, the request is forwarded to the PDNS service. In turn, the PDNS service looks up the requested domain in the RPZ policy and responds according to the policy’s configuration. The PDNS service may act in one of several ways, depending on its configuration:
- Send back an NXDOMAIN response (as defined by RFC8020), indicating to the client that the domain couldn’t be resolved to an address.
- Respond with an address different to the address which would exist on other DNS resolvers. This allows an organisation to, for example, display a page explaining to clients that an issue has occurred, and where to seek further assistance.
- Respond with a custom response, allowing for responses to be logged, and security operations teams to be alerted to the existence of such a response being issued. In turn, this allows teams to investigate issues. Further, custom responses are especially useful whilst a threat is still occurring, enabling the security operations team to investigate an issue in real time without causing unnecessary harm to clients on the network.
PDNS services are offered by a variety of organisations, both commercial and public sector, across the world. Examples include Cisco Umbrella, Vercara UltraDDR, the National Security Agency (NSA) Cybersecurity Collaboration Center (CCC) Protective DNS service, and the National Cyber Security Centre (NCSC) Protective DNS service.
Some providers of PDNS services offer additional features, such as automated recognition of suspicious, yet previously unseen, domain names. In addition to the breadth of threat intelligence sources available, these features differentiate PDNS services from each other, and those considering using a PDNS service should – where possible – weigh up alternative services against each other.
In the following section, we show an example architecture to implement third-party PDNS services for AWS workloads to make sure that they can meet, for example, compliance needs. If you wish to deploy your own PDNS capability, rather than implement a pre-existing one, you should consider AWS Network Firewall or Amazon Route 53 Resolver DNS Firewall.
Protecting AWS workloads with PDNS services
Network Firewall and Route 53 DNS Firewall are excellent options if you’re looking to establish your PDNS service. However, you may need additional mandated functionality provided by third-party PDNS services. This could be due to limitations such as lack of access to a comprehensive array of threat intelligence sources provided by externally-operated services. In this example, Amazon Route 53 Resolver can be utilised to direct traffic to an external PDNS service using the following approach in Figure 1.
Figure 1. An example architecture for integrating Amazon Virtual Private Cloud (VPC) with a PDNS service. The major components are VPC, Route 53 Resolver, and optionally, Route 53 Resolver DNS Firewall.
The preceding architecture highlights how an application running in a private subnet would interact with an Amazon Route 53 Resolver outbound endpoint, following these steps:
- The private subnet hosting the application has a Network ACL (NACL) in place, which allows or denies specific inbound or outbound traffic at a subnet level.
- If traffic is not blocked by the NACL, it is directed to the NAT Gateway in the public subnet.
- The NAT Gateway sends traffic to the Route 53 Resolver DNS Firewall, which filters traffic and regulates outbound DNS traffic before reaching the Route 53 Resolver.
- The Route 53 Resolver DNS Firewall forwards the traffic to the Route 53 Resolver outbound endpoint.
- When traffic reaches the Route 53 Resolver, logging takes place to allow observability. Route 53 Resolver Query Logging allows insight in to DNS queries in your VPC, which can be useful for compliance, threat detection and troubleshooting. Logs are sent to Amazon CloudWatch Logs, from where further analysis could take place using Amazon CloudWatch Log Insights to create metrics and alarms.
- Finally, the request is forwarded to the PDNS service which is then responsible for responding to the client’s request, utilising its own rules and threat intelligence sources to respond appropriately.
When implemented, this design protects workloads that run in VPCs to which the resolver rule is attached. This design scales resolving external addresses (such as those that don’t resolve to resources inside a VPC or to AWS services) to a trusted resolver across multiple VPCs. With appropriate consideration for cross-account networking, it could also be implemented through a transit gateway to provide centralised access to the PDNS service from multiple accounts.
In many cases, if you use third-party PDNS services, you can also configure how the PDNS service responds by amending rules. This provides a degree of flexibility unmatched by running a service of your own. You can choose to define custom behaviours, should your PDNS service offer such a feature, whilst relying on a trusted source backed by threat intelligence.
Conclusion
Organisations in regulated industries, and those with stringent security controls, often have requirements to make sure that their DNS requests don’t provide an easy route to target important workloads with DNS-based attacks. Gaining visibility in to the DNS requests made by infrastructure supporting important workloads helps security teams to gain real-time insight on the behaviour of their applications – and helps to spot anomalies. By using services such as Route 53 DNS Firewall or Network Firewall, or third-party offerings, to provide protective DNS capability, organisations can mitigate threats such as botnets and data exfiltration attacks.
The example architecture not only ensures protection across VPCs, but also enables compliance adherence and threat detection through comprehensive logging, making way for future analysis using services such as CloudWatch or existing security tooling.
Integrating AWS workloads with protective DNS services provides organisations with heightened security requirements a reliable means of safeguarding against DNS-based attacks without the burden of managing additional infrastructure. The integration of PDNS services with AWS workloads reinforces cloud resilience against evolving cyber threats, ensuring a secure environment for critical workloads.