Avoid driving expensive vehicles through bad neighborhoods
If you work in network defense or security operations and haven’t looked at custom Response Policy Zones in a while (or ever!) you’re not alone. In the day-to-day commotion between identifying and reacting to events on end points or at the edge, it’s understandable that configuring rules for DNS resolution gets missed. For simplicity, this function resides in “the middle”of our pantheon – the core network control layer not defined under “edge defense” and not within the purview of “endpoint security”. Often, I hear that rule management is someone else’s dark art, or overly complicated, or that DNS was “taken care of years ago” so not a high priority to look at. Sometimes it’s been a case of threat researchers and network or security operations just not getting together (teams are busy!). But you’d be surprised how little custom RPZs are used for enforcement across industries and sectors. If you knew that certain harmful sections of the Internet could be safely turned off for your organization, with high reliability, efficacy, and minimal disruption to the operations, wouldn’t you examine this? For customers who use them effectively, custom RPZs serve to integrate threat location data across vendors, solutions and data sources, and offer a single point of universal enforcement. And that function is carried out by your own DNS Resolver – something that will be part of your network operations well into the next decade. Today, we are focused on one aspect of custom RPZs, which is the capability to take action on abusive top level domains.
Defining the problem
First let’s examine why people put policy rules in place to begin with. This is essentially to automate and repeat the functions of “don’t do that, don’t go there, don’t allow that through”. That logic naturally creeps into “go there, but only you and only between 3pm and 5pm” and before long, a network firewall becomes a byzantine stack of potential conflicting rules in service of multiple masters. What’s worse is if that segmented firewall function doesn’t cover your entire sphere of responsibility and is taken down occasionally for maintenance. Your rule sets, however pristine, become useless if they don’t interface with the traffic you are responsible for inspecting and securing 24x7x365. The ideal scenario here has been described to me as “I set a rule once, it performs to precise expectation 100% of the time for 100% of my intended constituency and I rarely need to take another look at it….and oh, one more requirement – no angry phone calls complaining that I disrupted business operations”. Additionally, since vendors, analysts, and peers are always finding new bad places, we need capacity to both distribute the data where it needs to be and to house it within the blocking mechanism we are using. Whew! Anything else I missed?
So, we need a mechanism whereby effective rules can be applied to specific devices, specific network segments, or to entire networks at scale. This mechanism should also allow one to action specific FQDNs – those abusive subdomains mapped to legitimate base domains – or to entire zones for efficiency and accuracy. A DNS resolver with RPZs meets the need here. it’s a critical network protocol, seemingly everything assigned an IP address starts making DNS queries to some place. DNS resolution is hierarchical – root TLD, second level domain, subdomain and so on. There’s no fundamental redesign of anything required. This logic can be very similar to “close port 3389 on unnecessary devices facing the Internet” or “examine SSH traffic NOT on port 22” – rules that thousands of security practitioners apply today.
Persistently bad neighborhoods: Abusive TLDs have been present for years
In some of the recent newsworthy attacks, researchers and arm-chair quarterbacks alike identified abusive domains used in the attacks as residing in root zone registries with questionable long term reputations. To introduce the problem fully, in the past ten years the TLD space has grown exponentially. Becoming a registrar does require proof of $70,000 in working capital and completion of an ICANN application – not a total free for all. However, supply created its own demand in many respects and there have been several in-depth studies on the use and abuse of the newest generic TLDs. In the IANA system there are now 1,541 top level domains, all of which your DNS resolver will dutifully go query with or without some controls in place. A growing number of these TLDs are 90% abusive. That is to say, at least 90% of the total population of second level domains contained therein have been proven harmful to legitimate networks. Why do these reprobate registries and registrars continue to operate in this fashion? Don’t overthink the economics – the short answer is that they have zero incentive to work on this problem.
Much research has already been done by experts in the community. These links below are just a few that show commonly abused TLDs which most if not all of YOUR network has no business interacting with. We greatly thank these researchers and partners for their contributions!
https://www.spamhaus.org/statistics/tlds/
https://www.farsightsecurity.com/assets/media/download/VB2018-study.pdf
https://docs.apwg.org/reports/apwg_trends_report_q4_2021.pdf
Action Plan: Easy Prevention
A useful exercise is to take some of the newest and most exotic TLDs and simply examine a sample of your own DNS query/response data to see how your devices, users, and applications are interacting with these. You simply set the response rule to allow+log. This can be thought of as conducting a “TLD heat-mapping assessment” if you need an official-sounding name for the initiative. Those of you using Splunk or Infoblox Reporting servers could run reports to parse out deduplicated counts of 24 hours of query data in order to build a pie chart of the TLDs your network is talking to. By pure volume, .com and .net will remain the kingpins on which TLD suffers the most abuse. Nobody is suggesting blocking those for an instant. Where we want to apply our energy is on those TLDs which, as a percentage of their total population of second level domains, serve abusive destinations. Apply the law of large numbers!
https://data.iana.org/TLD/tlds-alpha-by-domain.txt
is the seminal resource for to see all available standardized TLDs. Now there are some emerging variants for cryptocurrencies and the like – that is a whole other topic. The point of the thought exercise is to ask “what systems and users I am responsible for securing can function perfectly fine without talking to these strange and highly abused corners of the Internet at all?” This can be accomplished by setting a simple Response Policy Zone rule that defines the questionable TLDs. You can also run the following TIDE queries within BloxOne Threat Defense Advanced and then search within the results for the top ten problematic TLDs.
/tide/api/data/threats/state?type=host&&threat_level_from=80&field=detected,host,domain,tld,property,threat_level
/tide/api/data/threats/state?type=host&threat_level_from=80&profile=SURBL&field=detected,host,domain,tld,property,threat_level,profile
In the one in a million chance that blocking on an abusive TLD causes a false positive for that rare legit record, you can add that unique record to a higher order RPZ list and resolve the matter in less than 5 minutes. Crisis averted!
Back to that expensive vehicle where multiple drivers have access to the keys, and can instantly drive it all over town via DNS resolution. Instead of asking “why were you in this bad neighborhood to begin with?” you can put some realistic and appropriate DNS controls in place, focus on the asset or application that was trying to get to that bad place and work the issue proactively. Quiet down the alerts that are caused by interacting with likely hotbeds of abuse. And no angry phone calls.
