Minimizing the risks of using DoH and DoT
DoH and DoT protection
Do you control your DNS traffic? Organizations invest a lot of time, money and effort in securing their networks. However, one area that is often overlooked is the DNS.
A good overview of the risks that DNS brings is at the Infosecurity conference.
31% of the ransomware classes surveyed used DNS for key exchange.Study Findings
31% of the ransomware classes surveyed used DNS for key exchange.
The problem is serious. According to the Palo Alto Networks Unit 42 Research Lab, approximately 85% of malware uses DNS to establish a channel of command and control, allowing attackers to easily infiltrate your network and steal data. Since its inception, DNS traffic has mostly been unencrypted and easily parsed by NGFW's security mechanisms.
New protocols for DNS have emerged to improve the privacy of DNS connections. They are actively supported by leading browser vendors and other software vendors. Encrypted DNS traffic will soon begin to grow in corporate networks. Encrypted DNS traffic that is not properly parsed and allowed by the tools poses a security risk to the company. For example, crypto lockers that use DNS to exchange encryption keys are such a threat. Attackers are now demanding a ransom of several million dollars to restore access to your data. Garmin, for example, was paid $10 million.
When properly configured, NGFWs can prohibit or secure the use of DNS-over-TLS (DoT) and can be used to prohibit the use of DNS-over-HTTPS (DoH), allowing analysis of all DNS traffic on your network.
What is encrypted DNS?
What is DNS
The Domain Name System (DNS) translates human-readable domain names (for example, the address ) to IP addresses (e.g. 34.107.151.202). When a user enters a domain name in a web browser, the browser sends a DNS query to the DNS server, requesting the IP address associated with that domain name. In response, the DNS server returns the IP address that this browser will use.
DNS requests and responses are sent over the network in plain text unencrypted, making it vulnerable to spying or changing the response and redirecting the browser to malicious servers. DNS encryption makes it difficult for DNS requests to be tracked or modified in transit. Encryption of DNS requests and responses protects you from a Man-in-the-Middle attack while performing the same functions as the traditional plaintext DNS (Domain Name System) protocol.
Over the past few years, two DNS encryption protocols have been implemented:
-
DNS-over-HTTPS (DoH)
-
DNS-over-TLS (DoT)
These protocols have one thing in common: they deliberately hide DNS requests from any interception ... and from the security guards of the organization as well. The protocols primarily use the Transport Layer Security (TLS) protocol to establish an encrypted connection between a client making queries and a server resolving DNS queries over a port that is not normally used for DNS traffic.
DNS query privacy is a big plus of these protocols. However, they create problems for security people who need to monitor network traffic and detect and block malicious connections. Since the protocols differ in their implementation, the methods of analysis will differ between DoH and DoT.
DNS over HTTPS (DoH)
DNS inside HTTPS
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 on the same connection", "make it difficult to parse DNS traffic", and thus circumvent corporate controls ( ). The DoH protocol uses TLS encryption and query syntax provided by the common HTTPS and HTTP/2 standards, adding DNS queries and responses on top of standard HTTP queries.
Risks associated with DoH
If you can't distinguish between normal HTTPS traffic and DoH requests, then applications within your organization can (and will) bypass local DNS settings by redirecting requests to third-party servers responding to DoH requests, which bypasses any monitoring, i.e. destroys the ability to control DNS traffic. Ideally, you should control DoH using the HTTPS decryption functions.
Π in the latest version of their browsers, and both companies are working on using DoH by default for all DNS queries. to integrate DoH into their operating systems. The downside is that not only reputable software companies, but also attackers have begun to use DoH as a means of bypassing traditional enterprise firewall measures. (For example, check out the following articles: , ΠΈ .) Either way, both good and bad DoH traffic will go unnoticed, leaving the organization blind to the malicious use of DoH as a channel to control malware (C2) and steal sensitive data.
Ensuring visibility and control of DoH traffic
As the best solution for DoH control, we recommend configuring NGFW to decrypt HTTPS traffic and block DoH traffic (application name: dns-over-https).
First, make sure NGFW is configured to decrypt HTTPS, as per .
Second, create a "dns-over-https" application traffic rule as shown below:
Palo Alto Networks NGFW rule to block DNS-over-HTTPS
As an intermediate alternative (if your organization has not fully implemented HTTPS decryption), NGFW can be configured to apply a "deny" action to the "dns-over-https" application ID, but the effect will be limited to blocking certain well-known DoH servers by their domain name, so how without HTTPS decryption, DoH traffic cannot be fully inspected (see and search for "dns-over-https").
DNS over TLS (DoT)
DNS inside TLS
While the DoH protocol tends to mix with other traffic on the same port, DoT instead defaults to using a special port reserved for that single purpose, even specifically disallowing the use of the same port for traditional unencrypted DNS traffic ( ).
The DoT protocol uses the TLS protocol to provide encryption that encapsulates standard DNS protocol queries with traffic using the well-known port 853 ( ). The DoT protocol was designed to make it easier for organizations to block traffic on a port, or agree to use it, but enable decryption on that port.
Risks related to DoT
Google implemented DoT in their client , with DoT automatically enabled by default, if available. If you have assessed the risks and are ready to use DoT at the organization level, then you need network administrators to explicitly allow outgoing traffic to port 853 through their perimeter for this new protocol.
Ensure visibility and control of DoT traffic
As a best practice for DoT control, we recommend any of the above, based on your organization's requirements:
-
Configure NGFW to decrypt all traffic for destination port 853. By decrypting the traffic, DoT will appear as a DNS application on which you can take any action, such as enable subscription to control DGA domains or already existing and anti-spyware.
-
Alternatively, you can completely block 'dns-over-tls' traffic on port 853 with the App-ID engine. This is usually blocked by default, no action is required (unless you specifically allow 'dns-over-tls' application or traffic on port 853). XNUMX).
Source: habr.com