Best Practices for Securing Cloud-Hosted DNS Services like Amazon Route 53

This post was originally published here by gregg rodriguez.

Amazon Route 53 is a highly available and scalable cloud-based Domain Name System (DNS) web service offered within AWS. Like any DNS, Route 53 handles domain registration and routes usersā€™ Internet requests to your application, whether itā€™s hosted on AWS or somewhere else.

Route 53 is designed to give developers and businesses an extremely reliable and cost-effective way to route end users to Internet applications by enabling the translation of domain names/URLs into numeric IP addresses that computers use to connect to each other.

It is a critical component of how end users are able to interact with the vast number of network resources at their fingertips and it takes management off your hands, especially internal traffic, even for internal networks, not just cloud. More importantly, Route 53 intelligently directs traffic based on sophisticated routing policies and, through automated health checks, away from servers that might be failing. It is also fully compliant with IPv6 as well.

Why is it important to secure your DNS services?

Securing your DNS services, such as Amazon Route 53, benefits both end users and service providers, as the critical nature of DNS makes it a sought-after target for those attempting to compromise or disrupt Internet services.

A 2018 survey byĀ EfficientIPĀ of 1,000 security and IT professionals found that 77% of organizations were subject to a DNS-based attack, and that the average cost of resulting downtime, response, and business loss due to an attack was $715,000.

If an attacker compromises your DNS services provided by Route 53, they can potentially control where your network traffic is routed. For instance, if an attacker redirects traffic intended for your servers to a malicious server, they could obtain sensitive information, or simply redirect traffic away from your servers as a Denial-of-Service (DoS) attack.

Other potential threats and vulnerabilities include:

  • Not Enabling Domain Transfer: Hijacking a domain and transferring it to another registrar.
  • Having Private DNS Records in Public Zones: If you donā€™t define your private DNS records within a private hosted zone, your DNSĀ records are not protected from malicious users who seek information about your internal IP addresses or network.
  • Not Removing Dangling DNS Records: A dangling DNS record occurs when the resources pointed to by a DNS record are removed (such as when an elastic IP is released into AWSā€™ EIP pool), but the DNS record itself remains. If an attacker has access to the same resource (such as someone who gets the same elastic IP from the AWS IP pool), they can use the dangling DNS record to control the domain/subdomain in your DNS entries.
  • Not Using SPF Records: An SPF record specifies which mail servers are authorized to send emails on behalf of your Amazon Route 53 domains. If you do not use SPF records you are not ensuring protected from malicious users who may use your domain for email spoofing; as a result, you are not ensuring the trustworthiness of your domains.

How Halo Cloud Secure Can Help

Halo Cloud Secure provides visibility and inventory of your DNS services provided by Amazon Route 53. This allows you to know what domains are registered in AWS, as well as how your end users are being routed to your applications. This kind of visibility enables you to figure out what external domain exposures you have and to enable basic fundamental security for DNS, such as:

  • Enabling Transfer Lock on your AWS Route 53 registered domains to prevent unauthorized transfers to other domain name registrars. With the Transfer Lock feature enabled on registered AWS Route 53 domain namesĀ (or domain names transferred to Route 53), you ensure that all transfer requests are rejected automatically, thus providing you with extra protection against domain hijacking.
  • Ensuring you do not define private DNS records within your AWS Route 53 public hosted zone prevents exposing your internal (private) network and the resources hosted on it. It also helps to optimize Route 53 service costs. In cases where a split-view DNS method is necessary, we recommend that you define your private DNS records in a Route 53 private hosted zone, which you can then use with a public hosted zone to implement the split-view DNS for your applications.
  • Identifying and removing dangling DNS records from your AWS Route 53 public-hosted zones to protect against malicious activity and ensure the integrity of your domains/subdomains.
  • Creating SPF records for corresponding MX records within your Route 53 DNS hosted zones to help you detect and stop email address spoofing, reduce spam, and increase the trustworthiness of your domains.

Learn more about how Halo Cloud Secure can give you visibility into your inventory of DNS and help you figure out your external domain exposures. Read our AWS solutionsĀ here, or request aĀ customized demo.

Ā 

Ad

No posts to display