Vercara’s Protective DNS service, UltraDDR, is designed to use its vast data lake of previously observed attacker infrastructure and correlate it with an incoming DNS query to decide if that Fully-Qualified Domain Name (FQDN) or domain is malicious. This capability by itself is the most accurate system in the market today to detect and block phishing, malware distribution, command-and-control, data exfiltration, and DNS tunneling.
However, UltraDDR also possesses an incredibly powerful tool that can be used to add additional protection policies for its devices and users: the Custom Rules Engine.
In this blog post, I will demonstrate the power and flexibility that custom rules have when it comes to augmenting and extending the other controls provided by UltraDDR by giving examples of policies and rules that we have implemented for ourselves and for our customers.
Custom rules can be made on the following data elements:
- Client IP: Which IP address made the DNS query. Example: 3.22.236.57.
- CName: The query answer contains a CNAME.
- CName FQDN: The answer to the query contained a CNAME to a specific Fully-Qualified Domain Name. Example: cdn.foo.com.
- CName TLD: The answer to the query contained a DNAME to a specific Top-Level Domain. Example: com.
- CVE: The IP address in the answer to the query has a specific vulnerability listed in the Common Vulnerabilities and Exposures (CVE) list. Example: 2008-4250.
- Domain: The domain name. This can also be blocked with the Lists Engine. Example: foo.com.
- Domain Age: The age, in days, from when the domain was registered. Example: 90.
- Domain Category: Any categories that the domain matches on. Example: gaming. This can also be blocked with the Categories engine.
- Domain TLD: The Top-Level Domain that the domain is in. Example: com.
- DoH: If the query was made using DNS over HTTPS (DoH). Example: N/A.
- DoT: If the query was made using DNS over TLS (DoT). Example: N/A.
- FQDN: A Fully-Qualified Domain Name (FQDN) in the query. Example: smtp.foo.com. This can also be blocked with the Lists Engine.
- IP: The IP address in the query answer. Example: 3.22.236.57. This can also be blocked with the Lists Engine.
- IP Country: The geolocation of the IP address in the query answer. Example: United States.
- Nameserver: The authoritative nameserver for the domain in the query. Example: ns1.foo.com.
- Nameserver FQDN: The FQDN of the authoritative nameserver that provided the answer. Example: ns1.foo.com. This can also be blocked with the Lists Engine.
- Nameserver IP: The IP address of the FQDN of the authoritative nameserver that provided the answer. Example: 3.22.236.57.
- Nameserver IP Country: The geolocation of the IP address of the FQDN of the authoritative nameserver that provided the answer. Example: United States.
- Nameserver TLD: The TLD of the authoritative nameserver for the domain. Example: com.
- Open Port: Open TCP and UDP ports on the IP address in the query answer. Example: 445.
- Proxy IP: An open proxy exists on the IP address in the query answer. Example: N/A.
- Query Type: The query type in the DNS query. Example: A.
- Registrar: The domain registrar that the domain was registered with. This can also be blocked with the Lists Engine. Example: CSC CORPORATE DOMAINS, INC.
- Status: The status returned by the previous UltraDDR Engines. Example: Permitted.
Country blocking.
It is very common that organizations block specific countries due to sanctions, more frequent attacks, etc. It is also extremely common for malware to use the .su (Soviet Union) country code TLD (CCTLD) since that country no longer exists, so companies may choose to block that as well.
You can block countries on the following criteria:
Domain TLD: Where the domain TLD is a country code TLD for the blocked country (Example: .us, .uk, .ca, .ru, .cn, .su)
IP Country: Where the IP address in the answer is geolocated to the blocked country.
Nameserver IP Country: Where the IP address of the nameserver for the domain is in the blocked country.
Block commonly abused top-level domains.
Some Top-Level Domains (TLDs) are used for malicious activity more frequently than others and are rather infamous inside of Incident Response circles:
- .xyz
- .icu
- .tk
- .pw
- .ga
- .ml
In 2023, we saw the rollout of Top-Level Domains such as .zip and .mov which are also file extensions that a lot of our customers want to explicitly block.
All these TLDs can be blocked directly inside a custom rule.
Block link-local and multicast DNS.
There are instances where internal recursive resolvers forward local domains such as .local used for Link-Local Multicast Name Resolution (LLMNR) or Multicast DNS (mDNS) (sometimes known as ZeroConf) to an upstream recursive server in error. These local domains should not exist outside the local network so the requests to them can be discarded. RFC (Request for Comments) 6762 Appendix G lists these TLDs that should be discarded:
- .local
- .intranet
- .internal
- .private
- .corp
- .home
- .lan
These TLDs can be blocked with a custom rule.
RFC 8375 also designates home.arpa as a local domain. It can also be blocked in custom rules.
This approach can also be applied to other domains that are used for internal purposes. For instance, where an organization uses a domain or subdomain only for internal resources such as corp.foo.com or internal.foo.com, they can block those if they leak out to the Internet.
Paranoid mode.
The Decision Engine inside UltraDDR provides statuses of “Watch Engine” and “Highly Suspicious” for domains that it wants to confirm are malicious before blocking them. Paranoid Mode extends blocking to domains with these statuses and is apropos for highly-regulated environments that are willing to block earlier on in the decision process.
Block new domains.
By default, UltraDDR blocks any domain that is newer than 30 days. You can very easily extend that behavior with a custom rule.
Limit DNS exfiltration and tunneling.
DNS exfiltration and tunneling use DNS queries in order to evade detection. Some types of exfiltration and tunneling use TXT and HINFO records because they have text responses that can hold more data. This is in contrast to A and AAAA query types which return an IP address. As a result, it is very common for organizations to have a desire to block TXT and HINFO queries.
This can also be used in combination with other conditions such as specific TLDs or specific countries.
Be creative.
In this blog post, I have provided some of our favorite custom rules and have showcased what kind of policies are possible through custom rules. This is a powerful capability in UltraDDR that will give you a lot of flexibility in creating powerful policies and rules to respond to your risks and threats.
