Application name is IP address

[Ian1]

We have some applications that get blocked in URL filtering and Application control by generic tags. Most often, the tag of Media Streams.

When I examine the log, it lists the application name as the IP address and nothing else. In this particular case, the URL is 

https://e94753aaf685411f8a9bcbcf7c6c4bbb.svc.dynamics.com/

And it lists the application as 52.158.128.189. I have tried specifying the above URL as a custom application and *.svc.dynamics.com and inspected the certificate and listing all the SANs in the certificate, but nothing seems to work.

The only way I have found to allow this application is to define one that is the IP address. This isn't ideal!

We are running a pair of Maestro SGMs with R80.30SP with the latest hotfix.

Is there a way we can define this with using the URL of *.svc.dynamics.com and make it work? We do not have HTTPS Inspection enabled.

[Albin]

When you have Categorize HTTPS sites on the URL-Filtering blade, you can run into this issue if the CA of the cert is not trusted.

So, either you need to update your trusted CA cert list (sk173629) and it will be able to categorize correctly, or you need to enable HTTPS inspection or install the cert manually in the trusted CA list. If this site is not signed by a generally trusted CA there is not much else you can do.

The categorize https sites does it by the CN in the cert so if we trusted that on a cert which is not signed by a legit CA, someone could impersonate any site, for example setting CN as google.com and signing it themselves.

[Ian1]

I have tried that and it still doesn't work. I have just noticed that if I try it and it goes out of our software Firewall on R80.40, then it works. But the Maestro pair of SGMs does not work. Looking at that cert, it its issued by Microsoft Azure TLS Issuing CA 01, which is issued by root CA DigiCert Global Root G2. The root CA is in the trusted list. I have seen some hosts that are issued by Microsoft Azure TLS Issuing CA 06 work correctly and this intermediate is issued by the same root CA DigiCert Global Root G2.

Is there a way to validate the trusted CA list on the actual SGMs?

[the_rock]

Not sure if there is an actual command to validate it, but, on the mgmt server, if you navigate to $CPDIR/database/TRUSTED_CA dir (then I think 3.3 or 2.0, may vary), there is zip file which is latest update on the management server that can be imported via legacy smart dashboard to CA list. Mine is November 2022, so thats probably last time it was updated. 

Do you get an option to update the list when you are in legacy https inspection dashboard?

[Ian1]

My zip file is from 8th August 2022, and is version 3.3. Is this the same version? I did transfer this from the mgmt server to my client and import it using Smartdashboard and it removed one entry and added none.

[the_rock]

Nope, I got latest one from November 2022. Disclaimer: Happy to send it over, but dont shoot the messenger if anything breaks 🙂

[Ian1]

Thanks. That would be useful. It does validate it on import and tell me what it is going to do, so should be safe.

[the_rock]

There ya go mate...GOOD LUCK 🤞

Andy

[the_rock]

Just verified and yes, its right file. I gave it to someone here recently and worked for them @Ian1 

https://community.checkpoint.com/t5/Cloud-Network-Security/Problem-with-URL-filtering-and-dev-azure-...

[Expert@QUANTUM-MANAGEMENT:0]# ls -lh
total 496K
-rw-rw-r-- 1 admin config 66 Nov 26 09:35 last_revision_DC.xml
-rw-rw-r-- 1 admin config 489K Nov 26 09:35 updateFile.zip
[Expert@QUANTUM-MANAGEMENT:0]# pwd
/opt/CPshrd-R81.20/database/downloads/TRUSTED_CA/2.0/3.3
[Expert@QUANTUM-MANAGEMENT:0]# ^C
[Expert@QUANTUM-MANAGEMENT:0]#

So, I sure hope works for you 🙂

[Ian1]

Hi

Thanks for that. I downloaded it and imported it and it said you are already up to date. So, although your date is newer, it is the same version.

Do you have any other suggestions?

[the_rock]

What is the exact site you are trying to whitelist? I have perfectly working https inspection lab, but if you dont use that blade, it should be easier to fix.

Andy

[Ian1]

*.svc.dynamics.com. We don't use HTTPS Inspection but have enabled "Categorize HTTPS websites".

[the_rock]

So that option being enabled simply ensures that mechanism does SNI verification, so clients can see correct SSL cert of the site they are accessing. Having said that, it 100% does NOT replace https inspection and to be brutally honest with you, even if you had it off, Im fairly positive it would not make any difference.

Now...here is what I always do if you wish to bypass site like that. Create custom application/site in dashboard and make sure to place *scv.dynamics* in the list, save and allow in the policy, install and test. If it still fails (which I dont see why it would), please send a log clearly showing where its failing, as to why its not being accepted.

Andy

[Ian1]

Hi

Thanks for that suggestion, but it has the same result.

The left hand image is the reject from the hardware SGMs. The one on the right is the software SGM, which works.
This would suggest to me that the way it is defined is OK, but it is an issue with the Maestro SGMs. Maybe a issue to raise a support ticket? 

[the_rock]

It would categorize differently considering one is IP and other one is fqdn. The only other thing I would do is confirm whatever category shows in the log is allowed in the rule. If it does and still fails, yes, I would contact TAC, for sure.

[PhoneBoy]

We added Verified SNI support in R80.30 (Maintrain) and backported it to R80.20 via JHF.
I do not know if this code is in R80.30SP or not.
However, the behavior you've described suggests it's not there.

In which case, your only option is to upgrade your Maestro gateways to a newer release.

[Ian1]

Thanks.. that's what I was afraid of! 

Do I upgrade the Orchestrator first and then the SGMs? (Obviously Management server before either). Any documents you would suggest for this process? 

[PhoneBoy]

R80.30SP is End of Support, so you definitely should upgrade 🙂
We have a guide that specifically addresses upgrading Maestro environments: https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_Maestro_AdminGuide/Topics-Ma...
To answer your specific question, the Orchestrator is upgraded first.