Archive

OPSEC lea_loggrabber connects but returns nothing?

Path Finder

We have two Splunk servers and two Check Point R71 management servers. One of the management servers is the standby management, but both act as log servers, as validated using 'tracker'.

Our first Splunk box grabs logs from the primary CPM, no problems.

I'm trying to configure the other Splunk box to grab logs from the secondary CPM. fwopsec.conf is configured appropriately, the opsec key is pulled down to the Splunk box, and lealoggrabber is able to connect to the CPM without errors. However, it just doesn't get any logs. After opsecmainloop gets called, there never is any callback to LeaRecordHandler, it just exits. LeaEndHandler things that it's at line 0 in the log (as per leagetrecordpos) and writes that out to lealogrecnum.cache.

Has anyone experienced this sort of issue where lea_loggrabber connects properly, but thinks the log is empty even through other methods of looking tell us there is something in it?

Tags (2)

Splunk Employee
Splunk Employee

I recently came across a similar problem today only to find out my firewall ACL was rejecting access to port 18184 to the Checkpoint manager from the splunk forwarder. As a quick test, try using netcat to ensure the checkpoint authport is indeed accessible from the splunk server.
'nc -z IP 18184'
It took me a while to figure it out since the lea
loggrabber binary very much appeared to connect and wrote the cache file. I would expect it to error if communication was offline.

Splunk Employee
Splunk Employee

in addition, include OPSEC debugging on the lea client:

OPSECDEBUGLEVEL=3; export OPSECDEBUGLEVEL

./lea_loggrabber --lea-config-file ./lea.conf

0 Karma

Splunk Employee
Splunk Employee

Can you post a capture of the network traffic using (tcpdump -s0 -xX port 18184) and include a copy of your lea.conf ??

0 Karma

Path Finder

Thanks, but in our case that's not the problem. tcpdump on the splunk host clearly shows the TCP connection, including 3-way handshake and 20 or so packets of psh - ack back and forth before a proper close. Also, the firewall logs mark the connection as allowed.

0 Karma