Securing the SplunkUF: ./splunk install app -auith

[Skeer-Jamf]

I'm creating an Ansible playbook for installing the UF in our org, and I discovered being able to use user_seed.conf for the initial --accept-license call, but now I am wanting something similar when running a subsequent ./splunk install app <path to SPL file> -auth <username:passwd>

Can I use the hashed password value here or maybe call the user_seed.conf file again?

Thanks!

[Skeer-Jamf]

Thanks Pickle.. So the idea here is that I'd like to keep a plain text password out of the playbook. Since I discovered splunk has a hash-password switch, and the user-seed.conf file I REALLY hoped that you could use one or both of those in other places.. not just the initial start + accept-license run.  Now, to be fair I could always, and will likely have to go the ansible vault route. But this is really disappointing as I had hoped to use something I bit simpler for this one-off playbook.

I'll probably toss in a support ticket too, just to be sure.

[isoutamo]

Hi

When we are talking about UF, I think that you have three options:

1. untar TA to .../etc/apps and restart
2. use ansible vault with no_log option on your tasks
3. setup DS and deploy configurations with it to UFs

As usually you must do the restart after change configurations on UF (like inputs, props etc.) this maybe the easiest and best way.

r. Ismo

[Skeer-Jamf]

Thanks Iso.. So in regards to Ansible the no_log is one thing. But I wanted to try to not have the local splunk user creds: --auth user:pass. 

Inside the playbook itself. I am now looking into ansible vault because.. I mean, we will need it later for other things so, why not? But being able to put an app file(s) into a sub-directory then bouncing the daemon sounds like an even easier solution.

[isoutamo]

Definitely that is the easiest way to do. Just remember to chown that directory and all files and sub dirs to user which are running splunkd on that node. Best practices is not to run it as root!

Splunk's own default way is use to DS (deployment server) to manage packages for most nodes (excl. Splunk clusters). But it's biggest issue is that it cannot install and do an initial configuration without an additional tool or a manual work. For that part, ansible is a great tool. But even if You are doing UF installation already with ansible, You should think if is ansible also that tool which you are using to manage UFs' configurations or should it be Splunk's DS?

r. Ismo

[PickleRick]

I know that deployment server is the "blessed" way of deploying apps but I don't like the idea of uncontrolled pushing of possibly any executable onto a remote computer and running it usually with quite high privileges (especially on windows, when it's quite typical to run UF with local system account).

[Skeer-Jamf]

In this case.. Infosec owns Splunk. I could go down the road of configuring rsyslog to send data to the heavy forwarder but I've found rolling the UF to be easier, and more reliable.

[PickleRick]

Really depends on your use case. Properly configured rsyslog can do wonders 🙂

[PickleRick]

You're mistaking two different uses.

In case of user-seed you can provide a hash because that allows you to provide an authentication mechanism without actually knowing the raw password value. That's why and how the password hashes are implemented in modern systems in the first place. You're not authenticating _yourself_. You're providing a mechanism the user will use to authenticate in the future.

But if you were providing such hash for authentication instead of password, it would make no sense and would provide no additional security because you'd be effectively providing a plain text password. It's just that it would not be easily intelligible.

Anyway, if you need the admin user/password just for deploying apps, remember that you can always simply unpack the app into $SPLUNK_HOME/etc/apps (and fix ownership if you're doing it as root)

[Skeer-Jamf]

That makes sense.. I am fairly new to Splunk in all aspects so I guess I might have assumed installing apps was.. idk, frequent, different,.. blah IDK what' sim saying now. But.. but I had no idea about your last sentence.. so I can what.. place the .spl into $SPLUNK_HOME/etc/apps and make sure the splunk user created when starting the daemon for the first time has rights and that's it?  So the install app really just does a copy/paste? lol

[PickleRick]

Close.

The spl file you're deploying are just tgz archives with another extension.  Sometimes the app files are named this way, sometimes the name simply ends with tgz but they really work the same way.

If you're installing an app for a single splunk instance, you can upload it via web interface or deploy it with a cli command but if you're managing a more distributed environment (have forwarders managed by deployment server or search-heads with apps pushed by deployer, or indexer cluster) you unpack the file, put the resulting directory into appropriate directory (like deployment-apps on deployment server) and configure proper application distribution. You can do the same with a single file (for example, I prefer to unpack the apps on windows forwarders manually - I hate working with CLI on windows).

Just as I said - remember about fixing ownership/perimssions. If the splunk instance you're deploying the app to runs - for example - with user "splunky", you have to chown the unpacked directory to this splunky user.

[Skeer-Jamf]

Hey Pickle.. So yeah exploding the SPL into the APPs dir, like i mentioned, is just beautiful. Works like a champ! The playbook is done and done thanks to you guys. Luckily, in my situation, we'll likely only ever have the one APP to install, a single ansible service account across all of our machines and.. we run primarily a Linux shop. 

Oh and with regards to rsyslog. I've got respect for it, but it's anything but friendly. 🙂

In either case.. much, MUCH thanks for the help!

[PickleRick]

The docs https://docs.splunk.com/Documentation/Splunk/8.2.4/Admin/GethelpwiththeCLI say username:password. Supposedly in plain text, there's not a word about providing hashed password. Which makes sense since many of the commands effectively run appropriate rest api calls.

Also remember that passing hashed password instead of plain text one wouldn't protect you from the authentication data leakage.

Anyway, of course, as with any other program which accepts user:password on cmdline, splunk might be (I haven't checked, to be honest and don't have any other instance than my home Splunk Free available for testing at the moment) susceptible to leaking authentication data provided this way by simply doing ps. I know that some programs are able to change their ps "appearance" to effectively mask the password but there's always the issue of shell history and such so it's worth exploring other forms of password input if possible.