IBM Support

QRadar: CheckPoint Troubleshooting Overview

Troubleshooting


Problem

These are some pointers on how to troubleshoot CheckPoint intergrations.

Resolving The Problem


Overview
Using the LEAPIPE2SYSLOG Binary to troubleshoot
Troubleshooting - SIC pull
Troubleshooting LEA Service
What Ports do you need to open to use OPSEC/LEA?
Resolving configuration issues



Overview


The OPSEC/LEA protocol executes a binary, called leapipe2syslog that was built using the CheckPoint SDK, to retrieve firewall events from CheckPoint. It utilizes 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 for any DSM listening on that port to parse the events and forward them along the pipeline.



Using the LEAPIPE2SYSLOG Binary to troubleshoot


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

The binary is located at "/opt/qradar/bin/leapipe2syslog", and the generated configuration file should 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. The majority of useful connection debugging information can be found after the line "Calling opsec_Mainloop".

SIC error (this is certs/CN/DN issues) or COMM FAILURE / COMM IS DEAD for communication path issues may 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 just cp instead of cp_mgmt ):
Server replies back 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 will stay active and continue printing out logs. If your CheckPoint Log Source is broken, it will exit and the logs will stop. Communication failures may 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:
  1. Incorrect one-time pull password.
  2. Policy not installed. If it was, you will 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.
  3. Port 18210 and 18184 are not open. You can verify if 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 they are not open, please see the "My SIC entries all seem correct but I'm getting DENY using sslca authentication" section for firewall rule configuration.

Examples of Successful and Unsuccessful Certificate pulls.
    

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

    

root@example tmp# 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):


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



Troubleshooting LEA Service


Is the LEA Service Running?
Command: ps -ef |grep -i lea
[root@example tmp]# ps -ef |grep 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 the LEA service is running:
    

LEA service is running

    


Sep 24 14:19:11 192.0.2.X [ecs] [OPSEC LEA Protocol Provider Thread: LEA Provider 192.0.2.X] com.q1labs.semsources.sources.LEA.LEASource: [INFO] [NOT:0000006000][192.0.2.X/- -] [-/- -]OPSEC LEA provider 'LEA Provider 192.0.2.X' config ok; now trying to run...
Sep 24 14:19:33 192.0.2.X [ecs] [OPSEC LEA Protocol Provider Thread: LEA Provider 192.0.2.X] com.q1labs.semsources.sources.LEA.LEASource: [INFO] [NOT:0000006000][192.0.2.X/- -] [-/- -]OPSEC LEA provider 'LEA Provider 192.0.2.X' now running.


Can I use the same certificate across multiple Checkpoint configurations?

You may 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 will see a Trust Established in the Object configuration.
  • When 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 their secondary server to the same certificate as their primary server, and they are 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 18210 bi-directional
For LEA, you need 18184 bi-directional.

What authentication type (sslca, sslca_clear, or clear) should I be using?
Majority of installations will use sslca. You can try additional authentication types, if they have been 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 this doesnt work, use the 'find' command to locate the fwopsec.conf file.
    find . -name fwopsec.conf -print
  • A sample of the files can be displayed using this command
    cat fwopsec.conf
    These 2 lines should exist

    lea_server auth_port 18184
    lea_server auth_type ssl_opsec
  • For more infomation on the fwopsec.conf file, please refer to the section Making Corrections using CLI


Resolving configuration issues


My SIC entries all seem correct but I'm getting DENY 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.
Please refer back 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

  1. Locate your certificate for OPSEC. It will look like /opt/qradar/conf/trusted_certificates/lea/opsec_cert_<serverip>.p12
  2. Run the command:
    keytool -list -keystore <your-cert>.p12 -storetype PKCS12 -v
  3. Press enter, as the certificate has no password.
  4. The output should look similar to this:

Keytool Output Example


[root@VM199-22 lea]# keytool -list -keystore opsec_cert_192.0.2.X.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 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 your Log Source configuration has the proper "O=" value in both the SIC Attribute and SIC Entity fields.

Firewall configuration


Secondly, configuring a firewall rule through the SmartConsole is a recommended first step for R80 / R80.10 or any other SmartConsole enabled CheckPoint management server.
  1. Log in to Smart Console
  2. Click "Security Policies on the left - hand side
  3. 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

  4. Publish any changes, install policies, install database.
  5. Attempt to connect to the server from QRadar once more.



Making Corrections 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 no other specific auth_type is in the fwopsec.conf file, you may still need to manually add sslca as the auth_type to the fwopsec.conf file due to configurations elsewhere.
  1. Using an SSH session connect to Checkpoint Management Server, and go into expert mode.
  2. Change directory's to $FWDIR\conf using the command:
    cd $FWDIR\conf
  3. Locate the fwopsec.conf file.
  4. Add the following lines to the bottom of the file:
    • lea_server auth_type sslca
    • lea_server auth_port 18184
  5. Restart the checkpoint service with a cpstop/cpstart command to ensure the changes are applied.

fwopsec.conf File Example

-Typical fwopsec file looks like:


[Expert@checkpointr75_mgmt]# 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, please contact IBM support for assistance.



Where do you find more information?

[{"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Integrations - 3rd Party","Platform":[{"code":"PF016","label":"Linux"}],"Version":"7.3.1;7.3;7.2.8","Edition":"","Line of Business":{"code":"LOB24","label":"Security Software"}}]

Document Information

Modified date:
16 June 2018

UID

swg22012801