Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Luis_Miguel_Mig
Advisor
Jump to solution

r81 manager logging

Since I upgraded the manager to r81 I get 2 new logging entries every 30 seconds. So more than 5k per day.

Mapping of Updatable Object started. OnlineServices

Mapping of Data Center server finished. OnlineServices

 

Does it need to be done so often? Is there a way to deactivate the logging of this activity.

 

0 Kudos
1 Solution

Accepted Solutions
Gil_Sudai
Employee
Employee

Sorry, my mistake. Please try onlineservices.scannerInterval and not OnlineServices.scannerInterval.

Yes, Geo updatable objects are supposed to generate these logs. Not a bug. It is indication that the update process is working.

View solution in original post

17 Replies
PhoneBoy
Admin
Admin

Don’t believe you can disable that.
However it’s probably worth a TAC case.

0 Kudos
Luis_Miguel_Mig
Advisor

I hope it gets removed in the next jumbo. They are 5k useless logs everyday.
I guess it only happens if you use updatable or datacenter objects.

0 Kudos
Tal_Paz-Fridman
Employee
Employee

Hi

Sent a question to R&D owner.

Will report if there is something that can be done directly or if needs to be addressed in future release.

Thanks

Tal_Paz-Fridman
Employee
Employee

Hi,

 

Answer from R&D is that the Security Gateway tries to download a package once every 2 hours.

It should not happen every 30 seconds, unless there probably might be some connectivity failure.

HTH

Tal

0 Kudos
Luis_Miguel_Mig
Advisor

These are the logs I am getting - see bellow. 
I am running a tcpdump in the manager and there are only external http connection attempts about every 5 minutes.

These logs  don't match any connection attempt. 

The list bellow are the hostnames that the firewall manager has successfully reached in the last 24 hours.

I have the impression that those mapping actions is an internal process. 

 

updates.checkpoint.com366
productservices.checkpoint.com286
dl3.checkpoint.com217
usercenter.checkpoint.com13
productcoverage.checkpoint.com12

 

Time: 2021-09-07T11:45:06Z
Id: 0a470b47-eeb2-9b19-6137-50c265990000
Sequencenum: 1
Client IP: x.x.x.x
Sendtotrackerasadvancedauditlog:0
Severity: Informational
Description: Mapping of Data Center server finished. OnlineServices []
Type: Control
Blade: CloudGuard IaaS
Origin: fm
Product Family: Network
Marker: @A@@B@1630969200@C@33221
Log Server Origin: x.x.x.x
Origin Log Server IP: x.x.x.x
Index Time: 2021-09-07T11:45:07Z
Lastupdatetime: 1631015106000
Lastupdateseqnum: 1
Confidence Level: N/A
Stored: true

Time: 2021-09-07T11:46:06Z
Id: 0a470b47-eeb2-9b19-6137-50fe659a0001
Sequencenum: 2
Client IP: x.x.x.x
Sendtotrackerasadvancedauditlog:0
Severity: Informational
Description: Mapping of Updatable Object started. OnlineServices []
Type: Control
Blade: CloudGuard IaaS
Origin:  fm
Product Family: Network
Marker: @A@@B@1630969200@C@33261
Log Server Origin: x.x.x.x
Origin Log Server IP: x.x.x.x
Index Time: 2021-09-07T11:46:07Z
Lastupdatetime: 1631015166000
Lastupdateseqnum: 2
Confidence Level: N/A
Stored: true

0 Kudos
Gil_Sudai
Employee
Employee

Hi.

Some technical background:

  1. The logs that you are seeing are related to the usage of the Updatable Objects feature.
  2. The update of the Updatable Objects data is done inside the CloudGuard Controller process, in parallel to the update of all other types of Data Center, for example Azure, AWS, VMWare vCenter and more.
  3. The CloudGuard Controller process runs on the mgmt server. It is not running on the security GW.
  4. In R80.40 in order to improve visibility and troubleshooting, we added the "start" and "finished" logs to each type of Data Center. This helps customers to verify the Data Centers scans are running and also the scanning duration.
  5. In R81.10 we changed the logic a bit, to send only one log when the scanning ends (this will reduce the number of logs that you see by 50%)
  6. The default delay between data update is 30 seconds.

Are you using the Updatable Objects feature or not?  If you are not using Updatable Objects, than you should not see these logs and this is a bug.

In order to change the delay between data update, you can edit $FWDIR/conf/vsec.conf and change or add 

OnlineServices.scannerInterval=<VALUE_IN_SECONDS>

And then run "vsec stop ; vsec start"

 

Luis_Miguel_Mig
Advisor

Thanks.
I do use the updatable objects  (geolocation objects)
So how will it work once the bug is fixed? Will it be fixed in the next jumbo?
I guess that it would be good if it was possible to enable/disable these logs just for troubleshooting because I think they are not needed in normal circumstances, no?
As a workaround I can change the scannerinternal to 2 hours   but I guess if this logging was disabled I would like to leave the scanner interval to 30 secs by default.

However is this supposed to generate traffic every 30 seconds? I don't see it.

By the way OnlineServices.scannerInterval is not defined in  $FWDIR/conf/vsec.conf. Do you mean global.scannerInterval?

0 Kudos
Luis_Miguel_Mig
Advisor

I don't see any change with OnlineServices.scannerInterval. However I tried with global.scannerInterval to 5 min and now I get those logs every 5 minutes.

So now, I still don't understand if Geolocation updatable objects are supposed to generate these logs or this is a bug.

My assumption is that we would like to get those objects updated as much as possible but the logs only generated if we there are problems and we need to troubleshoot.

0 Kudos
Gil_Sudai
Employee
Employee

Sorry, my mistake. Please try onlineservices.scannerInterval and not OnlineServices.scannerInterval.

Yes, Geo updatable objects are supposed to generate these logs. Not a bug. It is indication that the update process is working.

Luis_Miguel_Mig
Advisor

onlineservices.scannerInterval works thanks.
But I still don't see the value of those logs. I would like to keep the scan interval  to 30 secs and no logs by default.

I have noticed that vsec has an option to debug. Perhaps that is enough for troubleshooting purposes.

Anyway thanks.

0 Kudos
Matlu
Advisor

Hello,

Were you able to solve your problem?

I am having the same problem, I can no longer see the traffic logs, as I am currently "flooded" with messages "Mapping of data center....".

It's just not that easy anymore to check the important traffic logs in the management console.

I have a SMS in version R81.10 with Take 110.

Any way to fix this?


Regards.

0 Kudos
Tal_Paz-Fridman
Employee
Employee

Are these the only logs you receive?

When you filter them out do you see other logs, for example a connection you initiated to the Security Gateway?

 

0 Kudos
Matlu
Advisor

Hello,

It is being a bit "uncomfortable" these registrations.

Real traffic logs are appearing only for "moments", but we are being "flooded" by the "Mapping of ......" log.

If I try to filter out a particular IP that is actually generating traffic on our GW, well, it just doesn't show up.

LOGS2.pngLOGG1.png

Greetings.

0 Kudos
Tal_Paz-Fridman
Employee
Employee

As a workaround you can also filter out the Blade for CloudGuard IaaS:

NOT blade:"CloudGuard IaaS"

 

0 Kudos
Matlu
Advisor

More logs are visible, but it is not very "comfortable" to apply this filter, in order to be able to have a clearer view of the logs that really matter.

LOG3.png

Is there any solution nowadays to avoid this kind of "Mapping....." logs?

0 Kudos
Tal_Paz-Fridman
Employee
Employee

BTW, are you using Data Center objects or a Generic Data Center object?

@Amir_Senn What do you think?

0 Kudos
Amir_Senn
Employee
Employee

The number of logs for "CloudGuard IaaS" is insignificant comparing to the number of logs from traffic.

From what I can see the issue is they are presented before the traffic logs. The logs view shows the logs from newest to oldest, so according to that I assume that the clock of your management server is slightly ahead of the FW-01 clock. I suggest using NTP service to keep them aligned at all time.

If this is not the case I suggest creating constant filter by right clicking query line -> Add constant filter

Kind regards, Amir Senn
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Wed 01 May 2024 @ 02:00 PM (EDT)

    South US: HTTPS Inspection Best Practices

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Wed 01 May 2024 @ 02:00 PM (EDT)

    South US: HTTPS Inspection Best Practices

    Tue 23 Apr 2024 @ 11:00 AM (EDT)

    East US: What's New in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events