Hi @dwaddle  and others Im stuck with couple of questions and this thread is almost close to answer it.  Im actually working on securing communication between Splunk nodes. I have 4 forwarders sending data to 3 indexers which is in cluster . I have a 1 deployment server to manage  forwarders . and have 1 cluster master: Question 1 (securing forwarder->indexers): From the Splunk documentation and this thread i understand we need to have certificates for both forwarders and indexers. But don't understand why it is required on forwarders as well? Having certificates only in indexers does the job right? . Is it because of Splunk configuration or code demands to have it in forwarders as well? Question 2 (Cluster Master->indexers) : Since we have already in production , is there any impact or precautions that needs to be taken while making communication secured  between CM and indexers. please share any link to document on the configuration .    Thanks in Advance ... View more

Thank you! This worked fine. The resource field is cleand up, and the pipes removed. And the URl still works if needed for some reason. ... View more

Thanks that worked well for me! ... View more

Thank you! For some reason i didn't come across your answer in my searches. ... View more

We finally found a workaround. The loggrabber script never attempts to connect to port 18264 on the Checkpoint Server, but an strace revealed that it tries to open the CRL locally on the Splunk server from /etc/fw/conf/ICA.crl We configured a cron script that pulls an updated CRL list to this path. It now works. We are still stumbled when it comes to what changed on the Checkpoint server since this used to work before without the workaround. ... View more

I have the same problem with an old linux box. have you managed to fix it somehow? ... View more

Thank you. ... View more

I wish I had thought to search for this before I tracked this bug down and patched it myself 🙂 ... View more

You can monitor from the heavy forwarder side, as well as from the management server. In my case, I have a heavy forwarder on Red Hat, and a secondary management server that I'm connecting to for log retrieval. I open a screen session, and split the view into 2 panes. On the HF: watch -n 1 "ps aux | grep -i opsec" On the management server: watch -n 1 "ps aux | grep -i lea" From there I can see the number of lea_loggrabber sessions running from the HF, and the number of lea_session instances on the Check Point box. On a related note, I'm also having trouble retrieving data. It seems to circle around pulling SmartDefense data, or if I use the Non-Audit setting (which also includes SmartDefense). I'm still testing, but have found that I need to disable all inputs on the HF, restart the splunk process and reboot the management server to get to a clean state to work from. Hope that helps. ... View more

Are you using Splunk_TA_opseclea_linux22 (aka version 3.1) or Splunk_TA_checkpoint-opseclea (aka version 4.0)? If you're using 3.1, are you passing unique values for configentity? e.g.: audit, vpn, ips, etc? You might also be pulling historical data, as well as current. If that's the case then the data volume should settle down after your initial import. ... View more

You need to have a ssl_framework index, or override the destination of the logged events by creating your own indexes.conf and savedsearches.conf in the /local directory of the app. You can manually trigger a report with the command: /opt/splunk/bin/splunk cmd python /opt/splunk/etc/apps/SOCPrimeSSLFramework/bin/ssl-framework-report.py -c /opt/splunk/etc/apps/SOCPrimeSSLFramework/default/sslframework.conf You can monitor the reporting progress by following the app's own logfile: tail -f /opt/splunk/etc/apps/SOCPrimeSSLFramework/bin/ssl-framework-report.log It seems to take 2-3 minutes per server for the report to be generated. After the scan is finished then an output file is written to /opt/splunk/etc/apps/SOCPrimeSSLFramework/reports . I found that after the initial install, the app didn't schedule a scan until around 12 hours later, so the dashboard was blank unless I manually ran a report using the command above. Application error events are in the splunkd.log, you can monitor for them by watching: tail -f /opt/splunk/var/log/splunk/splunkd.log | grep SOCPrimeSSLFramework You can also do this through the Splunk search interface, by using the search index=_internal SOCPrimeSSLFramework and then filtering your results as needed. ... View more

Um, i don't really have much trouble with using spath? The ones i need to work on if i recall correctly are the Extended Attributes. What exactly do you need? I might have to check if i pushed the current version with the sample dashboards and lookups etc. update: After reviewing i saw that i added a macro to split those fields like the EA: eval $field$=replace($field$,"u\'","\"") | eval $field$=replace($field$,"\'","\"") | spath input=$field$ | fields - $field$ *.inheritance_source._ref| rename *.value AS * ... View more

I see that it should be working, but it's not. The field isn't extracting. http://docs.splunk.com/Documentation/Splunk/6.2.0/SearchReference/spath <action_info xmlns="http://schemas.microsoft.com/sqlserver/2008/sqlaudit_data"> <pooled_connection>1</pooled_connection> <client_options>0x28000020</client_options> <client_options1>0x0001f438</client_options1> <connect_options>0x00000000</connect_options> <packet_data_size>8000</packet_data_size> <address>local machine</address> <is_dac>0</is_dac> </action_info>", file_name="M:\AuditFiles\Audit_Logins_Fail_Success_Log_42C90784-3268-445A-94B3-4CD7D392B997_0_130934732017490000.sqlaudit", audit_file_offset=223147008, user_defined_event_id=0 But the action_info_address field isn't extracted for some reason. ... View more

I've fixed it. You have to change all the regex in transform.conf from: \s(dhcpd):\s to: \sdhcpd(:\s|[\d+]:\s) and change the following line in: eventtypes.conf from: [dhcpd_event] search = process=dhcpd to: [dhcpd_event] search = dhcpd ... View more

The --strip-components flag is appropriate for CentOS / RHEL tar. Check the manpage for your distro to determine the proper syntax. bbingham, thank you. This tip saved me a fair bit of frustration upgrading two instances installed on the same server. ... View more