How do I configure password protection for a deployment server and secure inputs for universal forwarders on VMs if the IPs change frequently?

[maciej_sawicki]

Hi,

I have Splunk Enterprise hosted on my Domain Controller, but in addition to that, I would like to collect data from some cloud machines.

I'm going to install a Universal Forwarder on those machines and open port on our edge firewall. The problem is that the cloud VMs' IPs will will change frequently.

I would like to protect my inputs (to collecting data only from trusted sources). Please let me know if this is possible and how to configure this.

The same question for deployment server.

[dwaddle]

There is no userid/password authentication for forwarders to indexers or forwarder to deployment server. What you can do, however, is use SSL certificate authentication. Each forwarder can have a client cert and use it to authenticate itself to the indexers / deployment server.

Examples of how to do this are in my .conf 2014 session slides -- http://conf.splunk.com/sessions/2014/conf2014_DuaneWaddleGeorgeStarcher_Self_UsingTrack.pdf

[Runals]

It sounds like what you are talking about is putting IP addresses in your serverclass.conf file as the whitelist parameters for particular stanzas that push out inputs. Is that correct? The way to solve that is to add a clientName string to the agent's deploymentclient.conf and reference that string in your whitelist. For example add the following do your agent installed in 'Cloud Land'

For server Foo

[deployment-client]
clientName = cloudland_imawindowsserver_foo

For server Bar

[deployment-client]
clientName = cloudland_imalinuxserver_bar

In your serverclass.conf file on your deployment server

[serverClass:all_cloudland_servers]
whitelist.0 = cloudland_*
[serverClass:all_cloudland_servers:app:stuff_common_to_all_cloudland_servers]

In your serverclass.conf file on your deployment server
[serverClass:all_cloudland_windows]
whitelist.0 = cloudland_imawindowsserver_*
[serverClass:all_cloudland_windows:app:cloudland_windows_inputs]

[serverClass:all_cloudland_nix]
whitelist.0 = cloudland_imalinuxserver_*
[serverClass:all_cloudland_nix:app:cloudland_nix_inputs]

You don't need to setup the clientname string exactly like that obviously but in managing about 3k agents like that I've found going from the least specific to the most specific is the way to go to include OS and hostname in your clientName strings. That allows you to quickly deploy packages to an entire group or just a specific machine.

Of course I could have totally misinterpreted your question lol.

[maciej_sawicki]

Thank you for answer Runals. If I understand your answer corrector this is still not an authentication and authorization solution. Client name can be sniffed or guessed (in case of SSL encryption) and then spoofed. Please let me know whether this is the case and if I am right I wold need to find another solution.

[Runals]

Ahh I see what you are asking now. Yeah depending on the scope of what you are including in authentication/authorization I'm not sure what options might be available. If you have a sales agent I'd bark up that tree to see what resources could be shaken loose to help answer your question. I know Splunk as a company uses a lot of off prem services so at some level they have likely had to solve for this issue at varying levels. In those cases though I think they leverage more APIs for data vs getting the logs from agents hosted in the cloud type of thing.