I have a question regarding the monitoring of several Checkpoint firewalls using the LEA-loggrabber add-on.
I must monitor 3 Checkpoints FW. The FW are managed with a Checkpoint Smartcenter.
I have setup LEA-loggrabber for one of the FW and it works fine. But as I am trying to monitor the 2 others, I wonder if I only need to add several lines in the lea.conf file (add their IP, their opsec_entity_sic_name, etc) or if I need to create a new data input into Splunk (kind of "duplicate the LEA-loggrabber add-on") and restart all the configuration from the beginning?
And as I'm using a SmartCenter, some of the steps described in "OPSEC LEA for Checkpoint" can't be done one more time, as files generated from those steps are unique (e.g. sslauthkeys.C and sslsess.C): it would break the functional node I think.
Does anyone already setup this?
Note: You need multiple apps renamed if you cant get all of the logs from one place. If you have multiple apps you must either fully qualify the script call or change the name of the script or you will get duplicate stanzas in inputs.conf and only one instance of the script will be called.
Updated Instruction Set for Provider-1:
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 Check Point Management Server via an SSLCA connection.
NOTE: The default application comes with pre-compiled binaries. If you choose to use these binaries, you would still need to generate the opsec.p12 file (refer to the section Check Point Modification) and place them in the bin dir.
First, follow instructions to set up Check Point and populate the lea.conf Then, follow instructions under INSTALLATION.
The lea-loggrabber-splunk-solaris-sparc.tar.gz and 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 willalso need the ia32 libs (run 'apt-get install ia32-libs') in addition to the other instructions.
3) Check Point Configuration
If you are comfortable with Check Point configuration, you may skip over this section.
a) Rule Set Adjustments
Open the CMA (Customer Management Add-on) SmartDashboard from which you want to pull logs. The following changes do not apply to the MDS (Multi-Domain Server).
In the Check Point security policy create security policy rules to allow the services FW1icapull and FW1_lea.
b) Create OPSEC Application
Next, create an OPSEC Application object on the CMA for the Splunk LEA client to communicate with.
In the Check Point SmartDashboard, click on Manage -> Servers and OPSEC applications.
Add a new object of the "OPSEC Application" type. Pick a name, set "vendor" to "user-defined", enable LEA in client entities, set "host" to the host object corresponding to the server where the Splunk LEA client will run (If that host object doesn't exist, create it using the "New" button).
Click on Communication in the LEA configuration screen and enter a one time password for the activation key. This will create a DN for the Splunk LEA server object. You will need this DN later to specify the opsecsicname in the lea.conf file for the Splunk LEA client. Click "Initialize" : The trust status should be "Initialized but trust not established".
Install the security policy or if this is a stand-alone Check Point Management server install the database to apply the above changes.
c) Retrieve OPSEC app certificate
On the Splunk host use the following utility located in $SPLUNK_HOME/etc/apps/lea-loggrabber-splunk/opsec-tools to retrieve the certificate from the LEA server in order to establish trust with it:
cd opsec-tools/ or opsec-tools/
./opsecpullcert -h -n -p
If the certificate pull is successful, this will create a file in the current directory called opsec.p12 and it will display the full entity SIC name of the LEA server object.
[root]# ./opsecpullcert -h 172.16.12.100 -n SplunkLEA2 -p lea The full entity sic name is: CN=SplunkLEA2,O=proManagementServer.support.splunk.com.xka37i Certificate was created successfully and written to "opsec.p12".
The trust state for the LEA server object communication status in Check Point SmartDashboard should now be "Trust established". Move the opsec.p12 file to the lea-bundle bin directory.
[root]# mv opsec.p12 ../../bin/
4) Splunk OPSEC/LEA App Configuration
a) LEA Client configuration
On the Splunk host edit the $SPLUNK_HOME/etc/apps/lea-loggrabber-splunk/default/lea.conf file.
Ensure configuration keys are properly populated. Example:
opsecsicname "CN=SplunkLEA2,O=proManagementServer.support.splunk.com.xka37i" //DN obtained from "Create OPSEC Application" step, also displayed as "full entity sic name" by the opsecpullcert command. opsecsslcafile leaserver ip leaserver authport 18184 leaserver authtype sslca leaserver opsecentitysicname "cn=cpmgmt,o=proManagementServer.support.splunk.com.xka37i" //Get the opsecentitysicname by running GuiDBedit.exe to connect to the CMA , search for sicname and get the value from the "sicname" field for the CMA's network object.
Note : More detailed instructions to retrieve opsecentitysicname can be found in Check Point SecureKnowledge solution sk61833 shown below.
· The SIC field shows the Certificate State: "Trust Established rather than the DN".
The latest versions of SmartDashboard are enhanced to show the SIC communication state.
This Solutios explains how to find the SIC DN (Distinguished Name) of the Check Point module to set up the OPSEC client configuration, when using third party applications that use Check Point OPSEC APIs.
When the SIC DN of the Check Point module is not available in SmartDashboard, use GuiDBedit:
Expand the 'Network Objects' branch.
Select the 'network_objects' table.
Select the desired object to. Either scroll down the list of Field Names to find the 'sicname' field near the end of the list or do a search for the 'sicname' field.
Enter the value found for 'sicname' in the OPSEC client configuration. For example; CN=cpmgmt_MyHaMgmt,O=MyMgmtServer..n55nc3 For more information on the use of GuiDBedit see sk13009.
To communicate with more than one CheckPoint target create multiple instances of the app bundle in $SPLUNK_HOME/etc/apps with different names and use fully qualified paths to the binaries that are called from inputs.conf. The stanzas in inputs.conf will merge on Splunk startup and one one wins if they all have the same stanza names.
Finally, start splunk.
b) Command Line Test
You can start the lealoggrabber binary manually to verify the configuration. Run the lealoggrabber binary using command line options:
--lea-config-file This is the only required command line argument. The full file path and file name must be supplied or the program aborts immediately.
[root]# ./lea_loggrabber --lea-config-file ../default/lea.conf
loc=1 filename=fw.log fileid=1320803565 time= 8Nov2011 17:52:45 action=keyinst orig=172.16.12.200 i/fdir=inbound i/fname=daemon hasaccounting=0 product=VPN-1 & FireWall-1 InternalCA:=started
loc=2 filename=fw.log fileid=1320803565 time= 9Nov2011 14:58:47 action=keyinst orig=172.16.12.200 i/fdir=inbound i/fname=daemon hasaccounting=0 product=VPN-1 & FireWall-1 InternalCA:=Certificate initialized serialnum:=93475 dn:=CN=splunkLEA1,O=proManagementServer.support.splunk.com.xka37i
loc=3 filename=fw.log fileid=1320803565 time= 9Nov2011 15:03:04 action=keyinst orig=proManagementServer i/fdir=inbound i/fname=daemon hasaccounting=0 product=VPN-1 & FireWall-1 InternalCA:=Initiated certificate is now valid serialnum:=93475 dn:=CN=splunkLEA1,O=proManagementServer.support.splunk.com.xka37i