Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
B_P
Advisor
Jump to solution

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

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:

CheckPoint Access Rule Name Example.png

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.

CheckPoint Last Rule Drop.png

It is also this way in Web SmartConsole.

0 Kudos
1 Solution

Accepted Solutions
Tomer_Noy
Employee
Employee

Glad to update that a fix / enhancement for this issue was developed and it's in the pipeline for the next Jumbo. I'll update when it's released.

The behavior will be to deprioritize the automatically added ordered layers (such as Playblocks and IoT) in the logs. If they are the ones responsible for the block, they will still appear in the log, but if they accepted, then you'll see the accept in your layer that comes after.

For customers using multiple ordered layers of their own, it will also be possible to add an indication to a layer of your own to be deprioritized in a similar way.

That way you will have control over which layer appears in accept logs.

View solution in original post

41 Replies
Tomer_Noy
Employee
Employee

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)

0 Kudos
B_P
Advisor

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.

0 Kudos
B_P
Advisor

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:

CheckPoint Access Rule Name.png

 

0 Kudos
the_rock
Legend
Legend

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.

0 Kudos
B_P
Advisor

@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.

0 Kudos
the_rock
Legend
Legend

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.

0 Kudos
B_P
Advisor

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

 

0 Kudos
the_rock
Legend
Legend

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. 

0 Kudos
B_P
Advisor

@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". 😉

0 Kudos
the_rock
Legend
Legend

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.

0 Kudos
B_P
Advisor

@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.

0 Kudos
the_rock
Legend
Legend

Like what exactly? Please elaborate...

0 Kudos
B_P
Advisor

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

0 Kudos
(1)
the_rock
Legend
Legend

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!!

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
B_P
Advisor

Updated original post with example screenshot.

0 Kudos
B_P
Advisor

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

0 Kudos
B_P
Advisor

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?

0 Kudos
Amir_Senn
Employee
Employee

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.

Capture2.PNG

Kind regards, Amir Senn
the_rock
Legend
Legend

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

Cheers,

Andy

0 Kudos
Tomer_Noy
Employee
Employee

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.

0 Kudos
Amir_Senn
Employee
Employee

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.

Kind regards, Amir Senn
0 Kudos
pal
Explorer

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

Logby_ARRule.jpg

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

0 Kudos
Paul_Warnagiris
Advisor

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.

0 Kudos
the_rock
Legend
Legend

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

Best,

Andy

0 Kudos
Paul_Warnagiris
Advisor

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

0 Kudos
the_rock
Legend
Legend

Absolutely I do.

0 Kudos
Paul_Warnagiris
Advisor

Do you use playblocks?

0 Kudos
the_rock
Legend
Legend

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Tue 23 Apr 2024 @ 08:00 AM (CDT)

    South US: HTTPS Inspection Best Practices

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Tue 23 Apr 2024 @ 08:00 AM (CDT)

    South US: HTTPS Inspection Best Practices

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events