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.
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 Agent 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 Agent.
-
Enable the LEA service on SPLAT. Log in to SPLAT, enter
expert
mode, and runvi $FWDIR/conf/fwopsec.conf
. Make sure the file contains the following lines. Then restart the firewall with thecprestart
command (orcpstop
andcpstart
).fwopsec.conflea_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. 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 Agent 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 Agent log collector
or something similar. - Host
-
Click 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 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 ourlea.conf
file as the opsec_sic_name parameter.
-
Retrieve the OPSEC application certificate. From the NXLog Agent 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 ofSPLAT_IP_ADDR
andACTIVATION_KEY
. If the command is successful, the certificate fileopsec.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 ofSPLAT_IP_ADDR
and use the correct DN values foropsec_sic_name
andlea_server opsec_entity_sic_name
.lea.conflea_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 Agent’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 Agent with the im_checkpoint module.
Configuration
The im_checkpoint module accepts the following directives in addition to the common module directives.
Optional 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 that arrive after NXLog Agent 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 The following matrix shows the outcome of this directive in conjunction with the SavePos directive:
|
|||||||||||||||||||||||||||||||||||||
Restart the |
|||||||||||||||||||||||||||||||||||||
If this boolean directive is set to |
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 Agent 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
oroutbound
. 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
This configuration instructs NXLog Agent 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>