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

[B_P]

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.

[Paul_Warnagiris]

Now I understand why you are ok with it.  If you use playblocks every single rule is now accepted on rule 4 because playblocks is the first layer (although not the most relevant).  It makes filtering by rule numbers useless.

 

 

[the_rock]

Ok, thats a bit confusing. If playblocks is first layer and there are other ordered layers below, traffic has to be accepted on all layers.

Andy

[Paul_Warnagiris]

100%. Although when you’re looking at Smart Log the only access control rule number you see is the one from play blocks because it’s first. So if you actually want to find out what other rules that it was accepted  on you have to click four times per log (AND GO INTO EACH LOG) instead of filtering in one click. That’s to find the relevant log rule number. You can no longer filter by log rule number with play blocks enabled because the data is not relevant.

[the_rock]

Hm, I never recall having that issue in PoC. Do you have TAC case open for it?

Andy

[Paul_Warnagiris]

I don't have a TAC case open on this because from what I understand its "expected behavior."  Which I agree it's expected behavior.  Its just bad expected behavior.  It takes away search functionality and for Check Point who prides themselves in the least number of clicks, they took a step backwards here.  @PhoneBoy do you have any feedback?  Am I just not understanding something correctly?  I think I have it straight.

Thanks,
Paul

[Tomer_Noy]

Hi,

This is indeed expected behavior, and following feedback from the field, we acknowledge that it's problematic behavior for some customers.

As I wrote in a previous reply, we're working on a solution that will try to keep the rule value in the log with the data of the admin's main ordered layer, and also give some control over that.

In the meanwhile, a possible workaround is to move the Playblocks ordered layer to be last instead of first. Since the rule field in the log takes the first layer by default, it will keep your layer's rules in the logs, instead of Playblock's matching rules.

There are a couple of caveats to this solution:
1) You'll have partial visibility to what Playblocks is potentially blocking, as anything blocked in your policy won't reach evaluation in Playblocks' layer.
2) You won't get the performance benefits of an "early block" by Playblocks when it's preventing external scanners and other bulk attackers.

Still, it's a reasonable temporary solution if the issue in the log is a significant bother.

And as I stated above, hopefully we'll release a better permanent solution soon.

[B_P]

---

@Tomer_Noy wrote:

we acknowledge that it's problematic behavior for some customers.

---

Since it performs one way on blocks and a different way on allows, I would image the only customers that this is not problematic for are the ones not using it.

[Paul_Warnagiris]

Haha...I sort of agree with your comment 😂  Or people that don't pay attention to logs.

[the_rock]

so true 😂😂

[Tomer_Noy · Accepted solution]

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.

[andrepc]

Was there ever an update / fix to this , and from which jumbo was it implemented ?

[Paul_Warnagiris · Accepted solution]

Happy Days!  Happy Days!  There is finally a work around for this.  Its a little crazy if you ask me, but it works just fine so its not crazy.  R81.20 JHF79 or higher or R82.  From this admin guide right here.  https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_LoggingAndMonitoring_AdminGuide/CP.... 

To exclude logs generated by rules in a specific a layer from the SmartConsole Logs view:
1. In SmartConsole, From the left navigation panel, click Security Policies.
2. Go to Access Control > Policy, right-click the Policy Layer whose logs you want to
exclude and click Edit Policy.
3. In the window that opens, go to the applicable layer, right-click the drop-down menu, and
select Edit Layer.
4. Add a downward arrow ↓ to the layer's name. You can add the downward arrow in two
ways:
n Copy it from here: ↓
Or

Haha...copy a down arrow and put it in the layer name.  Bookmark this page.  I'm 100% sure this will come in handy.  Thank you to all that have worked on this.  You have no idea how much trouble it saves (not to mention clicks). 

[Tomer_Noy]

Indeed 😀

We also made it so that Check Point orchestrated layers (such as the ones for Playblocks and IoT) will get this behavior by default (without having to modify the layer name), so starting from that JHF the logs prioritize the rules in your layers instead of the Check Point ones.

[the_rock]

Ok, I think I fully understand it now. I see the points you are making.

Best,

Andy

[PhoneBoy]

It is expected behavior at present, and it sounds like from @Tomer_Noy's comments that is something we plan to address.