A Security Practitioner's Perspective

Netskope Cloud Firewall Recommendations, Practical Advice, and Use Cases

Background

This document provides recommendations, practical advice, and use cases for Cloud Firewall (CFW).  When enabled in a tenant and applied to a steering profile, it will steer all traffic regardless of type-HTTP, HTTPS, and non-web traffic types. The non-web traffic includes TCP, UDP, and ICMP traffic.

CFW provides advanced security and access controls without the cost, complexity, and performance limitations of traditional firewall appliances. It accomplishes this through an integrated cloud-hosted firewall solution with granular control over outbound non-web traffic visibility.

It provides network security on outbound traffic across all ports and protocols for users and/or groups based on policy controls including a 5-tuple, fully qualified domains and wildcards as destinations, and an application layer gateway for FTP; the 5-tuple includes source address, source port, destination address, destination port, and protocol.  All of this combines to provide logging of firewall events that displays non-web traffic destined to the Internet.

In addition to protecting users with the Netskope client, we are able to provide protection using GRE or IPSec tunnels which are typically used with offices steering all traffic to Netskope.

Recommendations

Pre-Steering

Before steering all traffic for users, there are two recommendations we have, a destination network location bypass and allowing all non-web traffic. These recommendations are needed to minimize the impact on users when deploying CFW.

The first recommendation is to create a destination network location for Bogon IP Address Ranges and use this network location for bypassing connections to the Bogon IP Address Ranges.  A list of the Bogon addresses may be found at https://ipinfo.io/bogon.

NOTE:  The one exception to the Bogon traffic is 0.0.0.0/8 known as " 'This' network".  The reason to not add this network is due to how the Netskope client behaves on different OSes and using or writing to the 0.0.0.0 subnet.

The second recommendation is to allow all non-web traffic, see below. Doing so will allow users to continue to operate business as usual when deploying CFW, i.e. developers accessing remote tools over SSH in an AWS environment or accessing remote NTP servers.

Allowing all non-web traffic is performed in the Real-time Policies section at the bottom of the policies section.

Allowing all non-web traffic gives administrators the ability to monitor traffic and subsequently define real-time protection policies which we’ll cover later in this article.

Steering

After those two recommendations are in place, it is now time to steer all traffic. Steering all traffic, non-web and web traffic, is fairly straightforward and a matter of a few clicks of a mouse and keystrokes, as displayed in editing a steering configuration below.

Next Steps

What happens next is a matter of what you truly want to see, how you want to see it, and so forth.  For example, we could monitor CFW as is and not worry about segregation of all traffic based on user group or a predefined CFW app using all IP addresses and ports for TCP or UDP, aka discovery.

For the time being, we are going to allow traffic to flow to the tenant and on to its destination.

Monitoring

Real-time policies for CFW may have already been on the roadmap prior to its implementation.  If that is not the case then monitoring connections to non-web traffic would be a good place to start prior to CFW real-time policies creation.

We are able to monitor client traffic of all types using client logs, SkopeIT Network Events, and Advanced Analytics. While it is not readily apparent to use client logs to monitor connections, we do in fact use them when tuning policies and troubleshooting.

There are a few different mindsets when it comes to monitoring traffic;

• Allow all traffic to pass without any additional configuration;


• Create CFW applications for known destinations; and,


• Create CFW real-time policies for specific groups.

Allowing all traffic to pass without any additional configuration would be likened to the shotgun approach to monitoring where everything is sent without regard to source or destination.  In the example below, the “unknown” application is default non-web traffic being seen where an application is not defined in steering.

When we define CFW applications for known destinations and place them in steering, we will see those names defined in SkopeIT Network Events, as seen above.

A sampling of defined applications may be seen below and expect to see those appear in SkopeIT Network Events as users connect with those destinations.

We can even use the client logs to review communications from the client to remote destinations by examining the nsdebuglog files.

A more advanced approach to CFW monitoring is to use Advanced Analytics to report on client traffic using the “Cloud Firewall Discovery” predefined report.

Practical Advice

CFW policies have been difficult to define and implement using traditional firewall policy development methods. With security technologies blurring the lines between CASB, Web, and threat protection, it is no wonder that traditional firewall policy development methods fall short.  We are no longer constrained by location-based policies as traditional firewalls have relied on so much in the past. How we protect end-users relies on identity-based policies which allow for the freedom to move between the house, a coffee shop, and even an impromptu road trip to visit family. The perimeter is constantly changing, aka a moving target.

In an effort to conduct business and protect assets, businesses are constantly leveraging new products and services either in the cloud or hosted in remote data centers. This adds to the challenges we face when defining cloud firewall policies which also need to account for tight integrations of identity and access, CASB, Web, threat, VOIP, and so on. A change that seems minor might cause a business outage. 

Our Advanced Analytics Cloud Firewall Discovery report helps security teams see where traffic from a user’s machine is destined and ultimately make decisions on what non-web traffic to allow and what to block. After a policy has been defined, it provides a single pane of glass for viewing the effects of a policy change, a tool to educate, and, ultimately, a reporting tool for further policy definition. 

Out of the box without adding policies to it, administrators will be able to monitor traffic to make their initial policies definitions. This discovery mode gives us the opportunity to truly see where or what a user's machine is going without relying on older technologies such as JFLOW, SFLOW, or NetFLOW. We could even take this discovery a step further and create a policy centered around users or a group to see where they are going and ultimately craft policies based on user or machine “behaviors”.

Use Cases

Creating Custom Applications

By using the Advanced Analytics Cloud Firewall Discovery report, we are able to “hunt” for known services and common destinations. Once found and confirmed, we are able to create CFW applications for added visibility.

In the example below, we have previously located Google DNS traffic and NTP queries. Then we created custom applications to reflect these findings. The net results are that these applications now are readily identifiable within the Cloud Firewall Discovery report.

Blocking Unsanctioned DNS Connections

With Google DNS being the only “sanctioned” DNS provider, we can stop end-user machines from accessing other DNS providers. This is accomplished by using the custom application created earlier, creating a new general DNS CFW app using UDP port 53, and then applying them to a real-time policy to prevent access to other DNS providers.

We’ll then be able to see these blocks in SkopeIT and use CFW discovery to look at them from a 10,000’ view.

Block Malicious IP Addresses

Within any organization there comes a time to block access to a malicious IP address or IP address range. Malicious activity might be pulled from a multitude of sources, internal or external. For example, the MalwareHunterTeam (@malwrhunterteam) / Twitter reports on malware from a number of sources.

As with any feed, regardless of the source, it is important to perform due diligence and determine its authenticity, in particular the destination IP address or IP ranges.

For example, the Malware Hunter Team reported malware from a source of 45.95.1.34; and, by performing due diligence, we should check this against an IP reputation service such as IPQualityScore.

The IP Quality Score reported back indicates that the IP address has a high percentage of being malicious. https://www.ipqualityscore.com/free-ip-lookup-proxy-vpn-test/lookup/45.95.11.34

Based on the combined information, it would be prudent to block access to this IP address by defining a CFW application and using it within a real-time protection policy.

Conclusion

CFW is useful for monitoring traffic destined to the Internet. Whether it is for common applications using standard ports such as SSH (TCP/UDP 22) or NTP(UDP 123), blocking connections to destinations using custom ports such as malicious activities over TCP port 88, in the example listed above, and defining and monitoring custom applications.