Inconsistent behavior in SmartConsole | Not showing last matched rule number & name in logs

[B_P]

-- Edit --

As noted by @Paul_Warnagiris [ here ], there is now (at least) a workaround. 🤮

-- Original --

It would be nice if could set the log view to show the last matching rule number and name all the time. For some reason there's a difference for allowed and blocked traffic. If allowed, it will show the first matching rule in the logs view, if blocked, it shows the last matching rule.

This became very annoying after implementing layered policies, specifically for Geo IP filtering as discussed here. Now, the "Access Rule Number" and "Access Rule Name" column in the logs shows "Geo IP" for all Allowed traffic and the block rule number & name for all blocked traffic.

This makes the two columns in the log view practically worthless, so I'm a little suspect that there's already a fix out there, but I'm not finding anything.

Example:

What's stranger yet, is it does the exact opposite for Drops which is even inconsistent with the above and is the correct way it should display.

It is also this way in Web SmartConsole.

[Tomer_Noy]

Thanks for this feedback.

We'll try to look internally to better understand why there is a difference in behavior.

BTW, do you think that it makes sense for all customers and all cases to always show the last matching rule? (assuming that this remains a "single value" field)

[B_P]

Yes, it makes sense for all customers and all cases to show the last matching rule. I think any other way changes the purpose of the log view, which is to see why a packet was allowed or blocked.

[B_P]

5mo later.... The "Access Rule Number" and "Access Rule Name" are default columns in almost every log view and they're completely worthless. Why is this not fixed? Am I the only one that does GEO IP Protection in the recommended way?

Here's what I see:

[the_rock]

I dont see why you would say its worthless this way...I never have any issues showing the right rule, regardless if its ordered or inline layer. Unless Im not understanding something, it behaves exactly the way its designed. 

When you say it would be nice to show last matched rule, well, the rule thats hit is technically "last matched rule", isnt it? Because, in this case, or any case for that matter, implicit clean up rule will be last rule in network layer, so the only logical option is to hit rule that blocks specific countries.

Again, sorry if Im not connecting the dots here, but thats the way I look at it.

[B_P]

---

@the_rock wrote:

the rule thats hit is technically "last matched rule", isnt it?"

---

💯! So why is it showing the first matched rule? Going off the original post, I should see "17.45.23" for the "Access Rule Number" and "Group A Service" for the "Access Rule Name". Instead I'm seeing "6" and "Geo IP Cleanup".

My guess as to the reason you're not seeing it, is because you don't have multiple access control policies like you would if you did GEO IP in the new / recommended way.

[the_rock]

Ok, maybe we are using different wording here :-). Regardless...just so theres no confusion, can you send screenshots of those rules you are referring to? That would clear some things.

[B_P]

Well, it looks like this in SmartConsole:

Access Control

 - Policy

  - Geo IP

     - Rule: 6 | "Geo IP Cleanup" | Accept

  - General

     - Rule 17 | "GroupARules" | Inline

             - Rule 17.45 | "GroupAServices" | Inline

                - Rule 17.45.23 | "Group A Service" | Accept

[the_rock]

I would still like to see it, if possible (blur out any sensitive info), but to me, if it hits rule 6, then I cant see what else is there to be hit. So, if that geo rule is hit, then it will be first AND last matched rule. Anyway, sorry mate, not trying to be difficult, but thats the way I look at this. But, if you could attach what it looks like in your rulebase, it may prove me wrong. So far, just going based on what you wrote here.

The only possible way it would hit more than 1 rule if traffic is allowed is if you have multiple ORDERED layers. 

[B_P]

---

@the_rock wrote:

is if you have multiple ORDERED layers. 

---

You must not have clicked the link in the original post.

https://community.checkpoint.com/t5/Threat-Prevention/R81-Geo-policy-updatable-objects-with-exceptio...

Fist sentence says "use ordered layers". 😉

[the_rock]

Alright, I admit when Im wrong :). Anywho, regardless, I would STILL like to see what rules look like, that would help for sure. So, if you can attach a screenshot(s), would be awesome. I will say though, no idea if that post is indeed an official CP recommendation for geo policy, but I never do it like that. I always create geo rules way on top of network layer and it seems to work the best that way. I personally dont see sense in creating ordered layer just for geo block/allow, but again, thats just me.

[B_P]

---

@the_rock wrote:

I always create geo rules way on top of network layer

---

Sure, but there's severe limitations to that which don't work for us.

[the_rock]

Like what exactly? Please elaborate...

[B_P]

I think you can answer that with "Why did Check Point create ordered layers?"

[the_rock]

Sorry mate, but I strongly disagree there. I am pretty positive that reason why CP created ordered layers was NOT with geo stuff in mind : - )). Maybe someone from R&D will confirm or deny that. Either way, I cant really answer your inquiry any further, unless I see what those rules you mentioned look like.

Have an amazing weekend!!

[_Val_]

Can we please see a full example of one of those log entries?

[B_P]

Updated original post with example screenshot.

[B_P]

Just noticed that Drops display correctly and added another reference picture to the original post. That is very inconsistent behavior.

[B_P]

Still happening. I can't believe people just don't look at their rules. This tells me Check Point QA is not really testing much because they would immediately see something like this if they were. "Default Firewall view doesn't work properly with ordered layers" -- what's more obvious of an issue than that?

[Amir_Senn]

Hi,

This behavior is expected - when traffic is accepted - show first rule, when dropped show the rule it will match the drop on.

This behavior is not related only to inline layers but separate layers policy as well (which beside being in use today, was important for backwards compatibility). This might influenced the decision.

I can strengthen Rock's guess, unified layers was introduced during R80.10 and updateable object were introduced in R80.20 if I'm not mistaken.

I understand that this is not optimal for your needs and you rather have the last rule. I think SmartEvent works very well with this though, you might consider using it. The attached is part of a view I created with recorded traffic from my lab.

 

[the_rock]

Good to know thats expected, I was not aware, learnt something new today 🙂

Cheers,

Andy

[Tomer_Noy]

Thanks @Amir_Senn for the clear and accurate explanation!

Indeed there were challenges when adapting the log behavior that had a single rule match to the new paradigm where multiple matches are possible. 

In the last year or so, we see a significant rise in ordered layer usage. Both by customers trying to logically separate parts of their policy, and by our own products who leverage ordered layers to add additional enforcement capabilities (such as Playblocks and IoT). 

In case of a block action, I believe that it's the correct choice to put the rule that actually blocked the traffic. Since ordered layers are evaluated in order, that's the first matching rule that has a block action.
In case of an accept action, we understand the feedback that the first layer may not be the correct choice to use in the log. However, the last layer doesn't always make sense either.

@Meital_Natanson's team is looking into a slightly more "intelligent" mechanism for Accept logs. In this mechanism, Check Point's extra layers (Playblocks, IoT) will be skipped when choosing the rule to place in the log, so that we will choose the layer that matters more to the admin. In case you have your own ordered layer that you want to skip, you'll be able to mark it with a tag or prefix, and we'll take that into account as well.

We'll update the community once we have something available to try.

[Amir_Senn]

You might be able to manipulate this by using this as a separate layers policy instead of unified with inline layers. If the first layer would be Geo policy it would show it first.

[pal]

Many of our customers don't like this showing first accept rule number being Playblocks rule and not the actual network layer rule.

We would like to see the network layer rule number easily on main view, without having to open the individual log record.

[Paul_Warnagiris]

I will reiterate the word "worthless."  If this is expected design, then the it is terrible.  Everything in my logs on every gateway is now showing being accepted at rule #4.  This is the new automated remediation rule named "Allow traffic if allowed by Network layer and by Playblocks"  This effectively makes filtering by rule number useless.  You can't move the automated remediation or its not effective.  This is just pretty ugly no matter which way you cut it if you are working these logs on a daily basis.  YUK!  The only way to get what I'm looking for at this point is to click each rule and then click on "matched rule."  Four clicks per log entry when I used to be able to filter by rule number with one click.  I can't emphasize how bad this is.  Every one of my customers using playblocks is complaining about this.

[the_rock]

Respectfully, I would disagree that its terrible. To me, it makes total sense, specially if traffic is matched on multiple rules/layers.

Best,

Andy

[Paul_Warnagiris]

Do you ever use the rule number as a filter in SmartLog?

[the_rock]

Absolutely I do.

[Paul_Warnagiris]

Do you use playblocks?

[the_rock]

Used to, just as PoC, dont believe we have any customer using it atm.