- OS Support
- Enterprise Edition Reference Manual
- 127. Man Pages
- 128. Configuration
- 129. Language
- 130. Extension Modules
- 131. Input Modules
- 131.1. Process Accounting (im_acct)
- 131.2. AIX Auditing (im_aixaudit)
- 131.3. Azure (im_azure)
- 131.4. Batched Compression (im_batchcompress)
- 131.5. Basic Security Module Auditing (im_bsm)
- 131.6. Check Point OPSEC LEA (im_checkpoint)
- 131.7. DBI (im_dbi)
- 131.8. Event Tracing for Windows (im_etw)
- 131.9. External Programs (im_exec)
- 131.10. Files (im_file)
- 131.11. File Integrity Monitoring (im_fim)
- 131.12. Go (im_go)
- 131.13. HTTP(s) (im_http)
- 131.14. Internal (im_internal)
- 131.15. Java (im_java)
- 131.16. Kafka (im_kafka)
- 131.17. Kernel (im_kernel)
- 131.18. Linux Audit System (im_linuxaudit)
- 131.19. macOS ULS (im_maculs)
- 131.20. Mark (im_mark)
- 131.21. EventLog for Windows XP/2000/2003 (im_mseventlog)
- 131.22. EventLog for Windows 2008/Vista and Later (im_msvistalog)
- 131.23. Null (im_null)
- 131.24. ODBC (im_odbc)
- 131.25. Packet Capture (im_pcap)
- 131.26. Perl (im_perl)
- 131.27. Named Pipes (im_pipe)
- 131.28. Python (im_python)
- 131.29. Redis (im_redis)
- 131.30. Windows Registry Monitoring (im_regmon)
- 131.31. Ruby (im_ruby)
- 131.32. TLS/SSL (im_ssl)
- 131.33. Systemd (im_systemd)
- 131.34. TCP (im_tcp)
- 131.35. Test Generator (im_testgen)
- 131.36. UDP (im_udp)
- 131.37. Unix Domain Sockets (im_uds)
- 131.38. Windows Performance Counters (im_winperfcount)
- 131.39. Windows Event Collector (im_wseventing)
- 131.40. ZeroMQ (im_zmq)
- 132. Processor Modules
- 133. Output Modules
- NXLog Manager
- NXLog Add-Ons
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
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
/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
nx-im-checkpointbinary. If not specified, the default is
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.
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.adtlogwhich would then be passed to the
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.
nx-im-checkpointprocess 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.
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.
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
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
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.
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>