ACM.74 How these crucial services work by default and what happens if you want to use your own DNS and NTP servers on AWS
This is a continuation of my series of posts on Automating Cybersecurity Metrics.
It’s always DNS…
Everything in AWS needs to access DNS or it will break. And I mean EVERYTHING. When we connect to parameter store from our Lambda function, it needs to do a DNS lookup for the domain associated with SSM parameter store. If it cannot get back an answer because network rules block access to DNS or the DNS server is having issues, it won’t be able to connect to SSM.
I remember when we started deploying resources on AWS at Capital One. We were using our own DNS servers and things often failed to work. People would get angry and frustrated. Troubleshooting did not instantly reveal the problem. Network configurations looked correct. Invariably, it was a DNS problem.
We also had problems because applications on AWS could not automatically configure their DNS addresses within the DNS servers due to a lot of restrictions on how they could be accessed — especially in an automated manner. I got permission to use the DNS automation and documented how that could be resolved. Eventually it was, but not without a fight.
DNS servers are crucial for performance and security so access must be handled with care. If you don’t properly protect access to your DNS records, someone may be able to take over your cloud accounts for some types of services.
Since DNS servers are something that every resource needs to access, they are often a target by attackers and a means to get to other resources on your network, or more often — to exfiltrate data. Attackers can flip bits in the parts of network packets you don’t even see in your application data. They can use extraneous fields in DNS packets to send information out to the Internet unnoticed by most humans and sometimes network devices that don’t inspect packets down to that layer.
There are many aspects to DNS in an infrastructure as a service cloud environment.
Resources need to make DNS requestsMicroservices use DNS to route requests within an applicationYou may want virtual hosts in your VPC to have DNS names with your own domain names rather than the AWS default.Applications that are automatically deployed and end up with new IP addresses due to the ephemeral nature of IP addresses on AWS will need their domain names reassigned and pointed to the correct IP address.You can control which DNS servers your resources query using DHCP Options sets but caveat — your network architecture is going to get infinitely more complicated.
DHCP option sets in Amazon VPC
I’m not going to cover all those topics above right now but rather focus on what is important and required for the batch job architecture we are implementing at the moment.
DNS Requests from AWS Resources
DNS provides a DNS server to resolve addresses by default. You can override it and use your own DNS servers (something I helped Capital One do before AWS had private hosted zones) and it will be very tricky. You’ll need to think through how you structure your subnets, security groups, all the associated firewall rules, and how and where you deploy your DNS server.
Honestly, it is easier to use AWS DNS servers if you can. It is one of the services with a 100% update SLA (service level agreement).
Note: When using the AWS DNS Server it resolves to special local addresses and you cannot filter traffic to or from the Amazon DNS server using network ACLs or security groups. This is probably a good thing because if you do that everything will break, as I just explained. However, if for some reason you need to block DNS you’ll have to take additional steps. More on DNS from AWS here.
The bottom line for our network design above is that we don’t have to deal the the complication of DNS so that’s one less thing to worry about.
Domain Names for AWS Resources
You can register domain names at AWS or anywhere else. Once you register your domain names you have to tell the registrar which name servers to use to resolve your DNS records to AWS IP addresses where your application is hosted. You can use AWS Route 53 for this purpose.
If you use AWS for your name servers you’ll need to set up what are called “hosted zones” on AWS an configure them so queries to AWS correctly resolve a domain name to an IP address which, when accessed, will provide access to the correct application resource.
DNS has a multitude of complexity beyond that but I’ll leave it at that for now.
NTP
AWS EC2 instances used to use a public NTP pool by default. That meant you had a lot traffic on port 123 headed out to random hosts on the Internet. Thankfully now they use a private NTP server by default on most resources. You can override this of course, but similar to DNS, we don’t have to add special rules for it when using AWS services for the most part.
Set the time for your Linux instance
NTP is a crucial service for accurate logs in the case of security incidents and access to an NTP server is an AWS well-architected framework best practice:
Best Practice 12.1 – Use NTP to maintain time synchronization on devices
Basically what I’m telling you in this post is that you should be aware of the fact that if a resource can’t resolve DNS names everything will break, but if you use AWS default DNS you won’t really have to worry about it too much.
Also be aware that NTP is very important for security so all your logs are in sync, but if you use the AWS defaults it should be handled for you.
If you override the defaults of either of those services you will need to add DNS and NTP access to every list of network rules you create for those services to work properly.
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 repo:
____________________________________________
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
DNS and NTP on AWS was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
