Setting up a User and Role for Domain Name Administration

ACM.242 Adding a user who can modify NS records on domains for configuration of static websites

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: DNS | Deploying a Static Website | Cybersecurity

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I had to take a brief hiatus to finish an AWS and application pentest but now back to hopefully polish off this sub-series on deploying a static website on AWS.

In the last post, I covered a thought on the Cloud Security Center of Excellence concept that I had while helping my customer with their penetration test. This was a somewhat random thought in the midst of deploying a static website but relevant as we try to maintain governance throughout the process.

Prior to that, I wrote about was moving an account into an OU that allows updates and then back again.

Now I need to think through who is allowed to make DNS changes. I want to restrict the domain changes to a specific user profile that requires MFA. I want to make it difficult for anyone to change the permissions of this user and role or grant themselves access to it.

Users and Roles for Domain Administration

I debated how to present the role in the Route 53 domains account in this post. For the sake of time and because long term I want to do this another way, I’m going to refer you to prior posts and presume you already set up a role with MFA in your domains account the way I showed you in prior posts.

Note what I am not doing:

• Since the root account is never subject to SCPs, I don’t have any access to the domains account from the root account.
• The default AWS Organizations role does not exist in this account. It does not require MFA and has been deleted.
• The OrgRoot user created in the root account does not currently have access to this account since there is no cross account role for that user.
• No actions will be allowed if the account is in the DenyAll OU.
• I am not creating a cross account role at this time. All users and credentials are created in the domains account. There will be no access to modify the credentials or users in this account outside of this account.
• I am not going to use default session-length values. The session for making DNS changes will be short and re-authenticating with MFA will need to occur very frequently.

What does that leave for attack? I have to worry about sessions and any sort of attacks that might get at the domain administrator credentials.

• The sessions are short, but if someone were to get onto a machine while the session is active, they could execute commands using that session.
• Since I use MFA to assume the role to modify domains, the attacker would need to get both a password and access to an MFA device, or the MFA code as it is sent over the network.

I explain why I do not use a Yubikey with the CLI and why I don’t like other CLI options in prior posts.

Of course, you are also trusting the AWS infrastructure and AWS needs to do their part. If someone at AWS could get at the domains that would be a problem as well.

Whatever you choose to do in terms of access to your domains — my script is going to presume that you have set up an AWS CLI profile named “domain_ns” that is used to update the NS records on your domains in route 53 — wherever they are located and whatever credentials you choose to use to do that. Be careful!

Who can create the Domains User and Role?

How will I create the role in the account if the OrgRoot user can’t access it? I temporarily move the account to an OU that allows the root user for that account to login and create the role. Then I move the account back to the DenyAll OU until I am ready to make changes.

Freeing up access in development environments for automation and testing

Optional: Consider separate top level domains for dev and QA testing.

If you have people testing DNS code and changes you can use a separate account for development and QA domains and make them completely separate domains from your top level domains (instead of using subdomains).

For example, in a development environment I could use:

testrainierrhododendrons.com

In production I could use:

rainierrhodedrons.com

You will incur an extra fee per year for each domain in that case but you limit the chance that someone makes an incorrect change to a production domain, and you can allow automated changes without a lot of permission checks like I wrote about in this post:

The dev and QA environments can mirror each other, except for the domains. Then once the code is tested and working it can be published to the production domain. No changes should be made to the code, only the domain name passed into a script.

Maybe I can cover this later in more detail.

Creating a Route53Domains OU

Step 2: Create a Route53Domains OU.

I’m going to create an OU specifically for route53domains management. I explained how route53 and route53domains actions are different in the last post. Adding the new OU is one new line in our root_ous.sh file found at the path in the file header below.

Run the file to create the new OU. Recall that it uses the OrgRoot profile which needs permissions to make changes in the root account. Eventually I will move some of this to my Governance admins but need to get this one for now.

To validate my new OU is created I run the following:

#list out the roots to get the root id r-xxxxxx
aws organizations list-roots --profile OrgRoot

#replace the root id in the command below
aws organizations list-organizational-units-for-parent --parent-id r-xxxx --profile OrgRoot | grep Name
            "Name": "DenyAll"
            "Name": "Sandbox"
            "Name": "Backup"
            "Name": "Governance"
            "Name": "Domains"
            "Name": "Suspended"

Now we can check the account hierarchy and SCP in the console to make sure it is correct.

Looks good for now.

Note that I am creating this account at the root for now. It should move under the Governance OU eventually but I have not finished setting up my Governance infrastructure yet. Stay tuned for that.

An SCP to enforce MFA

Step 3: Create an SCP for the Route53Domains OU.

Note: this SCP may undergo revisions in future posts. This is a starting point.

I’m going to create an SCP that only allows the following actions in the Domains account:

* IAM (Set up Users, Roles, and Groups)
* Organizations (move the account back to the Deny all OU)
* Route 53

After creating an initial version of the SCP, I tried to deploy it and attach it to the Domains OU.

I ended up altering the SCP but you can see the process I went through here to troubleshoot some problems with it.

I got it to deploy, but then opted to test with a simpler version for this initial post. To see that my policy got deployed I can review all the service control policies:

aws organizations list-policies --filter SERVICE_CONTROL_POLICY --profile OrgRoot

And take a look at the specific policy:

aws organizations describe-policy --policy-id [policy id here] --profile OrgRoot --output text

Create a CLI Profile for the user and the Role

I’m going to create a separate role profile for DNS changes. As a reminder you can see what roles are configured on your host by running this command (or looking at the files associated with the AWS CLI which I covered in a prior post).

aws configure list-profiles

I configure an AWS CLI Profile named ns_domains_user and configure it with the AWS developer key associated with the user in the domains account. The only thing the user can do is assume the role to modify domains.

Next I configured an AWS CLI profile named ns_domains which uses the aws user as the source profile and assumes the role that has permission to modify NS records. The role assumption requires MFA to be present and set to true. Not that I am *NOT* using “if present” as described in some of the AWS documentation which seems to make MFA irrelevant as I explained previously.

Basic Test

I need to test this out a lot more thoroughly but for now I did the following:

• Check to see what OU the Domains account currently exists in.

First get the root id:

aws organizations list-roots --profile OrgRoot

Use the root ID to list the OUs under the root:

aws organizations list-children --child-type ORGANIZATIONAL_UNIT --parent-id [your root id r-xxxxx] --profile OrgRoot

Unfortunately this command doesn’t seem to be well thought out because it does not include the name of OUs only IDs. It’s not really that helpful because we’d have to run the describe command on each OU to figure out which one is the domains OU. what other options do we have? This command includes the name of the OU.

aws organizations list-organizational-units-for-parent --parent-id r-c0b3 --profile OrgRoot

Now I can grab the accounts in the OU. But I still have to guess which one my domains account is in currently. Instead of playing a guessing game is there a way to describe the account that includes the OU? Looks like get-parents might work.

First I need the domans account number:

aws organizations lisorganizations list-accounts --profile OrgRoot | grep -i domains -A2 -B2

Then I can use that to query the parents:

aws organizations list-parents --child-id [acct #] --profile OrgRoot

Unfortunately, this also doesn’t provide the OU names, only the IDs of the OUs. But since there is only one OU for an account (and I hope AWS keeps it this way), I can use the ID to get a specific OU name:

aws organizations describe-organizational-unit --organizational-unit-id [OU ID from last query] --profile OrgRoot

Finally! I can see that my domains account is in the proper DenyAll OU.

• Switch the account to an OU that allows us to make necessary updates.

I could use my code from the last post to move the account between OUs, but this is a one-off action I don’t expect to repeat, I manually moved the account into an OU so I can add the new role.

• Create a role that has permission to modify NS records. Require MFA to assume the role in the trust policy.

Looking at the options in the console it seems like this is all you should need. And all of this may not even be neccessary, but the main thing is we don’t want anyone to transfer domains away or to a different AWS account.

It may even be possible to restrict actions to specific domain names but I am not going to test that here.

[see prior AWS IAM blog posts for how to automate the creation of IAM roles and create proper trust policies.]

• Created the user that only has permission to assume the role that can alter NS records. Require MFA to assume the role. In my case, I did not grant console access as this is temporary. I plan to manage this differently in the future.

[see prior AWS IAM blog posts]

• Created the role profile in my AWS CLI configuration for the user:

aws configure --profile ns_domains_user

[enter aws secret key and access key]

• Create a role profile for the role that references the user profile for credentials and includes the MFA ARN.

[see prior AWS IAM blog posts]

• Manually moved the account to the Domains OU to run a test.
• Ran a command to list the domain names using the new CLI profile

If everything is set up correctly, this should work and you should be required to enter MFA:

aws route53domains list-domains --profile ns_domains

So got that working.

You can also run some tests to see what the user is and is not allowed to do based on the Service Control Policy we created.

Next up I need to use this role to update the NS records.

I manually move the domains account back to the DenyAll OU because I’m going to write a script to automate moving it and making the NS changes.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2024

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity for Executives in the Age of Cloud
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Appication Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presenation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Medium: Teri Radichel
❤️ Sign Up For Email
❤️ Twitter: @teriradichel
❤️ Mastodon: @[email protected]
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab