Allowlisting: Exception Handling for Blocked TLDs

Dave Piscitello

In this article, we discuss how to deal with blocklisting exception cases by using selective allowlisting to complement generalized blocklisting as part of an incident response.

Applying Old School Firewall Best Practices to DNS blocklisting

Like many first-generation firewall greybeards, I spent a fair bit of time testing and configuring network firewalls. The firewall admins whom I most respected were strong advocates of conservative outbound or egress traffic filtering policies. Over the years, I folded the accumulated wisdom of these admins into a egress traffic filtering best practices article, where I explained how to establish the most secure egress traffic baseline:

The best way to configure egress traffic filtering policies is to begin with a DENY ALL outbound policy, packet filter, or firewall rule. This creates a “nothing leaves my network without explicit permission” security baseline. Next, add rules to allow authorized access to the external services identified in your egress traffic enforcement policy.

Explicit permission is the exception handling language for firewall traffic filtering, and you can apply it in cases where you’ve blocked a TLD.

In previous articles [1][2], we explained that security conscious organizations sometimes choose to take extreme domain name blocklisting measures when they identify a threat and their tolerance for risk exceeds acceptable thresholds. In such scenarios, such organizations may employ stringent traffic filtering or blocklisting using their own security systems, but others may also use features of certain public, open resolvers to reduce risk. We then demonstrated how to block a TLD that is shown to exhibit significant cybercriminal activity, to reduce the threat surface.

Allowlisting Scenario

Since no one can practically begin by blocking the DNS entirely, blocking a TLD is essentially a baseline DENY ALL action on DNS traffic. But organizations should be prepared to handle exceptions should they make this choice.

For example, imagine that your healthcare organization falls victim to a malware attack that is disrupting critical services and is exfiltrating sensitive information. Your security team has monitored outbound DNS traffic and your event logs indicate that the infected systems are communicating with their command-control host using domains from a single TLD. Further analysis reveals that the domains appear to be part of a large network of registered domain names generated algorithmically (RDGAs). Containing and mitigating this threat quickly and thoroughly is your primary concern. You consult with your security team and staff and determine that no authorized or critical services are hosted at domains in this TLD so you and your team agree: blocklist it and continue with remediation and response.

With the command-control now unreachable from your network, you begin to identify infected devices from events in your DNS logs. As you restore services, you learn that you need to access one domain in this TLD to reach a supplier. You’re still remediating affected devices, so removing the block on the entire TLD at this time is premature.

In such a scenario, allowlisting is a practical option: this is a circumstance where explicit permission is appropriate for exception handling in traffic filtering or name resolution. Specifically, you can add an explicit ALLOW filter. This is the name resolution equivalent of what we called “punching a hole through your firewall”.

How to Allowlist Domains

In a previous article, we explained how to block a TLD using the NextDNS public, open resolver. NextDNS accommodates this via the Allowlist tab. In our allowlist scenario, we might add a single (wildcarded) domain:

With this exception filter in place, the organization should be able to reach the supply chain provider, but all other domains in the TLD remain blocked. While our previous articles only focused on using public, open resolvers, many security systems, e.g., firewalls, DNS servers or proxy devices, can accommodate both TLD blocking and exception handling.

Summary

In this post, we’ve used a compromise-and-breach scenario to explain what we mean by “extreme case” where blocking may be in play. In our scenario, a security team concluded that the welfare of the organization outweighed the benefits of universal domain resolvability, and the DENY ALL “staunched the bleeding” communications between the organization’s infected systems and the malware command-control were disrupted. The infected systems could be identified from DNS traffic logs and IT teams could begin malware removal, assess damage, and continue with restoring services. In this as in many scenarios, blocklisting is useful when employed temporarily. In persistent threat scenarios, it may be employed for as long as the threat condition persists.