CPLog to Syslog for R80 Managed environments

[Vladimir]

Attached is the document describing a simplified approach to enable CPLog to Syslog forwarding for R80 managed environments.

This solution will work for Security Management server. for MDS, it is slightly different. Please see referenced SKs for expanded information.

Note that the execution of the manual stop and start for the CPLogToSyslog described in SKs, (not using watchdog commands), may prevent service from starting properly.

[Vladimir]

Be advised that if you have to discern the origin of the messages forwarded by CPLogToSyslog utility, presently you can only do so by the IPs of the gateways. 

Check Point can provide you with the hotfix for your server based on its cpinfo that should include the DN names of the gateways in the messages.

[Vladimir]

Update: the DN name resolution hotfix does not work.

The issue was replicated by TAC and forwarded to R&D.

Service Request # 1-9775464071

I'll update the thread once problem is solved.

[Vladimir]

Below are the steps to have the syslog contain the origin_sic_name field.

Perform these steps on the Log server that has CPLogToSyslog installed:

  1. Stop services on the Log Server.

  [Expert@HostName]# cpstop

2. Backup and modify $FWDIR/conf/log_fields.C

  [Expert@HostName]# cp -pv $FWDIR/conf/log_fields.C

$FWDIR/conf/log_fields.C_ORIGINAL

  [Expert@HostName]# vi $FWDIR/conf/log_fields.C

3. Search for "origin_sic_name" and under ":display_mode" there will be a

field, ":application_name (FWLog)". Change from:

: (

  :AdminInfo (

    :chkpf_uid ("{5DF46778-79F6-487B-AF90-8CE40333E117}")

    :ClassName (application_display_mode_object)

  )

  :application_display_mode (none)

  :application_name (FWLog)

)

TO:

: (

  :AdminInfo (

    :chkpf_uid ("{5DF46778-79F6-487B-AF90-8CE40333E117}")

    :ClassName (application_display_mode_object)

  )

  :application_display_mode (own_column)

  :application_name (FWLog)

)

4. Start services.

  [Expert@HostName]# cpstart

The logs will now contain the origin_sic_name field:

Nov 9 2017 14:39:50
Nov 9 2017 19:39:50 GMT
Thu Nov 9 14:39:50 Log host CPLogToSyslog: 0 16386 encrypt 52.184.158.74 >eth1 LogId: <max_null>; ContextNum: <max_null>; OriginSicName: <max_null>; log_sequence_num: 0; is_first_for_luuid: 131072; inzone: Internal; outzone: External; rule: 90; rule_uid: {AE182161-16C0-4367-A732-B036B35935E9}; rule_name: Internet access; service_id: domain-udp; src: 10.aaa.aaa.aaa; dst: 10.bbb.bbb.bbb; proto: 17; scheme: IKE; methods: ESP: AES-128 + SHA1; peer gateway: 62.aaa.bbb.ccc; community: Onprem-AzureCloud; fw_subproduct: VPN-1; vpn_feature_name: VPN; origin_sic_name: CN=gatewayname,O=managementserver.domain.com.d4w394; aba_customer: SMC User; date: 9Nov2017; hour: 14:29:57; type: log; Interface: < eth1; ProductName: VPN-1 & FireWall-1; svc: 53; sport_svc: 9679;

[Prabulingam_N1]

Dear Vladimir,

The above works perfect with R80.10 & Kiwi Syslog server by using CPLogToSyslog Hotfix.

(I had done the above in R80.10 with Kiwi Syslog server)

But when I try to use ArcSight - I could not find the Event kind of format. Instead, we are getting Raw logs in ArcSight (just like Kiwi Syslog server).

Also is there any other config changes we should do in Checkpoint side so that ArcSight can get in Event format which they used to get in R77.30-Syslog Object.

Eagerly awaiting any workaround so that I can make for my customer.

(I also read somewhere that manual Parser kind of config should be done in ArcSight inorder to get Event format - (FlexConnector) not sure on this)

Regards, N.Prabulingam

[Vladimir]

Ultimately, all syslog messages are strings. If you expect your SIEM to identify individual fields, then the parser must be implemented on their side.

Since they have previously parsed the R77.30 logs, there is likely one in place, but it may not match the output of the CPlog-to-syslog utility.

For example, this is the statement from another SIEM, Alert Logic, describing the process:

"As part of the normalization process, log messages are passed through the Alert Logic parser to determine if the details match specific parameters. If the parameters are met, then the log messages are tokenized to allow for better searching, alerting, and reporting.

To determine if log messages are considered parsed or not within the Alert Logic User Interface, you will want to look at the "Message Type" column (when viewing the log messages section) and see if the column states "Text" or some other value. If the word "Text" is in the column, that means those log messages are considered "Unparsed" and have fewer options for alerting and reporting. Any other value listed within the "Message Type" column means those log messages are considered "Parsed" and have more options available for searching, alerting, and reporting.

Should you need to have unparsed messages parsed, please reach out to the Alert Logic Support staff requesting a "Parser Request Form". Once that form has been filled out and sent back to our Support staff, they will get the information over to the Parser Development team. It takes generally two weeks from the time the form has been submitted back to Alert Logic for the parser to be added to the Alert Logic parser system."

[Tom_Cripps]

https://community.checkpoint.com/people/vladff097c1d-a31f-483e-9404-5bf20903d568‌

We're having issues getting CPLogToSyslog holding a connection and sending Syslog traffic on our R80.10 environment. I can see using Wireshark on the server that the traffic stops in under 5 minutes. I'm sending it over UDP and not TCP, but we have a lot of traffic. I've got a seperate Checkpoint environment running R77.30 and it's been working for over 2 hours, and nearly 3 now as I'm writing this. 

Any advice is appreciated. I seem to think it's either an issue with R80.10 or, it's an issue with how much traffic we send? 

[Vladimir]

Please verify the status of the CPlog_to_syslog process during normal operation as well as after the failure and let me know what you are seeing.

As to "holding connection", this implies session. Please verify that it is only UDP that you are sending, not both.

[Tom_Cripps]

Hi Vladimir, 

The status of the process is running, and i can see the session making a connection to our management server using port 18184, and this session will drop and we will stop receiving traffic at our Syslog server. 

To your question about, making sure it's only UDP I'm sending, that is correct, I've made sure of that already using an SK I've been advised to look at.

[Vladimir]

Tom, the 18184 is used for LEA connections. typical syslog output is on ports. I'd expected to see 514 for the outbound messages.

Please let me know if I understand your setup correctly:

You have a single management/log server.

You have CPLog_to_syslog utility installed on it.

It is configured to output UDP on port: ??? to your syslog server as per  sk109016 (specify syslog server vendor)

When you are stating "i can see the session making a connection to our management server using port 18184", it sounds as the CPLog_to_syslog is not installed on your management server- please describe your environment in greater detail.

[Tom_Cripps]

Hi Vladimir, 

I followed the sk to a tee really, the only real changes I made, is for the IP address for the Syslog Server and Management server, as well as my filter options. We have two management servers, but only one is running the service. We have the CPLogToSyslog installed and for the right take too. Just looking back now at the sk, and I can now see that port 514 is used for syslog outputs and not for the LEA session. 

Doing the netstat command and looking at both ports, I can see the service on port 18184 and not 514. See image for what I mean.

[Tom_Cripps]

Must of been me getting confused with the port numbers.

Tom

[Tom_Cripps]

Vladimir, I've just gone over that SK and i've seen it wasn't sending over UDP, but I'm sure i've done that before, so i've now changed the fwstart file so it will send over UDP but it's still sending over TCP?

See images below.

[Vladimir]

As is expected.

If you are using UDP port 514, it will be present in netstat on the syslog server.

On your management server you likely will see the ephemeral port #s from which messages originate, or the predefined ports (seldom the case and I am not sure if it is for CPLog_to_syslog).

I had to reboot my management server for the change from TCP to UDP to take effect.

Let me know if you are still experiencing the issue with UDP output.

[Tom_Cripps]

Will have a look round today and will play around with a few things and let you know.

Tom