Check Point Application Control and URL filtering custom applications not behaving like expected

[RamGuy239]

Greetings,

We are facing some issues with the use of "custom applications" on a Check Point Maestro environment running MHO-140 orchestrators and CPAP-SG6500 appliances on GAiA R81.10. Currently running JHF Take 9 with plans to patch to Take 22.

Using a very simple test scenario we have isolated a single source IP and tried to have a rule using a custom application to allow for traffic towards *.vg.no. This is a unified policy, the rule is deployed directly in the network policy within an inline layer.

We get hits on the rule, but something is obviously acting awkward. When viewing the logs we can see that the traffic is matching multiple rules. It will match both the rule containing the custom application, but also the rule two places below it with is the normal surf rule that is not using application control.

If we try to add to similar rules. One allows the traffic using the customer application, and a rule below it drops the traffic. Both using the same custom application the traffic ends up being dropped, not accepted when through its two identical rules, the only difference being that rule 17.84 is accept, rule 17.85 is drop.

This surely can't be expected behaviour? The traffic is indeed TLS 1.3 and there is no TLS Inspection deployed. But "Categorize HTTPS websites" is enabled. The logs show SNI and hostname matching *.vg.no for the logs that are hitting the correct rule, but for the other logs, it's not showing any information for SNI nor hostname. The destination IP is the same for all the logs.

It feels like such a simple scenario for Application Control and URL filtering to handle so we have a hard time understanding why this is not working?

[Chris_Atkinson]

The destination subnet actually differs in the logs shown.

198.88.55.x

198.88.54.x

Are you able to expand one of the drop log cards please? (redacted where appropriate).

[RamGuy239]

Hi, @Chris_Atkinson 

Here you have two additional screenshots. It was a bit of a miscommunication on my part. The drop rule below it is not using the same custom application, it's using an FQDN Domain Object. But it's the same issue, there is no reason why the traffic shouldn't match the accept rule above it?

[Chris_Atkinson]

How do bond6.401 and bond6.2038 relate to one another from an interface/topology/routing perspective?

Would recommend TAC having a look at this with you live to expediate.

[the_rock]

Chris is right...maybe have TAC do live remote with you on the phone to check. It does not make lot of sense that multiple rules would match this traffic. If you have layered rules, and it hits parent rule, then it would either hit one of "child" rules in that layer or it would drop at the bottom explicit layer rule. If you dont have layered rules, then its even easier to "parse" actually.

[RamGuy239]

We had a remote session with Check Point TAC, kudos to TAC for being extremely efficient here even though I created the ticket as a low-priority case.

It all made sense from a technical standpoint. We know how to successfully create these kinds of rules, and it's something I should have been aware of myself considering the FW chains and their order.

With R80+ and the introduction of the unified policy, you are able to utilise applications directly in the ruleset. There is no longer a need for a separate ordered layer for application control. This makes it way more flexible, and from what I understand the unified policy is the recommended way of utilising application control on R80+ as with ordered layers all your rules have to first match the network policy, then match the application control policy. With a unified policy, you are supposed to just hit one rule and be done. It's more efficient. Being able to utilise applications directly in the network policy is also more flexible and will lower the complexity.

But it doesn't seem like the software on the gateways have been fully optimised to take a unified policy into consideration. And this is what was causing this to fail. You can't simply create a flat rule in a unified policy and utilise an application and expect it to work. The traffic still needs a regular firewall rule allowing for the traffic for application control to be able to kick in.

This made it really confusing. So when we have a regular firewall rule not utilising application control saying src: 192.168.1.10, dst: Internet, service: https, action: drop it doesn't matter if this rule is above or below the rule containing the application. FW blade comes before application control in the FW chain so even if you have it like this:

Rule 1:
src: 192.168.1.10, dst: Internet, application: vg.no (*.vg.no), action: accept

Rule 5000:
src: 192.168.1.10, dst: Internet, service: https, action: drop

Rule 1 won't work. Rule 1 is utilising application control, the initial traffic will hit an FW Blade rule first, and if there is no FW Blade rule allowing for the https to happen in the first place, your application control rule no matter where it is within the policy will never be taken into account.


This is obviously extremely confusing. And to be honest it feels like an oversight? With older versions where the unified policy was not a thing, this would never be a problem as traffic would never reach the application control policy as you would only move to the next ordered policy after getting accepted in the first policy. You would never have, or expect your application control rules to be taken into account unless you had an FW blade rule in your network policy allowing the traffic in the first place.

This same logic still applies in R81.10, even though with a unified policy enabled. Making it all really confusing as it doesn't really make much sense unless you know how the FW chains work. So you have to ensure that you have an FW blade allowing for the https traffic to work, only then will the application control rule be able to work. And to make this extra confusing the rule numbering doesn't matter, you can have FW blade rule allowing for https at rule number 5000, and your rule using an application at rule number 1. It doesn't matter, it will still get its https accepted in rule 5000, and then utilise rule 1 for application control even when all of this lives in the same network policy as a unified policy.

Knowing all this it obviously makes sense, and it also means that if you are going to utilise applications in a unified policy you should put it into an inline layer as that's the only way to ensure that it looks organised and structured. If you try to put this flat without inline layers it becomes a  real mess rather quickly considering knowing how FW blade rules will be taken into account before any rules using applications regardless of their rule number.

It's not all that bad as it makes sense to strive for using inline layers for these kinds of rules, to begin with, but the fact that you don't even get a policy verification error when using application controls flat in a unified policy when you have rules that will clearly not work is not great. This is something that should be added for a better user experience. When the logic behind the behaviour doesn't really make much sense for anyone not knowing the FW chain logic behind it all there should at least be some feedback within Smart Console telling users that they are trying to apply non-working application rules.

But to be honest this feels like an oversight more than anything else. When R80+ provides you with the capability of utilising applications within a unified policy there should be some logic making this work automatically. There should be some functionality here recognising the fact that the user has created a flat rule saying src: 192.168.1.10, dst: Internet, app: vg.no (*.vg.no) and automatically have the FW blade recognise this and make sure that http+https from 192.168.1.10 for this should be implicitly allowed. There is really no reason to expect otherwise. Why else would the user create such a rule in the first place? It just add additional complexity, steps and confusion. Especially considering the applications themselves tells the users that the application allows for services: web browsing and the settings for application control tells you that this entails http, https, http_proxy an https_proxy services.

[_Val_]

Wow, that is a long read 🙂

Long story short, we did explain it thoroughly in multiple sources when Unified Policy came to life. Here is just one of the examples. 

Long story short, to detect applications and/or to run content inspection, you need to open a session first and wait till some meaningful data starts flowing. 

But to accept the first SYN packet, you need an Accept rule that could match that traffic, before you can have data flow and re-match it to another rule. This is as expected. For better usability, instead of using a plain Access Policy with elements of both services and applications, it makes sense to use inline layers, or to separate access and application rulebases completely in a layered policy package. My personal choice would be inline layers.

EDIT NOTES: I have stroked out my apparently incorrect explanation of the root cause. After talking to R&D SMEs, the fact is, additional "looser" access rules are not required, if the application is defined properly. 

@Micky_Michaeli has identified the actual issue, and it is explained below. With that, I'll shut my trap 🙂

[RamGuy239]

Hi, @_Val_.

Thank you for your reply. I've been made aware of the SK and as I said, it all makes sense from a more technical standpoint now that I've been made aware of why it behaves like this.

I still have to say that it's not all that great from a user perspective. There should as a bare minimum be a policy verification kicking in telling users when they are creating rules that are in essence not going to work. From a user perspective, there is really no reason why they would expect a flat rule using an application to not work. As I've said, the unified policy allows for the user to create these kinds of rules, and the applications themselves within their details specifically tells the users that this application will be matched by application signature and a list of services.

It would be in everyone's best interest for there to at least be some feedback within Smart Console telling the users that this is not going to work, perhaps with some reference to the SK for application control and unified policy explaining it in more detail. Policy verification will fail if you have rules hiding other rules, this is more or less the same when you create rules containing applications that can't be utilised because you lack an FW blade rule allowing for the rule to be work in the first place.

Ideally, there would be some internal logic making sure that once users create a rule like this there is an implied rule allowing for whatever is needed for the application to work. There is really no reason to expect a user to create a rule containing an application and have the action set to allow and not have the services needed for said application to now automatically be allowed in the FW blade. If it behaved like this it wouldn't have this issue at all, and the user experience would be the best it could be as it all behaves logically from the user perspective.

Going the inline layer route is obviously the way to go here. But in my honest opinion, you are creating a scenario adding additional confusion and complexity for the user by having all of this behave this way. Having policy verification telling the users what is going on would be one way to make it an overall better user experience, but the best thing would have this logic solving itself by simply allowing the expected ports/services of the application to be utilised automatically.

[_Val_]

@RamGuy239 I appreciate your thought explanation.

Let me address your second point, before anything else. I do not believe that adding an accept rule for a Web application should also create an implied HTTP accept rule. That mean, your policy becomes a Swiss cheese, and not a Gruyere, but one with too many holes in it. That is the reason we did not go this route, unlike some other vendors. 

For policy verification though, I do agree that some additional logic might help. You can actually request an RFE to request this feature.

Also, let's try adding R&D to this discussion. @Tomer_Noy , can you ask your team to look at this thread and maybe provide some additional guidance?

[RamGuy239]

I just read through sk112249 - Best Practices - Application Control. It contains examples for R80.10 using unified policy and the screenshots is showing non-working examples?

We got referred to this SK for reference, but unless I'm completely mistaken this example is actually showing how we originally did this and is an example that would not work?

The only FW blade rule in the screenshot is rule 5, and it's src: any, dst: internet, service: any, action: drop. In this scenario rule, 1-4 would not be able to work as there is no FW Blade rule allowing the traffic to get past the FW blade so it would drop before hitting AppCtr?

My customer got utterly confused when reading the SK as it seems to reference the exact unified policy design that we need to avoid for the rules to work?

[_Val_]

The example shown in the SK is for Layered Application Control policy. It is obviously the 1 to 1 copy of older R77 policy to R8x. R77 did not have Unified policy capabilities, and the SK itself is not about Unified Policy, but exclusively about Application Control and URLF. I will ask SK owners to make this point mentioned explicitly, so you would not be confused anymore.

Thank you for your feedback. 

[RamGuy239]

Hmm, that might be. It's correct as you say that it does not mention unified policy, but the screenshot shown is using a unified policy as you can see from the pane to the left where it's adding the application's rules directly in the network policy. There is no ordered layer for application control shown.

[_Val_]

As I said, may be confused with Unified Policy, but it is not what on the screen. I have already asked a relevant team to fix. 

[RamGuy239]

I think it would also be wise to update the SK with information regarding how to apply AppCtr in a unified policy? It's the best practice - application control after all? Wouldn't it be the expected SK to obtain this information?

I've read:

sk120964 - Unified Policy
sk73220 - ATRG: Application Control
sk166732 - How to identify rule(s) conflict in R80.XX Rule Base

As well. And they are not making this very simple. sk112249 - Best Practices - Application Control, seems to be the most visual and easy to understand SK of them all. So having a section for using unified policy with images wouldn't be a bad idea.

[the_rock]

I will just share my feedback on this. I worked with customer for many months trying to make this work up to their liking and let me tell you, it was not easy. 

We worked with TAC for many hours trying to figure out, okay, should we use inline layer for this, should we use another ordered layer, what is the best approach to it. After spending so much time and realizing that customer did not wish to use ordered layer in policy, due to fact CP recommends blacklist approach for app control and not whitelist and they did not wish to do so, as they had issues with it from previous vendor, though it is recommended(https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_RN/Topics-RN/Whats-New.htm#:....)

We tried using inline layer as well, but since that gave so many issues too and conflicts, we just decided to actually create separate section towards the top of the rule base, with few rules in it and whitelist whatever everyone was allowed and use access roles to block whatever sites/categories needed to be blocked and we never had an issue since.

Is that the best approach? Once could argue maybe not, but not a single problem in more than a year. I can tell you that customers that come to Check Point from another vendor usually do NOT feel comfortable with approach of having allow rule at the bottom of every ordered layer (thats at least my experience). 

[anstelios]

Hello,

Can you please give some rule examples about what you did there?
So you have allow rules high in the rulebase, and how do you do the blocking of all other apps/URLs/categories ???

[Micky_Michaeli · Accepted solution]

Hi,

Custom application is matched against the URL. When I tried to access vg.no I saw additional sources tried to be loaded, such as vgc.no.

vgc.no can't be matched to vg.no, so it also should be part of the custom application (and it's just an example).

Probably the dropped traffic is indication to a missing content in the custom application.

When HTTPS Inspection is disabled and only "categorize HTTPS websites" is used, you need to include in your custom application every URL/domain that the site is trying to load as part of the page.  

You can find the missing sources using a specific rule (with your client IP for example) with extended logs and accessing to the site.

In addition, you don't need to open ports on a specific firewall layer for APPI/URLF to work properly. You can have only 1 unified layer and the matching will work as expected, meaning the upper rule going to be matched when all the information arrived. In case there are multiple ordered layers, then you need to be accepted on all layers in order the connection to be accepted. I used a pretty simple policy in my environment for testing this case. One layer with only two rules, so it can be very simple to define policy with APPI/URLF in one unified layer.

For more information on enforcement in ordered layers, you can refer to "Order of Rule Enforcement in Ordered Layers" in https://sc1.checkpoint.com/documents/R80.10/WebAdminGuides/EN/CP_R80.10_NexGenSecurityGateway_Guide/...

Another good source to understand the unified policy matching is this video: https://www.youtube.com/watch?v=c-FOqr6Gwj8

Thanks,

Micky

[anstelios]

Hello,

Can you please elaborate on what is actually the recommended way of configuring APP/URL Rules in R81.10?

We have a fresh R81.10 environment and we use Unified Policy (1 layer only) without inline layers.

So we have APP/URL rules on a specific section where we use Access Roles in source column and specific Apps/Categories/CustomApps in Services column and the action is Accept.
Of course we also have normal FW rules on other sections of this single layer where we use protocols in Services column.
The last rule is any-any-Drop (as usual in a FW policy) where we expect it to also match  all the Apps/URLs/Categories that are not allowed in above rules.
We don't use HTTPS inspection, just "Categorize HTTPS sties"

So is this configuration recommended or should we use other approach (inline layers/separate layer) ???

[_Val_]

We have Best Practices SK for Application Control: sk112249. It should answer all your questions. TL'DR: your approach is just fine, although for complex TLS-based apps you may want to consider HTTPSi.