{"id":97349,"date":"2020-10-17T14:42:14","date_gmt":"2020-10-17T12:42:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh"},"modified":"2020-10-17T14:42:14","modified_gmt":"2020-10-17T12:42:14","slug":"minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/minimizacziya-riskov-ispolzovaniya-dns-over-tls-dot-i-dns-over-https-doh","title":{"rendered":"Minimizing risks of using DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MinimizingMinimizing the Risks of Using DoH and DoT<\/p>\n

Protection Against DoH and DoT<\/h2>\n

Are you monitoring your DNS traffic? Organizations invest a lot of time, money, and effort in securing their networks. However, one area that often gets overlooked is DNS. <\/p>\n

A good overview of the risks posed by DNS is Verisign's presentation<\/a><\/noindex> at the Infosecurity conference. <\/p>\n

\"Minimizing31% of surveyed ransomware families used DNS for key exchange. Findings of the study<\/p>\n

31% of surveyed ransomware families used DNS for key exchange.<\/p>\n

The problem is serious. According to research by Palo Alto Networks Unit 42, approximately 85% of malware use DNS to establish command and control channels, allowing attackers to easily deploy malware in your network and exfiltrate data. Since its inception, DNS traffic has mainly been unencrypted and easily analyzed by NGFW mechanisms. <\/p>\n

New protocols for DNS have emerged, aimed at enhancing the privacy of DNS connections. They are actively supported by major browser vendors and other software providers. Soon, corporate networks will see a rise in encrypted DNS traffic. Encrypted DNS traffic, which is not properly analyzed and permitted, poses a security threat to the company. For example, such a threat comes from ransomware that uses DNS for exchanging encryption keys. Attackers are currently demanding ransom amounts in the millions of dollars to restore access to your data. For instance, Garmin paid $10 million.<\/p>\n

When properly configured, NGFW can block or protect the use of DNS-over-TLS (DoT) and can be used to prohibit DNS-over-HTTPS (DoH), allowing for the analysis of all DNS traffic in your network.<\/p>\n

What is Encrypted DNS?<\/h2>\n

What is DNS<\/p>\n

The Domain Name System (DNS) translates human-readable domain names (like the address www.paloaltonetworks.com<\/a><\/noindex> ) to the IP address (for example, to 34.107.151.202). When a user enters a domain name in a web browser, the browser sends a DNS request to the DNS server, asking for the IP address associated with that domain name. In response, the DNS server returns the IP address that the browser will use.<\/p>\n

DNS requests and responses are transmitted over the network as plain text in an unencrypted form, making them vulnerable to eavesdropping or altering responses and redirecting the browser to malicious servers. DNS encryption makes it difficult to track DNS requests or alter them during transmission. Encrypting DNS requests and responses protects you from Man-in-the-Middle attacks while serving the same functions as the traditional DNS (Domain Name System) protocol in plain text. <\/p>\n

In recent years, two DNS encryption protocols have been implemented:<\/p>\n

    \n
  1. \n

    DNS-over-HTTPS (DoH)<\/p>\n<\/li>\n

  2. \n

    DNS-over-TLS (DoT) <\/p>\n<\/li>\n<\/ol>\n

    These protocols share one common feature: they intentionally hide DNS queries from any interception\u2026 including from the organization's security personnel. The protocols primarily utilize the TLS (Transport Layer Security) protocol to establish an encrypted connection between the client making requests and the DNS server resolving those requests, via a port that is typically not used for DNS traffic.<\/p>\n

    The privacy of DNS requests is a significant advantage of these protocols. However, they create challenges for security personnel who need to monitor network traffic and detect and block malicious connections. Since the protocols differ in their implementation, the analysis methods will vary for DoH and DoT.<\/p>\n

    DNS over HTTPS (DoH)<\/h2>\n

    \"MinimizingDNS inside HTTPS<\/p>\n

    DoH uses the well-known port 443 for HTTPS, for which the RFC specifically states that the goal is to \"mix DoH traffic with other HTTPS traffic in the same connection,\" \"make DNS traffic analysis difficult,\" and thereby circumvent corporate control measures ( RFC 8484 DoH, section 8.1<\/a><\/noindex> ). The DoH protocol uses TLS encryption and the request syntax provided by common HTTPS and HTTP\/2 standards, adding DNS requests and responses on top of standard HTTP requests.<\/p>\n

    Risks associated with DoH<\/h2>\n

    If you cannot distinguish regular HTTPS traffic from DoH requests, then applications within your organization may (and will) bypass local DNS settings by redirecting requests to external servers that respond to DoH requests, which circumvents any monitoring, thus eliminating the ability to control DNS traffic. Ideally, you should manage DoH using HTTPS decryption features. <\/p>\n

    I can use Google and Mozilla have implemented DoH capabilities<\/a><\/noindex> in the latest versions of their browsers, and both companies are working towards using DoH by default for all DNS requests. Microsoft is also developing plans<\/a><\/noindex> to integrate DoH into its operating systems. The downside is that not only reputable software development companies but also malicious actors have begun using DoH as a means to bypass traditional corporate firewall measures. ( For example, see the following articles: PsiXBot now uses Google DoH<\/a><\/noindex> , PsiXBot continues to evolve with an updated DNS infrastructure<\/a><\/noindex> and analysis of the Godlua backdoor<\/a><\/noindex> .) In any case, both good and malicious DoH traffic will remain undetected, leaving the organization blind to the nefarious use of DoH as a channel for controlling malware (C2) and stealing sensitive data.<\/p>\n

    Ensuring visibility and control over DoH traffic<\/h2>\n

    As the best solution for controlling DoH, we recommend configuring HTTPS traffic decryption and blocking DoH traffic in NGFW (application name: dns-over-https). <\/p>\n

    First, ensure that NGFW is configured for HTTPS decryption, according to the decryption best practices guide<\/a><\/noindex>.<\/p>\n

    Second, create a rule for the application traffic \u2018dns-over-https\u2019, as shown below:<\/p>\n

    \"MinimizingPalo Alto Networks NGFW rule to block DNS-over-HTTPS<\/p>\n

    As an interim alternative (if your organization has not fully implemented HTTPS decryption), NGFW can be configured to apply the 'deny' action to the application identifier 'dns-over-https', but the effect will be limited to blocking certain well-known DoH servers by their domain name, as without HTTPS decryption, DoH traffic cannot be fully inspected (see.  Palo Alto Networks Applipedia<\/a><\/noindex>   and search for the phrase \u2018dns-over-https\u2019).<\/p>\n

    DNS over TLS (DoT)<\/h2>\n

    \"MinimizingDNS within TLS<\/p>\n

    While the DoH protocol aims to blend in with other traffic on the same port, DoT, by contrast, uses a dedicated port reserved for this sole purpose by default, even specifically prohibiting the use of the same port for traditional unencrypted DNS traffic ( RFC 7858, Section 3.1<\/a><\/noindex> ).<\/p>\n

    The DoT protocol uses the TLS protocol to provide encryption that encapsulates standard DNS protocol queries, with traffic using the well-known port 853 ( RFC 7858, Section 6<\/a><\/noindex> ). The DoT protocol was developed to simplify the process for organizations to either block traffic on that port or permit its use while enabling decryption on that port.<\/p>\n

    Risks associated with DoT<\/h2>\n

    Google implemented DoT in its client Android 9 Pie and later versions<\/a><\/noindex> , with automatic use of DoT enabled by default if available. If you have assessed the risks and are ready to use DoT at the organizational level, then network administrators will need to explicitly allow outbound traffic on port 853 through their perimeter for this new protocol.<\/p>\n

    Ensuring visibility and control over DoT traffic<\/h2>\n

    As best practices for controlling DoT, we recommend any of the following, based on your organization's requirements:<\/p>\n