Note
You must have the Cloud Firewall and DNS licenses to use DNS Security. This feature is available with IPSec, GRE, and Netskope Client traffic steering methods.
DNS Security is a Cloud Firewall feature that provides protection for DNS services.
DNS is one of the most widely used internet protocols for most services, which makes it vulnerable to attackers looking to exploit this service. These attackers use phishing sites, C&C servers, and malware on new domains that aren’t yet flagged as malicious. For example, newly registered domains (NRDs), domain generated algorithm (DGA) domains, etc. Attackers can also attempt Command and Control (C&C) and data exfiltration with tunneling over DNS by using software on an infected host to encode extra content within a DNS query.
This feature allows you to identify and block malicious DNS requests. You can apply domain blocking categorically to prevent your users from connecting to unsafe domains. This allows you to stop or sinkhole connections to newly registered domains (NRDs), DGA domains, and others that aren’t yet classified as malicious. You can also allow or block DNS tunnels and protect against unauthorized data transfers using those tunnels. Netskope updates the threat database every 15 minutes to protect your data against the latest threats.
DNS servers refusing to respond are treated like unreachable servers and resolved through Netskope DNS. When “All Traffic” is steered to the Netskope SSE platform, whether through the Client or using GRE or IPSec tunnels, Cloud Firewall will inspect the packets and identify DNS requests sent on TCP or UDP protocols, thus allowing for DNS Security on DNS requests that use non-standard ports.
Workflow
The primary steps to configure DNS Security include:
- Create a steering configuration to steer DNS traffic to the Netskope cloud.
- Create a DNS exception for your steering configuration. You should bypass local domains by specifying them in the steering exceptions.
- Create a DNS Profile to define the actions taken for different domain categories. For example, you can block all domains that fall under the phishing category.
- Create a Real-time Protection policy for the DNS profile you created.
Once you enable your policy, all detected DNS threats are captured in Alerts. If a log all DNS configuration is set for debugging purposes, then those events are captured under Network Events.
DNS Security Through the Netskope Client
The Netskope Client is capable of steering DNS requests originally destined to an internal DNS Server if the appropriate steering configurations are in place. In essence we want to configure the default “Local IP address range” steering bypass to “Bypass, except for DNS traffic”:
The Netskope Client is also capable of performing exceptions based on the DNS query content itself. Those exceptions are called “DNS” steering exceptions, and instruct NSClient to send direct queries that match the configured record type and domain:
DNS exceptions are mandatory for all the internal domains, as all the internal domains are to be resolved by the local DNS server, and as such they must not be steered.
DNS Security with Web Traffic Mode
DNS Security can be enabled for “Web Traffic” steering only. The idea behind this is that DNS Security can be used by customers that don’t want to use other CFW features. This is also very useful for migrating from “Web Traffic” to “All Traffic” in steps.
DNS Security can also be enabled or disabled when steering “All Traffic” and it can be granularly configured when Dynamic Steering is enabled.
Generative AI Considerations
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.
Events associated with Generative AI will be covered by the following cases:
Case 1
With GenAI set to Block and subcategories allowed, any domain matching subcategory and the main category will be blocked.
Case 2
With a GenAI sinkhole and the GenAI subcategory allowed, all GenAI and GenAI subcategories will be Sinkhole and application/categories will be displayed as GenAI, in other categories as subcategories.
Case 3
With GenAI set to Allow and the GenAI sub category set to either Block or Sinkhole, domains in GenAI subcategories, network events displays subcategories in the events, in app/category options and other categories as GenAI.
Case 4
With GenAI set to Block, one subcategory Sinkhole and another subcategory as Block, all the Block actions, app/category displays GenAI and other categories as a subcategory.
As the Sinkhole action has highest precedence: for Sinkhole, app/category displays GenAI- subcategories and other categories display GenAI.
Case 5
For all the Allow network events, app/category display GenAI, and no subcategories gets displayed in Allow action as there is no other category field.
