The internet used to be so simple. In the beginning, there were only six easily remembered Top Level Domain (TLD) types which we all knew and loved. It was easy. [Top Level Domains – also called generic Top Level Domains (gTLD) – are everything after the “dot” in a website address. The first six were .com, .edu, .org, .net, .gov, and .mil. Outside the United States, every country had its own TLD (.uk, .ru) as well.]
Then the Internet Corporation for Assigned Names and Numbers (ICANN) and its subsidiary, the Internet Assigned Numbers Authority (IANA) changed everything. In 2012, they ended restrictions on TLDs, essentially allowing anyone to register their own vanity domains. Now just under fifty percent of web addresses end in .com. The remaining generic TLDs are a hodgepodge of terms which range from intriguing (.guru) to confusing (.xyz).
How to tell a “bad” TLD
You can actually tell a lot about a website by its Top Level Domain. Just as .net was viewed with some suspicion in the early days (as the catchall for sites which didn’t fit anywhere else), the wild west of today’s TLDs should give everyone pause.
That’s because the worst of these newer TLDs are used almost exclusively for malicious activity. They’re significant sources of spam. They’re associated with domain generation algorithms – machine-created “pop-up” domains used to circumvent filters of known bad sites. The TLD owners are either turning a blind eye to malicious activity or actively complicit in it.
How bad are these TLDs? Spamhaus actually created an index of the world’s most abused TLDs, using formulas to track the worst of the worst. The champion of 2018 was .men (in case you’re wondering, .women didn’t even make the list), but the rankings change all the time. In some cases, over 90% of the domains in a TLD are used for malicious activity. In others the percentage of “bad” domains may be lower but the overall volume is still high enough to merit caution on any address with that TLD.
Just block it
There is simply no reason that any Domain Name System (DNS) query from a corporate network should be allowed to resolve to any TLD with a record of malicious activity – or any “sponsored” top level domain – at all.
There’s no upside. Either the probability of hitting a malicious domain is too high, or the probability of hitting a site of any value is too low. It’s unlikely that a critical network update or valuable data of any kind can be found anywhere on .men – any query of that TLD is most likely to find trouble. The best option in these cases is usually to block the entire TLD.
…And then investigate it
Beyond simple blocking, there’s another step that network administrators can and should take against malicious TLDs. Whenever a “known bad” TLD is queried, it makes sense that security personnel should investigate where that query is coming from. It’s tempting to declare victory when the query itself doesn’t resolve. But wouldn’t you want to know if malware on the source device is generating these queries?
That’s where the specific IP addresses and associated devices which attempt to connect with those blocked internet domains become important.
The boundary problem
Just about every corporate network uses filters and firewalls on the network boundary. Some of these are equipped with the capability to block DNS queries, and specifically those associated with malicious TLDs. There are plenty of threat feeds out there which can block bad domains en masse.
Here’s the problem with that approach: boundary level filters and firewalls can block external connections to bad TLDs, but they usually have no visibility into which device on the network generated that DNS query to begin with. They basically treat the symptoms without offering a cure. While those symptoms are very important, they are not the same as getting rid of the root cause of a security vulnerability.
Why do boundary-level filters and firewalls fall short? The answer can be found in how most networks are architected. When an external-facing security system looks back toward source devices, it only sees the recursive server which last forwarded the DNS request. Tracking the DNS query back to the source device requires the ability to correlate data between these recursive layers – a huge task which can take a lot of time and effort. With these challenges at the level of infrastructure, top level domains can easily prove to be more trouble than the effort of investigation.
The “first hop” solution
At BlueCat, we take a unique approach to the challenge posed by top level domains and other DNS-based threats. Instead of assessing the validity of TLDs at the network boundary, we do it at the device level.
By taking the place of the “first hop” recursive server, BlueCat can apply security policies to every DNS query which comes off of a device before it moves up the network hierarchy. In the case of malicious TLDs, this security policy can monitor, block, redirect, or allow a query to resolve based on user-defined parameters.
The fact that this happens right at the device level matters when the investigative angle comes in. Unlike boundary-level filters and firewalls, BlueCat can actually see which device is producing queries to a malicious TLD. That gives network administrators the ability to not only deal with the suspect request, but also to trace that request back to a specific device. This opens up a whole new aspect of network security, allowing for rapid remediation of infected devices.
Another advantage of being at the first hop is the ability to block lateral movement within a network. Queries of known bad TLDs may be the final act of an advanced persistent threat, where the software uses internal connections to find sensitive information, using a TLD for data exfiltration, perhaps through a DNS tunnel or a site created by a domain generation algorithm. These threats rely on the inability of most network administrators to monitor and block internal traffic. With BlueCat, suspect activity inside the network and queries of an external malicious TLD can both be blocked before they cause irreparable harm.
Learn more about how BlueCat uses intelligent security to protect critical networks.
Critical conversations on critical infrastructure
Find out how your peers are managing their networks through profound change. Watch this series of live interactive discussions with IT pros & join the debate in Slack.
BlueCat Blueprint for AWS
Instructions provided allow BlueCat Address Manager (BAM) and BlueCat Gateway to discover and import data from an Amazon cloud environment.
SUNBURST/Solorigate Situation Briefing
BlueCat leaders discuss how the malware attack via SolarWind’s Orion platform exploited DNS and how BlueCat Edge could have helped to detect it.
React faster at the wire with BlueCat and ExtraHop
With the BlueCat ExtraHop Plugin, automatically create missing PTR records, and detect and react to security threats before they reach DNS servers.
Yes, IT should see what developers do in the cloud
Errors and outages occur when admins lack visibility into DNS and IP allocation in the cloud. With Bluecat, central DDI visibility is within reach.