Splunk’ing Check Point
By: Bill Mathews, Steve McMaster, and Patrick Sayler

Alright, so you already know how great Splunk and Check Point are already. But what if we told you that they could work together? That’s right, after hundreds of unanswered phone calls to CERN “politely requesting” tours of the LHC (so we could sneak in our own Gordan Freeman [Toby]), our engineers here at Hurricane Labs have devised a way to combine these two products without just stapling invoices together. Who needs real scientists anyway? Certainly not this lab.

You see, Splunk is pretty much magic. You can search all your logs and make cool graphs…we could go on for days praising Splunk. Now, wouldn’t it be nice to see your firewall logs in Splunk too? Graphing and keeping track of those drops and policy pushes would be swell. And being able to look at all your logs in one place is probably the most appealing aspect of this venture. Unfortunately, Check Point doesn’t normally keep these items tracked in syslog. But with our help, you’ll be Splunking your firewall in no time.

At this point you’re thinking to yourself, “Self, isn’t there already a way to connect to Check Point to get logs? I’m sure there is, it’s call LEA (Log Export API).” You would be right, also you should see someone about talking to yourself like that. LEA has some drawbacks, most notably it seems you cannot have more than one LEA connection. That might be a deal breaker right there if you want to use one of the various Check Point specific log analyzers out there (including Check Point’s) in conjunction with something like Splunk. There are also unsubstantiated rumors that LEA doesn’t support 64 bit source operating systems so well. Those are the main reasons we came up with hlcp2syslog. It’s totally free to use and open source. Got any patches, compliments or complaints? Send them to us (blog@hurricanelabs.com) and we’ll make sure you get credit or blame, whichever is the most appropriate. Enjoy!

NOTE: Installing 3rd party tools into SPLAT will cause it to be unsupported by Check Point. Hurricane Labs is not responsible for any damages incurred by this process.

1) Download THIS. It includes the necessary scripts and other assorted files you’ll need to start sending your Check Point logs into syslog.

2) Place the shell scripts into /usr/local/bin. If /usr/local/bin does not exist, it can be created as follows:

mkdir -p /usr/local/bin
chmod 0755 /usr/local /usr/local/bin

3) Take the included rc.local.user and place it in /etc/rc.d/. If /etc/rc.d/rc.local.user already exists, simply remove the shebang line from the version in this distribution and append the rest of the contents to the existing file. If only audit logging is needed, comment out the log_fw.sh script from rc.local.user.

4a) Append the following to /etc/syslog.conf. Once you’re finished restart syslogd by entering /etc/init.d/syslog restart

local0.crit        @YOURLOGGINGSERVER.com
local1.crit        @YOURLOGGINGSERVER.com

4b) If TCP syslog will be used, install the RPMs in the syslog-ng directory. Place the provided syslog-ng.conf into /etc/.

Run the following to make syslog-ng start at boot:
chkconfig –add syslog-ng

You can start syslog-ng by running:
/etc/init.d/syslog-ng start

Now verify the socket exists:
ls -l /dev/log-ng

5) Execute the logging watchdog scripts from rc.local.user. If you’ll only be audit logging, simply start log_audit.sh.

6) Verify syslog is leaving the device by using tcpdump. If only audit logging is being used, have someone login to the GUI to verify that logs are flowing correctly.

Easy enough, right? Now obviously you may need to make a few modifications for your own systems. But this should at least get you on the right track. If you’re a customer and need help simply open a ticket, not a customer? Send us an email at blog@hurricanelabs.com and we’ll try to help on a best effort basis.