Return to
Portfolio

109.7. 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.

Note
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:

SmartDashboard

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).

NXLog

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.

  1. Enable the LEA service on SPLAT. Log in to SPLAT, enter expert mode, and run vi $FWDIR/conf/fwopsec.conf. Make sure the file contains the following lines. Then restart the firewall with the cprestart command (or cpstop and cpstart).

    fwopsec.conf
    lea_server auth_port 18184
    lea_server auth_type sslca
  2. 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.

  3. Create the certificates for NXLog in SmartDashboard. Select Manage  Servers  OPSEC Applications, then click New and select OPSEC Application. A dialog window should appear. Fill in the following properties and then click OK.

    Name

    Set to nxlog.

    Description

    Set to NXLog log collector or something similar.

    Host

    Click on New to create a new host and name it accordingly (nxloghost, for example).

    Client Entities

    Check 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.conf file as the opsec_sic_name parameter.

  4. 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 SPLAT_IP_ADDR and ACTIVATION_KEY. If the command is successful, the certificate file opsec.p12 should appear in the current directory. Copy this file to /opt/nxlog/etc.

  5. Get the DN of SPLAT. In SmartDashboard, double-click on Network Objects  Check Point  SPLAT. The properties window will contain a similar DN under Secure Internal Communication such as CN=cp_mgmt,o=splat..ebo9pf.

  6. Retrieve the sic_policy.conf file 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
  7. Edit /opt/nxlog/etc/sic_policy.conf, and add the necessary policy to the [Outbound rules] section.

    sic_policy.conf
    1
    2
    3
    4
    5
    6
    
    [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
  8. Edit /opt/nxlog/etc/lea.conf. The file should contain the following. Make sure to substitute the correct value in place of SPLAT_IP_ADDR and use the correct DN values for opsec_sic_name and lea_server opsec_entity_sic_name.

    lea.conf
    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 command: /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.

Note
The OPSEC_DEBUG_LEVEL environment variable can be set to get debugging information if something goes wrong and there is no output produced. Run OPSEC_DEBUG_LEVEL=1 /opt/nxlog/bin/nx-im-checkpoint --readfromlast FALSE > output.bin and check the debug logs printed to standard error.
Note
The two files sslauthkeys.C and sslsess.C are used during the key-based authentication. These files are stored in the same directory where lea.conf resides. To override this, set the OPSECDIR environment variable.

If the log collection is successful, you can now try running NXLog with the im_checkpoint module.

109.7.1. Configuration

The im_checkpoint module accepts the following directives in addition to the common module directives.

Command

The optional directive specifies the path of the nx-im-checkpoint binary. If not specified, the default is /opt/nxlog/bin/nx-im-checkpoint on Linux.

LEAConfigFile

This optional directive specifies the path of the LEA configuration file. If not specified, the default is /opt/nxlog/etc/lea.conf. This file must be edited in order for the OPSEC LEA connection to work.

LogFile

This can be used to specify the log file to be read. If not specified, it defaults to fw.log. To collect the audit log, use LogFile fw.adtlog which would then be passed to the nx-im-checkpoint binary as --logfile fw.adtlog.

ReadFromLast

This optional boolean directive instructs the module to only read logs which arrived after NXLog was started if the saved position could not be read (for example on first start). When SavePos is TRUE and a previously saved record number could be read, the module will resume reading from this saved record number. If ReadFromLast is FALSE, the module will read all logs from the LEA source. This can result in quite a lot of messages, and is usually not the expected behavior. If this directive is not specified, it defaults to TRUE.

Restart

Restart the nx-im-checkpoint process if it exits. There is a one second delay before it is restarted to avoid a denial-of-service if the process is not behaving. This boolean directive defaults to FALSE.

SavePos

This boolean directive specifies that the last record number should be saved when NXLog exits. The record number will be read from the cache file upon startup. The default is TRUE: the record number is saved if this directive is not specified. Even if SavePos is enabled, it can be explicitly turned off with the global NoCache directive.

109.7.2. Fields

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 $EventTime). 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. The $raw_event field contains the list of all fields and their respective values without any modification to the original LEA field naming.

$raw_event (type: string)

Contains the $EventTime, $Hostname, $Severity, and the original LEA fields in fieldname=value pairs.

$AccountName (type: string)

The user name. Originally called user.

$ApplicationName (type: string)

The application that the user is trying to access. Originally called app_name.

$DestinationIPv4Address (type: ip4addr)

The destination IP address of the connection. Originally called dst.

$DestinationPort (type: integer)

The destination port number. Originally called d_port.

$Direction (type: string)

The direction of the connection with respect to the interface. Can be either inbound or outbound. Originally called i/f_dir.

$EventDuration (type: string)

The duration of the connection. Originally called elapsed.

$EventTime (type: datetime)

The date and time of the event. Originally called time.

$Hostname (type: string)

The IP address or hostname of the device which generated the log. Originally called orig.

$Interface (type: string)

The name of the interface the connection passed through. Originally called i/f_name.

$RecordNumber (type: integer)

The record number which identifies the log entry. Originally called loc.

$Severity (type: string)

The IPS protection severity level setting. Originally called severity. Set to INFO if it was not provided in the logs.

$SourceIPv4Address (type: ip4addr)

The source IP address of the connection. Originally called src.

$SourceName (type: string)

The name of the device which generated the log. Originally called product.

$SourcePort (type: integer)

The source port number of the connection. Originally called s_port.

109.7.3. Examples

Example 543. Converting Check Point LEA Input to JSON

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.

nxlog.conf [Download file]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<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>