Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
r1der
Contributor

Understanding application categorization

Jump to solution

I have a case with support, but I am hoping to get more understanding on how CheckPoint categorizes some of its traffic. I tried searching to see if anyone else had these issue, but maybe I am using the wrong vocabulary. I hope I am posting this in the right location.

This morning we had a scan to email issue, which I found was being dropped due our policy to block the category "Remote Administration" under the Application Layer. It passed our Security Layer rule, but for whatever reason decided yesterday the rule matched the VNC/Remote Administration category. With support's assistance I created an exception for the services being stopped (smtp & vnc) to be allowed  going to our spam filters. So far this is OK for scan to email, but I am not understanding how scan to email is now being identified as VNC traffic.

I could just be paranoid, but I decided to be a bit pro-active and filter my logs by "appi_name:VNC" and I am seeing service "https (tcp/443)" all now being dropped. Logs for the past 30 days show that this just started yesterday, and I am worried there are things users are trying to access that is allowed by our security rule, but is now being blocked due to this categorization under the application rule. 

For example, this traffic log shows the user is trying to access Microsoft OWA, but for whatever reason picks it up as VNC? I believe if it wasn't for being categorized as VNC - this traffic would have passed through the firewall. 

Am I being paranoid for nothing? I've had this happen before but with a different service identifying as "SKYVPN", even though that wasn't being used. So this is kind of concerning to me that it is randomly doing this, and I have no explanation why it starts doing so. 

Thanks!

 

Update: Issue was resolved after creating TAC case. Sometime in between contact TAC and the issue, application and url filtering updated, and the issue disappeared the next day. According to TAC a new update fixed this.

0 Kudos
Reply
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin

We’re always improving the various signatures and false positives do happen from time to time.
When that happens, it’s generally best to get the TAC involved right away so we can address the issue.

View solution in original post

4 Replies
PhoneBoy
Admin
Admin

One of the VNC signatures does involve HTTP(S):

Screen Shot 2021-01-04 at 5.03.49 PM.png

The regular VNC signature does not:

Screen Shot 2021-01-04 at 5.03.22 PM.png

What precise app is being matched?
It should show in the relevant log card.

I would make sure your App Control signatures are up to date.
If you're still seeing issues after that, best to raise this with the TAC. 

r1der
Contributor

Hi PhoneBoy! Got resolution from TAC. Attached pic of the log card just so you can see what I was seeing.

"According to R&D, a new application control update was released last night in order to fix our issue with VNC application."

As soon as the problem showed up it went away as of yesterday afternoon. I'm not sure how it even matched VNC with port 25! I was truly concerned because other 443 traffic were also being blocked. Not sure how to prevent this other than totally stopping app control updates but that seems wrong.

I'm curious now on the frequency everyone has on the App control & URL Filtering to update.

Thanks for your response!

0 Kudos
Reply
PhoneBoy
Admin
Admin

We’re always improving the various signatures and false positives do happen from time to time.
When that happens, it’s generally best to get the TAC involved right away so we can address the issue.

View solution in original post

Alex_Gilis
Advisor

Default update interval should be every day midnight on the management, every 2 hours on the gateways.