DNS Control rules essential best practices

When DNS traffic reaches ZIA and the DNS Control module of the Advanced Cloud-Gen Firewall is active then consider the following best practices for rules:

  1. Set the default rule Unknown DNS Traffic to Block. This will stop non-DNS posing as DNS on dest:53 or malformed DNS. This will also identify some forms of abuse of DNS that are consistent with some DNS tunneling methods in real time.

  2. Block all Commonly Blocked DNS Tunnels and Unknown DNS Tunnels. These are Black and Grey classifications that ThreatlabZ has determined are clearly malicious or might be malicious.

  3. Consider blocking all Commonly Allowed DNS Tunnels. These are legitimate tunnels that are operated by common services but each usually has alternate and more normal means of communication.

  4. Block the Advanced Security category of domains and IP addresses. This targets both domains and IP addresses that are known to host targeted malicious content or used as backchannel (C2) communication or host hijacked domains.

  5. At the same time as recommendation 4, consider blocking other categories of domains or resolved IP addresses. For example, there is likely no business need for users in Locations or remote (Road Warriors) to access the Adult Content category etc. Also consider blocking or issuing warnings to categories that might exclusively apply to web browsing using the URL categorization of the web proxy (SWG). The advantage of blocking via the SWG is that the user can receive an EUN (but beaconing to the outside server in the case of HTTPS) whereas the advantage of blocking via DNS Control is that the action happens earlier in the killchain and applies to all traffic including non-web like SSH (but not giving the user any indication of why the silent DNS drop is happening).

  6. Consider blocking the entire Miscellaneous category with a particularly strong recommendation to block the Newly Registered and Observed Domains (NRODs). NRODs are often part of attack chains like being termination points for DNS tunnel exfiltrations or hosting drive-by and other malware before a classification can be done on these domains. There is also very little general business need for a business critical (or any commonly used) application to be hosted at an NROD.

All the above DNS Control policy is accessible in the left-nav of the UI console by clicking Policy → DNS Control.

8 Likes

Any recommendations around DNS request type?

We have recommended to some risk-adverse customers to block TXT and MX records since they are legitimate communication paths that can be used for malicious purposes but this currently falls short of becoming one of our best practices.

Blocking TXT records would come with the notable caveat that this would break the Sender Policy Framework used by MS Exchange and potentially cause problems with some other DNS server configurations. Blocking MX records would actually stop the transfer of mail between mail servers (though not typically users/MUA and their MTA). So these endpoints would need to be separated out from the general user population.

2 Likes