We'd love to hear about it! Click here to go to the product suggestion community
On v17 and v18, micro-app scanning is still disabled in my case.
I tried to enabled it but Skype stops working (although an Application Filter allowing it is enabled and attached to the firewall rule I am using to surf). CA is imported and decrypt and scan is enabled.
Is still a feature that is there and we are not able to use?
Waiting from feedbacks from other community users.
microapp detection works just fine and has since 16.5 MR4. It worked before then as well, but differently.
The CLI option 'system application_classification microapp-discovery' is used by Sales Engineers for Proof of Concept demos.
There used to be a published KB about this but it looks like it was pulled because the it was old.
Here is part of it:
In reply to Michael Dunn:
In several installation, micro-app scanning does not work. At home, for example, Skype stops working. Skype is allowed on the Application filter.
If this is the case, I will move the thread to XG v17 section and change the title.
Please reply there. Thanks
In reply to lferrara:
More info on the setup:
So basically you will try to intercept and scan Skype, which is not possible as far as i know? You would need a HTTPs Exception.
In reply to LuCar Toni:
the web exception is already there since v17 I guess.
Anyway, some common applications should work without web exceptions. I spent time to create the exceptions, investigate the url and so on. Now file download and skype calls do not work. I remember another user had the same issue in another thread but no solution was provided.
Test yourself and if you need, I can share my xg box (it is not the first time. On v18, I found already 5 bugs)
In XG, any policy that is Allow does not actually allow. It just means don't block at this stage.
You have an App Control policy that is Allow Skype. Which really means don't block Skype due to app control. Which actually does nothing, unless your "Allow Skype" policy also does blocking.
So for example if you have a Web Policy that blocks skype.com and a App Control Policy that allows skype, then Skype is blocked. Having an App Control policy does not override any other reason for blocking.
"microapp" is just a term for applications that are identified via their URL in HTTPS by the web proxy, rather than applications that are identified by snort signatures. Or to rephrase, if you have URL path of a decrypted HTTPS session that defines the application, it is a microapp. If an entire domain is associated with an application, that is snort. If you have an exception that applies that either skips HTTPS decryption or skips Policy checks that will effectively turn off microapp detection - because microapps are detected from HTTPS decrypted URL paths. The applications may still be detected via snort.
Let me give you an example. https://maps.google.com is the application Google Maps because of a snort detection (snort can see the unencrypted domain in SNI). https://www.google.com/maps is a the application Google Maps because of a microapp detection (snort cannot see the encrypted URI in the request). Because www.google.com has many paths, some of which are Google Maps and some of which are not, the detection must be done on the path, and it must be done with HTTPS decryption. Turn off HTTPS decryption and the proxy only sees www.google.com.
A quick check suggested that all application Skype detections are via snort, there are no microapp detections for Skype.
So, I don't think that your App Control Policy or microapps are involved at all. I would start fresh with this problem report. In both v17 and v18:
1) Skype does not work. Please describe what exactly does not work. eg Cannot log in, cannot place call, can place call but no audio, etc.2) You have a web exception for HTTPS scanning containing a custom category, which contains a lot of skype domain names. Does enabling or disabling this web exception make any difference?
Then please let us know logs, error messages, pcap, etc.
There is no way to improve “application detection “ in any way? All the time we need to “loose” time to investigate from logs (when we are lucky from log viewer) and put the links in web exception list. Since you have the signature you could manage a well-known web exception list that is automatically updated using patterns. The best way could be to manage this process automatically somehow. I am having problems with teams too. The only way is to investigate on Microsoft website and find the right ports.
If i turn off the web exception, I am not even able to see the status of the contact. For their point of view, I am offline.
Enabling micro-app scanning and keeping the web exception on, I am in the same situation. I am offline.
The main problem still remain logging.
I will provide you the pcap.
I guess the only way to improve Application detection is SAC (Synchronized Application Control) with the Endpoint.
Like the whats new document show: Improved Synchronized Application Control Verdict In the event of a pattern-based match conflict, Synchronized Application Control Verdict will be adhered to for more accurate application control.
It will likely be more precise and accurate to verify the correct application. So to call you could easily manage to except a application based on SAC instead on IPS.
You are not using SAC in your Setup (because Home appliance)?
LuCar Toni not all users go for Synch security.
You have the applications patters and you also created KB on which url to add in the web exception. So, you know the url and the destination IP to add in the exceptions.
If the only way to detect and avoid that Skype, Teams and other https application is to manually create web exceptions, I do not understand why we have application filter for.
Please find a way to investigate and improve the technology.
Could you please replace "you" with "Sophos". Because basically i am just another user, using Sophos Technology and helping / explaining certain things here.
You need Exceptions for this.
Application Control is to block / allow traffic.
You are comparing HTTPs Scanning with Blocking, which is not the same. Skype and other applications are not working, not because you are blocking them via App Control, instead because they do not like the concept of HTTPs Scanning.
If you configure a Proxy (HTTP based) and block Google.com, you will still be able to open Google, because you do not decrypt the traffic.
If you configure a Proxy (HTTPs Based) and block Google.com, you will not be able to open Google, but you have to deal with the consequences of intercepting the Traffic.
If you have a Application, which is not able/willing to use a HTTPs Proxy, you will have to use the Exception. Ether by the Proxy as a Exception or by the new DPI Engine.
Both ways needs to be configured by a Administrator.
Sophos is going this way with the management of "Managed TLS exception Lists" in V18. But as you can see, the list is quite full and not all applications are now working. Still work to do but its like a never ending game. If some vendor is changing anything, you will to have import new URLs etc.
There for SAC would be the perfect solution because the Endpoint application most likely do not change.
I am saying that technically you can try to find a different way to avoid users to create manual exceptions.
For home users, you could try to extend the SAC for Home users maybe by paying a "short" license. If you do this, you can collect a lot of logs from people using it at home. SAC is used and a nice products (nothing against this) but the number of companies using it still restricted compared to the number of possible "home" users.
More installation, more feedback, better product!
today I found the time to test Skype. Via API, I imported this exception list:
Skype with micro-app scanning disabled work as expected exept for file downloading. If someone sends me a file, download still fails.
I have the pcap file. Let me know from Sophos who would investigate what is missing.