Either through human error or intentionally, configuration changes in the cloud may suddenly increase your attack surface. AWS Route 53 is an example of a service that needs to be continuously tracked for risky changes. As the first line of defense of our cloud, it is necessary to secure Amazon Route 53 and monitor risky configuration changes to avoid unwanted surprises.
As you probably know, AWS Route 53 is of course a very popular DNS service offered by AWS, with millions of top-level domains. For each domain, there are likely to be many sub-domains, such as www, finance, login, support, and so forth.
While highly applicable for many DNS use cases for organizations of all sizes, Route 53 can be a lot of work and actually may potentially expose your cloud account to risk if not configured correctly.
Amazon Route 53 risks
While some of us may often equate DNS attacks with volumetric denial-of-service attacks, it doesn’t take an all-out attack to cause a big problem in your cloud. AWS Shield and AWS Shield Advanced can help protect your Amazon Route 53 resources against DDOS attacks but not against risky changes to the underlying configuration.
High level risks to our DNS posture on the Internet include registering new domains, deleting domains, and creating or deleting DNS records. We need to keep an eye on Route 53 changes in our account.
AWS Route 53 real-world problems are many.
For example, a BGP hack re-routed domains for AWS Route 53 for 2 hours resulting in $150,000 in cryptocurrency being stolen. And while the incident did not involve any compromise of Amazon Route 53 itself, this goes to show how carefully you need to track any domains that are being created in Route 53.
Imagine if this happened and you did not even know about some of your domains, because they were created by a different team in your AWS cloud?
A Frightening POC
In a scary Proof-of-Concept, a security researcher based in England named Patrik Hudak showed how scanning for registered domain names for S3 buckets could allow the buckets to be taken over.
This PoC shows with numeration techniques for enumeration, an attacker can discover orphaned Cloudfront distributions and DNS Records that are attempting to serve content from an S3 bucket that no longer exists.
This shows the connection between the Route 53 DNS records and the rest of your AWS infrastructure.
AWS Route 53 Security Best Practices
At a fundamental level, knowing which domains you have in Route 53 is top of the list. As is knowing in real-time when somebody or something creates or deletes one of your domains.
AWS Maintains a general best practice page that outlines the basics for getting the best results, but in addition to that other aws security best practices that can be found in the open standard CIS Amazon Web Services Three-tier Web Architecture Benchmark from the Center for Internet Security.
The best practices include for example:
- Set TTLs appropriately to afford to wait for a change to take effect
- Ensure Root Domain Alias Record Points to ELB
- Ensure a DNS alias record for the root domain
Sysdig has identified risky changes that need to be monitored as a best practice.
These include:
- Associate VPC with Hosted Zone
- Change Resource Record Sets
- Register Domain
Searching for Risks with CloudTrail
AWS wouldn’t leave us high and dry without a way to track our changes, and fortunately CloudTrail acts as essentially a giant audit log for everything. AWS CloudTrail tracks all actions taken by your users, roles, and AWS services. Activity from both users and services is recorded as a CloudTrail event, which is basically an audit log entry.
Regardless whether the activity is made through the AWS console, the AWS CLI, or the AWS API, CloudTrail doesn’t miss a beat.
Does this by itself solve our problem?
CloudTrail is great! But CloudTrail is not designed to be a good judge of guilt vs innocence; CloudTrail can’t distinguish between a perfectly valid change in our account vs a change which might suddenly increase our attack surface. And even if it could, CloudTrail lacks an alerting and reporting mechanism.
CloudTrail can be thought of as a really enormous haystack, and the risky changes in our AWS account can be thought of as really tiny little needles.
Finding these needles manually (by hand!) is going to be painful and it doesn’t scale.
Like all AWS services, when it comes to AWS Route 53, what you need is an automated solution for real-time alerting, reporting, a dashboard for visualization, role-based access control for your security team, as well a host of supporting professional features to stay on top of risky events.
And while rolling up your sleeves and building many of these missing pieces using the native tools AWS provides may sound like fun, in our testing we were surprised to find somewhat mixed results even after a lot of hard work.
It would be great to have a team of cloud developers, but unfortunately not many of us have such luxuries at our disposal. For the rest of us, we just want something that works out of the box. This is where Sysdig Secure comes in.
Finding Risks with Sysdig Secure and CloudTrail
Sysdig watches CloudTrail like a security camera watching over your house, so the moment CloudTrail sees something, Sysdig sees it.
But unlike CloudTrail, Sysdig knows right from wrong and will Alert us with the Who/What/When/Where/How so that we can take action, and best of all, Sysdig Secure works right out-of-the-box.
Sysdig Secure includes these rules for the following risky AWS Route 53 events:
| Sysdig Falco Rule | Description | Why it matters |
| Associate VPC with Hosted Zone | This rule detects the association of an Amazon VPC with a private hosted zone. | This allows IP addresses in your VPC to be resolved by DNS probing. |
| Change Resource Record Sets | Detects the creation, changes, or deletion of a resource record set, such as a name for a website | New DNS entries need to be tracked. DNS for your most important sites should not change or be deleted without you knowing. |
| Register Domain | Detects the registration of a new domain. | Domains contain all your resource records and the registration of a domain should not happen without a valid business reason |
Try out finding risky AWS Route 53 events first with CloudTrail, and then with Sysdig Secure and see the difference for yourself:
CloudTrail + Sysdig: Better Together
Somewhere in CloudTrail, events are hiding like buried treasure. But just like real treasure, this can attract attackers to your front door. We have already published blogs showing examples of interesting CloudTrail events for AWS RDS and AWS EC2.
Sysdig mines CloudTrail for this treasure and gives you the Who/What/When/Where/How that you need to secure your cloud account.
You get out-of-the-box rules to secure AWS Route 53, and you can easily extend the ruleset using the open source Falco syntax.
Sysdig provides a single view of risk with deep visibility and rich context to find and fix issues faster.
But don’t take our word for it – if you have a few minutes, get started today at no cost and see the proof for yourself.