Hello,
The firewall will only record the traffic log with the destination IP as the Netskope gateway IP and the source IP as the machine IP.
The traffic log will display App-ID "SSL or Web-browsing" if there is no SSL decryption policy (on FW). Reason: The firewall's inability to see L7 signatures in order to compare them to custom or pre-defined APP-ID signatures.
With SSL decryption enabled we can see the specific App-ID such as -facebook, -box, -dropbox, -Microsoft.
Hi @MetgatzNK , Hope you had a wonderful holidays. Just wanted to checkin if @Zulkifal answer to your questions was helpful. Please feel free to mark his comment as a "Accept as Solutions" 😊
Hello @Zulkifal , good afternoon.
-According to what I have been told, at least in the official Netskope courses, please confirm, that it is not possible or on the contrary if it is possible, to apply SSL-Decrypt in the firewall, example, Palo Alto, when the traffic goes to the Internet and then the Decrypt that makes Netskope in Cloud, please confirm, is it possible to have anyway SSL/Decrypt in the perimeter ? that does not affect the operation of Netskope and the flow in Cloud, in the Tenant of Netskope ?
-Another thing, of course I understand the decrypt and the much more accurate annealing of the applications, but my post, my question is focused exactly to the flow, of endpoint/client netskope installed, when the traffic of that machine, of this workstation, has the netskope client and goes for example to facebook, gmail, twitter, box, dropbox, onedrive, etc, etc,etc. . .. what is expected that I should see in the perimeter firewall, like a Cisco ASA, a Fortigate, a Palo Alto, in the logs, of source IP workflows, the workstation(s) with Netskope, the basic expected flow is:
- Source IP, the workstation with Netskope Client.
-Destination IP/Destination FQDN, Netskope (according to the assigned Tenant).
-Port 443/TCP
-APP SSL.
Is a basic flow similar to the one shown above, that I should see on the perimeter devices ? or the destination, i.e. the destination FQDN and/or IP, is not altered ? will I still see the original destinations ( facebook, gmail, twitter, box, dropbox, onedrive, etc ...) ? or will I see the traffic all with Netskope destination ?
Thanks for your time
Best regards
It depends on how Netskope is deployed, I would consult with one of our architects on best practices for the business security need, Netskope provides a variety of options to deploy the service to complement existing security investments including firewalls including tunneling directly from a firewall, client or no client… guest users, contractors, are of interest to most customers of Netskope. Depending on the traffic that the customer is attempting to secure, it may make sense to send it to Netskope for the additional scrutiny that we can provide. Once an application is allowed, our deeper inspection of the embedded content becomes a critical control: the identity (who logged into the app), the activities the user is performing, is it in paid company version (instance) of the app, is the data malicious (download) is the data toxic to the business (infiltration of PII or Intellectual data), etc. With many of the vendors you mention Netskope has integrations to increase their visibility with what we uncover: keeping track of malicious files (including SSL encrypted and web-embedded content) for other vendors threat intel and sandboxes to inspect to increase the defense-in-depth IE: Palo Alto WildFire, Checkpoint Sandblast, etc. I'm happy to assist you if you would like to reach out to me personally, I have assisted in deploying all of the same vendors in prior roles, as well as overlayed them with Netskope.
Hello @javery , very good evening.
Thank you for your comments, for your time and for all your details delivered, will be all absolutely considered.
Hello, very good evening.
Thank you for your comments, for your time and for all your details delivered, will be all absolutely considered.
Well thinking about the Post, and all the detail indicated, my question and your approach is the detail of how I will see the sessions on a perimeter firewall and / or edge equipment.
In the example condition:
Endpoint ( Client Netskope Steering/Steer traffic to Netskope Secure Web Gateway ) IP-LAN: 10.10.10.100.100/24 -----Firewall LAN 10.10.10.254--Firewall-WAN-IP:200.200.200.200.100/28---------Internet ( Web-Cloud services,Saas, static pages, non-static, etc etc etc )
-Endpoint-Laptop/Desktop with "Netskope Client Installed" ( Explicit Proxy, No GRE-IPSEC tunnels, just the Netskope client forwarding the traffic ).
-Internet traffic from sites such as facebook, dropbox, box, google.com, netflix, onedrive, sharepoint, slack, twitter, etc.
-Perimeter Router/Firewall ( Palo Alto Network, FTD, Fortinet, etc ,etc ) which like many networks, has a perimeter firewall that limits traffic going in and out to the Internet.
-Traffic that is being forwarded by the Netskope client to Netskope SWG (Steering/Steer traffic from the client to the Internet/Cloud Next Gen Secure Web Gateway Netskope SWG).
Focused on this case, my question is simply to know, that traffic, thinking that this client/endpoint forwards its traffic ( Steering/Steer, No explicit Proxy, no GRP/IPSEC tunnels, full client Netskope Steering/Steer ) using the Netskope Client goes through a traditional Firewall on say an old traditional standard "perimeter".
Focused on all the detail shared, I just want to know, how is it that at the Log/Flow level, sessions, I will see that Netskope traffic, when it passes through the Firewall and goes to the Internet.
Example of flow that I want to confirm, that is to say to know what I expect to see in the logs/flows/sessions:
-Source IP, the workstation with Netskope Client (Steer-Steering SWG Netskope).
-Destination IP/Destination FQDN, Netskope (according to the assigned Tenant).
-Port 443/80
-Protocol: TCP
-APP SSL/Web Browser/http/https
In destinationIP/Destination FQDN ( I expect to see as destination, as the traffic is encapsulated by the Netskope Client, I expect to see as destination is the FQDN of the Tenant/SWG of Netskope, to where the traffic is forwarded or I should expect to see the original destination, IP/FQDN, that I am trying to access the endpoint).
Thank you for your time and cooperation.
Best regards
Netskope Client in the mode you described (Web-direct, treating the local network as untrusted/no tunnel offload/no termination by the edge device, you may want to revisit this architecture IE Prisma Integration and many others we support) will request the operating system to encapsulate all outbound traffic (excluding RFC1918 and/or other entries as part of client steering exceptions) on ports 80/443 into a (D)TLS 1.3 (TCP or UDP) tunnel (DTLS is recommended usually) on port 443 to the closest NewEdge datacenter IPs (as you will see as many destinations in the log) which ultimately map to the FQDN: gateway-"tenantname".goskope.com as well as gateway-backup-"tenant name".goskope.com for backup, you can leverage the bottom link below with your support account to get the latest consolidated range of all the potential Cloud ip addresses that map to the gateway FQDNs and one or many of those will populate in a traditional log entry.
From a life of the packet perspective natural (D)TLS and HTTP/S session re-use by the operating system will consolidate those various web connections when appropriate into the same session(s) to reduce setup time. DTLS uses UDP to further reduce the overhead associated with TCP, so you will see significant outbound UDP on the edge device log. From the point that the traffic hits the NewEdge, Netskope will collect the log entries (enriched with our intelligence) of the actual traffic being sent which can then be collected by the customer just like a traditional edge log using our Cloud Exchange via Log Shipper Module or as a stream of raw data if preferred.
Additionally per this article other FQDNs will be accessed by the clients for other aspects of operation that are not related to user traffic. Netskope Client Network Configuration
If you have multiple edge devices (SD-WAN, Router, Firewall) then you will need to deploy all of these outbound IPs in an outbound firewall rule or as a business (intent) policy (SDwan) with the destination/zone as internet or optimized backhaul at every egress point. Be cognizant that some or all Firewall/Router vendors you may run into do in fact have a limit on the number of IP address they can cache via FQDN lookup, so it is appropriate to leverage an IP-based rule to prevent accident DOS by the edge device.
https://support.netskope.com/s/article/NewEdge-Consolidated-List-of-IP-Range-for-Allowlisting
Hello @javery , good afternoon, thank you very much for your prompt response.
It is already clear to me what I will see in the logs of the perimeter firewalls, of the users from the LAN networks, who have the Netskope client installed, thank you.
Now as one last question, regarding what another colleague mentioned in the history of this Post, it is feasible to perform SSL Decrypt in the perimeter firewall, when the Netskope Client is installed, in the endpoints (same scheme/architecture mentioned above and detailed in this post), of the network(s) that go through the perimeter firewall to go out to the Internet? Or is it not feasible to implement SSL Decrypt in this type of environment? Is it not compatible for correct operation to do SSL Decrypt in the firewall? If the firewall in question already has SSL Decrypt enabled for "ALL traffic" going through the perimeter firewall, an SSL Decrypt exception should be added for traffic going to Netskope FQDNs ( FQDN: gateway-"tenantname". goskope.com ) ?
Thank you, I am attentive to your comments
Best regards
Not possible or recommended (and why i mention using standards-based VPN termination options). The best analogy is to think of the client tunnel as a private airplane (with a verify-all traffic methodology) to the internet where security/identity/network optimization is built-in for the best possible experience versus a public airplane where any edge device hands off the packet to the public internet provider which then has to traverse the same public internet with everyone else.
Speaking from experience most protocol decoders from any vendor would not be able to parse this type of multiplexing of traffic anyway, they are looking for individual streams, it would be similar to try to do SSL decryption on a client-based SSL-VPN from any of the same vendors by a MITM of thier own solution.
As for the second question, it would be recommended to bypass SSL for Netskope domains and ip addresses for client-based traffic. I have seen more creative ways of routing and/or using sdwan lately to largely avoid firewall inspection of this traffic anyway due to performance penalties of firewall inspection (latency) in general.
Hello @javery , thank you very much for your time and for your collaboration.
I get the point, now you mention it's not possible or not recommended.
Thinking of a use case, or well, a particular situation, where, for example, the end customer cannot, due to internal issues, compliance, guidelines, visibility, reporting, tracking, etc., disable SSL Decrypt in their perimeter firewalls, is there a problem with run that let's say, double decrypt ? Since I understand that the client traffic, from the Netskope client, goes in an SSL tunnel using TLS (TCP) or DTLS (UDP) and when it reaches Netskope, the Decrypt is produced for a deep inspection, thinking about this flow, where would it be? exactly the problem? and/or the impediment that the Perimeter Firewall applies SSL Decrypty and then re-encrypts the traffic, the packet and reaches Netskope and redoes the process, what would be the technical impossibility to put it in a way to do that? In an environment that for ABC reasons requires it and/or the client needs that double decrypt both in the firewall and later in Netskope?
Netskope Client-------Tunnel-Netskope-TLS/DTLS( Inside tunnel to Netskope Destination,the packet contains Destinations example FQDN:BOX,Dropbox,Onedrive ) ------ Firewall with SSL Decrypt -------Inspect Packet-- ----The perimeter firewall re-encrypts the packet/session--------The session packet arrives at Netskope and performs, as usual and normal, its inspection operation and applies the security policies.
Is there a technical and more in-depth reason why this is not technically feasible?
I really appreciate and appreciate that you take the time to make these clarifications.
Thank you, I am attentive to your comments
Best regards
I don't have much more detail other than what I mentioned. We have a privacy office that would be more than willing to discuss directly with your customer about any concerns they may have about our security program and/or 3rd party risk and concerns around trust of our infrastructure. This more of a business discussion than technical. I sent you a note privately.
