Netskope Cloud Firewall - Netskope Knowledge Portal

Note

This document guides you to configure the Netskope Cloud Firewall. The Netskope Cloud Firewall controls your organizations’ outbound non-HTTP(S) traffic. However, if you intend to manage the HTTP(S) traffic (on port 80/443 and non standard ports), you can refer to the Netskope Secure Web Gateway and Netskope Cloud Access Security Broker documentation.

Netskope Cloud Firewall provides centralized management, visibility, and consistent policies for distributed offices and roaming users. Also, advanced security and access controls without the cost, complexity, and performance limitations of traditional firewall appliances. Netskope also provides integrated cloud hosted firewall capabilities that allow granular control over your organizations’ outbound non-HTTP(S) traffic viz., TCP, UDP, and ICMP traffic.

Netskope Cloud Firewall provides network security on outbound traffic across all ports and protocols for users and offices. Cloud Firewall policy controls include 5-tuple (source and destination addresses and ports with protocol), plus user-IDs and group-IDs, fully qualified domains and wildcards as destinations, an application layer gateway for FTP, and firewall event logging.

With Netskope Cloud Firewall, you can apply an allow/block security policy based on source and destination IP address, destination ports, protocols, and users.

Netskope Cloud Firewall Key Benefits and Capabilities

Firewall Policy Controls: Includes 5-tuple (source / destination address and port, protocol), user-IDs and group-IDs, FQDNs and wildcards for egress firewall policy settings.
FTP Application Layer Gateway: Enables seamless use of FTP through cloud edge network address translation services.
Firewall Event Logging: Full logging of all desired cloud firewall events (TCP,UDP, and ICMP), available for export.
Integrated SASE Architecture: Netskope Security Cloud integrates cloud firewall with Secured Web Gateway (SWG), Cloud Access Security Broker (CASB), and Zero Trust Network Access (ZTNA) solutions for users and offices, to provide protection to all ports and protocols. Secure remote users and branch offices with Firewall-as-a-Service (FWaaS) using one console, one policy engine, and one platform.
Lower Cost of Operation: Reduce appliance expenses and maintenance,dependency on endpoint firewalls, and administration efforts with multiple consoles.
Protect Users: Provides network security for outbound traffic on all port sand protocols for safe direct to internet access with the Netskope client on managed devices. Cloud firewall filters egress traffic of managed users covering all ports and protocols, plus FQDNs and wildcards as destinations, an FTP ALG, and with full logging.
Secure Office: Provides network security for all outbound ports and protocols for safe direct to internet access via GRE and IPSec tunnels for any user or device. SD-WAN compatible, cloud firewall supports IPSec and GRE tunnels from offices to the Netskope Security Cloud to filter egress traffic.
DNS Security

Netskope enables you to steer non-HTTP(S) traffic using various methods. The following sections describe the various configuration steps.

Best Practices

If you have Explicit Proxy over Tunnel (EPoT) configured, and intend to procure Cloud Firewall license , you must adhere to following EPoT guideline prior to Cloud Firewall activation:
1. Use EPoT with port 80 (Recommended by Netskope)
2. If port EPoT has to be used with port 8080 for unavoidable reasons, then you must also define port 8080 in your Steering Configuration under Non-Standard Ports.
Not following above guidelines would result in traffic loss for EPoT after activation of Cloud Firewall.
Please refer to /en/explicit-proxy-over-ipsec-and-gre-tunnels#general-guidelines for more details.

When implementing Cloud Firewall there are a series of general best practices that should be followed. This list contains the best practices that should be followed when implementing Cloud Firewall in the majority of use cases, but it shouldn’t be considered as an exhaustive list as some best practices may depend on the environment, use cases, implementation.

When implementing Cloud Firewall the following are the most general best practices:

Choose the Default Non-Web Policy behavior according to your organization’s security posture.
By default, the Default Non-Web Policy (last resort) blocks all non-web traffic.
Although this default behavior is consistent with general Firewall hierarchies and best practices, it is possible to change the behavior of the Default Non-Web Policy to allow all non-web traffic as a last resort. There are valid use cases for doing so (for testing purposes, for discovery purposes, for a more “relaxed” non-web security posture when it comes to Internet traffic).
Depending on how the Default Non-Web Traffic Policy has been configured, keep in mind that:
- If it has been configured to block all non-web traffic, specific Policies that allow the sanctioned traffic must be put in place
- If it has been configured to allow all non-web traffic, specific Policies that block the unsanctioned traffic must be put in place
When configuring CFW in the presence of Tunnels, it’s extremely important to:
- Correctly define what non-web traffic should be sent to Netskope via Policy Based Routing
- Correctly define what are the expected “Custom Web Ports” sent to Netskope and configure them under the Default Steering Configuration. This will ensure that well-known and expected Web traffic sent to non-standard ports (e.g. 8080) will be managed by CASB/SWG which will also apply FW policies instead of CFW.
Since steering CFW traffic using NSClient, not unlike SWG traffic, relies on the ability to filter clear-text DNS queries and associated requested FQDNs to destination IPs to correctly associate the destination FQDN to the outbound TCP/UDP traffic, ensure that:
- DNS over HTTPS (DoH) is blocked by the appropriate Policy in the tenant
- DNS over TLS (DoT) is blocked by a Custom Firewall Application for port TCP 853 in the tenant
- DNS over Quic (DoQ) is blocked by a Custom Firewall Application for port UDP 443 and UDP 853 in the tenant
Configure all the Policies containing L3/4 Custom Firewall Applications above any Policy that contains a L7 Predefined Application. This is to guarantee that the Policies for L3/4 Custom firewall Applications will be triggered at the first packet.
Conversely, configure all the Policies for L7 Predefined Applications below any Policy that contains a L3/4 Custom Firewall Application.
There can be exceptions where one may want to place a Policy containing a L3/4 Custom Firewall Application below a Policy containing a L7 Predefined application, depending on the use case, but those use cases are niche use cases, and in that case one must keep in mind that the Policy containing the L3/4 Custom Firewall Application below any given Policy containing a L7 Predefined Application will trigger and be enforced only after DPI has completed or aborted the inspection of the L7 protocol.
Never mix L3/4 Custom Firewall Applications and L7 Predefined Applications inside the same Policy, for the reasons above, unless the admins have a specific reason for doing so.
Cloud Firewall Policies that act on Web ports/traffic must be placed accordingly to the overall CASB/SWG Policy hierarchy. For instance:
- Policies that contain L3/4 Custom Firewall Applications that apply to web ports 80/443 blocking the traffic, would prevent any CASB/SWG traffic if placed above any CASB/SWG Policy
- Policies for Hybrid Applications (such as Teams) that apply to both CFW and CASB/SWG allowing the traffic, would prevent any further CASB/SWG Activity/Instance/Threat Protection/DLP policy that is placed below. Hybrid Application Policies must be placed generally at the bottom