QRadar: CheckPoint troubleshooting overview

Troubleshooting

Problem

The following technical note contains tips on how to troubleshoot CheckPoint integrations.

Resolving The Problem

Overview
The OPSEC/LEA protocol executes a binary called leapipe2syslog that was built by using the CheckPoint SDK to retrieve firewall events from CheckPoint. It uses a TCP connection to the port 18184 by default. Received events are ingested into the binary, then posted back through UDP to the port 18184 again. Any DSM listening on that port parses the events and forwards them along the pipeline.

Using the LEAPIPE2SYSLOG Binary to troubleshoot

Once you have your Log source set up, a configuration file is created which needs to be passed into the leapipe2syslog binary. The protocol generally uses the binary as a daemon (background service) for receiving and forming the events. It is possible to run it in the foreground in order to provide insight into any possible connection problems.

The binary can be found in /opt/qradar/bin/leapipe2syslog, and the generated configuration file can be found in /store/tmp, and look like leapipe_config_####.conf.
In order to see how your configuration is performing within the binary, use the following command:

/opt/qradar/bin/leapipe2syslog -vV -s /store/tmp/leapipe_config_<####>.conf

Where <####> is a number appended to the end of the filename, the -vV command ensures verbose output to the terminal window.
To send output to a text file for sending, storage, or searching, use the following command version:

/opt/qradar/bin/leapipe2syslog -vV -s /store/tmp/leapipe_config_<####>.conf > <yourOutputFile>.txt

Checking this file allows the user to see debug output of the leapipe binary. Most of the useful connection debugging information can be found after the line Calling opsec_Mainloop.

SIC error (this is a certs/CN/DN issue) or COMM FAILURE / COMM IS DEAD for communication path issues might be noticed here, indicating improper configuration parameters were provided.

EXAMPLE OUTPUT ERRORS (from binary output):
A) Trust was not initialized, or previously established, this needs to be reset in SmartConsole:

Sample Output Errors

[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] call_handlers_list: no conversion done, set cn=cp_mgmt,O=CheckPoint1..example3 as sic name
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] PM_session_init: given session O(CN=vm19922_app,O=CheckPoint1..example3;cn=cp_mgmt,O=CheckPoint1..example3;18184;lea).
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] PM_policy_query: input session O(CN=vm19922_app,O=CheckPoint1..example3;cn=cp_mgmt,O=CheckPoint1..example3;18184;lea).
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] PM_policy_query: rule found (ME;cn=cp_mgmt,O=CheckPoint1..example3;18184;lea;sslca(1/1)).
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] PM_policy_query: finished successfully. 1st method = sslca
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] filter_method_array: auth method sslca not initialized, remove it from query result.
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] PM_policy_choose: finished successfully. choose: DENY.
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] policy_choose: choose failed.
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] sic_client_negotiate_auth_method: policy choose failed.
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] fwasync_do_mux_in: 13: handler returned with error
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] sic_client_end_handler: for conn id = 13
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] opsec_auth_client_connected: connect failed (119)
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] opsec_auth_client_connected: SIC Error for lea: Client could not choose an authentication method for service lea
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33]<b>opsec_auth_client_connected:conn=(nil) opaque=0x90a7e80 err=0 comm=0x90a8990</b>
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] comm failed to connect 0x90a8990
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] OPSEC_SET_ERRNO: err = 8 Comm is not connected/Unable to connect (pre = 0)
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] COM 0x90a8990 got signal 131075
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] destroying comm 0x90a8990
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] Destroying comm 0x90a8990 with 2 active sessions
[6585 151541840]@VM199-22.q1labs.lab[5 Oct 10:25:33] Destroying session (90ab3c8) id 3 (ent=90a5690) reason=SIC_FAILURE

B) Improper SIC ATTRIBUTE in QRadar (set it to cp instead of cp_mgmt):
Server replies with the proper rule name, which does not match our configuration so the process fails.

Sample SIC ATTRIBUTE

[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] set_keep_alive(comm 0x9019988): first time setting: session: 3, interval: 5000
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] fwasync_conn_params: <ac10c716,39322> <ac10966a,18184>
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] fwasync_connbuf_realloc: reallocating 0 from 0 to 1028
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] fwasync_conn_get: get max buffer size (4194304) .
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] fwasync_connbuf_realloc: reallocating 0 from 0 to 1028
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] sic_client_set_version: 13: protocol version is 59000000
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] cpsicdemux_check_mode: server_mode=1 | requested_mode=1
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] fwasync_conn_get: get max buffer size (4194304) .
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] fwasync_conn_get: get max buffer size (4194304) .
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] sic_client_handler: server sent wrong sic name to the client cn=cp_mgmt,o=CheckPoint1..example3
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] sic_client_handler: Trying to make connection with sic name "CN=cp,O=CheckPoint1..example3",
but peer says its sic name is "cn=cp_mgmt,o=CheckPoint1..example3".
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] fwasync_do_mux_in: 13: handler returned with error
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] sic_client_end_handler: for conn id = 13
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] opsec_auth_client_connected: connect failed (111)
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] opsec_auth_client_connected: SIC Error for lea: Peer sent wrong DN: cn=cp_mgmt,o=CheckPoint1..example3
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] opsec_auth_client_connected:conn=(nil) opaque=0x90096d8 err=0 comm=0x9019988
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] comm failed to connect 0x9019988
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] OPSEC_SET_ERRNO: err = 8 Comm is not connected/Unable to connect (pre = 0)
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] COM 0x9019988 got signal 131075
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] destroying comm 0x9019988
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] Destroying comm 0x9019988 with 2 active sessions
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] Destroying session (90099b8) id 3 (ent=900aa80) reason=SIC_FAILURE
[13875 150833232]@VM199-22.q1labs.lab[5 Oct 10:51:23] SESSION ID:3 is sending DG_TYPE=3

C) BAD APP NAME (set to vm1992_app instead of vm19922_app):
Server attempts to find authentication method for the improperly named application. When this occurs CheckPoint is not initialized and fails.

Sample Bad APP Name

[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] call_handlers_list: no conversion done, set CN=cp_mgmt,O=CheckPoint1..example3 as sic name
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] PM_session_init: given session O(CN=vm1992_app,O=CheckPoint1..example3;CN=cp_mgmt,O=CheckPoint1..example3;18184;lea).
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] PM_policy_query: input session O(CN=vm1992_app,O=CheckPoint1..example3;CN=cp_mgmt,O=CheckPoint1..example3;18184;lea).
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] PM_policy_query: rule found (ME;CN=cp_mgmt,O=CheckPoint1..example3;18184;lea;sslca(1/1)).
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] PM_policy_query: finished successfully. 1st method = sslca
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] filter_method_array: auth method sslca not initialized, remove it from query result.
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] PM_policy_choose: finished successfully. choose: DENY.
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] policy_choose: choose failed.
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] sic_client_negotiate_auth_method: policy choose failed.
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] fwasync_do_mux_in: 13: handler returned with error
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] sic_client_end_handler: for conn id = 13
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] opsec_auth_client_connected: connect failed (119)
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] opsec_auth_client_connected: SIC Error for lea: Client could not choose an authentication method for service lea
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] opsec_auth_client_connected:conn=(nil) opaque=0x9f230e0 err=0 comm=0x9f25a30
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] comm failed to connect 0x9f25a30
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] OPSEC_SET_ERRNO: err = 8 Comm is not connected/Unable to connect (pre = 0)
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] COM 0x9f25a30 got signal 131075
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] destroying comm 0x9f25a30
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] Destroying comm 0x9f25a30 with 2 active sessions
[20565 166664272]@VM199-22.q1labs.lab[5 Oct 10:54:23] Destroying session (9f28508) id 3 (ent=9f22ef0) reason=SIC_FAILURE

If your CheckPoint Log Source is working, it stays active and continues printing logs. If your CheckPoint Log Source is broken, it exits and the logs stop. Communication failures might take a minute to display and exit from logging.

Troubleshooting - SIC pull

If you are unable to pull the certificate, here are the most common reasons:

Incorrect one-time pull password.
Policy not installed. If it was, you need to reset the object, and from Smart Dashboard, go to Policy, Install. Also, publish changes and install to database to ensure everything is up to date.
Ports 18210 and 18184 are not open. You can verify whether these ports are open using a tcpdump session. For example, at a command prompt use the command
```
tcpdump -nnAs0 -i eth0 port 18210 and port 18184
```

If the ports are not open, read the section "My SIC entries all seem correct, but I'm getting DENY using sslca authentication" for firewall rule configuration.

Examples of Successful and Unsuccessful Certificate pulls.

Successful Certificate pull from /var/log/qradar.log

cat opsec_cert_192.0.2.X.log

The full entity sic name is:
CN=<APPNAME>,O=<SERVERID> (as defined in Log Source Configuration)
Certificate was created successfully and written to "/opt/qradar/conf/opsec_cert_192.0.2.X.p12".

Unsuccessful Certificate pull from /var/log/qradar.log

Unsuccessful Certificate pull (From qradar.log):

com.q1labs.semsources.sources.LEA.LEAProvider: [INFO] [NOT:0000006000][XXX.XXX.XXX.XXX/- -] [-/- -]Following message suppressed 1 times in 300000 milliseconds
com.q1labs.semsources.sources.LEA.LEAProvider: [ERROR] [NOT:0070003100][XXX.XXX.XXX.XXX/- -] [-/- -]Failed to pull the certificate for the LEA server XXX.XXX.XXX.XXX.
com.q1labs.semsources.sources.LEA.LEAProvider: [INFO] [NOT:0000006000][XXX.XXX.XXX.XXX/- -] [-/- -]Following message suppressed 1 times in 300000 millis
com.q1labs.semsources.sources.LEA.LEAProvider: [INFO] [NOT:0000006000][XXX.XXX.XXX.XXX/- -] [-/- -]Following message suppressed 1 times in 300000 milliseconds
com.q1labs.semsources.sources.LEA.LEAProvider: [ERROR] [NOT:0000003000][XXX.XXX.XXX.XXX/- -] [-/- -] Opsec error. rc=-1 err=-93 The referred entity does not exist in the Cer
tificate Authority
com.q1labs.semsources.sources.LEA.LEAProvider: [INFO] [NOT:0000006000][XXX.XXX.XXX.XXX/- -] [-/- -]Following message suppressed 1 times in 300000 milliseconds
com.q1labs.semsources.sources.LEA.LEAProvider: [ERROR] [NOT:0070003100][XXX.XXX.XXX.XXX/- -] [-/- -]Failed to pull the certificate for the LEA server XXX.XXX.XXX.XXX.
com.q1labs.semsources.sources.LEA.LEASource: [ERROR] [NOT:0070003100][XXX.XXX.XXX.XXX/- -] [-/- -]There appears to be a configuration issue with the provider connection 'LEA Provider XXX.XXX.XXX.XXX'.

Troubleshooting LEA Service

Is the LEA Service Running?
To confirm the status of the lea service you can use the following command

ps -ef |grep -i lea

root 5472 15114 0 14:20 pts/2 00:00:00 grep lea
root 11442 1 0 Sep23 tty1 00:00:00 /sbin/mingetty --noclear tty1
root 31840 18763 0 14:19 ? 00:00:00 /opt/qradar/bin/leapipe2syslog -s /store/tmp/leapipe_config_46350.conf

In the /var/log/qradar.log file, you can also see that the LEA service is running:

LEA service is running

XXX.XXX.XXX.XXX [ecs] [OPSEC LEA Protocol Provider Thread: LEA Provider XXX.XXX.XXX.XXX] com.q1labs.semsources.sources.LEA.LEASource: [INFO] [NOT:0000006000][XXX.XXX.XXX.XXX/- -] [-/- -]OPSEC LEA provider 'LEA Provider XXX.XXX.XXX.XXX' config ok; now trying to run...
XXX.XXX.XXX.XXX [ecs] [OPSEC LEA Protocol Provider Thread: LEA Provider XXX.XXX.XXX.XXX] com.q1labs.semsources.sources.LEA.LEASource: [INFO] [NOT:0000006000][XXX.XXX.XXX.XXX/- -] [-/- -]OPSEC LEA provider 'LEA Provider XXX.XXX.XXX.XXX' now running.

Can I use the same certificate across multiple Checkpoint configurations?

You can run into an issue where you have two servers where you are trying to pull logs from, especially if they are using the same Opsec Object. For example, 10.10.x.1 and 10.10.x.2. Since you can only pull one certificate, you have to do the following:

Configure 10.10.x.1 in QRadar UI to pull one-time certificate from 10.10.x.1 for the object. You see a Trust Established in the Object configuration.
When you are configuring 10.10.x.2 in the UI, do not try to pull the certificate, as it will fail since it's only a one-time pull. Instead, check the 'Specify Certificate' box, and fill out the same certificate used for 10.10.x.1. It should be /opt/qradar/conf/opsec_cert_10.10.x.1.p12.

Once we found out it was using the same OPSEC object, we pointed the certificate for the secondary server to the same certificate as the primary server, and they are both up and running.

What Ports do you need to open to use OPSEC/LEA

What ports do you need open to use OPSEC/LEA?
For the cert pull, you need Port 18210 bidirectional.
For LEA, you need Port 18184 bidirectional.

What authentication type (sslca, sslca_clear, or clear) should I be using?
Most installations use sslca. You can try additional authentication types, if they are configured within checkpoint, but by default you should use sslca.

To validate the config, you can:

SSH to Checkpoint Management Server, and go into expert mode.
Run the command.
```
cd $FWDIR\conf
```
If the command does not work, use the 'find' command to locate the fwopsec.conf file.
```
find . -name fwopsec.conf -print
```
A sample of the files can be displayed by using this command.
```
cat fwopsec.conf
```
These 2 lines should exist.
```
lea_server auth_port 18184
lea_server auth_type ssl_opsec
```
For more information about the fwopsec.conf file, refer to the section Making Corrections using CLI.

Resolving configuration issues

My SIC entries all seem correct, but I'm getting DENY when using sslca authentication. If you see this message PM_policy_choose: finished successfully. choose: DENY in your leapipe_config output, this troubleshooting section might provide some solutions on resolving this issue.
Refer to Using the LEAPIPE2SYSLOG Binary to troubleshoot on leapipe_config if you require more information.

CheckPoint Deny Example

[ 13448 -135006528]@example.q1labs.inc[24 Sep 14:07:46] PM_policy_query: finished successfully. 1st method = sslca

[ 13448 -135006528]@example.q1labs.inc[24 Sep 14:07:46] filter_method_array: auth method sslca not initialized, remove it from query result.
[ 13448 -135006528]@example.q1labs.inc[24 Sep 14:07:46] PM_policy_choose: finished successfully. choose: DENY.
[ 13448 -135006528]@example.q1labs.inc[24 Sep 14:07:46] policy_choose: choose failed.
[ 13448 -135006528]@example.q1labs.inc[24 Sep 14:07:46] sic_client_negotiate_auth_method: policy choose failed.

Check your certificate configuration

Locate your certificate for OPSEC. It looks like /opt/qradar/conf/trusted_certificates/lea/opsec_cert_<serverip>.p12

Run the command:

keytool -list -keystore <your-cert>.p12 -storetype PKCS12 -v

Press enter, as the certificate has no password.
The output looks similar to the following:

Keytool Output Example

keytool -list -keystore opsec_cert_XXX.XXX.XXX.XXX.p12 -storetype PKCS12 -v

Enter keystore password: <hit ENTER - no password>

***************** WARNING WARNING WARNING *****************
* The integrity of the information stored in the keystore *
* has NOT been verified! In order to verify its integrity, *
* you must provide the srckeystore password. *
***************** WARNING WARNING WARNING *****************

Keystore type: PKCS12
Keystore provider: IBMJCE

Your keystore contains 2 entries

Alias name: Example_ca
Creation date: Oct 5, 2017
Entry type: trustedCertEntry

Owner: O=CheckPoint1..example3
Issuer: O=CheckPoint1..example3
Serial number: 1
Valid from: 6/29/17 9:23 AM until: 6/24/37 9:23 AM
Certificate fingerprints:
MD5: C8:B3:04:6B:D3:10:F3:E8:49:B5:85:01:89:D4:10:F5
SHA1: 88:29:6C:F0:12:49:1F:2E:F5:72:AB:6A:16:83:AB:2B:EE:81:FF:33
SHA256: 89:A4:A7:77:CB:3B:40:E9:6D:08:6A:95:A4:1F:ED:D4:B8:DF:51:83:44:15:EA:2C:D2:28:AA:10:F4:10:99:CE
Signature algorithm name: SHA256withRSA
Version: 3

Extensions:

#1: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]

#2: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]

*******************************************
*******************************************
-> Alias name: vm19922_app
Creation date: Oct 5, 2017
Entry type: trustedCertEntry

-> Owner: CN=vm19922_app, O=CheckPoint1..example3
-> Issuer: O=CheckPoint1..example3
Serial number: 175cb
Valid from: 10/4/17 10:33 AM until: 10/4/22 10:33 AM
Certificate fingerprints:
MD5: 22:26:40:61:D2:A8:37:14:FE:03:1D:59:87:8F:91:FE
SHA1: 9A:8D:26:78:53:2B:DC:FB:C2:22:C9:49:46:20:B1:4A:89:A9:A2:D7
SHA256: A6:1D:B7:DB:2C:08:97:AF:1C:0D:89:38:14:10:B4:6F:B2:DA:BB:3A:70:85:02:40:9B:41:AE:C4:AC:74:AA:33
Signature algorithm name: SHA256withRSA
Version: 3

Extensions:

#1: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
1 CRL Distribution Points:

Distribution Point: [
Distribution Point Name: [URIName: ,http://CheckPoint1:18264/ICA_CRL0.crl CN=ICA_CRL0, O=CheckPoint1..example3]
Reason Flags: null
Issuer: null
]
]

#2: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
DigitalSignature
Key_Encipherment
]

#3: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:false
PathLen: undefined
]

The main lines that we are checking are:

Alias name: vm19922_app
Owner: CN=vm19922_app, O=CheckPoint1..example3
Issuer: O=CheckPoint1..example3

This certificate is good for a Log Source OPSEC/LEA configuration by using:

OPSEC Application Object SIC Attribute (SIC Name): CN=vm19922_app,O=CheckPoint1..example3
Log Source SIC Attribute (Entity SIC Name): CN=cp_mgmt,O=CheckPoint1..example3

The OPSEC_SIC_NAME can be verified here with certainty, but the CN for the OPSEC_ENTITY_SIC_NAME still needs to be checked, but is usually cp_mgmt.
Using these details, verify that your Log Source configuration has the proper "O=" value in both the SIC Attribute and SIC Entity fields.

Firewall configuration

Configuring a firewall rule through the SmartConsole is a recommended first step for R80 / R80.10 or any other SmartConsole enabled CheckPoint management server.

Log in to Smart Console
Click "Security Policies on the left - hand side
Create a firewall rule:
Source: <Your checkpoint server> Destination: Any Services and Applications: https : 443 ssh_version_2 : 22 FW1_lea : 18184 FW1_ica_pull : 18210 FW1_ica_mgmt tools : 18265 FW1_ica_services : 18264 icap : 1344 Install On: Policy Targets Action: Accept
Publish any changes, install policies, install database.
Attempt to connect to the server from QRadar once more.

Making Corrections by using CLI

Lastly, if the Smart Console method is not correcting the issue, we can attempt to do so through the CLI.

In some cases, even though that no other specific auth_type is configured in the fwopsec.conf file. You might still need to manually add sslca as the auth_type to the fwopsec.conf file due to configurations elsewhere.

Using an SSH session, connect to Checkpoint Management Server, and go into expert mode.
Change directory's to $FWDIR\conf by using the command:
cd $FWDIR\conf
Locate the fwopsec.conf file.
Add the following lines to the end of the file:
- lea_server auth_type sslca
- lea_server auth_port 18184
Restart the checkpoint service with a cpstop/cpstart command to ensure the changes are applied.

fwopsec.conf File Example

A typical fwopsec.conf file looks like:

cat fwopsec.conf

#
# (c) Copyright 1993-2011 Check Point Software Technologies Ltd.
# All rights reserved.
#
# This is proprietary information of Check Point Software Technologies
# Ltd., which is provided for informational purposes only and for use
# solely in conjunction with the authorized use of Check Point Software
# Technologies Ltd. products. The viewing and use of this information is
# subject, to the extent appropriate, to the terms and conditions of the
# license agreement that authorizes the use of the relevant product.
#
# This file, by default, has no active entries.
# From this Check Point version, the purpose of this OPSEC
# configuration file is:
# 1) To present the default configuration of security methods
# and port numbers of the OPSEC servers within Check Point.
# 2) To allow the administrator to change those defaults.
# 3) To configure non-default security methods for OPSEC client products.
#
# Note:
# To change the security method with old OPSEC server products, use the
# SmartDashboard to edit the backwards-compatibility method of the UFP/CVP
# servers.
#
# The format of a configuration entry is:
# <opsec-server> <security-method> <port-number>
#
# Where:
# <opsec-server> is one of:
# sam_server, lea_server, ela_server, cpmi_server, uaa_server.
# <security-method> is one of:
# auth_port: The OPSEC server listens to secure connections
# on the following port number.
# port: The OPSEC server listens to clear connections
# on the following port number.
# <port> is an integer port number:
# 0: Means that this security method is disabled.
# >0: Indicates the port number for this security method.
#
# It is possible that a specific OPSEC server will listen to both
# secure and clear connections (on two different ports!).
# the 'clear' security method may only be used for connections with
# OPSEC products using an OPSEC SDK version 4.1.2 and below.
#
# To change the default setting of an entry:
# a. Remove the comment sign (#) at the beginning of the line.
# b. Change the port number.
#
# The Security Gateway/Management default settings are:
#infoview_360000094_1.7z
# sam_server auth_port 18183
# sam_server port 0
#
# lea_server auth_port 18184
# lea_server port 0
#
# ela_server auth_port 18187
# ela_server port 0
#
# cpmi_server auth_port 18190
#
# uaa_server auth_port 19191
# uaa_server port 0
#

Results: Your CheckPoint Log Source is now configured.

If you are still having issues configuring your CheckPoint Log Source, contact IBM support for assistance.

Related Information

Integrate Check Point by using OPSEC

Check Point

[{"Type":"MASTER","Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000cwsyAAA","label":"Admin Tasks"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"7.5.0"}]

Tips