By Splunk October 22, 2014
By now you are probably tired of seeing poodle memes. Fear not! Instead, I will share mitigation techniques on how to protect Splunk against this attack and leave out the memes.
Let me preface the different techniques by adding some context to the exploitability of POODLE: This attack requires that an attacker have MITM (Man In The Middle) access to your communication between the client and Splunk. This is a important point to keep in mind when considering different mitigation techniques and their aggressiveness. I mention this because many of you do not have your Splunk deployment exposed to the internet architecturally, or require VPN access to your corporate network before a client can access Splunk. This reduces the risk of exploration from a malicious outsider. Of course, if an attacker has MITM access and is decrypting VPN communication, you have a bigger issue to consider!
Mitigation Techniques:
1. Place a reverse proxy in front of your Splunk deployment
This is Splunk’s recommended mitigation tactic and the best one I have seen yet. Configuring a reverse proxy (like nginx) on the same server that is running the Splunk search head is pretty straightforward and should be sufficient for most situations. This is well-documented and battle-tested. This addresses the web component of Splunk, which in most cases would be the primary attack vector for someone using POODLE. However, it does not address the indexer/forwarder component of Splunk. Although Splunk2Splunk communication does not “permit an attacker to generate the necessary arbitrary requests to execute an attack” it will still show up as vulnerable in vulnerability scans and such. To address this issue, I recommend looking into technique #2:
2. Force TLSv1.2 protocol on everything!
Another option is to configure web.conf in Splunk to only accept cipher suites that are TLSv1.2 compliant. How do you know which ciphers Splunk ships with that conform to TLSv1.2? Use the following command:
$SPLUNK_HOME/bin/splunk cmd openssl ciphers -v
and you should see something similar to:
Notice that there are two versions, SSLv3 (the one we are trying to avoid like the plague due to POODLE) and TLSv1.2. To force TLSv1.2 on the Splunk web component, set the cipherSuite setting in $SPLUNK_HOME/etc/system/local/web.conf as in this example:
[settings]
enableSplunkWebSSL = true
cipherSuite = TLSv1.2:!eNULL:!aNULL
supportSSLV3Only = False
For a more in-depth view into web.conf options please refer to the config docs:
http://docs.splunk.com/Documentation/Splunk/6.1.4/Admin/Webconf
In order to implement this on the indexer/forwarder, modify the $SPLUNK_HOME/etc/system/local/inputs.conf as in this example:
[SSL]
cipherSuite = TLSv1.2:!eNULL:!aNULL
Detailed example and in-depth explanation at http://docs.splunk.com/Documentation/Splunk/6.1.4/Admin/Inputsconf
This will force the indexer and forwarder to talk using TLSv1.2 supported ciphers. As an added benefit, vulnerability scanners will stop complaining about your Splunk instance being vulnerable to SSL exploits like POODLE.
There are a few issues with forcing TLSv1.2 on the Splunk web component. They present themselves in the form of compatibility problems with existing browsers. Only the latest Chrome and Safari share common ciphers with Splunk forcing TLSv1.2. Unfortunately, you will see an ssl_error_no_cypher_overlap error with the latest Firefox (Version 33).
If you force TLSv1.2, only Chrome and Safari will work out-of-the-box with Splunk! This means IE6-8 will not work. However, I have not yet tested IE 9 and 10 for compatibility. However, there is a third choice in which we do not have to pay the compatibility price. Refer to technique 3:
3. Upgrade to Splunk Enterprise 6.2
Splunk Enterprise 6.2 will be released October 28th and ships with features (splunkd proxy) that further facilitate mitigating openssl base attacks like POODLE.
On a side note, disabling SSLv3 in your browsers is a great way of tackling this vulnerability from the client side. The https://disablessl3.com/ has great instructions on how to do this in all the common browsers. I highly recommend approaching this from both angles; from the server side and client side. Another good resource for hardening SSL communication in Splunk is our hardening docs, and the Generating Elliptical Curve Certs blog post
Thank you @piebob(Rachel), Alex Eisen, Chris Green, Fred for helping me make this post cohesive and legible ;-). You are awesome!
----------------------------------------------------
Thanks!
Jose Hernandez