Is there any supported or recommended way to secure a deployment server and deployment clients to prevent man-in-the-middle (MITM) attacks?

[jtacy]

All, is there any supported/recommended way of preventing MITM attacks on deployment clients? Using the default certs, it seems like all it would take is DNS poisoning or other manipulation of an untrusted network to impersonate a deployment server and send arbitrary scripts to a universal forwarder (where they'll probably run as Local System or root). In a cloud or workstation deployment this is seems like a real-world concern.

The Avoid the SSLippery Slope of Default SSL presentation suggests using a custom CA and the sslCommonNameToCheck server.conf option to protect deployment clients, but the server.conf documentation for that option states that "This feature does not work with the deployment server and client communication over SSL." It seems to work for me but I'd be concerned that the feature could be unexpectedly broken in a later release since the behavior contradicts the docs. I'm curious what others are doing to protect themselves other than to avoid the deployment server. Thanks for any thoughts on this!

[fairje]

As of version 6.3:

It would appear that they have removed "This feature does not work with the deployment server and client communication over SSL" from the specification file as it relates to sslCommonNameToCheck, so this should be fine to use from now on at least according to the documentation.

[dwaddle]

Deployment server MITM protection was one of the driving factors behind that presentation so I totally agree as to the need for additional protections here.

I remember seeing something about this warning in server.conf when we were working on the slides for that presentation. As I recall, it seemed to work right during testing, so it's possible the docs aren't quite right. I will try to figure out exactly what's going on and update this.

[jtacy]

Thanks, Duane! Great presentation, by the way! The only problem we've noticed in testing is that the UF does not stop properly (at least on Windows) when the sslCommonNameToCheck does not match the cert presented by the DS. It hangs and chews some CPU for a while before it finally stops. In that sense it doesn't have a "solid" feel to it; I wonder if we should send a feature request for Splunk to build explicit support for this use case?