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
41 Replies
Paul_Warnagiris
Advisor

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.

 
 

playblocks-example.jpg

0 Kudos
the_rock
Legend
Legend

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

0 Kudos
Paul_Warnagiris
Advisor

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.

0 Kudos
the_rock
Legend
Legend

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

Andy

0 Kudos
Paul_Warnagiris
Advisor

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

0 Kudos
Tomer_Noy
Employee
Employee

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.

0 Kudos
B_P
Advisor

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

0 Kudos
Paul_Warnagiris
Advisor

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

 

the_rock
Legend
Legend

so true 😂😂

0 Kudos
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.

the_rock
Legend
Legend

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

Best,

Andy

0 Kudos
PhoneBoy
Admin
Admin

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events