By Nilesh Dherange, CTO, Gurucul
It’s safe to say that the Domain Name Service was instrumental in turning the Internet from a curiosity that first linked university and defense contractor mainframes together in the early 1970’s into the ubiquitous global platform it is now. Before the introduction of DNS in the early 1980’s, systems had to rely on memorized IP addresses or a local HOSTS.TXT file to reach other hosts. With names, the world changed and it’s hard to even imagine what it was like before you could reach out to whatyourelookingfor.com[1] to find what you’re looking for.
DNS isn’t without its flaws, of course. There have been numerous attacks against the system, ranging from simple typo-squatting to draw people mistyping a popular domain into a malicious site, to outright stealing domains from people at the registrar, to various DNS poisoning attacks that redirect valid names to compromised addresses. A clever variation of typo-squatting has been to use Unicode characters that look similar to their Latin equivalent but represent a different domain name.
Fortunately, there are ways to both defend against DNS attacks and to use it for defense. For example, back in the early 2000’s a worm got loose in a major manufacturer’s network. The information security team identified it and recognized that the worm was using an IRC (Internet Relay Chat) server for command and control. One of their team threw up an IRC server in their lab and had the company’s DNS purposely poisoned to point that domain name to the server in the lab. That broke the worm’s C&C and with some simple scripting they could quickly identify newly infected hosts as they came up.
Having control over their local name servers let them quickly mitigate the attack. In the same vein, protocols like DNSSEC help to prevent DNS hijacking attacks. But there is more we can do on the defense side to resist attacks that rely on the Domain Name Service.
For example, services exist now that provide a “sanitized and sanity checked” DNS service. When a query comes in they examine the domain name and check the records to see if it’s suspicious. When was it created? Is the registrar reputable? Where is it registered? Who’s it registered to? Do they have other registrations, and do those look legit or a bit sketchy? Most queries are going to pass through as expected, but questionable ones can be directed to a warning page that askes the quite valid question “Are you sure you want to go there?”
This is a very useful capability, as malware authors have used randomly generated domain names for command-and-control functions for years. Since these names are often generated shortly before a new malware variant and frequently look like random gibberish, amongst other telltale characteristics, it’s easy to spot them when they come up.
Not every organization will want to use an external service to sanitize their DNS for them. While it is effective, there is a lot to be said for using tools in the existing security stack to their best effect. And in this case, it’s likely there are already tools in the stack that can help defend against abuse of the name service – beyond the Best Practice of enabling DNSSEC where possible.
For example, organizations that employ a SIEM can set up alerts that highlight “requests to sketchy domains” based simply on the domain names being called. Known domains make it through. Domains that look like the cat walked across the keyboard get called out. It’s easy then for someone on the SecOps team to check it out and see whether it’s legitimate or malicious and act accordingly. That’s oversimplifying it, but it’s a simple approach. In fact, much of it can be automated which makes it even easier. If the organization has a security analytics platform in the stack, it’s even easier, as the analytics engine will be looking at what sort of traffic is flowing, and from what hosts, along with the domain name itself. Machine learning systems can easily spot traffic to sketchy domains and act accordingly, whether it’s to have the local DNS server shunt traffic to a warning page, or block traffic entirely, or simply flag it for a Human analyst to follow-up on.
DNS has made the Internet what it is today. And, while bad actors have figured out how to abuse it, they are also as dependent on it as we are. That makes it a choke point we can use to help defend our environments from attack. We can identify inappropriate traffic, infected hosts, bad actors, and emerging threats based on a set of protocols we all rely on. It’s by no means a perfect solution, but it puts tools in our arsenal that malicious actors will have to work hard to get around.
About the Author
Nilesh Dherange is the chief technology officer for Gurucul and is responsible for development and execution of Gurucul’s technology vision. Nilesh brings a wealth of experience in inventing, designing, and building software from inception to release. Nilesh has been a technologist and leader at three startups and at one of the largest software development companies in the world. Prior to founding Gurucul, Nilesh was an integral member of a company that built a Roles and Compliance product acquired by Sun Microsystems. Nilesh was also a co-founder and VP of Engineering for BON Marketing Group where he conceptualized and created BON Ticker — an innovative patented bid management system which used predictive analytics to determine advertising bids for PPC marketing campaigns on search engines like Google, Yahoo, MSN etc. Nilesh holds a B.A in Social Science, B.E in Computer Engineering from University of Mumbai and M.S in Computer Science from University of Southern California.
