DNS is everywhere. Your laptop uses it. Your phone uses it. Your production servers use it. Its everywhere, but for many people, once its working, they forget about it. And yet, DNS can be used for data transfer (several bytes at a time), it can be used to lookup malicious domains, it can be used for remote command and control for botnets.
So why aren’t you securing it in your production data center and cloud deployments? If you don’t have a strong handle on DNS, and just blindly rely on DNS resolution and nothing else, then you are overlooking a gaping hole in your security posture.
In this post I am looking at production “server” deployments: virtual machines, EC2 instances, running in your network or VPC or equivalent.
Use a specific DNS Resolver
You should clearly have a set DNS resolver, and ensure it is working. I’ve seen one government organisation that had 3 DNS resolver IP addresses handed out in DHCP, but only two servers were in use, randomly causing DNS timeouts and unexpected delays for their entire network. If you have a DNS server, monitor it to ensure it is working, and how much it is being used. Look for anomalies. increases in queries, unusual query types . These suspicious activities could be an indicator of compromise (IoC)
Block server traffic initiating outbound connections
Block new outbound traffic from your servers, except the items that you do need your servers to establish connections for (eg, API integration). even then, you may want to have a specific proxy handle those connections, so you can validate the outbound connections are going to where you want them to.
Only permit your DNS resolvers to make outbound TCP/UDP port 53.
There’s no reason that your hosts in your network should be making direct DNS queries to the outside world. Not only block it, but report on this very suspicious behaviour: its another indicator of compromise.
Configure DNS Blocking
There’s a load of lists online that are constantly updating that contain malicious domains, those used for botnet command and control, that would be ideal for not doing DNS resolution for (and alerting on if a query comes from your severs).
Continuously update these lists as they are updated, and monitor them – ensure they are not truncated to zero, or oversized. Perhaps configure some rules to ignore blocklist entries if they were to contain known good domains in case the blocklist itself gets compromised.
Doing this in AWS VPC
- Always use the VPC DNS Resolver.
- Configure your EC2 instances to use the link local resolver address.
- Never create a Security group that allows OUTBOUND ALLOW ALL. It is a default, but it should be removed. The only thing a security group show allow is specific outbound patterns, such as to the database host, or specificly permitted outbound ports. For example:
- Outbound TCP 5432 (Postgres), to address range 10.0.3.0/24 – it doesn’t need to make Postgres requests anywhere else
- Outbound TCP 443 (HTTPS), to address range 0.0.0.0/0 (everywhere?) – unless using a specific proxy
- Enable Guard Duty.
- Enable Route53 DNS firewall.
- Monitor your alert channels: if using SNS to an email destination, test the alert mechanism gets actioned. You may want to log the alert going off so you can see it in a dashboard.