Thread Info
  • Locked Locked
  • Replies 3 replies
  • Subscribers 6 subscribers
  • Views 7429 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

UTM DNS – Security Considerations

DouglasFoster

Recently, I have been thinking about DNS security.   This seems odd, since DNS lookups are unauthenticated.   But DNS security definitely needs to be part of the implementation decisions.

UTM DNS is an integral part of defenses for users on the Internal Network.   ATP intercepts dangerous DNS lookups and the DNS SEC client protects against forged DNS entries, at least for those DNS Domains that have implemented DNS SEC signatures.  For this reason, the standard recommendation is for any internal DNS server to forward requests to UTM, so that UTM can screen them before forwarding them to external servers such as Google or Quad9

Given the value of UTM DNS for protecting the internal network devices, it is tempting to assume that it should be the DNS resource for all devices, including DMZ-based servers, Site-to-Site VPN, Client VPN, and Guest WiFi.   For simplicity, let’s use the term Extranet to represent these users.  Users in the Extranet are less trusted than internal users, and in particular Guest WiFi devices are no more trustworthy than any other Internet source IP.   As a result, the UTM must defend against potential threats from the devices even as it seeks to provide some protection to them.

DNS configuration comes from different sources:   For VPN Clients and UTM DHCP clients, UTM provides DNS configuration along with an IP address.   For DMZ-based servers, the organization configures DNS during deployment.  For Site-to-Site VPN devices, the DNS is usually provided by the remote site, using their DNS servers and possibly a HOSTS file.   To protect the internal environment, UTM must block access to either UTM or Internal DNS severs for those devices that should not have such access.

The configuration options are:

  • External DNS (e.g. Google or Quad9), optionally supplemented with Hosts file entries.
  • UTM DNS
  • Internal DNS

Unfortunately, UTM DNS may not be sufficiently different from Internal DNS, and in many cases either UTM DNS or Internal DNS will introduce unwanted information disclosure to Extranet users.  Additionally, UTM provides only one DNS setting for all Remote Access VPN client methods, so flexibility is limited.

Here are the security concerns with using UTM DNS for Extranet users:

  • Some DNS resources will have both an External (Internet) address and an Internal address. For security reasons, Extranet users should generally be directed to the External address, and should generally be blocked from connecting with the Internal address.  WAF sites are one example of this condition.  The purpose of WAF is to protect against less-trusted clients, and by definition, Extranet devices are less trusted than Intranet devices, so they should be directed to the WAF site.   UTM DNS will typically resolve to the internal address.  This produces a traffic misdirection when the DNS result is utilized.
  • Even if no traffic is misdirected, DNS queries which reveal unnecessary internal information to an Extranet user is also a security risk, since a persistent attacker will value the mapping information available from the DNS zone files. Reverse DNS queries present the greatest risk, because an attacker can walk the set of all possible IP addresses to obtain a complete DNS map of both addresses and host names on the internal network.

Possible mitigations against these concerns:

  • Minimize the amount of Internal DNS information configured into DNS. There are some disadvantages to doing this, so the risks and benefits should be traded against each other.
  • Use DNAT entries to replace internal addresses with either external addresses or dead-end addresses. This provides a way to direct users to a WAF virtual webserver even if DNS returns an internal address.   While it prevents traffic misdirection, it does not solve the concern about information leakage.
  • Use multiple UTM devices for different purposes, so that the DNS information in each device can be tailored to each Extranet user group. In particular, I recommend using a dedicated UTM for Guest WiFi, rather than trying to  share it with the UTM that defends the internal network.

Here is a brief discussion of the ways that Internal DNS information become integrated into UTM DNS, so that the tradeoffs can be properly evaluated as those decisions are being made:

  • UTM “Host” objects may reveal information about a single host.
    A UTM “Host” object only represents a DNS host record if the DNS name field is populated, and it only represents a Reverse DNS pointer object if the “Reverse DNS” option is also checked. The object name is irrelevant for DNS purposes.
  • UTM “DNS Host” objects reveal information about an entire Forward lookup zone. This occurs because a DNS Host record requires a DNS Zone Forwarding entry to support it.   Once the Zone Forwarding is configured, the entire zone contents become visible to DNS queries.  One reason that DNS Host records may be needed is for HTML5 VPN access to desktop devices that use DHCP configuration.  For most other purposes, they can probably be avoided.
  • UTM “Reverse DNS” forwarding reveals information about an entire Reverse Lookup zone. Reverse DNS is necessary to provide host names in log files, which may be essential to correctly attribute traffic to DHCP-configured devices.   However, this extra information for logs also exposes important information to anyone with the ability to perform DNS queries to UTM, and Reverse DNS represents the greatest risk of information leakage.

Additionally, we need to consider the security effects caused by interaction between the proxies and UTM DNS.   Standard Web and FTP perform DNS resolution on behalf of the client, then direct traffic based on that result.   Transparent Web (and probably Transparent FTP) will also perform these steps if Pharming protection is enabled.  These lookups are unrelated to any DNS configuration on the device, and this traffic will also bypass UTM Firewall Rules.   These steps are recommended to mitigate the risk of these proxies:

  • Do not include Extranet addresses in the Allowed Networks list for any Standard Web Filter Profile or for Standard FTP. It would seem impractical to routinely configure these clients for a Standard Proxy, so any use of this configuration seems inherently hostile.
  • Do not enable Pharming Protection if any Extranet users are allowed access to a Transparent Web or Transparent FTP proxy. Because this is a system-wide setting, it also affects internal users.
  • Do ensure that the Filter Actions for Extranet users have web site block rules to prevent them from being used to access internal sites for which they should not have access.

Because of the above considerations, the following recommendations seem wisest to me:

  • Guest WiFi
    Use external DNS with Transparent proxies, or a dedicated UTM.
  • Site-to-Site VPN
    Use remote site DNS supplemented with HOSTS file entries as appropriate.
  • Remote Access VPN
    Avoid its use as much as possible, use UTM DNS, and avoid creating Reverse DNS forwarding.
  • DMZ-based servers
    Use External DNS supplemented with HOSTS file entries as appropriate.

What I would like to see in the future:

  • A UTM configuration and license which is optimized (and priced attractively) for dedicated Guest WiFi. All unrelated features are disabled, and management is performed from a management-only network connection.
  • The ability to restrict UTM DNS objects to VPN users and group. Any attempt to query for an object which is not authorized will automatically become an External DNS lookup.   This provides a way to ensure that Extranet users only have DNS information for resources to which they have been granted access.

What are your thoughts on this?



This thread was automatically locked due to age.
Parents
  • DNS gives the attacker information.  But it does not give them access.
     
    Scenario 1:
    Lets assume for a second that an attacker is on a separate guest network (segregated such as in BAlfson's recommendation) but has full access to all the DNS on the UTM and on the AD server.
    How can an attacker leverage this information to gain access to a system he shouldn't?

    Scenario 2:
    Lets assume for a second that an attacker is on a separate guest network but has no access to any internal DNS records.
    How can an attacker who can guess IP addresses and use hosts files gain access to a system he shouldn't?

    The difference between scenario 1 and scenario 2 is the attacker knows the hostnames and IPs.  But an attacker could easily guess those.  So is there any real access security difference between them?  Obscurity is not security.
Reply
  • DNS gives the attacker information.  But it does not give them access.
     
    Scenario 1:
    Lets assume for a second that an attacker is on a separate guest network (segregated such as in BAlfson's recommendation) but has full access to all the DNS on the UTM and on the AD server.
    How can an attacker leverage this information to gain access to a system he shouldn't?

    Scenario 2:
    Lets assume for a second that an attacker is on a separate guest network but has no access to any internal DNS records.
    How can an attacker who can guess IP addresses and use hosts files gain access to a system he shouldn't?

    The difference between scenario 1 and scenario 2 is the attacker knows the hostnames and IPs.  But an attacker could easily guess those.  So is there any real access security difference between them?  Obscurity is not security.
Children
  • in reply to Michael Dunn

    Yes, the issues are severable and somewhat independent:

    • Does the DNS configuration return an internal result when an external result is required for the person issuing the query?
    • Does the DNS configuration provide information about the internal network to someone who does not need the information?
    • Can the implicit DNS functions, implemented within the web/ftp proxies, create an access path that is not intended?

    The most challenging topic is the second one, about information disclosure.   You are correct that it does not provide access, but it still represents a risk to be managed.   The DNS SEC development faced this same issue.   An early version of DNS SEC was believed to provide a way for an attacker to harvest all host names within a DNS SEC zone, and the design was changed to respond to the objection and hinder any such efforts.

    More recently, I presented substantially this same material to my local ISC2 chapter.   The audience was a small group of CISSP-certified people like myself plus a college class with their professor.   The presentation was on the conceptual problem, because the audience would not be interested details of a product that they do not use.  Nobody suggested that the information leakage issue was unimportant, and nobody suggested that they knew of a firewall product that solved it beautifully.   But I am hoping that it gets strategic consideration for long-term product plans.

Unfiltered HTML