Application and URL Filtering Logs NOT recording for some users

[SriNarasimha005]

Hi All

  Gaia R 80.10  is used in my organization and we see Application and URL filtering Logs doesn't seem to be capturing for some users.

 Affected Users getting Blocked Message/page but Logs are NOT recorded in smart log. Identity awareness is done by AD (LDAP).

 Kindly let me know for any data required .Please advise.

Thanks,

Sri

[Danny]

Best Practices - Application Control

Make sure you've installed the latest R80.10 Jumbo Hotfix of your installed release.

There is most likely a Block rule matching before the Allow rule you are referring to. Put a temporary Allow rule for the specific IA users on top of the App Control rulebase and check if it matches. Verify that all rules are set to Log. Verify that Categorize HTTPS is not an issue.

Debug Application Control.

[SriNarasimha005]

Hi ,

 Thanks for your reply. We're allowing the specified sites (White list)  then blocking the BLACKLISTED sites and followed by at the end is fail-open rule to Internet .

 The problem we face is for some users,Logs are not captured and for all rules is set to Track->Log.

  Is this happening of any Bug. Please advise.

[PhoneBoy]

With Application Control rules, it's better to use Detailed or Extended Log rather than just Log. 

Right-click on the Track field in the relevant rules and say More.

Choose Detailed or Extended logs as shown.

[Rob_Bush]

I am having the exact same problem.  We upgraded to R80.10 on the mgmt server with R77 gateways.  Everything was working just fine.  Then we upgrade the gateways to R80.10 and all the sudden our Application clean-up rule was blocking tons of web traffic that was not hitting the rules above it, even though with the R77 gateways it was working correctly.

I turned to the logs to find out what was going on and to my shock, the Application logging is drastically changed!  When I filter for the Application Control blade, I see traffic for it, the correct icon appears in the Blade column, I see application names BUT... the "Access Rule Number" and "Access Rule Name" are showing the firewall rules information, not the application rules policy.  So all the sudden, I no longer have visibility as to what in the world is going on!  I have noticed that if the Action is either "DROP" or "REDIRECT" that it all the sudden shows the Application rule number and name, not the firewall rule number and name.  However, if the action is just Accept (which 90% of the traffic is) it no longer shows the App rule/name but the Firewall rule/name.  This is so frustrating.

Per the recommendations on this thread, I made sure I'm running the latest Jumbo hotfix across my entire environment and I also changed all App logging to be "Extended Logging" but neither of these made any difference.  That data is clearly there (even prior to those two actions) because if I double click on a single entry, I can go to the "Matched Rules" tab and see both the firewall rule AND the App rule listed.  So clearly, this is an issue with the SmartLog viewer deciding to show the firewall rule/name in the view when the action is accept, but ONLY for R80.10 gateways.  I still have some R77 gateways and their logs still appear just fine in the SmartLog viewer.

HELP!  This is driving me nuts!  I lost my ability to easily filter and see what was going on with the Application Control blade!  Is this a bug or are things working (horribly) as designed?

[PhoneBoy]

I'm assuming since you are still using R77.x gateways that you are using ordered layers (e.g. an access layer and an App Control layer).

This means the relevant connection would need to be matched against a Log (again, with Detailed or Extended) in both layers (not just the access layer).

You might want to use the Packet Mode search to validate what rules a given connection would match.

Refer to Packet Mode, a new way of searching through your security policy in R80.10‌

If it is matching a Log in both layers and you're not getting correct logs, I recommend opening a TAC case for further investigation.

Contact Support | Check Point Software 

[Rob_Bush]

You are correct, since we still have R77 in the environment, we have not actually moved to the new way of handling access and app layers.

Great information!  I thought I had tried changing the logging on both the affect firewall and application policy to "Detailed," but perhaps I only did one or the other but not both.  I'll give that a shot and see if it makes any difference.  It's still crazy to me that traffic going our our R77 gateways shows in the logs correctly, but the R80 gateways does not unless the action is anything other than "Accept."

And THANK YOU for the video link on the packet mode search.  I didn't even know that existed.  That is a very powerful way to help me troubleshoot what is going on!

[Rob_Bush]

This means the relevant connection would need to be matched against a Log (again, with Detailed or Extended) in both layers (not just the access layer).

I just checked and Detailed/Extended is not an option for logging in the access layer, only the application layer.  I already have access layer that the packet is hitting set to "Log" and I had the app layer that the packet is hitting set to "Detailed" and yet the SmartLog still does not show the app layer number/name in the column of the view, only the firewall number/name in the view when the packet is "Accept."  Am I to understand that this is NOT the correct behavior for an R80.10 gateway when viewing the logs? If this is not the correct behavior (and I hope it's not) then I'll open up a ticket with Checkpoint.  If it is the correct behavior, that the view column no longer shows the app num/name for accepted traffic when the line is clearly marked as belong to the App Control blade, then that really sucks.

[PhoneBoy]

Right, a "Detailed" log entry doesn't make sense in a Firewall only layer.

Do you have Log Generation "per connection" enabled in the Track settings for the rule?

If you do, then to me, at least, it doesn't seem like what you are seeing is the correct behavior. 

Thus the suggestion to open a TAC case.

[Rob_Bush]

Yep, I've tried all sorts of combos.  I've made sure the access rule is per Connection.  I've tried it per Session.  I've tried it both, all while trying the same set of combos on the App layer (detailed, per Connection / detail, per Session / detailed, both Connection & Session.)  Clearly I'm flailing and just tossing every "logging" option I can at the problem 😉

Your suggestion on the Packet Mode search will probably allow me to at least solve my current issue of the application layer not processing the packet the same way on the R80 gateway as it had on the R77 gateway.

[PhoneBoy]

It's also worth pointing out that in R80, some categories of apps were deprecated.

See the list here: Deprecated Categories in Application Control R80 and above 

[Rob_Bush]

Thx!  When we upgraded our Mgmt server a few months ago, we did take note of these and adjusted our app categories as needed to resolve the ones that had been removed.  I'll have to double check the list though as possibly we missed one that only rears it's ugly head when the gateway is upgraded to R80.

[DIEHARD]

Did you ever get this resolved? For me i swear it worked till I upgraded to R80.40 and i have a TAC case open about it but they don't seem to understand why it is doing this and act like the issue has never been seen before.. yet here it is.. the exact same issue and someone ran into it 4 years ago!

It IS very frustrating to look at logs and have to manually click into each individual log entry to see the ACTUAL rule hit and not just the inline layer rule#. It does know.. you just have to actually go into the individual log and you can see it in the Matched Rules just under the Inline Rule match. This is an issue for Accept rules only.. Drop rules always show the exact rule# hit!

It makes quick filtering the logs a pain too as you can't filter out specific inline layer rules without knowing the rule number first and manually typing it in as a right click and NOT quick filter will just get rid of everything because it's going to remove the entire layer from your view!