Or rather, DNS - the simplest way to take down an enterprise.
From our SOC - A few on our team of 150+ security professionals mitigated a huge attack again on the HTTP / HTTPS ports as usual for a hosted solution. While there is a lot of attention on mobile apps and web hosted delivery in general because that’s where all the action is in ads and purchases, teams, let’s not forget other areas of the infrastructure!
Security is about more than merely the hosted solution or content delivery, alone. Resilience in backups, processes in place to prevent social engineering and physical security are all important to your businesses security posture, too.
Attackers can be sophisticated, and will continue to seek out weak points.
One area I’m getting concerned about lately is DNS, because sometimes not enough attention is paid attention to this seemingly low-maintenance area, yet it can be a logical choke point.
Consider the following security factors:
- Assuming you have more than one authoritative name server - and I do hope you have several -, are they in the same co-location or Is your DNS distributed, using several different providers? You’ll want to protect yourself if any provider’s route goes down, or there is a flood or other calamity.
- Are your NS protected against fire with resiliency via different physical locations with automated failover, or does failover require manual intervention, extending potential mitigation speed?
- Is your zone protected against man-in-the-middle attacks? You can ask your DNS provider if this protection is optionally available. Most managed DNS optionally includes it as DNSSec, including Akamai FastDNS. (DNSSec is potentially another big topic of discussion.)
- Assuming your authoritative NS are access-controlled via ACLs for approved changes, is it a short ad known list, are contact points reachable 24hrs in case of emergency? This may seem administrative, but in a zone crisis situation, speed of knowledgeable and authoritative technical response becomes important. Do you have someone who can switch your DNS server at the Registrar?
- Are your main primary name servers (the ones where you make changes to your zone record) the same ones authoritative for your zone, that is, are they completely open to the world including potential bad actors? Ideally a managed solution includes some tiered zone distribution, thus freeing up resources on the servers where you may need to make zone record changes, ensuring they are highly responsive to your edits in a crisis situation.
- What is your TTL of your zone records? Consider, if the TTL is very high and you must go to a new provider, the lead time could be high, and there is no way to effectively issue a purge to caching NS and proxies out in the wild. In the old days a TTL of two days was just fine, but we’ve learned that lower TTL can be more adaptive. Of course, not too low, as conversely, lower TTL results in reduced catchability thus more requests per second to your NS will be coming through. For the SOA and NS though, the TTL at the apex is going to be long such as 48 hours.
- Finally, and I realize a domain lookup may only be done once per new visitor to your page in a given time period, but is your DNS as fast as you’d like it to be? Speed can be important as lookups may affect your SEO ratings. Have you tested it during peak hours? If it became suddenly 40% slower would you be alerted? How long does it take to resolve a non-cached record lookup from different geographical locations - the ones that are important to your customer base? You’ll want to have DNS hosts near those locations, for speed and you’ll want initial responses to be fast.
Administratively, for domain registration; when does billing begin/ end? when is your domain up for renewal? Knowing the cycle can help ensure your team stays on top of it.
One example large attack was seen in our SOC and one of the attack vectors was to DNS. The attacker was in control of multiple devices that could run a custom attack script, and it seemed they were trying to implement a DDoS attack on the DNS structure as part of their coordinated effort. We ran a packet capture and we saw attempted lookups like:
...and so on...
None of these hostnames existed, although the domain did, so the attack operator was seemingly trying to overload the DNS infrastructure with lots of random lookup requests to DNS, hoping in their attack to leverage points where there wasn’t sufficient resiliency. Fortunately, Akamai SOC was able to help block the attack and keep their business up, but it goes to illustrate that DNS can also be under attack as a vector, not just application ports and/ or web delivery.
For your own business, is your DNS well-documented? Is there an emergency contact list, would your security team be able to quickly assemble the right folks in charge of the ACL, or the firewall, are the IPs of all the master name servers well documented, or would it take a lot of phone calls just to determine the right points of contact?
The recently prominent Mirai botnet has a configurable DNS attack, HTTPs attack, two different GRE tunnel floods, a Valve Engine flood, various UDP floods and more - 10 different configurable types in all.
In Q3, in Akamai’s State of the Internet report, we saw that DNS reflection continued to be a large portion of the DDoS attack traffic across our routed network. A considerable amount of UDP fragmentation traffic is a byproduct of DNS traffic. Combined UDP fragmentation and DNS floods grew by 4.5% in the third quarter, accounting for nearly 44% of the attack vectors.
Akamai FastDNS is one distributed solution that can help, with IP-anycasting and multiple NS in many different geographies very close to end-users. It is able to absorb many of the volumetric attacks easily, and the distribution automatically works around many of the potential bottlenecks of having just a few distribution points with common network points of potential congestion. FastDNS helps maintain a fast experience through the largest of DDoS attacks, with additional administrative controls such as rate limiting and whitelisting… and optional DNSSEC to help guard against Man-in-the-middle zone record manipulation including forgery.
Considering the prominence of DNS attacks, and how attack vectors change, I recommend discussions of DNS come to your meetings. I hope the above lists help.
Best practice of course is to consider risk from multiple attack vectors, don’t just talk about web and site delivery in any hosting or application security discussion, DNS should continue to be mentioned and considered in planning, part of your overall security posture, along with physical plant, redundancy of logical paths and prevention of social engineering, and included in your team’s ongoing periodic risk assessment reviews.
This post is a part of our Cloud Security Thought Leadership series. Join Roger Barranco, Akamai’s Senior Director, Global Security Operations in a webinar where he talks about best practices to defend against the Mirai botnet and the next wave of Mega Attacks. Click here to register.