PolicyLayer Odd Behavior

[Smorales]

Hello, everyone.

I would like to tell you about a very odd situation that happened to me with a client, and I would like to discuss it with you to see if you have any idea what might have happened. I have been reading the following documents, but I am still not clear on what might have happened:

R82 Quantum Security Management Administration Guide
R82 Best Practices for Access Control Rules
ATRG: Unified Policy

My client wanted to test how application control policies work and generated some rules, but here's something important: they did NOT enable the ApplicationControl Blade within the firewall, they only created the policy layer within the policy package as follows:

1. Network Layer: Firewall Blade
2. AppControl: Firewall and Application Control blades.

Reference: see image Policypakage.png

They left the rules on a Friday as follows (reference Appctrl1_policy.png) and nothing happened; only the Network layer flow was respected, and according to the logs, the flow did not reach the AppControl layer. Then on Monday, they wanted to install policies, but an error message appeared saying, “The app control policy will not work until you enable app control blade on the firewall.” So, to avoid seeing those messages, they disabled all the rules in the AppControl layer, including the cleanup rule, and that's where the tragedy happened.

The implicit cleanup rule of the app control layer acted in drop mode because it was left at drop by default, causing everything to be blocked. That's when they call us, and we acted first by setting the implicit rule to accept, and it started accepting everything.

Now, this part of the context is important. One of the clients, for reasons unknown to us, enabled the explicit cleanup rule in the app control layer, changing it from accept to drop. For some reason, this policy began to be enforced and blocked all connections again. The logs now read “dropped by cleanup rule” instead of “dropped by implicit cleanup rule” or “accepted by implicit cleanup rule.”

What confuses me is why these rules weren't applied before, and after those strange movements, it began to be considered and filtered with that cleanup rule.

In the end, what I did was remove the firewall blade from the application control layer and set both the explicit and implicit cleanup rules to accept. This is how the rules ended up (see Appctrl2_policy.png). The first two rules remained disabled from the incident until now, but that policy layer is no longer taken into account.

My question is why this happened. I read the admin guide I mentioned at the beginning of the post, but I don't know if I need to understand them better or if they don't say anything about this:

Has anyone else experienced something similar or know why this happened?

[Bob_Zimmerman · Accepted solution]

This all sounds normal to me. With layers arranged the way you show them in Policypackage.png, any drop is final, and all layers must accept a connection for the connection to be allowed. This is why the URL Filtering/Application Control rules should usually end in Any-Any-Any-Accept. When they built an explicit cleanup rule and set it to drop, they must have pushed the policy.

[Smorales]

Yes, traffic must be accepted in both policy layers for that to continue, I understand correctly, but if the cleanup rule was previously set to drop in the second layer according to the Policy Package image, why wasn't this policy applied at the beginning? Because it is enforced until it is disabled and re-enabled so that it starts blocking connections.

In my logic and according to what you mentioned, when the second layer was created and the cleanup rule was left in drop, it should have been blocking everything from the beginning, but this did not happen until you made changes such as disabling rules and changing from accept to drop.

I don't know if I'm explaining myself clearly.

[the_rock]

Here is somewhat basic example.

Lets pretend for a second you have client who did this:

-ordered layer (default network) with just fw blade enabled, any any drop at the bottom

-2nd ordred layer with some inline layers, any any allow at the bottom

-3rd layer, any any drop at the bottom, fw blade on

-4th layer, last one, any any drop 

in such case, NOTHING would work

Reason you may ask? Because traffic has to be ACCEPTED on EVERY ordered layer...so say you had 50 ordered layers, if traffic is accepted on 49 of them and dropped on 50th one, nothing would work.

Makes sense?

[the_rock]

I will send you link for a video I made about this recently. Just check it out, hopefully will make sense. Just doing cutover with a customer now, hopefully wont be too long.

[the_rock]

@Smorales 

Official guide.

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_SecurityManagement_AdminGuide/Topi...

[the_rock · Accepted solution]

See if this post I made helps.

https://community.checkpoint.com/t5/General-Topics/Lab-setup-video/m-p/268062

[the_rock]

What @Bob_Zimmerman said is 100% correct. Its more less shows the same in my post.

[the_rock · Accepted solution]

Hey @Smorales 

I carefully read once more all you wrote and what Bob wrote is totally logical. Think of it this way. When it comes to traffic being dropped, if its dropped on any given rule, there is no more matching. Say, for example, you have 5 ordered layers, all is accepted on 1st ordered layer, then its dropped on 2nd layer, either generic ordered layer or inline layer inside that ordered layer, there wont be any more matching, so other 3 layers wont be checked.

Now, for traffic to be accepted, it has to be accepted on all the layers (both ordered and inline ones). Im happy to do remote with you if you want and show you how I did this in my lab or if you check the video I posted in the other link, it would help as well.

Just to explain something further, so as Bob had said, for appc/urlf layer, point is to have any any allow at the bottom, because whatever has to be dropped, would be dropped on network layer.

For inline layers, this is the "mentality". Say you have inline layer, lets pretend parent rule says from internal zone, to any, service any, layer internal layer (or whatever name). Default rule shows as explicit any any drop (bottom of the layer), then you create rules ABOVE it to allow the traffic. Once traffic hits "parent" rule, then would check all the rules inside that layer, if it passes, great, goes on. If it fails, gets dropped, NO MORE checks.

I hope all that makes sense, but again, if its overwhelming and you would feel more comfortable to do remote, Im more than happy to do it. Im in Canada EST, so 5 hours behind GST.

[the_rock]

Hey @Smorales 

If you are still interested in doing remote session, Im happy to show you my lab where I can explain how all this works. I will see if I can find the actual document I made with lots of screenshots couple of years ago about this as well.

[Smorales]

Hello everyone.

I'm sorry for the very late response, I was too busy with other work things.

I had a meeting with the customer and here it is what happened vs what i thought about the incident:

What customer said to me on the incident:

Thursday:
1. created app control layer with Firewall and AppControl blades
2. cleanup on drop
3. Installed policy

Cleanup rule in drop in de app control layer with firewall blade and no incidents?
No sense to me.

Monday:
Changed cleanup rule from drop to accept
2. They disabled all rule on the layer
3. Implicit cleanup on drop take action
4. Changed implicit from drop to accept.
5. Someone enable cleanup and changed accept to drop
6. We changed cleanup from accept and drop.
7. Also disabled firewall blade from the layer.

What happened and after investigating audit and security logs and had another meeting with the customer:

Thursday:
created app control layer with Firewall and AppControl blades
2. cleanup on drop
3. No install policy

All weekend (Thursday to Sunday) they didn't install policy, that's why they didn't have an incident.

Monday:
1. Changed cleanup rule from drop to accept
2. They disabled all rule on the layer
3. Implicit cleanup on drop take action
4. Changed implicit from drop to accept.
5. Someone enable cleanup and changed accept to drop
6. We changed cleanup from accept and drop.
7. Also disabled firewall blade from the layer.

What didn't make sense to me was that at first they had created the second layer with the cleanup rule in drop and installed policies without any incidents, but in the end it turns out that they had never installed policies.

I hope that this explanation helps you understand a little more about the scenario I had in mind and my confusion.

This was more of a communication problem between the client and me.

However, I greatly appreciate your comments and advice, and even explaining it to me in a session.

Thank you, team.

[the_rock]

This all boils down to what we discussed already.

Just remember this...traffic has to be ACCEPTED on all ORDERED layers, otherwise, nothing will work.

Hypothetical example:

Say you had 100 ordered layers and 99 of them have any any drop at the end, but traffic flows as other rules above it allow that...well, if 100th layer also had any any drop, nothing would ever work.

Same sort of applied to inline layers, if traffic hits parent rule, goes to "child" rules underneath it, if it works, great, goes on, if its dropped, no more checks.

Again, Im happy to do remote and show you, though Im fairly confident my video demonstrates exactly what Im referring to.

[Smorales]

Hello the_rock,

Okay, I would like to have that remote session with you to better understand what you are explaining to me.

I understand that your time zone is GMT-5/Canada UST, I am in GMT-6 or CST, so you would be one hour ahead of me.

How can we agree on this?

Regards!

[the_rock]

No problem, happy to help! Just message me directly, we can connect that way.

[the_rock]

Hey mate,

Im happy to do remote when you are able to, just message me directly. I also sent you my info, so you can also contact me there.

[the_rock]

Here is another simple doc I have about it too.