NXLog Legacy Documentation

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

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
```
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 The SmartDashboard host must be added as a GUI Client on SPLAT and a user must be configured to be able to log onto SPLAT remotely from SmartDashboard.
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.
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.
Get the DN of SPLAT. In SmartDashboard, double-click 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.
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
```

Edit /opt/nxlog/etc/sic_policy.conf, and add the necessary policy to the [Outbound rules] section.

sic_policy.conf

[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

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.

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.

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.

Configuration

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

Optional 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 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 that arrive after NXLog is started. This directive comes into effect if a saved position is not found, for example on the first start, or when the SavePos directive is FALSE. When the SavePos directive is TRUE and a previously saved record number is found, the module will always resume reading from the saved record number. If ReadFromLast is FALSE, the module will read all logs from the LEA source. This can result in a lot of messages and is usually not the expected behavior. If this directive is not specified, it defaults to TRUE.

The following matrix shows the outcome of this directive in conjunction with the SavePos directive:

ReadFromLast SavePos SavedPosition Outcome

TRUE

Reads events that are logged after NXLog is started.

TRUE

Yes

Reads events from the saved position.

TRUE

FALSE

Reads events that are logged after NXLog is started.

TRUE

FALSE

Yes

Reads events that are logged after NXLog is started.

FALSE

TRUE

Reads all events.

FALSE

TRUE

Yes

Reads events from the saved position.

FALSE

Reads all events.

FALSE

Yes

Reads all events.

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

If this boolean directive is set to TRUE, the last record number will be saved when NXLog exits. The record number will be read from the cache file upon startup. The default is TRUE, the record number will be saved if this directive is not specified. This directive affects the outcome of the ReadFromLast directive. The SavePos directive can be overridden by the global NoCache directive.

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 that 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: ipaddr): 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: ipaddr): 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.

Examples

Example 1. 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

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