About arcsight_guru

arcsight_guru · ‎10-24-2023

Hey, Nice write-up, this is certainly an interesting subject. The whole SSL/TLS implementations seems a bit rushed and indeed not very well documented. Did you try this on a Search Head Cluster? Because it clearly states "TLS host name validation only works for search head clusters that use App Key Value Store." on the docs page you referred to. Also in the server.conf.spec for the [kvstore] serverCert setting, it says: * Only used when Common Criteria is enabled (SPLUNK_COMMON_CRITERIA=1) or FIPS is enabled (i.e. SPLUNK_FIPS=1). My conclusion is that when KV-Store is in stand-alone mode there is no need to verify certificates since there will never be external connections in either direction. When traffic is localhost only I guess Splunk consider it "secure" enough - unless FIPS or CC is enabled. But I find it very annoying that you get a warning at each start-up that the KV-store is not "secure" even though it is stand-alone. I haven't had the opportunity to test this out in a clustered environment yet, but I will for sure let you know if I do. Please let me know if you make any progress in this matter.

arcsight_guru · ‎05-07-2020

I have noticed the same thing, but in the Splunk_TA_windows app. I guess the same logic applies to the Infra as well. There is an EVAL in props.conf that sets the field ta_windows_action based on the value of Status. And if there is no match a default value of "failure" is set. So the meaning of "failure" is basically "failure to set a proper value in this field ". Which, in my opinion, is confusing. It should say "unknown" or just leave it blank. Also the coverage of this field in the logs seems very low so a lot of the events has this field set to failure. This is the EVAL statement in the Windows-app: props.conf EVAL-ta_windows_action = case(upper(Status) == "0XC000006F", "denied", upper(Status) == "0XC0000070", "denied", upper(Status) == "0XC000015B", "denied", upper(Status) == "0XC0000234", "denied", upper(Status) == "0XC0000064", "unknown", upper(Status) == "0XC0000133", "error", upper(Status) == "0XC0000225", "error", 1=1 , "failure") My way forward is to create an override of this and changing the text "failure" to "unknown" instead.

arcsight_guru · ‎02-27-2020

Support confirmed that this is a bug (SPL-182112) for S2S communication between 8.x nodes. In my case I had issues between SH and INX. The recommendation was to set negotiateProtocolLevel=5 to downgrade the protocol version to 7.3. This can be done in the [tcpout] stanza on the sending node (SH), or in the [splunktcp] stanza on the receiving end (INX).

Posts	3
Solutions	1
Karma Given	1
Karma Received	3
Member Since	‎06-27-2019

Online Status	Offline
Date Last Visited	‎10-24-2023 05:57 AM

Re: A writeup: KV store / mongo TLS configuration ...

Re: ta_windows_action

Re: After Upgrade from Splunk 7.2.3 to Splunk 8.0....