How to handle possibly false positive in application control?

[Ilmo_Anttonen]

A customer user has problems downloading files from Basecamp, which is a file-sharing application. We have an excplicit allow for this application in the policy but generally don't allow file sharing, as you can see in the policy snippet. When the user tries to download a file from Basecamp they can't. The drop log seems to point to Google Cloud Platform. I myself don't have an account at this basecamp site but when I go to the URL i face an Google-log in prompt. Seems Google is used as authenticating part here. Could this be the reason for the miss-classification?

Not sure how to solve this, without activating the disabled rule below, which allows downloads from Google Cloud Platform. The customer doesn't use Identity Awareness because of issues with AD. So allowing only this one user downloads from all google cloud is not possible either. Should I report this as an error in CheckPoint interpretation or am I getting it wrong?

[Daniel_Taney]

I face these kinds of issues frequently with App Control. It gets trickier and trickier to keep things locked down when sites like Google and Facebook use their authentication solutions to authenticate other 3rd party sites. You could try opening a ticket with TAC, but my hunch is that it is seeing the Google Login integration as "Google Cloud Platform". 

I've typically used Identity Awareness Roles as the means to get around these kinds of problems. I understand that won't work in your use case. You said its just one user? Would it be possible to give that user a Static IP or DHCP reservation and just create a separate rule for that IP to access Google Cloud Platform? Without IA, that is probably the quickest way to work around this without enabling Google Cloud access for everyone.

Hope this helps!

[Ilmo_Anttonen]

Ok! Thanks for confirming my suspicion. I thought about a static IP/reservation, but those actions are performed by another department (as always), so I just wanted to see what my options were before I request this lease. Of course there are drawbacks with this as well since the user would only be able to access the service when they are at the local office. No branch sites or VPN would work. But it's clearly better than nothing. I hope they can sort out the AD issues so that we can run IA in the future. Would simplify things a notch.

Many thanks for the input!

[G_W_Albrecht]

Just a hint: Identity Collector is a good tool when AD query takes to much ressources.

[Ilmo_Anttonen]

Thanks Günther! Wasn't aware of IC. I'll present this for the customer team.

[Danny]

Ilmo Anttonen wrote:

The customer doesn't use Identity Awareness because of issues with AD.

Well, AD is not the only identity source for Identity Awareness.

You have a set of options you can choose from. As it's just for one customer user you should be able to use Browser-based Auth or an Identity Agent, or.. you see?

[PhoneBoy]

A TAC case probably wouldn't hurt here.

Note that if you're not using HTTPS Inspection, some applications may be viewed as something you don't expect or something generic like Google.

This is because Google especially uses wildcard certificates for many of their services and, without seeing the exact URLs accessed, it's not always clear what is being accessed.

Yes, proper SNI support will help (and it's coming).

[JP_Rex]

Proper SNI support is still not there ☹️

[_Val_]

@PhoneBoy was referring to SNI enforcement available with R80.40 and up. 

@JP_Rex can you please elaborate on your "still not there" claim?

[JP_Rex]

If the Certificate of the requested server is not trusted by the FW, the SNI is not evaluated. So if a porn site uses a CA like "Let's Encrypt"  the FW will probably not block the HTTPS traffic, depending on when the key store was last updated. (example s e x.de)

[_Val_]

Is it a theory or a fact?

URL categorization will still work for that site. Also, in HTTPSi settings, you can turn on blocking sites with untrusted certs.

Either way, I believe your claim deserves a post in the community, instead of reviving 3 year old discussion.

[JP_Rex]

Sorry about the old Thread.
Yes I should start a new Thread about that. Which I was planing to do anyway. But when I read your statement I got carried away...

 
And i think it is fact since I got the TAC Case to prove it with the R&D reply that this behavior is by design. 

[_Val_]

No need to be sorry. I was about to say, it is by design, but still, several things:

1. You can add CAs at will, on top of those updatable by Check Point
2. You can decide to block all sites with untrusted CAs.

Also, categorization is not totally based on SNI, so there might be some other ways.

[JP_Rex]

Well it is the Design that gets me agitated ...
But we will discuss this in another (new) thread

[_Val_]

Please do 🙂

[PhoneBoy]

Actually it's available as far back as R80.20 with the appropriate JHF.