DNS Control rules essential best practices

Secure Internet Access (ZIA) Cloud Firewall
, , ,
1

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.

    Screen Shot 2021-12-10 at 14.03.44
    Screen Shot 2021-12-10 at 14.03.442542×144 11.1 KB

  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.

    Screen Shot 2021-12-10 at 14.08.29
    Screen Shot 2021-12-10 at 14.08.291496×1456 241 KB

  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.

    Screen Shot 2021-12-10 at 14.14.33
    Screen Shot 2021-12-10 at 14.14.331920×1308 101 KB

  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.

    Screen Shot 2022-04-01 at 11.32.46
    Screen Shot 2022-04-01 at 11.32.461920×1312 108 KB

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

12 Likes
2

Any recommendations around DNS request type?

3

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
4

Hi,
When creating the DNS block rule for the Advanced Security or any other recommended category blocking, is it best to add these categories to the Requested Categories or the Resolved Categories section of the rule?
Thanks

5

Generally speaking it is best to add block rules to both sides of the DNS transaction – so apply the policy to both the request and the response.

Couple of things to keep in mind:

  • A block on the request side will be implemented immediately. ZIA will not allow a blocked domain request to get to the targeted DNS resolver (the ZTR or some 3rd party) and so the response side will never happen
  • There are more categorizations on the domain side than the IP side. The domain side categorizations are more precise in the sense that it focuses on the content more directly since an IP address can host 2 or more domains, each with a separate categorizations.
  • IP categorizations give an extra level of protection. For example, if a domain has been poisoned, it might be categorized accurately but is then served by an IP that is known to host malicious – and this would be the opportunity to catch this. Hence the recommendation to mirror the policy on both side when possible
6