Community:Configure OPSEC LEA input
From Splunk Wiki
This package contains all the necessary files to create an OPSEC LEA bundle to drop into Splunk 3.3 or later. It functions on Solaris Sparc and Linux Intel.
The following instructions describe how to pull logs from the Checkpoint firewall via an SSL connection.
NOTE: The default Applications come with pre-compiled binaries. If you choose to use these binaries, you would still need to generate the opsec.p12, sslauthkeys.C, sslsess.C files (refer to the section Checkpoint Firewall Modification) and place them in the bin dir.
First, follow instructions to set up CheckPoint and populate the lea.conf Then, follow instructions under INSTALLATION.
lea-loggrabber-splunk-linux.tar.gz packages contain all the necessary files to create an OPSEC LEA application to drop into Splunk 3.3 or later. It functions on Linux and on Solaris.
The instructions below are for a Solaris box. Instructions for a Linux installation are identical. Replace Solaris with Linux.
Note: If you are installing it on 64-bit Debian linux you will also need the ia32 libs (run 'apt-get install ia32-libs') in addition to the other instructions.
1. Checkpoint Firewall Modification
If you are comfortable with Checkpoint configuration, you may skip over this section.
Enabling a LEA Server
The LEA client must communicate with a LEA Server. To set one up:
1. Log into the box running the Checkpoint Management Server.
2. Edit $FWDIR/conf/fwopsec.conf and add the following lines to enable the LEA service:
lea_server auth_port 18184 lea_server auth_type ssl_opsec
3. Restart the FW1 engine using the following commands:
Rule Set Adjustments
For this to work you must enable an FW1_ica_pull (accept) rule in the main Checkpoint configuration. In addition, for LEA to work you must add a rule to accept FW1_lea traffic.
Create OPSEC Application
You must add a LEA OPSEC server to the Checkpoint configuration.
1. In the CheckPoint Smart Dashboard, click on Manage -> Servers and OPSEC applications.
2. Add an entry for SplunkLEA (vendor: user-defined, make sure to click LEA
in client entities).
[host = <Splunk/client>]
3. Click on Communication in the LEA configuration screen and enter a one time password for the activation key; it will respond with a DN. You will need this DN later in the LEA.conf on the Splunk server. The DN should be the opsec_sic_name in the LEA.conf.
[NB: R75 will not respond with a DN but the DN is viewable after saving. Navigate to the opsec application properties page after saving to see it.]
Retrieve OPSEC app certificate
Use the following utility located in $SPLUNK_HOME/etc/apps/lea-loggrabber-splunk/opsec-tools to extract the certificate in order to communicate with the LEA server:
cd opsec-tools/<solaris2> or opsec-tools/<linux22> ./opsec_pull_cert -h <ip of checkpoint box> -n <object> -p <sic one-time password> (i.e. opsec_pull_cert -h 10.1.1.96 -n SplunkLEA -p <password>)
This will produce a file in the current directory called opsec.p12.
Place that file in the lea-bundle bin directory.
Special Considerations for Provider-1: P1 allows separation of duties with respect to management, logging, and enforcement; CMA's manage policies, and CLM's handle logging. While it is possible to run both on the same system, it's entirely likely that they could be split off. If that is your case, make sure you use the CMA IP address in the above step, not the CLM.
NB: You may encounter different acronyms per updated Checkpoint naming standards:
CMA = DMS
CLM = DLS
Create / Retrieve authentication key
(on FW1 machine)
For an SSL-based connection:
fw putkey -opsec -ssl <Destination IP address of the solaris box>
Enter secret key: ********* Again secret key: *********
Note down the secret key for retrieving the authentication key on the Solaris box
(on Splunk Forwarder)
To retrieve this key, on the Solaris or Linux box:
cd opsec-tools/<solaris2> or cd opsec-tools/<linux22> opsec_putkey -ssl -port 18184 <Source IP address of checkpoint box>
You should see something like:
Please enter secret key: ***** Please enter secret key again: ***** FW: Received new control security key from <Source IP address of checkpoint box>
Authentication with <Source IP address of checkpoint box> initialized successfully
This will generate the files: sslauthkeys.C and sslsess.C
2. Splunk Application Configuration
LEA Client configuration
1. Edit the $SPLUNK_HOME/etc/apps/lea-loggrabber-splunk/default/lea.conf file. You can
2. Ensure proper values are populated. It should look like:
opsec_sic_name "CN=SplunkLEA,O=qa-checkpoint..emfsep" //DN obtained from "Create OPSEC Application" step opsec_sslca_file </path/to/opsec.p12> lea_server ip <ip of FW1 box> lea_server auth_port 18184 lea_server auth_type ssl_opsec lea_server opsec_entity_sic_name "cn=cp_mgmt,o=qa-checkpoint..emfsep" //The opsec_entity_sic_name can be retrieved from double clicking on the main Checkpoint object
Applying the files and installation
Copy the sslauthkeys.C , sslsess.C and opsec.p12 files into the bin dir of the bundle. Copy the lea-loggrabber-splunk directory to your $SPLUNK_HOME/etc/apps directory. The directory $SPLUNK_HOME/etc/apps/lea-loggrabber-splunk should exist when this is done.
There are three relevant configuration files in the lea-bundle directory:
- inputs.conf is a Splunk configuration file. See the Splunk documentation for information on how to modify this configuration. The default configuration will place any information from your Checkpoint target in the main index with sourcetype "opsec".
- props.conf is a Splunk configuration file. It is used to recognize the time format used by the checkpoint firewall logs. Read the Splunk documentation for further details.
- lea.conf is the file containing connection information between the loggrabber agent and the Checkpoint target. The default configuration contains values for unauthenticated, clear sessions between the Loggrabber agent and the Checkpoint target. Documentation for configuring a more secure channel on loggrabber agent's side is available in the doc directory. Substantial configuration is required on the Checkpoint side. Consult your Checkpoint documentation for that information.
To communicate with more than one Checkpoint target create multiple instances of the bundle in $SPLUNK_HOME/etc/apps. Finally, start splunk.
Command Line Options
You can start the lea_loggrabber binary by itself as root to validate that it is working properly. To do this, login to the system and use SUDO or SU to become root. Run the lea_loggrabber binary using command line options:
- --lea-config-file <full file path and name>
This is the only required command line argument. The full file path and file name must be supplied or the program aborts immediately.
This command shows the program execution. On my current system it prints out debugging information: opsec environment initialized successfully...opsec client, server entities initialized successfully...start handler called ...reading from start of log...end handler called ...
be forwarned, the debug command does not print line feeds!
NB: The --debug flag will sometimes show that a successful communication has occurred when a network connection is established though application connectivity has failed. In these cases (where no Checkpoint logs are returned) it may be beneficial to install a loggrabber with more verbose debug output (i.e. http://sourceforge.net/projects/fw1-loggrabber/files/fw1-loggrabber/). If using that package, for example, update its fw1-loggrabber.conf with a DEBUG_LEVEL="3" to troubleshoot challenges with configuration options. Once the challenge has been identified and remediated - map its known-good configuration to the lea_loggrabber.
There is an article on Check Point's site that details "How to configure a LEA client connection to Provider-1 using an auth_type method of ssl_opsec" . It is listed as being for R60 and R70 but has led to undocumented success on R75 regarding SSL-LES when multiple domain log servers are in play.
In some environments, lea.conf may need to have this setting (based on Check Point side $CPDIR/conf/sic_policy.conf)
lea_server auth_type sslca
vs. this setting
lea_server auth_type ssl_opsec