ACM.125: Strategy for protecting domain names and DNS configurations in your AWS Organization
This is a continuation of my series on Automating Cybersecurity Metrics.
I wrote the importance of securing your domain names in my last post and why it matters. If someone can take over your domain name or DNS configuration they can potentially take over your entire cloud account, depending on which cloud services you use and how they verify you are the owner of the domain used to set up cloud services using that domain.
Domain Name Registration Security
To prevent unauthorized changes or takeover of your domain name you’ll want to consider who has access to manage and make changes to your domain names or DNS settings. Here is one possible approach to limit access to domain names and DNS changes for domains hosted and managed by Route 53 on AWS in an organization.
Create a new AWS account for domain name management on AWS.
You could try to lock down your IAM controls in a particular account to only allow certain people to access DNS configurations. Alternatively, you can put your domain names in a single account.
If you want to automate account creation, I wrote about how you can do that in the following blog post:
That code is currently not part of the GitHub repo associated with this series but it may be in the future if I have time.
Set up one specific account dedicated for domain name management. People who have access to manage domains in that account cannot create compute resources, S3 resources or any other resources that could leverage the domain names. The sole purpose of the account is for domain name administration and activities in that account are limited to that purpose.
Each AWS account you create comes with some overhead in regards to security and logging. To reduce some cost and complexity associated with multiple accounts, you can completely disable regions and services except those you actively need. Monitor changes closely in case someone tries to activate things you have disabled.
Route 53 is primarily a global service with the exceptions noted in this documentation:
For my purposes, a separate account works. If you are trying to use other AWS Route 53 functions than those I use in this blog series, you’ll have to see if this approach works for you.
2. Leverage segregation of duties for different DNS actions.
Allow one group to define the DNS configuration. Give a separate group permission to assign that configuration to an application. In other words, DNS admins set up NS records; Developers use them to configure applications.
For my purposes, in this blog series, I’m going to grant one automation role access to create the NS records for the domains in the DNS account. I’ll give another automation role permission to assign those DNS records to a static website in an S3 bucket.
I’m also going to set up an AWS SSO user as a DNS admin in a separate “domains” account who can log into the AWS console for the DNS account and manage domains and DNS configurations. Ideally we want everything automated but there may be some existing domains to transfer over via the AWS CLI or some other one-off function that doesn’t make a lot of sense to automate.
How organization size affects role assignments
If you work for a large company like Capital One, such as I did, you might have separate teams that each get a single one of role. You may have a team dedicated to DNS who uses the DNS administrator role and only has access to the domains account.
In a smaller organization, you might have a single DevOps team that is allowed to assume multiple roles due to limited resources and a separate developer team that performs application development functions. The DevOps teams may manage the domain names, network, and encryption keys, for example. In this latter scenario, executives might want to register domain names in one account or even using a separate service and use Route 53 to manage hosted zones for that domain name.
To create separation of duties for a very small team, create different credentials for a single person. Use separate MFA devices and credentials for different actions. It’s as if there are two different users even though the same person happens to be using two sets of credentials. The higher level, riskier credentials, shouldn’t need to be used as often so there’s less risk that an attacker gets access to them. You should have additional logging and alerts for risky actions.
Caveat with role assumptions
If you’re using AWS SSO, now AWS IAM Identity Center, beware of granting one person broad permissions through assumption of different roles. If a user can easily login and switch to any account or role, so can an attacker.
AWS IAM is not that much better but you do have to know the account alias or number and role if using the AWS console to switch to a different account.
The way way to emulate forcing MFA when switching accounts or roles would be to use different sets of credentials and/or MFA devices to force re-authentication for certain actions as I have been doing throughout this blog series.
3. Move domains to the central account
Having all your domain names located in a single, central account should make them easier to find and manage.
Here are the instructions to transfer the domain to another AWS using the AWS CLI. Do you know who has access to do this in your organization?
transfer-domain-to-another-aws-account – AWS CLI 1.27.41 Command Reference
The basic syntax is pretty simple, though there are some additional options in the documentation above.
aws route53domains transfer-domain-to-another-aws-account
–domain-name <value>
–account-id <value>
The above command will return a password that is required for the next step. It’s simple to run the command in the AWS cloudshell if someone has access to the AWS console.
To finalize the transfer, the account that is accepting the domain transfer must run the AcceptDomainTransferFromAnotherAwsAccount command. Here’s how to do that from the AWS CLI:
accept-domain-transfer-from-another-aws-account – AWS CLI 1.27.41 Command Reference
aws route53domains accept-domain-transfer-from-another-aws-account
–domain-name <value>
–password <value>
The password that was returned by the TransferDomainToAnotherAwsAccount request.
In my case, I transferred one of my domains between two AWS accounts in different organizations.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Make sure you restrict access to this Route 53 functionality on AWS! These commands are simple to run, as you can see. Two lines of code can move your domain name to another AWS account. Access to your domain may mean disabling and enabling services, manipulating email accounts, and taking over cloud accounts as explained in the last post.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
I just read a blog post about an “attack” that allows someone to transfer an AWS resource between accounts in different organizations. This is not an attack. It is a feature. I actually just needed that feature to move my domain as I just demonstrated above. It is up to the customer to understand what permissions people have in their cloud accounts and limit actions appropriately.
4. Create or move NS records for the domain in the appropriate account
Note that transferring the domain does not transfer the NS record for the domain. Even though I just transferred the domain from one AWS account to another, the functionality of my web site and email was unaffected. The domain got transferred, not the hosted zones.
Warning: It could be that someone takes control of your domain and you don’t even realize it because everything continues to work.
You can use this to your advantage when it comes to governance for domain names. You can register the domains in one account and use the NS records in a completely separate account where you host your applications and websites.
We’ll look more at NS records in upcoming posts.
Follow for updates.
Teri Radichel
If you liked this story please clap and follow:
******************************************************************
Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research
******************************************************************
© 2nd Sight Lab 2022
All the posts in this series:
Automating Cybersecurity Metrics (ACM)GitHub – tradichel/SecurityMetricsAutomation
____________________________________________
Author:
Cybersecurity for Executives in the Age of Cloud on Amazon
Need Cloud Security Training? 2nd Sight Lab Cloud Security Training
Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.
Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts
Governance for DNS on AWS was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
