Splunk Add-on for Check Point OPSEC LEA 4.0: Why are we getting "111 - SIC Error for lea: Peer sent wrong DN..."?

[edwardrose]

We are setting the Splunk Add-on for Check Point OPSEC LEA 4.0 and are getting the following error

SIC ERROR 111 - SIC Error for lea: Peer sent wrong DN: cn=cp_mgmt,o=wvdpcscmgr.wv.mentorg.com.r65zch

I am confused as to where it is getting the wrong CN? I have checked everywhere and it is not specified in any of the .conf files.

ebs-sys-aruba-01:/opt/splunk/etc/apps/Splunk_TA_checkpoint-opseclea # grep -r -l "cp_mgmt" .
./samples/opsec.sample
./samples/opsec_threat_emulation.sample
./samples/opsec_audit.sample
./samples/opsec_anti_malware.sample
./bin/ta_opseclea_rh_cert_original
ebs-sys-aruba-01:/opt/splunk/etc/apps/Splunk_TA_checkpoint-opseclea #

So where is the script finding the incorrect CN?

2016-06-29 18:06:15,620 +0000 log_level=ERROR, pid=27418, tid=Thread-9, file=ta_opseclea_data_collector.py, func_name=get_logs, code_line_no=62 | [input_name="internal_fwe" connection="wvdpclogsvr" data="fw"]log_level=0 file:lea_loggrabber.cpp func_name:check_session_end_reason code_line_no:2159 :Session end reason: SIC ERROR 111 - SIC Error for lea: Peer sent wrong DN: cn=cp_mgmt,o=wvdpcscmgr.wv.mentorg.com.r65zch

[bramuno]

this appears to be a bug in Checkpoint's app or their log server software. I did the above and followed everything correctly according to the documentation. The app pulled the certificate and no errors. But the data was not showing in the indexers. I changed the addon to debug logging and tailed the addon log and found the SIC error. It showed the SIC name being sent by the CP server (log server) was not what the app had received during the certificate pull.

2018-05-03 19:51:11,159 +0000 log_level=ERROR, pid=7122, tid=Thread-133, file=ta_opseclea_data_collector.py, func_name=get_logs, code_line_no=75 | [input_name="CMA04-input" connection="xxxx" data="non_audit"]log_level=0 file:lea_loggrabber.cpp func_name:check_session_end_reason code_line_no:1056 :ERROR: Session end reason: SIC ERROR 111 - SIC Error for lea: Peer sent wrong DN: CN=xxxxx,O=xxxxxxxxxxxxxxxx..xxx

So I edited opseclea_connection.conf and changed opsec_entity_sic_name to match the DN text that was found in the debug log. Restarted splunk and the logs started showing in the indexers.

This seems like a problem with the CP server in relation to the splunk addon as it provides the app with the wrong DN.

[kishor_pinjark1]

It worked for me.

[kishor_pinjark1]

Thank you.

[mreynov_splunk]

Your config looks right, but the fact that it tries to connect to cn=cp_mgmt means the code thinks you are working with Primary Management Server vs a dedicated server. See section 2 for more detail: http://docs.splunk.com/Documentation/AddOns/released/OPSEC-LEA/Troubleshoot

Did you change Log Server Type at any point?

[edwardrose]

Nope original setup and configuration has been dedicated server.

[mreynov_splunk]

I confirmed CN setting logic in the addon based on the server type and all looks right there. We only do it once when pulling the cert. Your input is correct based on that logic. Upon further research, this may be an issue on the OPSEC side: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Do we know that the OPSEC server is thinking of itself as dedicated? Might it be configured as primary?

[mreynov_splunk]

This error means that the addon does not have the certificate which needs to be downloaded from OPSEC side in order to establish secure communication.
In OPSEC LEA addon v 4 this should happen automatically as part of the install.

Did you upgrade from an older version?

Did you follow the installation steps here: http://docs.splunk.com/Documentation/AddOns/released/OPSEC-LEA/Setup2?

Note: upgrade will not work, addon needs to be installed fresh

[edwardrose]

This is a brand new install of the TA and new configuration. I see the certificate int the certs directory. So it did down the cert.

[jamesarmitage · Accepted solution]

Is the DN for for your opsec_entity_sic_name actually cn=cp_mgmt,o=wvdpcscmgr.wv.mentorg.com.r65zch? It may in fact be something like cn=cp_mgmt_YOURSERVERHOSTNAME,o=wvdpcscmgr.wv.mentorg.com.r65zch

Take a look at chubbybunny's response in this thread:

https://answers.splunk.com/answers/153982/why-am-i-getting-connection-errors-after-configuring-add-o...

For how to use GuiDBEdit to get the exact sic name you need.

In terms of where the script is finding the sic name, once a connection is set up you should find the configuration file in /opt/splunk/etc/apps/Splunk_TA_checkpoint-opseclea/local/opseclea_connection.conf. Before a connection has been created the value is only in the input setup modal dialog inside the TA's web interface and not written to the TA's /local directory.

[edwardrose]

This is my opseclea_connection.conf.

[wvdpclogsvr]
cert_name = wvdpclogsvr_2107467814.p12
fw_version = R77
lea_app_name = SplunkLEA
lea_object_name = wvdpclogsvr
lea_server_auth_port = 18184
lea_server_auth_type = sslca
lea_server_ip = 147.34.104.26
lea_server_type = dedicated
opsec_entity_sic_name = CN=wvdpclogsvr,O=wvdpcscmgr.wv.mentorg.com.r65zch
opsec_sic_name = CN=SplunkLEA,O=wvdpcscmgr.wv.mentorg.com.r65zch
disabled = 0

[jamesarmitage]

Did you validate that the opsec_entity_sic_name is correct via GuiDBEdit? From what you've posted, I would expect it to look more like cn=cp_mgmt_wvdpclogsvr,O=wvdpcscmgr.wv.mentorg.com.r65zch

[edwardrose]

So my checkpoint admin went and ran through the validation to get the correct opsec_entity_sic_name and low and behold it is working now.

Thanks for all the support.

[mreynov_splunk]

yay, great news! can you just clarify what validation was done and did you have to update your addon configs?

[mreynov_splunk]

Let's be careful with these assumptions, cn name depends on type of server. Please note, the addon was revamped for 4.0, so assumptions from previous versions may be dangerous.

[jamesarmitage]

Sure thing. I'm using my config file from a fresh setup of the 4.0 TA as a reference, but that's why I asked edwardrose to validate the via GuiDBEdit.

I believe your comment below about the lea_server_type is probably the issue here, I had missed that previously.