Check Point OPSEC LEA (im_checkpoint)
This module provides support for collecting logs remotely from Check Point devices over the OPSEC LEA protocol. The OPSEC LEA protocol makes it possible to establish a trusted secure and authenticated connection with the remote device.
|To examine the supported platforms, see the list of installer packages in the Available Modules chapter.|
|The OPSEC SDK provides libraries only in 32-bit versions and this makes it impossible to compile a 64-bit application. For this reason the im_checkpoint module uses a helper program called nx-im-checkpoint. This helper is responsible for collecting the logs and transmitting these over a pipe to the im_checkpoint module.|
CheckPoint uses a certificate export method with an activation password so that certificate keys can be securely transferred over the network in order to establish trust relationships between the entities involved when using SSL-based authenticated connections. The following entities (hosts) are involved in the log generation and collection process:
The firewall administrator can use the SmartDashboard management interface to connect to and manage the firewall.
- SecurePlatform based FireWall-1
The SecurePlatform based FireWall-1 device will be generating the logs (SPLAT).
The log collector running NXLog which connects to SPLAT over the OPSEC LEA protocol utilizing the im_checkpoint module.
The following steps are required to configure the LEA connection between SPLAT and NXLog.
Enable the LEA service on SPLAT. Log in to SPLAT, enter
expertmode, and run
vi $FWDIR/conf/fwopsec.conf. Make sure the file contains the following lines. Then restart the firewall with the
lea_server auth_port 18184 lea_server auth_type sslca
Make sure SPLAT will accept ICA pull requests, the LEA Connection (port 18184), and can generate logs. For testing purposes, it is easiest to create a single rule to accept all connections and log these. For this the SmartDashboard host must be added as a GUI Client on SPLAT and a user needs to be configured to be able to log onto SPLAT remotely from SmartDashboard.
Create the certificates for NXLog in SmartDashboard. Select, then click New and select OPSEC Application. A dialog window should appear. Fill in the following properties and then click OK.
NXLog log collectoror something similar.
Click on New to create a new host and name it accordingly (
nxloghost, for example).
- Client Entities
LEA. All other options should be unchecked.
- Secure Internal Communication
Click on Communication. Another dialog window will appear. Enter and re-enter the activation keys, then click Initialize. Trust state should change from Uninitialized to Initialized but trust not established. Click Close. Now in the OPSEC Application Properties window the DN should appear. This generated string looks like this:
CN=nxlog,O=splat..ebo9pf. This value will be used in our
lea.conffile as the opsec_sic_name parameter.
Retrieve the OPSEC application certificate. From the NXLog host, run the following command:
/opt/nxlog/bin/opsec_pull_cert -h SPLAT_IP_ADDR -n nxlog -p ACTIVATION_KEY. Make sure to substitute the correct values in place of
ACTIVATION_KEY. If the command is successful, the certificate file
opsec.p12should appear in the current directory. Copy this file to
Get the DN of SPLAT. In SmartDashboard, double-click on. The properties window will contain a similar DN under Secure Internal Communication such as
sic_policy.conffile from SPLAT. Initiate a secure copy from the firewall in expert mode. Then move the file to the correct location.
[Expert@checkpoint]# scp $CPDIR/conf/sic_policy.conf user@rhel:/home/user [root@rhel ~]# mv /home/user/sic_policy.conf /opt/nxlog/etc
/opt/nxlog/etc/sic_policy.conf, and add the necessary policy to the
[Outbound rules] # apply_to peer(s) port(s) service(s) auth-method(s) # -------------------------------------------------------- # OPSEC configurations - place here (and in [Inbound rules] too) ANY ; ANY ; 18184 ; fwn1_opsec, ssl_opsec, ssl_clear_opsec, lea ; any_method
/opt/nxlog/etc/lea.conf. The file should contain the following. Make sure to substitute the correct value in place of
SPLAT_IP_ADDRand use the correct DN values for
lea_server ip SPLAT_IP_ADDR lea_server auth_port 18184 lea_server auth_type sslca opsec_sic_name "CN=nxlog,O=splat..ebo9pf" opsec_sslca_file /opt/nxlog/etc/opsec.p12 lea_server opsec_entity_sic_name "CN=cp_mgmt,o=splat..ebo9pf" opsec_sic_policy_file /opt/nxlog/etc/sic_policy.conf
Refer to the Check Point documentation for more information regarding the LEA log service configuration.
To test whether the log collection works, execute the following
/opt/nxlog/bin/nx-im-checkpoint --readfromlast FALSE >
output.bin. The process should not exit. Type Ctrl+c to
interrupt it. The created file
output.bin should contain logs in
NXLog’s Binary format.
The OPSEC_DEBUG_LEVEL environment variable can be set to get
debugging information if something goes wrong and there is no
output produced. Run
The two files
If the log collection is successful, you can now try running NXLog with the im_checkpoint module.
The im_checkpoint module accepts the following directives in addition to the common module directives.
The optional directive specifies the path of the
This optional directive specifies the path of the LEA configuration file. If not specified, the default is
This can be used to specify the log file to be read.
If not specified, it defaults to
This optional boolean directive instructs the module to only read logs which arrive after NXLog is started.
This directive comes into effect if a saved position is not found, for example on first start, or when the SavePos directive is
The following matrix shows the outcome of this directive in conjunction with the SavePos directive:
If this boolean directive is set to
The following fields are used by im_checkpoint.
The LEA protocol provides Check Point device logs in a structured format.
For the list of LEA fields, see LEA Fields Update on CheckPoint.com.
Some of the field names are mapped to normalized names which NXLog uses in other modules (such as
The list of these fields is provided below.
The other LEA fields are reformatted such that non-alphanumeric characters are replaced with an underscore (
_) in field names.
$raw_event field contains the list of all fields and their respective values without any modification to the original LEA field naming.
The user name. Originally called user.
The application that the user is trying to access. Originally called app_name.
The destination IP address of the connection. Originally called dst.
The destination port number. Originally called d_port.
The direction of the connection with respect to the interface. Can be either
outbound. Originally called i/f_dir.
The duration of the connection. Originally called elapsed.
The date and time of the event. Originally called time.
The IP address or hostname of the device which generated the log. Originally called orig.
The name of the interface the connection passed through. Originally called i/f_name.
The record number which identifies the log entry. Originally called loc.
The IPS protection severity level setting. Originally called severity. Set to
INFOif it was not provided in the logs.
The source IP address of the connection. Originally called src.
The name of the device which generated the log. Originally called product.
The source port number of the connection. Originally called s_port.
This configuration instructs NXLog to collect logs from Check Point devices over the LEA protocol and store the logs in a file in JSON format.
<Extension json> Module xm_json </Extension> <Input checkpoint> Module im_checkpoint Command /opt/nxlog/bin/nx-im-checkpoint LEAConfigFile /opt/nxlog/etc/lea.conf </Input> <Output file> Module om_file File 'tmp/output' Exec $raw_event = to_json(); </Output> <Route checkpoint_to_file> Path checkpoint => file </Route>