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.

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