Reading logs in the Management API ?

[Gerard_Fowley]

I see no support for reading logs (audit or rule) in the R80.10 Management API.

Am I missing it ?

Is it likely to appear in future ?

Thanks

-gf-

[Robert_Decker]

Hi Gerard,

The current version of Management API (v1.2) doesn't support reading logs information.

This will be supported in the future release.

Robert.

[Gerard_Fowley]

Thanks all.

-gf-

[Gerard_Fowley]

Thanks for the quick reply.

Is there a feature development road-map that indicates when that may be ?

It would help me decide whether to cobble together an alternative or just defer until then.

Thanks.

-gf- 

[PhoneBoy]

Timelines for this have not been finalized.

As Tomer Sole‌ suggested, your best bet is to use Log Exporter for this, which makes the logs available via syslog.

Log Exporter guide‌

[Paul_Hagyard]

R80.x still doesn't have a log mechanism in the API, although I regularly here Check Point personnel claiming that you can essentially do everything with the API that you can in the GUI. I've seen people trying to hack up an interface using tcpdump to read cookies and sending requests via curl, but it's not straightforward.

The log exporter exports individual logs, not the "consolidated" logs (if that's the right word) you see in SmartLog. So you need to unify them after exporting.

fwm logexport output does not produce consistent columns (unless you request a hotfix that should have been included in the jumbos by now). I'm pretty sure these aren't consolidated either.

You can now only export 50 records in SmartLog R80.x.

You can export 1M records from SmartView but it's slower than a wet week.

Exporting huge quantities of logs for manual analysis should not be this hard.

[PhoneBoy]

SmartLog will only export "visible" logs (which I think is 50 by default).

SmartView is what is recommended to export large chunks of logs currently.

We do plan to enhance Log Exporter to export "consolidated" logs (currently it does not).

[Tomer_Sole · Accepted solution]

Look for the “log exporter” thread at CheckMates. The new logs API provide a secure channel for exporting logs with same-arrival-rate with just 1 line of configuration. There is no official way for one-time consumption of existing logs, though. 

[Yonatan_Philip]

For some specific use cases, the good old 'fw log' command (with all its flags) can also be useful.

This option has been around for a long time but it sometimes feels as if many people are not aware of it.

It's somewhat limited in its usability but does work for some use cases.

Out of professional curiosity, could you elaborate on your use case, please?

HTH 

 Yonatan 

[Gerard_Fowley]

The use case is to extract a monthly audit report which is reviewed by another person. It's not hard to do manually, but it is the only GUI/manual extraction in an otherwise completely automated set of data collection tasks.

Thanks for the reminder about 'fw log ...' that's probably what I'll use as I have SSH access. I had forgotten about it as I was distracted by the potential of a RESTful API.

I sometimes visit clients where I am not already integrated into their support team. Having data collection tools that don't require the logistical overhead of OPSEC or GUI-clients configuration make life much easier. I expect permission configuration for the API but I hope it's less).

-gf-

[Yonatan_Philip]

fw log does sound like it's potentially what you're looking for.

But as Tomer suggested, I'd still keep the Log Exporter in mind as a viable option.

You can set it up to export only audit logs, and limit it to export to 30 days back.

Once per month turn it on to have it export the past 30 days, or leave it running ( and use the reexport flag when needed).

Both the log exporter and 'fw log' can be made to work for this use case.

The log exporter will need a receiving server, which is either a plus or minus depending on your environment, and the fw log will probably need a bit more tinkering with the output (but you'll probably have to do this in any case to parse the information).

Neither option is ideal for this use case, but both can be made to work. Off the top of my head, I don't see a clear advantage to either one.

I'd start tinkering with both of them and see if one of them comes out the clear winner.

Good luck, and post back here if you need help with implementing this.

HTH

 Yonatan 

[Paul_Hagyard]

This is an answer to an old post, but perhaps for someone elses benefit...

Depending on what you are trying to get:

1. SmartEvent scheduled reports
2. Scripted "fwm logexport" run from cron. I typically use a wrapper script that exports the key fields I'm interested in to a file and gzips it. Then you can use other scripts that run gzip -d -c <file> and pass the data through your favourite selection of cut/grep/awk/sort/uniq etc. If the job runs daily then you've always got data you can go back and review fiarly quickly.
3. Otherwise it's the log exporter into an ELK platform or similar.