Skip to main content
  • EN

I understand the underlying premise for Netskope's recommendation for blocking DNS over HTTPS, to mitigate exfiltration risk, etc. However, with the industry push to move to DOH, won't we need to allow DOH traffic at some point? Most of our users browsers are configured to try DOH first, and some of them seem to be running into issues if DOH is not available and falling back to traditional udp 53 fails.

 

I also don't understand why Netskope says they don't support DOH traffic steering. (See https://docs.netskope.com/en/netskope-help/data-security/real-time-protection/best-practices-for-real-time-protection-policies/best-practices-for-utility-policies/#recommended-utility-policy-2-1) It would seem Netskope DOES support it since we ARE steering DOH traffic to Netskope, Netskope identifies the DOH traffic, and then blocks it with the Block DOH real time protection policy. So what does Netskope mean when they say "DNS over HTTPS is not a supported protocol for Netskope steering (CASB/NGSWG/NPA)"?

 

With the push toward DOH, you would think we would want to allow DOH traffic steering, have Netskope decrypt it and inspect, then be able to identify and alert on anomalous behavior within the DOH request packets. I'm sure there are technicalities I'm unaware of here, so could anyone clue me in on why this apparently isn't possible?

 

And like many other customers who have shared in a separate post out here, the thousands of DOH block alerts we are receiving every day in our Skope IT alert log makes it impossible for our security to acknowledge them all, and this drastically skews our reporting. Filtering out DOH from the Alerts view is not a helpful solution.

 

Thanks

Hello @bhennrel 


 


DoH(DNS over HTTPs) is definitely steerable via Netskope Inline, What is meant by this is;







Netskope recommends blocking DoH(DNS over HTTPS) or DoT(DNS over TLS) as it enforces the browsers to use the DNS over UDP resolution. In this way, Netskope Client continues to monitor the DNS responses and maintain the IP address to hostname mapping.


For the Client to apply steering configurations, it is essential to validate the DNS queries and responses. Since DoH or DoT encrypts the DNS payload, the Netskope Client cannot look into the DNS response. Hence, Netskope recommends to configure policies in proxy or firewall to block DoH and DoT and steer traffic. To steer DoT traffic(using port 853), Netskope Client checks for the following conditions:







We also need to consider Browsers and ISPs are implementing consumer grade security to avoid exploitation of individuals without security programs. 



DoH encrypts DNS requests, preventing eavesdropping and manipulation of DNS traffic. While good for ensuring privacy in home networks, DoH can present risks to enterprise networks if it isn’t appropriately implemented. The recommendations detailed will assist enterprise network owners and administrators in balancing DNS privacy and governance for their networks. It outlines the importance of configuring enterprise networks appropriately to add benefits to, and not hinder, their DNS security controls. These enterprise DNS controls can prevent numerous threat techniques used by cyber threat actors for initial access, command and control, and exfiltration.


NSA recommends that an enterprise network’s DNS traffic, encrypted or not, be sent only to the designated enterprise DNS resolver. This ensures proper use of essential enterprise security controls, facilitates access to local network resources, and protects internal network information. All other DNS resolvers should be disabled and blocked.
https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/2471956/nsa-recommends-how-enterprises-can-securely-adopt-encrypted-dns/

Hi @jforrest,

 

I appreciate the information you provided. And thanks for the details about how the Netskope client handles the monitoring of DNS responses (or doesn't if DoH is used). I'll take a look at those links you provided.

 

Again, much appreciated, 🙏

Brock

Definitely glad to help Brock and Happy Lunar New Year 🙏

Reply


Terms & ConditionsCookie settings