Real-time Protection Policies
The Netskope proxy accepts HTTP and HTTPS traffic destined for port 80 and 443 respectively but enhancements to the proxy can now handle non-standard ports for HTTP and HTTPS traffic.
Tip
You may see other options available to you in the UI menu options. You can use them in conjunction with the Cloud Firewall policies but they are not required.
This capability provides the ability to configure allow / block security policies based on source and destination IP addresses, ports, and protocols.
This type of egress firewalling allows admins to:
- Prevent command and control type of of malware from exfiltrating data out of your network
- Blocks unwanted internet services from being used by all or specific users due to legal and / or compliance rules
- Provides awareness of any authorized and unauthorized activity on the network by logging all network events
- It enables fast and secure local internet breakouts for all ports and protocols, without any appliances to upgrade or deploy, all with unified management. Policies do not have to be tied to a physical location. Instead, policies adhere to a follow-the-user type model and provide identical protection no matter what device the user is using, or where they connect from. These policies are flexible and this is useful because Netskope can enable a more stringent policy as needed if a user is off premises or at a different location such as a risky country.
To get started, go to: Policies > Real-time Protection.
This pages shows:
- Name of each policy.
- The source (traffic criteria) for the policy.
- The destination for each app the policy monitors.
- The current action applied to each policy.
- The number of alerts generated by the policy in the last 30 days.
- Default behaviors are listed at the bottom of the policy page. You can edit the Non-Web traffic from this page, click the pencil icon to change the action.
For a more detailed view of each policy, click the name of the policy.
Policy details provide information about:
- Traffic Criteria: Traffic Criteria are sorted into ‘Source’ and ‘Destination.’ Netskope will show the most appropriate criteria based on the application selected for ‘Destination.’
- Profile and Action: The action is performed when the traffic criteria and profile are both matched.
- If the ‘Destination’ column of the policy has ‘Firewall App Definitions’ then it is a firewall policy. Typically the firewall app definition is enclosed within ‘[ ]’. Additionally, if the ‘Destination’ column lists ‘Any Traffic’ then it is also considered a firewall policy.
Firewall Policy Order
Policy Hierarchy
Netskope Policy Engine is hierarchical and it adopts a top-to-bottom, first-match approach.
This means that as soon as the traffic being analyzed matches with the higher policy in the hierarchy, Netskope Policy Engine enforces that policy and it applies the action corresponding to that policy. No other policies that are further down the hierarchy will be evaluated.
Policy Matching
On any Next Gen Firewall, or more simply any L7 Firewall, there are different ways on which the Firewall identifies the traffic in order to apply the policies in the hierarchical order. The Netskope Cloud Firewall is the same.
Consider 2 types of Firewall Applications:
-
Layer 3/4 (in short L3/4): these firewall applications, currently known and managed as Custom Firewall Applications, and in the future known and managed as Services, are defined by the L3/4 protocol and port (L3 being ICMP, with no port as L3 protocols don’t deal with ports, and L4 being either TCP or UDP, with the relative ports). Currently, Custom Firewall Applications are also defined by the destination (IP, IP Ranges, CIDRs, FQDN, wildcard domains), while in the future Services and Destinations will be independent profiles that can be used as independent criteria in the Policy construct.
FQDNs and Wildcard Domain destinations can only be evaluated when using the NSClient, as we need to observe the DNS resolutions to map the FQDN to the IP address used by the application to connect. Custom Firewall Applications defined on FQDNs or Wildcard Domains won’t match if the traffic is coming from a Tunnel (IPSec/GRE) -
Layer 7 (in short L7): these firewall applications sit on the last ISO/OSI layer and are application-specific services, such as HTTP, SSL, SSH, RDP, that rely on a L4 transport method (UDP/TCP). Layer 7 applications require what is called a Deep Packet Inspection engine (DPI in short) in order to identify them, as they can’t be just identified by the L3 packet or the L4 datagram headers information. In essence, an inspection engine must be used to inspect the datagrams payloads to understand what higher-level application is encapsulated within. This process requires the inspection of more than one packet, sometimes looking at both the requests and the replies as opposed to a L3/4 application identification that is based on just looking at the headers of the L3 packets and L4 segments headers of the first request.
When you create CFW Policies, you can select both L3/4 and L7 applications, but due to the nature of the two, the engines required to identify them, and the policy hierarchy, there are implications on when the policy engine is able to associate certain traffic to an application, hence to a policy.
Summarizing the policy matching as follows:
- In all cases the first Policy in the hierarchy that matches the traffic will match, and the relative Action will be taken
- Policy defined for L3/4 firewall applications match at the first packet (TCP SYN or first UDP Packet), as long as they are above in the hierarchy to any other Policy containing L7 Applications (not even in the same Policy)
- Policy defined for L7 firewall applications, or for L3/4 applications when placed below in the hierarchy to any other Policy defined for any other L7 firewall applications (or defined in the same Policy) require Deep Packet Inspection of the traffic, so they can’t be blocked at the first packet
- When Deep Packet Inspection is required as per the above logic, the DPI engine takes a certain number of packets to identify the application. The packets the DPI engine takes to identify the L7 Application, or before giving up, flow through the cloud Firewall, so they are always allowed
- If the DPI engine cannot identify the application in 6 packets (for TCP plus the handshake), there is no L7 application matching, hence the traffic will be handled by any L3/4 Policies matching the traffic or it will hit the Default Policy, and the relative Action will be taken
- If the traffic stops before the DPI engine has identified the L7 Application or before 6 packets (for TCP plus the handshake), no Policy can be matched, so the logs will show those packets as “Allowed” hitting “No Policy”
- In both the above cases if the traffic was matching a L3/4 firewall application (whether or not defined in a Policy), the logs will show the name of the L3/4 firewall application, if not they will show a blank (“ “) application
- In some cases (for instance in non-web protocols that use SSL) the DPI engine identifies SSL as “partial protocol” while carrying on the Inspection. If the traffic flow terminates before DPI can identify the real L7 firewall application, or if DPI cannot identify the real L7 firewall application in 6 packets (for TCP plus the handshake), no definitive L7 firewall application can be used for Policy matching, but in case there is no L3/4 application matching the traffic, the logs will show the partial L7 application identified and the “Default Policy” applies
- If the DPI engine identifies a L7 Application before the traffic flow ends and before 6 packets (for TCP plus the handshake), the first Policy in the hierarchy defined for the matching L7 firewall application identified will match, and the relative Action will be taken
The firewall policy is applied based on the order (Rule ID in image below). Any other non-firewall policies will not affect the firewall traffic. The numbering sequence is irrespective of the policy type. For firewall traffic, only firewall policies will be considered and the system skips the in between numbers which are non-firewall policies.
Important
Firewall policies for custom firewall applications are applied on the first packet during traffic inspection. Due to this behavior, Netskope recommends the following order for your firewall policies:
- Service Object and Destination Profile policies
- Firewall app policies or hybrid (firewall and cloud) app policies
- Cloud app policies
Additional Menu Options for Editing a Policy
You can edit the policy by clicking the three dots to the far right of the policy name. A menu opens that enables you to edit, view alerts, move policies, disable, clone, and delete policies.
Searching for a Policy
You can search for a specific policy by typing the name in the search box. The policies that match closely to your search text are filtered in the Policies list. Optionally, you can select the Show Matched Policies Only checkbox which further filters your policy list to display only the policies that precisely match your search text.
The Real-time Protection Policies page also allows you to use search filters to find policies for specific users, apps, websites, and firewalls.
 |
To use the search filters, click the filter icon to apply one or more of these filters:
- User: Find policies that detect specific users.
- Action: Find policies that take a certain action, like block or encrypt.
- Network Location: Look up and filter by a specific or multiple network location(s).
- Application: Look up and filter by a specific application.
The Real-time Protection Policies list page by default displays 25 rows. To change your view, select the option from the bottom right of the page (options include: 25, 50, 100, 150).
You can view the list page in Default or Custom table view. From the Custom table view, you can customize the columns or restore the default view. To access the Customize Columns window, click the gear in the upper right corner of the table while in Custom table view.
Service and Destination Profiles
Service Objects and Destination Profiles are supported in RTP and BWC. Custom firewall apps are still being used in steering exceptions.
If L3/L4 policies are created with activities, these will not be evaluated by CFW.
Service and Destination Profile can now be selected during the creation of a Real-Time Protection Policy.
As an example, consider the following policy:
This FTP application will only be blocked through the ports defined in the Service Profile to the IPs defined in the Destination Profile. An alert will fire in SkopeIT if the traffic is blocked.
If the Action is set to Allow, this FTP application will only allow traffic through the ports defined in the Service Profile to the IPs defined in the Destination Profile.
Create a Real-time Protection Policy: Firewall
By default, this field is set to Block. This means traffic that does not match any policy will be blocked.
The Identify HTTP Traffic on Non-Standard Port feature is incompatible with an already existing custom port configuration.
For example:
Traffic won’t be blocked if the tenant is configured with the Custom Port configuration feature enabled + Custom Port Configuration + HTTP-AD enabled + block-http-non-standard-port enabled. This applies to both HTTP1.1 and HTTP2 protocols.
Policies are defined using a set of variables. These variables define the criteria for detecting policy violations.
To create a Real-time Protection policy:
Important
You must set the Destination field first and then the Source field. This is required because if you select the Source before Destination, the Source is deleted / reset.
If Destination apps are selected as Firewall apps (Predefined or Custom) then the “Source > User=” dropdown list doesn’t show the Exclusions = option because Cloud Firewall does not support this option.
- On the Real-time Protection Policies page, click New Policy > Firewall. When creating a new policy, select a template that most resembles your goal. No matter the choice, you can edit as you work through the policy creation workflow. Choosing a template means some fields are auto-populated for efficiency. You may see other options as shown below, but only Firewall applies to this workflow.
- For Destination, select Application or Any Traffic. Only these options are applicable for setting up firewall policies. These options allow you to write a specific policy against a few applications, or a generic policy against entire categories of applications or type of traffic.
The Application option allows you to select cloud applications as well as DPI-based or custom firewall applications for your policy. DPI applications are available by default. In order to select firewall applications, you must first define them as custom applications.
To learn how to create custom applications, see App Definition.
To learn more about available applications:
The Any Traffic option makes the firewall allow or block any traffic (only the source is applicable and the destination is ignored).
- Select the Source. Click in the text box to select Source IP User or a user ID (email address). The system will show the most appropriate criteria based on your policy template selection.
The Source IP is set to ‘Matches’ by default. This means the policy engine will match against the criteria. The Source field can be left blank. If left blank, it implies that the source IP is set to ‘Any’.
The user ID must already exist in the system or ensure you add the new user. Refer to the Add Users topic for help. The app firewall learns the user ID (email address) and corresponding user IP address and caches this mapping. When the system sees traffic from this user IP, it uses this mapping and finds the associated user. This user ID is an additional policy attribute (used with other firewall attributes like IP address, port, protocol, etc.)
- Select the Action you would like to take: Allow or Block. For firewall policies, these are the only two options which apply.
- Enter a name and a policy description.
Important
When creating policy names, only use alphanumeric characters and symbols such as “_” underscore, “-” dash, and “[ or ]” square brackets. You cannot use the greater than “>” and less than “<” symbols in policy names.
- Click Save in the upper right corner to save your new policy. All policies are processed in a top-bottom order, meaning the policy that is at the top of the policy table will be processed first followed by the next in the order.
You should see the saved policy in the Policy list page.
You can drag-and-drop the policy name by highlighting the row and moving your cursor to the
icon and drag-and-drop the line to the desired location in the list page.Important
In order to support a Netskope Private Access (NPA) client inside a branch office that reaches an NPA gateway through a GRE tunnel, admins must configure an SSL Decrypt bypass rule in the WebUI for the account as *.goskope.com.
Access the configuration setup page by navigating to Policies > SSL Decryption. If you are not using NPA in your account, no action required.
Create a Real-time Protection Policy: DNS
DNS based security stops attacks at the DNS layer by blocking DNS requests for malicious domains, DNS tunnels, and newly registered domains and DGA-generated domains. You can customize inspection by uploading domain allow or block lists or sinkholing malicious connections. You also can create exceptions to handle resource record types.
DNS based security is available with IPSec, GRE, or Netskope Client traffic steering methods. However, IPv6 DNS traffic is not supported.
After you create a DNS profile, you must add it to a DNS-type Real-time Protection policy.
To create a DNS policy:
- Go to Policies > Real-time Protection, then click New Policy > DNS.
- Select the Source. Click in the text box to select Source IP User or a user ID (email address). The system will show the most appropriate criteria based on your policy template selection
The Source IP is set to Matches by default. This means the policy engine will match against the criteria. The Source field can be left blank. If left blank, it implies that the source IP is set to Any.
The user ID must already exist in the system or ensure you add the new user. See Add Users. The app firewall learns the user ID (email address) and corresponding user IP address and caches this mapping. When the system sees traffic from this user IP, it uses this mapping and finds the associated user. This user ID is an additional policy attribute (used with other firewall attributes like IP address, port, protocol, etc.)
- The Destination is DNS by default. Only this option is applicable for setting up DNS policies.
- For Profile & Action, select a DNS profile. You can only select one DNS profile per policy. The only available Action is Default, because the actions are configured in the DNS profile.
- Add a name and description for the policy.
Note
When creating policy names, only use alphanumeric characters and symbols such as underscores (_), dashes (-), and square brackets ([ ]). You cannot use the greater than (>) and less than (<) symbols in policy names.
- For Status, enable or disable the policy.
- Click Save in the upper right corner to save the policy.
Once you save the policy, it appears in the Policies list page.
Create a Real-time Protection Policy: DLP
DLP now supports FTP applications. For specific information on DLP, see Data Loss Prevention.
Supported Traffic and Features
- Passive FTP only (data connection from client to server)
- RTP rules with DLP profiles and activities (upload/download)
- RTP rules with activities only (no DLP profiles)
- DLP for files up to 128MB, 16MB for non-web proxy
- DLP profile actions: Allow, Block, Alert
- Fallback Action, Max File Size, Client Timeouts
- Access methods: IPsec, GRE, NSClient
- Network events for flows and DLP policy enforcement
- DLP alerts
To create a DLP policy:
-
Go to Policies > Real-time Protection, then click New Policy > DLP. (Firewall can also be selected)
-
Select the Source. Click in the text box to select Source IP User or a user ID (email address). The system will show the most appropriate criteria based on your policy template selection
The Source IP is set to Matches by default. This means the policy engine will match against the criteria. The Source field can be left blank. If left blank, it implies that the source IP is set to Any.The user ID must already exist in the system or ensure you add the new user. See Add Users. The app firewall learns the user ID (email address) and corresponding user IP address and caches this mapping. When the system sees traffic from this user IP, it uses this mapping and finds the associated user. This user ID is an additional policy attribute (used with other firewall attributes like IP address, port, protocol, etc.)
-
Set the Destination to Application to FTP.
-
From here, you can set the Activities to Upload and/or Download.
There are also Activity Constraints that can be added such as File Size and File Type.
-
For Profile & Action, Allow, Alert, and Block are the settings with Firewall Template that can be set.
If a user chooses a mixture of applications and wants to use DLP in the policy, the selection look like the following image:
-
Enter a Policy Name and set the Group to be either in the Header Policies, Default, or Footer Policies
-
Set the Status to Enabled.
Create a Real-time Protection Policy: Activities and file constraints
RTP policies can be created for the FTP application.
To create an FTP policy:
-
Go to Policies > Real-time Protection, then click New Policy > Cloud App Access
-
Under Source, select the appropriate criteria from the Add Criteria button.
-
Set the Destination to Application to FTP.
-
From here, you can set the Activities to Upload and/or Download.There are also Activity Constraints that can be added such as File Name, File Size, and File Type while also deciding whether the File should Match or Not Match the following constraints.
File Names or Extensions can be imported from a CSV or manually entered.
File Types can be selected from a preexisting list of file types.
File Size must have a unit specification from B, KB, MB, or GB.
-
Under Profile & Action, select between Alert, Allow, or Block. If enabled, you can also add a DLP profile.
-
Enter a Policy Name and set the Group to be either in the Header Policies, Default, or Footer Policies
-
Set the Status to Enabled.
Create a Real-time Protection Policy: Threat Protection for FTP
Threat Protection policies for FTP can be created. For more info, see Threat Protection profiles and Remediation profiles.
Supported Traffic and Features
- Passive FTP only (data connection from client to server)
- RTP rules with TSS profiles and activities (upload/download)
- TSS profile actions (for different severity levels): Allow, Block, Alert and Remediation
- Combinations of service objects, destination profiles, activities, file size, file type and TSS profiles in an RTP rule
- TSS for files up to 400MB
- data trickling for large files > 16MB.
- Fallback Action, Max File Size, Client Timeouts
- Traffic action alert/block/allow in case no profile matched
- Access methods: IPsec, GRE, NSClient
- Network events for flows and TSS policy enforcement
- TSS alerts and Incidents
To create a Threat Protection policy:
- Go to Policies > Real-time Protection, then click New Policy > Threat Protection
- Select the Source. Click in the text box to select Source IP User or a user ID (email address). The system will show the most appropriate criteria based on your policy template selection.
The Source IP is set to Matches by default. This means the policy engine will match against the criteria. The Source field can be left blank. If left blank, it implies that the source IP is set to Any.The user ID must already exist in the system or ensure you add the new user. See Add Users. The app firewall learns the user ID (email address) and corresponding user IP address and caches this mapping. When the system sees traffic from this user IP, it uses this mapping and finds the associated user. This user ID is an additional policy attribute (used with other firewall attributes like IP address, port, protocol, etc.) - Set the Destination to Application to FTP.
- From here, you can set the Activities to Upload and/or Download.There are also Activity Constraints that can be added such as File Size and File Type.
- In the Profile & Action section, select a Threat Protection profile. Netskope recommends selecting Default Malware Scan (predefined) because it automatically scan across all Threat Protection engines based on your organization’s license.
- Select the Action for each severity level. The recommended action for every severity level is Block. This ensures the best protection for users. To apply a remediation profile for each severity level, select a remediation profile from the dropdown list.
- Optionally, if you selected File Type constraints and chose a Block action for a severity level, you can see the Block till benign verdict by dynamic threat analysis option (This feature requires the Advanced Firewall license. For more information, please contact your account executive or support@netskope.com). Select to block users from uploading or downloading a file until Netskope dynamic threat analysis provides a benign verdict. The analysis can take up to 10 minutes.
- Enter a Policy Name and set the Group to be either in the Header Policies, Default, or Footer Policies
- Set the Status to Enabled.
Create a Real-time Protection Policy: Source IP (Egress)
Supported Traffic and Features
- DNS Policies only
- DNS profile actions: Allow, Block, and Sinkhole
- Combinations of User, Source IP, Source IP (Egress) and DNS profile in an RTP rule
- Traffic action is allowed if nothing is matched in the DNS Profile
- Access methods: IPsec, GRE, NSClient, Direct
- Network events for flows and source IP(Egress) policy enforcement
- DNS events and alerts
To create a Source IP (Egress) policy:
-
Go to Policies > Real-time Protection, then click New Policy > DNS
-
Select the Source. Click in the text box to select Source IP (Egress) User or a user ID (email address). The system will show the most appropriate criteria based on your policy template selection:
- Source IP (Egress) is set to Any by default. This will match against all IPs by default. To match against a specific IP, select Network Location Object from the drop down. The Network Location Object must be created pre-created. In case of DNSaaS, the Network Location should be the whitelisted IP in DNS Resolver Settings page.
- The user ID must already exist in the system or ensure you add the new user. See Add Users. The app firewall learns the user ID (email address) and corresponding user IP address and caches this mapping. When the system sees traffic from this user IP, it uses this mapping and finds the associated user. This user ID is an additional policy attribute (used with other firewall attributes like IP address, port, protocol, etc.)
- Source IP is set to Any by default. This means the policy engine will match against all the IP. The Source Ip field can be left blank. If left blank, that implies the source IP is set to Any. If Source IP is selected other than Any or blank then this policy will not work for DNSaaS (Direct path) but will continue to work for IPSec, GRE and NSClient.
-
Set the Destination to DNS.
-
In the Profile & Action section, select a DNS profile.
-
Select the Action for each severity level. Set Action to default as DNS profile guides what action to take based on various available actions withing DNS profile.
-
Enter a Policy Name and set the Group to be either in the Header Policies, Default, or Footer Policies
-
Set the Status to Enabled.
Alert and Continue to Next Policy Group After Match
Starting in R129, Web and Email policy groups now support continuing to the next policy group. You can configure policies where the last rule in a policy group will be the general block policy for a particular DLP profile and the preceding rules in the group will be exception rules where, if matched, an alert will be generated and policy evaluation will continue with the first policy rule in the next policy group.
When this feature is enabled, in the Policy creation screen under Profile & Action, there will be two options. These options are exclusive and only one can be selected at a time.
- Continue policy evaluation after match
- Continue to next policy group after match
This only applies to the Alert action.
Network Events for Flows and DLP Policy Enforcement
Events/Alerts are generated for the following cases:
1: Rule matched has DLP Profile.
A network event fires, and we will see it under the Network Events page, but webui will not display dlp_profile section for network-event, because DLP itself sends an alert, application-event, and incident separately, and we will see “nspolicy” as type for alert coming from DLP.
This will generate:
- A Network Event
- An Alert
- An Application Event
- An Incident
2: Rule matched has no DLP Profile and action is set to Alert.
This will be seen under the Alerts page.
3: Rule matched has no DLP Profile and action is set to Allow.
This will be seen under the Network Events page.
4: Rule matched has no DLP Profile and action is set to Block.
This will be seen under the Alerts page.