Netskope Global Technical Success (GTS)

Implementing and Verifying DNS Security Measures

Netskope Cloud Version - 120

Objective

This article provides a comprehensive overview of DNS-based security measures, focusing on techniques to block malicious DNS traffic, implement Sinkholing, and prevent DNS tunneling attacks.

Prerequisite

To use the DNS security feature, you need two specific licenses:

1. Cloud Firewall license

2. DNS Security license

Context

As one of the most exploited internet protocols, DNS requires robust security measures to protect against a variety of attacks. DNS Security is a vital feature of Netskope's Cloud Firewall, designed to protect DNS services from various cyber threats. This document will detail how to configure DNS Security to block these malicious requests and implement sinkholes effectively. 

Foundational Concepts

• What is DNS Sinkholing?

DNS sinkholing is a security technique that redirects malicious DNS queries to a controlled IP address, often referred to as a "sinkhole." This method prevents users from connecting to harmful domains by resolving their requests to an IP that provides warning messages or logs the activity, allowing organizations to monitor and analyze potential threats.

• What is DNS Tunneling?

DNS tunneling is a method used by attackers to encode non-DNS traffic within DNS queries and responses. Since DNS traffic is often allowed through firewalls, attackers can exploit this to bypass security measures. By disguising the data as DNS requests, they can communicate with a remote server or exfiltrate information without detection.

Step-by-Step Configuration

We will proceed to configure the following setup in this demonstration:

• Sinkhole for Newly Registered and Newly Observed Domain Categories
• Block All Security Risk Categories
• Manually add specific domains to both the blocklist.
• Block DNS Tunneling

Before we begin, please ensure that the Netskope steering configuration is set up as outlined in the document provided here

Key points: 

• Inspection of DNS over HTTPS or DNS over TLS is not currently supported by Netskope. Therefore, Netskope recommends configuring a policy to steer and block this traffic.
• Block all Security Risk categories, but be careful with NRDs and NODs to ensure users can still access legitimate resources. Consider using RBI for SWG as an alternative.
• DNS steering exceptions must be manually created for internal domains.
• The steering exceptions for both “Local IP address range” and “Bogon Networks” must be edited to select “Bypass, except for DNS traffic.” This ensures that NSClient will steer DNS requests sent to internal DNS servers.
• A Real-Time Protection Policy that associates a DNS Profile with the user’s traffic must be created and placed above any Layer 3/4 or Layer 7 policies that explicitly allow DNS traffic.

Step1: Configure a DNS Profile:

Path: Netskope Tenant UI >>> Policies >>> Profiles >>> DNS >>> Click on "New DNS Profile"

We have configured the DNS profile with the following settings: 

All security risk categories are blocked, the categories for Newly Registered and Newly Observed Domains are set to sinkhole with an IP address of 163.116.128.90, explicitly blocked domain “example.com” and DNS tunneling is set to Block.

Note : Configure logging to capture only blocked DNS traffic.. If troubleshooting or specific users require it, you can select “all DNS traffic”.

Step 2: Add the DNS profile to a Real-Time Policy

Path: Netskope Tenant UI >>> Policies >>> Real-Time Protection >>> Click on “New Policy” and select DNS.

Sinkhole for Newly Registered and Newly Observed Domain Categories

• To achieve this, we took inspiration from the “EPoT” solution, which operates using IP addresses in the 163.116.128.0/24 range assigned to Netskope. These addresses do not provide any publicly available Internet services ,their purpose is solely to route traffic to the Netskope Point of Presence (PoP). Following this concept, we selected the IP address 163.116.128.90 as our “Sinkhole” address.
• The primary advantage of using the Sinkhole option is that it allows end users to see a block page when attempting to access sinkholed traffic. For example, if a user tries to access a Newly Registered Domain, a DNS query will be generated from their machine. Netskope will respond to that DNS query with a sinkholed IP address, leading the user to receive a block page based on the real-time protection policy we set up. To implement this, we will configure a firewall application for the IP address 163.116.128.90 and set the action to "block" in the real-time policy. Please note that this configuration is only necessary if you want a block page. If you prefer, you can skip this step, and the sinkhole will still function without displaying a block page.

Note : Currently we only support A type DNS query (IPv4) for sinkholing. All other DNS query types will receive an NXDOMAIN response (empty section).

Step 1: Configure a Cloud Firewall Application for IP 163.116.128.90:

Path: Netskope Tenant UI >>> Settings >>> Security Cloud Platform >>> Traffic Steering >>> App Definition >>> Click on "New App Definition Rule" and then select the Firewall App.

Configure the CFW App as outlined, then click "Save" and “Apply the changes”

Step 2: Map the configured CFW App nDNS Sinkhole IP] in the real-time protection policy, setting the action to "Block."

Path: Netskope Tenant UI >>> Policies >>> Real-Time Protection >>> Click on “New Policy” and select Firewall.

Note :The block page will make use of the default template, which cannot be changed.You can still edit the default template to insert more information about the block.

Path: Netskope Tenant UI >>> Policies >>> Templates >>> User Notifications >>> Default Template with Type Block

Verification

Sinkhole domains:

We picked some random newly registered domains from external sites such as:  https://dnpedia.com/domains/dailydata.php

The nslookup output for newly registered sites returned the DNS sinkhole IP as the response.

When the user attempted to access the newly registered site from the browser, it got blocked with the default template.

Blocked domains:

“Security Risk” categorization can be tested using the Netskope hardcoded domains listed below.

Now let’s check nslookup to “example.com” which is explicitly blocked in the DNS profile.

In the Netskope tenant UI,blocked,sinkholed and DNS Tunnel logs can be found under SkopeIT > Alerts. You can filter the results by selecting "Alert Type: DNS" to focus exclusively on DNS traffic.

Explicitly blocked domains can be filtered using query  “(alert_type eq 'DNS') and threat_type eq domain_blocked”

Events based on categories are generated with the type "domain_category."

Whenever DNS tunneling is detected, an event will be generated with the event subtype labeled as "dns_tunnel”

FAQ:

Question 1 - Which traffic steering methods support the DNS security feature?

Answer - This feature is available with IPSec, GRE, and Netskope Client traffic steering methods.

Question 2 - What does the "None" action signify in a DNS profile?

Answer - "None" means the DNS queries are allowed.

Question 3 - How often does Netskope update its threat database?

Answer - Netskope updates the DNS threat database every 15 minutes

Question 4 - Can I create DNS exceptions on the client?

Answer - Yes, you can create exceptions based on DNS Resource Record, IP, and Domains.

Question 5 - Which operating systems support this feature?

Answer - The feature is supported on Windows 10 and later, as well as macOS Big Sur and later.

Currently it’s not supported on Linux , Android and iOS

Question 6 - What standard ports does Netskope recognize for DNS traffic?

Answer - 

•      DNS over UDP: Port 53
•      DNS over TCP: Port 53
•      DNS over TLS: Port 853
•      mDNS (Multicast DNS): Port 5353

Question 7 -How is DNS Traffic Inspected in Order?

Answer - DNS traffic is inspected in the following order:

1. Blocklist Check: If the domain is on the blocklist, the DNS traffic is denied.
2. Allowlist Check: If the domain is on the allowlist, the DNS traffic is permitted.
3. Categorization: Domains are categorized, and appropriate actions (allow,block,or sinkhole) are taken based on their categorization.
4. Uncategorized Domains: Domains that do not fall under any specific category will be allowed.

Terms and Conditions

• All documented information undergoes testing and verification to ensure accuracy.
• In the future, it is possible that the application's functionality may be altered by the vendor. If any such changes are brought to our attention, we will promptly update the documentation to reflect them.

Notes

• This article is authored by Netskope Global Technical Success (GTS).
• For any further inquiries related to this article, please contact Netskope GTS by submitting a support case with 'Case Type – How To Questions'.