According to the Splunk documentation the recommendation is to use the default certificates provided by Splunk for inter-Splunk communication. <a href="http://docs.splunk.com/Documentation/Splunk/6.2.2/Security/AboutsecuringyourSplunkconfigurationwithS... About Splunk SSL Configuration</a>. However, when looking at the certificates the key length is 1024bit and the signature algorithm is SHA1.
One option is to create and deploy my own certificates with the appropriate security requirements.
Can Splunk generate it's own certificates with a longer key length and at least a signature algorithm of SHA 256?
In my opinion, this is just a bad recommendation in the documentation. The default-provided certificates & configuration give you no practical authentication strength, because the certificates are not verified.
The default-generated certificates and associated configuration settings should be considered "appropriate for a test / proof-of-concept / pilot, but completely inadequate for production"
Using Deployment Server as an example of inter-Splunk communication - do you REALLY want your forwarders to trust ANY server claiming to be the deployment server? The default configuration puts you in a position where any number of attacks (arp poisioning, DNS games, etc) could cause a forwarder to trust a rogue deployment server. The person who controls the content of the apps on a deployment server effectively has permissions equal to the user running Splunk on each deployment client. Are you sure this is a good place for weak SSL configs?
Generate your own certs, off of your private CA, and enable (at the barest minimums) certificate verification and common name checking. In my opinion, asking Splunk to make the default certs "seem stronger" with a larger key length and newer hash algorithm is a step in the wrong direction. The default certs should stand out like sore thumbs in a production install, so that they are replaced with something appropriate.
In my opinion, this is just a bad recommendation in the documentation. The default-provided certificates & configuration give you no practical authentication strength, because the certificates are not verified.
The default-generated certificates and associated configuration settings should be considered "appropriate for a test / proof-of-concept / pilot, but completely inadequate for production"
Using Deployment Server as an example of inter-Splunk communication - do you REALLY want your forwarders to trust ANY server claiming to be the deployment server? The default configuration puts you in a position where any number of attacks (arp poisioning, DNS games, etc) could cause a forwarder to trust a rogue deployment server. The person who controls the content of the apps on a deployment server effectively has permissions equal to the user running Splunk on each deployment client. Are you sure this is a good place for weak SSL configs?
Generate your own certs, off of your private CA, and enable (at the barest minimums) certificate verification and common name checking. In my opinion, asking Splunk to make the default certs "seem stronger" with a larger key length and newer hash algorithm is a step in the wrong direction. The default certs should stand out like sore thumbs in a production install, so that they are replaced with something appropriate.
Do you have a blog post or article that discusses Security best practices like this? @dwaddle
Hello dear Duane,
thank you for your presentation at https://conf.splunk.com/session/2015/conf2015_DWaddle_DefensePointSecurity_deploying_SplunkSSLBestPr...
Do you confirm this is fully supported by Splunk and therefore should be documented in official documentation?
Thanks.
Best regards.
Hi! I can't speak for splunk on this topic as I'm not employed by them. The fact that they were willing to let us (@starcher and I) present on this topic at their conference is a vote of confidence on their part, but certainly not an official statement of support. There's nothing I know of in that presentation that is explicitly unsupported, as we're just using standard configuration file settings.
We've worked with the docs team before to improve some of the content around SSL configuration, but I'm not sure if they want to just adopt it wholesale or not as the solutions in that talk are certainly opinionated.