DNS and NTP on AWS
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics | Code.
🔒 Related Stories: DNS Security | Cybersecurity | Application Security | Network Security
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the last post I wrote about network design for serverless applications.
Now let’s consider some of the other core technologies we’ll need to consider and configure in an AWS network.
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 requests
- Microservices use DNS to route requests within an application
- You 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.
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
AWS 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 and 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 mountain 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.
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:
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.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2022
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ 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 LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab