Real-time Protection Policies for Cloud Firewall

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

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:

  • Custom firewall app policies
  • Firewall app policies or hybrid (firewall and cloud) app policies
  • Cloud app policies
firewall_policy_order.png

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.

AdditionalMenuOptions.png

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.

RTpolicyPageFilters.png

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.

TableView.png

Create a Real-time Protection Policy: Firewall

The Default Action applies to all the policies.
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.

  1. 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.
    NewPolicy.png
  2. 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).

    The Destination options for a Firewall policy in Real-Time Protection.
  3. 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.)

  4. Select the Action you would like to take: Allow or Block. For firewall policies, these are the only two options which apply.
    AllowBlock.png
  5. 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. 

  6. 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.
    MovePolicy.png

    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 order.png 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:

  1. Go to Policies > Real-time Protection, then click New Policy > DNS.
    Creating a new DNS Real-time Protection policy
  2. 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.)

  3. The Destination is DNS by default. Only this option is applicable for setting up DNS policies.
  4. 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.
  5. 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.

  6. For Status, enable or disable the policy.
  7. 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.

Currently supported features:

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 256MB, 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:

  1. Go to Policies > Real-time Protection, then click New Policy > DLP. (Firewall can also be selected)

  2. 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.)

  3. Set the Destination to Application to FTP.

  4. 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.

  5. 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:

  6. Enter a Policy Name and set the Group to be either in the Header Policies, Default, or Footer Policies

  7. Set the Status to Enabled.

Network Events for Flows and DLP Policy Enforcement

Events/Alerts are generated for the following cases:

1: Rule matched has DLP Profile.
Non-web proxy sends a network event, 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:

  1. A Network Event
  2. An Alert
  3. An Application Event
  4. 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.

Appfwl

Appfwl generates 2 types of events while handling FTP traffic with FTP qosmos rule DLP profile/FTP activity. For both of these cases, the highest priority rule matched should be the FTP Qosmos rule with DLP profile/FTP activity.

Type 1: When there’s a FTP traffic on port 21 or already cached (same src ip, dst ip, port and protocol) FTP traffic on a different port:

Appfwl will generate a Flow Open event indicating that the policy will be applied by non-web proxy. The Flow Open event will have the FTP Qosmos rule with DLP profile/FTP activity due to which Appfwl decided not to apply any policy rather send packets to non-web proxy which will apply the policy.

Type 2: When there’s non cached FTP traffic on a different port than 21

Since the FTP traffic is not on port 21 and this traffic is not cached by Appfwl, Appfwl does not send the traffic to the non-web proxy. Later, when Qosmos classification finishes and Appfwl realizes that this is FTP traffic and needs to be sent to non-web proxy, Appfwl adds an entry to cache and terminates the flow.

Articles

Share this Doc

Real-time Protection Policies for Cloud Firewall

Or copy link

In this topic ...